当前位置: 代码迷 >> 综合 >> (SEED-Lab)Buffer Overflow Vulnerability Lab缓冲区溢出实验
  详细解决方案

(SEED-Lab)Buffer Overflow Vulnerability Lab缓冲区溢出实验

热度:52   发布时间:2023-11-21 16:00:14.0

(SEED-Lab)Buffer Overflow Vulnerability Lab

欢迎大家访问我的GitHub博客

https://lunan0320.cn

文章目录

  • 一、实验目的
  • 二、实验步骤与结果
    • 2.1 环境初始化
    • 2.2 Task1 运行shellcode
    • 2.3漏洞程序
    • 2.4 Task 2
    • 2.5 Task 3: ASLR
    • 2.6 Task 4: Stack Guard
    • 2.7 Task 5:不可执行栈
  • 三、参考文献

一、实验目的

  1. 理解缓冲区溢出攻击的原理以及如何实施攻击
  2. 理解针对缓冲区溢出的防御措施。

缓冲区溢出介绍: 缓冲区溢出是指程序试图向缓冲区写入超出预分配固定长度数据的情况。这一漏洞可以被恶意用户
利用来改变程序的控制流,甚至执行代码的任意片段。出现此漏洞的原因是数据存储区(例如缓冲区)和
控制存储区(例如返回地址)的混合:数据部分的溢出会影响程序的控制流,因为溢出会改变返回地址

二、实验步骤与结果

2.1 环境初始化

首先是取消地址空间布局随机化ASLR机制
在这里插入图片描述
接着是配置/bin/sh,将/bin/sh切换到一个没有防御机制的/bin/zsh
在这里插入图片描述

2.2 Task1 运行shellcode

call_shellcode.c代码如下
在这里插入图片描述
编译call_shellcode.c文件,此处需要注意的是需要设置栈可执行条件。成功编译后可以看到文件夹中多了call_shellcode的可执行文件
在这里插入图片描述
运行call_shellcode的可执行文件,可以看到,首字母为 $ ,/bin/sh链接的是zsh,并且能够在这个shell中成功执行ls命令。
说明已经成功使用汇编版本的shell code重写了缓冲区,并且登录了shell,拿到了这台机器的使用权。
在这里插入图片描述

2.3漏洞程序

漏洞程序的编译。stack.c是需要使用的漏洞程序,基于利用缓冲区漏洞,在栈中执行代码以获取shell 的目的,因此,必须先设置栈为可执行,因为gcc默认为不可执行栈。其次是因为GCC针对缓冲区溢出的保护机制,因此,需要关闭此保护机制:-fno-stack-protector。
在这里插入图片描述
除此之外,还需要设置Set_UID程序,与之前的实验类似,设置该程序为Set_UID程序,有效用户为root。可以看到,成功设置了stack有效用户为root的可执行程序。

2.4 Task 2

