seedlabs_网络攻防技术_lab4
lab4 缓冲区溢出实验
一、实验要求
本实验旨在让学生通过实践应用课堂上所学缓冲区溢出漏洞的相关知识,并通过实际操作获得 firsthand经验。
缓冲区溢出发生于程序试图将数据写入预先分配固定长度缓冲区边界以外的情况。
恶意用户可利用此漏洞影响程序控制流并可能执行任意代码。
该漏洞由数据存储(如缓冲区)与控件存储(如返回地址)混合造成:数据部分溢出会改变系统的返回地址从而影响控制流。
本实验为学生准备了四台独立服务器每台运行一个带有所述漏洞的程序。
任务要求学生开发一个利用该漏洞攻击目标系统并最终获取这些服务器上的root权限。
此外还将研究几种针对这种缓冲区溢出攻击采取的有效防护措施。
学生需评估这些防护措施的效果并阐述其原因。
二、实验步骤及结果
task1: Get Familiar with the Shellcode
- 进入shellcode文件夹,修改shellcode_32.py ,使其能够删除文件

- 编译运行(需要先行创建一个tmpfile)

task2: Level-1 Attack
- 进入server-code文件夹,执行下列命令
make
make install

- 回到labsetup文件夹下,执行下列命令
dcbuild
dcup


- 保持上述终端窗口,另开一个终端到attack-code文件夹下执行下述命令
nc 10.9.0.5 9090
- ctrl+C终止后,可以看到server显示

- 修改exploit.py为下图

6. 注意要关闭ASLR(地址空间随机化),不然后面运行会失败
sysctl -w kernel.randomize_va_space=0

像这样两次输出一致且都是0xffffxxxx的形式就成功了

- 再根据ebp和buffer address计算ret和offset
ret = ebp + 8
offset = ebp - buffer address + 4 # 需要注意统一进制

- 运行exploit.py后,传输badfile,查看输出,得知成功运行

task3: Level-2 Attack
- 输入
echo hello | nc 10.9.0.6 9090,连接2号服务器
可以看到只提供了buffer address

- 根据文档可知offset范围为100~300

- 创建一个exploit2.py文件,并对其代码进行以下修改:因为offset未知,则采用循环方式进行测试。

4. 运行并传输文件,攻击成功

task4: Level-3 Attack
- 输入
echo hello | nc 10.9.0.7 9090,连接3号服务器
可以看到3号服务器使用64位系统,rbp就是上面的ebp

- 修改exploit3.py,注意shellcode部分使用shellcode_64.py中的代码
该寄存器的值由缓冲区地址决定。
计算偏移量时采用公式:offset = rbp - buffer address + 8。
具体来说:
- 首先计算rbp与buffer address的差值;
- 然后将结果加8得到最终偏移量。
需要注意的是:
- 在32位系统中整数部分为4;
- 在64位系统中整数部分为8;
- 所有数值均为十进制表示。


- 运行并传输文件,攻击成功

task5: Level-4 Attack
- 连接服务器
4号服务器与3号服务器相同,但是buffer size更小

2. 与task4原理相同,修改exploit4.py文件如下

- 运行后传输文件,成功

task6: Experimenting with the Address Randomization
- 开启ASLR,观察它是如何影响攻击的
sudo /sbin/sysctl -w kernel.randomize_va_space=2

- 向1号服务器和3号服务器发送hello信息,多发送几次,进行观察


为什么ASLR使缓冲区溢出攻击更加困难
内存地址随机化(ASLR)是一种内存保护机制,作为一种内存保护技术用于抵御缓冲区溢出攻击。该技术通过将攻击者在进行缓冲区溢出攻击时所使用的内存偏移量进行随机化处理,从而降低了攻击成功的可能性并增强了系统的控制流完整性。ASLR通过这种方式使得相关进程的内存地址变得不可预测,并因此增加了与这些进程相关的漏洞利用难度
通常普遍认可的是ASLR在64位系统上的应用效果更为出色。其主要原因在于64位系统相比32位系统具有更为宽广的内存空间
克服32位系统的ASLR
根据pdf给出的shell脚本进行循环攻击

攻击成功就会停下,理论上十分钟内能得到结果
但是我这里运行了16分钟、11万次都没有成功

task7: Experimenting with Other Countermeasures
a. Turn on the StackGuard Protection
访问server-code目录,并关闭gcc中的栈溢出保护功能(-fno-stack-protector)。然后对stack.c源代码进行编译,并以badfile作为输入文件进行链接连接。

可以看到检测到了 stack smashing
b. Turn on the Non-executable Stack Protection
进入 shellcode 文件夹,去除 -z execstack 编译 call_shellcode.c 并运行

可以看到,发生了segmentation fault,栈不可再用
