20145221高其_PC平台逆向破解_advanced

20145221高其_PC平台逆向破解_advanced

实践目录

• shellcode注入
• Return-to-libc 攻击实验

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模式，或许这种改进思路行不通吧~

参考资料

• 逆向及Bof基础实践说明
• Return-to-libc 攻击实验
• linux权限之setUID