使用gcc命令编译调试stack.c程序,使得其输出为stack的可执行文件。此处在编译的时候需要注意的是,因为需要利用缓冲区漏洞执行shellcode,所以需要设置栈可执行。
因为gcc自带的保护缓冲区溢出攻击的机制,因此需要设置取消这个栈保护机制。成功编译后可以看到stack文件。
在这里插入图片描述
除此之外,设置地址空间布局随机化。
在这里插入图片描述
此时,对stack可执行程序使用gdb调试工具调试
在这里插入图片描述
在main函数处设置断点,运行到断点处,查看此时str的地址
在这里插入图片描述
在这里插入图片描述
运行到断点处停下后,查看此时main函数的反汇编结构。可以看到,图中红框中内容即为参数str入栈的过程,str是从badfile文件中读出的517长度的字符串,根据反汇编代码得出str位于ebp-0x211的位置。
在这里插入图片描述
在这里插入图片描述
直接查看str在内存中的位置,这个位置即是badfile传入进去的首地址。
在这里插入图片描述
此时计划将shellcode的位置放在str字符串的150处,即从150处开始覆盖。得到shellcode在内存中的位置是0xbfffebdd,这就是函数strcpy()的返回地址的新地址。需要将返回地址设置为这个地址,即让返回地址指向shellcode代码,程序返回后即可成功执行。
在这里插入图片描述
此时,需要找到的是函数strcpy()的返回地址,因此,需要对函数bof()的汇编代码分析。
根据参数的入栈规则顺序,参数buffer是在call之前最后入栈的,因此ebp-0x38就是参数buffer的地址。
在这里插入图片描述
因此,在计算返回地址的时候,只需计算出ebp的地址,然后+4即可(此处+4是因为返回地址在ebp上方4字节处)。
在这里插入图片描述
计算ebp的地址,再根据strcpy()函数的复制作用,即是在bof中的buffer+0x38,也就是str+0x38。
此处的str也即exploit.c文件中的buffer,所以在exploit.c文件中,计算得到的返回地址是buffer+0x38+0x4,即buffer+0x3c。
在这里插入图片描述
此处shellcode的定位,由上述可知,将shellcode定位到buffer+150位处即可。
在这里插入图片描述
exploit.c文件的补充如下。将shellcode放置到buffer之后150的位置,将返回地址改变位shellcode的位置。
在这里插入图片描述
编译并运行exploit.c文件,可以看到,成功生成了badfile的文件。
在这里插入图片描述运行stack程序,可以看到,成功启动了root shell,以#开头。使用id查看所有者,发现这个Set_UID程序的拥有者是seed,有效用户是root。使用whoami命令,查看当前用户权限。说明攻击成功!
在这里插入图片描述
但是上述攻击过程,其真实用户是seed,这会在运行时与真正的root权限不同。因此,我们需要继续提高权限,使之得到真正的root shell。
编辑setuid.c程序,即在得到的shell中运行此程序,使之能够设置当前用户为root,setuid(0),其中0表示的是root身份。
在这里插入图片描述
编译该程序,如下。
在这里插入图片描述
此时,重新执行stack程序,使之能够成功发起缓冲区溢出攻击,最终启动一个shell。查看此shell环境的真实用户为seed,有效用户为root。在这个新得到的shell中运行setuid程序,重新查看id,发现真实用户和有效用户均为root。此时便是获得了一个真正的root进程。
在这里插入图片描述

2.5 Task 3: ASLR

由于使用的linux32位系统,栈的基址空间只有2^19次,这使得可以通过暴力破解的方式进行攻击,即使此时开启了地址空间布局随机化ASLR技术,也完全可以在一定时间内完成攻击。
首先需要打开地址空间随机化技术ASLR,如图
在这里插入图片描述
尝试在打开地址空间布局随机化ASLR之后,运行stack程序,看是否可以攻击成功。可以看到,提示了段错误的信息,说明此时溢出攻击失败。
在这里插入图片描述
因此尝试在这种情况下,使用暴力破解的方法,使用脚本循环,攻击脚本script.sh如下:
在这里插入图片描述
接着运行exploit程序,输出badfile文件,继而通过bash shell运行脚本script.sh
在这里插入图片描述
在经过129748次尝试后,破解成功,得到了Set_UID程序的shell
在这里插入图片描述
与Task2同理,可通过setuid程序继续提高权限,拿到了真正的root权限的shell。
说明在地址空间布局随机化的情况下,使用暴力破解的方式,攻击成功!
在这里插入图片描述

2.6 Task 4: Stack Guard

首先需要关闭地址空间布局随机化ASLR技术
在这里插入图片描述
重新编译stack.c这个漏洞程序,使之能够启动栈保护机制(gcc 默认启动),输出可执行文件stack2
在这里插入图片描述
运行exploit程序,生成更新badfile文件,然后运行stack2程序(启动了栈保护的程序)。得到提示,stack smashing deteced 以至于中断了程序的运行
在这里插入图片描述
查阅资料后得知,stack smashing是一种gcc检测缓冲区溢出攻击的保护机制
在这里插入图片描述
也就是说,构造的缓冲区溢出攻击程序被检测出来,导致程序终止,无法攻击成功。缓冲区溢出,导致覆盖了ebp旁边的canary表指,而canary就是用来保护函数的返回地址的。
在更改返回地址的时候,需要用nop覆盖了返回地址之前的数据,也就覆盖了canary的值,而canary的值又是随机的,因此,很容易检查出缓冲区溢出。

2.7 Task 5:不可执行栈

首先设置取消地址空间布局随机化设置
在这里插入图片描述
重新编译stack.c程序,这个过程中,需要设置的是栈不可执行,noexecstack。显然此时再运行程序时候发现提示了段错误。这是正常的,因为取消了栈的可执行,因此缓冲区溢出的代码也是没有被执行的。
在这里插入图片描述

三、参考文献

[1] 缓冲区溢出-canary保护_Margin_51cto_51CTO博客
https://blog.51cto.com/u_11797152/2379735
[2]缓冲区溢出攻击 - Florian - 博客园 (cnblogs.com)
https://www.cnblogs.com/fanzhidongyzby/archive/2013/08/10/3250405.html

  相关解决方案