64位Ubuntu系统下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的防御技术。
实验环境
- 虚拟机系统：Ubuntu 12.04（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
here: pop %rdi
xor %rax, %rax
movb $0x3b, %al
xor %rsi, %rsi
xor %rdx, %rdx
syscall
there: call here
.string "/bin/sh"
needle1: .octa 0xdeadbeef
");
}
- 无论我们的代码在内存中的哪个地方结束，call-pop指令都将使用“/bin/sh”字符串的地址加载rdi寄存器，接下来编译运行shell.c文件，成功获得了一个shell：
实践过程
-
我们先提取要注入的payload，查看机器代码：
-
在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!
", name);
return 0;
}
- 在Ubuntu系统上，有三种对策来保护堆栈，第一种是SSP，又名ProPolice，编译器重新排列堆栈布局，使缓冲区溢出不太危险，并插入运行时堆栈完整性检查；第二种是可执行空间保护（NX），当尝试在堆栈中执行代码时会导致分段错误；第三种地址空间布局随机化（ASLR），堆栈的位置每次运行都是随机的，所以即使我们可以覆盖返回地址，也不知道该放在哪里。
三种攻击尝试
第一种尝试
-
我们可以想办法绕过这些方法，使用gcc的-fno-stack-protector选项禁用堆栈保护，编译victim，然后使用execstack -s指令禁用可执行文件空间保护，发现提示没有安装：
-
安装完成之后，禁用可执行文件空间保护，然后在运行文件时禁用ASLR：
-
我们再在原victim.c代码的基础上加上一句
printf("%p ", name);，打印缓冲区的位置，然后再编译运行：
-
后面的过程中应该也会出现该缓冲区的地址，我们让它以小端法显示：
-
这个时候我们攻击我们的victim.c程序，可以看到攻击成功：
第二种尝试
-
接着，我们再通过一个例子来看看打补丁的重要性，在以前，我们可以通过查看/proc/pid/stat来读取任何进程的ESP注册表，但是这种漏洞很早就被修复了，我们假装目前在没有打补丁的系统上，先查看所有进程的esp：
-
我们先运行禁用了ASLR的victim程序：
-
再在另一个终端窗口查看victim程序的esp：
-
因此，当程序正在等待用户输入时，它的堆栈指针0x7fffffece8，我们计算从这个指针到名称缓冲区的距离：
-
现在重新运行启用了ASLR的victim程序：
-
我们查找victim进程的esp指针，然后添加上偏移量，就是上一步中运行victim程序的缓冲区地址：
-
接着用管道命令来进行演示：
-
在另一个终端中输入如下命令：
-
可以看到攻击成功，获取到了shell：
第三种尝试
-
先通过运行execstack -c指令重新启动可执行空间保护，此外，在ROP攻击中代码片段从可执行内存中挑选出来，例如，它们可能是libc的片段，所以我们还要通过locate指令找到libc的位置，如图所示，我们选择第一个：
-
我们希望执行
pop %rdi retq，而指向“/bin/sh”的指针位于堆栈的顶部。这将在推进堆栈指针之前将指针分配给rdi，相应的机器代码是两个字节的序列0x5f 0xc3，它应该在libc的某处发生。但是没有Linux工具能够直接在文件中搜索给定的字节序列，所以我们可以用下面的grep指令来实现检索：
-
在ROP中，以RET结尾的一系列指令称为gadget，如果我们用以下顺序覆盖返回地址：libc的地址+ 0x22a12；“/bin/sh”的地址；libc的system（）函数的地址，然后在执行下一个ret指令时，程序将弹出“/bin/sh”的地址到rdi，然后跳转到系统函数，我们就可以达到我们的目的。先输入如下指令运行禁用了ASLR的victim程序：
-
再在另一个终端中输入如下指令：
-
我们可以看到，libc被加载到从0x7ffff7a1a000开始的内存中，因此gadget地址是0x7ffff7a1a000 + 0x22a12，“/bin/sh”的地址我们之前已经找到了，是0x7fffffffed40，最后我们通过下面的指令来找libc的system（）函数的地址：
-
我们可以得到libc的system（）函数的地址是0x7ffff7a1a000 + 0x45730，最后将它们放到一起，成功得到了shell：
