20145221高其_PC平台逆向破解_advanced
20145221高其_PC平台逆向破解_advanced
实践目录
shellcode注入
概述
- Shellcode实际是一段代码（也可以是填充数据），是用来发送到服务器利用特定漏洞的代码，一般可以获取权限。另外，Shellcode一般是作为数据发送给受攻击服务器的。
- Shellcode是溢出程序和蠕虫病毒的核心，提到它自然就会和漏洞联想在一起，一般来说通过BOF漏洞，构造shell的地址来覆盖返回地址，达到调用shell的目的。
知识储备
- Linux下有两种基本构造攻击buf的方法：
retaddr+nop+shellcode，nop+shellcode+retaddr。因为retaddr在缓冲区的位置是固定的，shellcode要不在它前面，要不在它后面。一般来说，缓冲区小就把shellcode放后边，缓冲区大就把shellcode放前边。 ps -ef | grep xxx：将xxx进程按格式（-f）显示出来（-e）- 格式为：
UID PID PPID C STIME TTY TIME CMD
- 格式为：
- 相关BOF攻击防御技术：
root@KaliYL:~# execstack -s pwn1 //设置堆栈可执行
root@KaliYL:~# execstack -q pwn1 //查询文件的堆栈是否可执行
X pwn1
root@KaliYL:~# more /proc/sys/kernel/randomize_va_space
2
root@KaliYL:~# echo "0" > /proc/sys/kernel/randomize_va_space //关闭地址随机化
root@KaliYL:~# more /proc/sys/kernel/randomize_va_space //查看地址随机化状态，0关闭，2开启
0
- 在使用
exestack命令时，需要先安装：apt-get install exestack
动手实践
Step1
- 配置好注入环境：设置堆栈可执行，关闭地址随机化
Step2
- 构造要注入的
payload，采用anything+retaddr+nops+shellcode方式（需要先估计返回地址的位置，并且找到shellcode地址） - 可以使用
xxd来查看其内容，其中\x01\x02\x03\x04要填写返回的地址 
Step3
-
在终端注入这段攻击BUF：
(cat input_shellcode; cat) > ./20145221pwn1 -
20145221pwn1已经开始执行，此时打开一个新终端，查找20145221pwn1的UID -
-
找到UID号为：3527
Step4
-
通过GDB调试，打开GDB，对
20145221pwn1进行调试 -
-
对
foo函数进行反汇编，以此找到函数的返回地址，而我们要做的就是将返回地址覆盖，指向我们设置的shellcode代码 -
-
接下来我们在此处设置一个断点，用以调试进程，断点设置完毕后，在程序执行的终端按一下回车，开始执行程序（但程序会在断点处停止），此时查看esp寄存器情况
-
-
可以发现此时esp的值为
0x04030201，是我们构造的shellcode中的一部分，也就是说0x04030201所在的位置即是执行完foo函数后的返回地址，而接下来需要做的就是修改此处的值，使他指向shellcode的首地址 -
观察内存不难发现，shellcode的首地址在相对于前者偏移量为8的位置，所以其首地址为
0xffffd324，重新修改构造的payload如下图所示： -
-
攻击成功
小结
- 这次的实验相较于上一次，没有依赖程序本身的shell函数，而是通过构造一个shellcode，并将函数返回地址引向shellcode，才使得攻击可以成功，关键还是在于找到shellcode在堆栈段中的首地址，进而改变函数的返回值。
Return-to-libc 攻击实验
概述
- 缓冲区溢出的常用攻击方法是用 shellcode 的地址来覆盖漏洞程序的返回地址，使得漏洞程序去执行存放在栈中 shellcode。为了阻止这种类型的攻击，一些操作系统使得系统管理员具有使栈不可执行的能力。这样的话，一旦程序执行存放在栈中的 shellcode 就会崩溃，从而阻止了攻击。
- 不幸的是上面的保护方式并不是完全有效的，现在存在一种缓冲区溢出的变体攻击，叫做 return-to-libc 攻击。这种攻击不需要一个栈可以执行，甚至不需要一个 shellcode。取而代之的是我们让漏洞程序调转到现存的代码（比如已经载入内存的 libc 库中的 system（）函数等）来实现我们的攻击。
知识储备
- 输入命令安装一些用于编译32位C程序的东西：
sudo apt-get update
sudo apt-get install lib32z1 libc6-dev-i386
sudo apt-get install lib32readline-gplv2-dev
-
Ubuntu和其他一些Linux系统中，使用地址空间随机化来随机堆（heap）和栈（stack）的初始地址，这使得猜测准确的内存地址变得十分困难，而猜测内存地址是缓冲区溢出攻击的关键。因此本次实验中，我们使用以下命令关闭这一功能，关闭地址随机化：
sudo sysctl -w kernel.randomize_va_space=0 -
此外，为了进一步防范缓冲区溢出攻击及其它利用shell程序的攻击，许多shell程序在被调用时自动放弃它们的特权。因此，即使你能欺骗一个
Set-UID程序调用一个shell，也不能在这个shell中保持 root 权限，这个防护措施在/bin/bash中实现。 -
linux 系统中，
/bin/sh实际是指向/bin/bash或/bin/dash的一个符号链接。为了重现这一防护措施被实现之前的情形，我们使用另一个 shell 程序（zsh）代替/bin/bash。
动手实践
Step0
- 实验楼中的环境，用户密码为：
dees
Step1
- 配置32位运行环境，并把
sh指向zsh 
Step2
-
编写
20145221retlib.c，保存到/tmp目录下 -
代码托管链接：点击查看代码
-
编译该程序，并设置
SET-UID -
-
上述程序有一个缓冲区溢出漏洞，它先从一个叫“badfile”的文件里把 40 字节的数据读取到 12 字节的 buffer，引起溢出。fread()函数不检查边界所以会发生溢出。由于此程序为
SET-ROOT-UID程序，如果一个普通用户利用了此缓冲区溢出漏洞，他有可能获得root shell。应该注意到此程序是从一个叫做“badfile”的文件获得输入的，这个文件受用户控制。现在我们的目标是为“badfile”创建内容，这样当这段漏洞程序将此内容复制进它的缓冲区，便产生了一个root shell。
Step3
- 编写
20145221getenvaddr.c读取环境变量的程序，同样保存到/tmp目录下 - 代码托管链接：点击查看代码
- 编译一下：
gcc -m32 -o getenvaddr getenvaddr.c
Step4
- 编写
20145221exploit.c，保存到/tmp目录下 - 代码托管链接：点击查看代码
- 代码中
0x11111111、0x22222222、0x33333333分别是BIN_SH、system、exit的地址，需要我们接下来获取。
Step5
-
用刚才的
getenvaddr程序获得BIN_SH地址： -
-
gdb获得
system和exit地址，在调用打开文件后设置断点，并查看相应的地址： -
-
综合上述3个地址，将
20145221exploit.c进行修改 -
修改完毕后删除调试产生的
20145221exploit程序和badfile文件，并对20145221exploit.c重新编译
Step6
- 先运行攻击程序
20145221exploit，再运行漏洞程序20145221retlib，可见攻击成功，获得了 root权限： 
深入：将/bin/sh 重新指向/bin/bash
操作过程
-
操作步骤大体如上，只需在bin文件夹下删除sh，并让其指向bash：
-
-
结果如上图所示，很遗憾，在此条件下仍能取得root权限
思考
此外，为了进一步防范缓冲区溢出攻击及其它利用 shell 程序的攻击，许多 shell 程序在被调用时自动放弃它们的特权。因此，即使你能欺骗一个 Set-UID 程序调用一个 shell，也不能在这个 shell 中保持 root 权限，这个防护措施在/bin/bash 中实现。
- 上面的一段话引自实验指导书，很显然，要么书中说的有问题，要么是哪里出了问题：
- 操作中的问题，编译哪里有漏掉吗？
- SETUID的问题，是因为之前为
20145221retlib程序开启了setuid吗？ - sh版本的问题，实验楼中版本太老，不具有这个保护机制？
- ……
改进：在溢出区注入setuid（已取消前述中对retlib的setuid操作）
-
如前文介绍到，setuid可以使普通用户拥有root权限，所以在进入system之前，能否让程序调用系统函数setuid(0)来提升权限？
-
如前文，编译调试
20145221exploit，查看setuid内存地址 -
-
将其地址注入到溢出区中，如下图所示：
-
-
修改完毕后，先运行攻击程序
20145221exploit，再运行漏洞程序20145221retlib，查看结果如下： -
-
很遗憾，相当的遗憾，花了一天的时间，最后还是没有没能让其进入Root模式，或许这种改进思路行不通吧~
