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权限

思考

上面的一段话引自实验指导书，很显然，要么书中说的有问题，要么是哪里出了问题：

操作中的问题，编译哪里有漏掉吗？

SETUID的问题，是因为之前为

20145221retlib

程序开启了setuid吗？

sh版本的问题，实验楼中版本太老，不具有这个保护机制？

……

改进：在溢出区注入setuid（已取消前述中对retlib的setuid操作）

如前文介绍到，setuid可以使普通用户拥有root权限，所以在进入system之前，能否让程序调用系统函数setuid(0)来提升权限？

如前文，编译调试

20145221exploit

，查看setuid内存地址



将其地址注入到溢出区中，如下图所示：



修改完毕后，先运行攻击程序

20145221exploit

，再运行漏洞程序

20145221retlib

，查看结果如下：



很遗憾，相当的遗憾，花了一天的时间，最后还是没有没能让其进入Root模式，或许这种改进思路行不通吧~

参考资料

逆向及Bof基础实践说明

Return-to-libc 攻击实验

linux权限之setUID