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\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，查看机器代码：
在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);，打印缓冲区的位置，然后再编译运行：
后面的过程中应该也会出现该缓冲区的地址，我们让它以小端法显示：
这个时候我们攻击我们的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：