Binary Exploitation (VIII): Solución Reto Sunshine CTF 2020 "speedrun02"

Continúo incluyendo las soluciones a retos de la categoría 'Binary Exploitation' de la competición Sunshine CTF 2020.

En esta entrada la solución al desafío que lleva por título "speedrun02", y que, en mi opinión, presenta un nivel de dificultad medio (★★★☆☆).

- Enunciado:

- Solución: Se proporciona un archivo ejecutable (chall_02) y lo primero que hago es ejecutarlo; incluyo una cadena larga ('AAA…A') y el programa finaliza:

Después, compruebo los mecanismos de seguridad del binario utilizando ‘checksec’:

Se trata de un binario de 32 bits y como se ve en la figura anterior NX está habilitado, por lo que ya sé que en el caso de que sea vulnerable a un desbordamiento de ‘buffer’ (en inglés, ‘buffer overflow’) no podré inyectar ‘shellcode’ en la pila (en inglés, ‘stack’) para ejecutarlo.

Decompilo el binario con ’Ghidra’:

 

Veo que en main() se utiliza fgets() en lugar de gets() lo que, en principio, evitaría un desbordamiento de ‘buffer’.

Sin embargo, también veo que se realiza una llamada a la función vuln():

Esta función utiliza gets(), por lo que es susceptible a un ataque de desbordamiento de ‘buffer’.

El ‘buffer’ tiene un tamaño de 54 bytes y, conforme al nombre de la variable local_3e en ‘Ghidra’, la dirección de retorno de la función se encontraría desplazada 0x3e (62) bytes desde la dirección de inicio del ‘buffer’.

Asimismo, veo que hay una función win() a la que no se llama nunca:

En esta función se realiza una llamada a system() con un argumento: iVar1 + 0x12e, pero: ¿Qué contiene iVar1? y ¿Qué se le pasa como argumento a system().

La función __x86.get_pc_thunk.ax() almacena en el registro EAX la dirección de la siguiente instrucción y, por tanto, en nuestro caso iVar1 contiene esa dirección, y a la función system() se le pasa como argumento la dirección contenida en iVar1 + 0x12e, que actúa como puntero al inicio de una cadena.

Utilizando ‘gdb’ veo que la dirección de la siguiente instrucción a la llamada a __x86.get_pc_thunk.ax() es: ’0x080484e2’:

Por lo que a system() se le pasa como argumento la cadena almacenada en la dirección ‘0x080484e2’ + ‘0x12e’ = ‘0x08048610’, y veo que el contenido de ésta es:

Teniendo en cuenta que el formato de almacenamiento es 'little-endian':

Con lo que la llamada a system() es realmente system(“/bin/sh”), lo que me permitiría obtener una ‘shell’ en el servidor.

Aún a riesgo de “meterme en un jardín” y como ejercicio, voy a intentar explicar lo anterior analizando el código ensamblador. Para ello, desensamblo la función win() utilizando ‘gdb’:

 La función __x86.get_pc_thunk.XX() - donde XX puede ser ax, bx, cx y dx -  almacena en XX la dirección de la siguiente instrucción a ejecutar. En nuestro caso al usarse ax la dirección de la siguiente instrucción a ejecutar (‘0x080484e2’) se almacenará en el registro EAX.

Cuando se ejecuta la siguiente instrucción (‘add $0x1b1e,%eax’) el registro EAX pasa a contener la dirección: ‘0x080484e2’ + ‘0x1b1e’ = + ‘0x0804a000’.

La siguiente instrucción (sub ‘$0xc,%esp’) reserva 12 bytes en la pila. Aquí cabe recordar, tanto que en la arquitectura de 32 bits los argumentos se pasan a las funciones a través de la pila, como que la pila crece de las posiciones más altas de memoria a las más bajas, razón por la cual para reservar memoria en la pila se resta al registro ESP (‘Extended Stack Pointer’), que apunta siempre a la cima de la pila (la última dirección de memoria ocupada por ésta).

La instrucción (‘lea -0x19f0(%eax),%edx’) carga en EDX la siguiente dirección efectiva: ‘0x0804a000’ – ‘0x19f0’ = ‘0x08048610’.

Después, mediante la instrucción (‘push %edx’) se almacena en la pila la dirección obtenida en la instrucción anterior, es decir: ‘0x08048610’, que será el argumento que se le pase a system(), y como ya hemos visto anteriormente esa dirección contiene la cadena “/bin/sh”, por lo que la llamada que se realiza es: system(“/bin/sh”), lo que, también como ya he dicho, me permitiría obtener una ‘shell’ en el servidor.

Por tanto, mi plan de ataque consiste en sobrescribir la dirección de retorno de la función vuln() con la de inicio de la función win(), con lo que se obtendrá una ‘shell’, se podrá buscar y ver la flag, y, en consecuencia, se resolverá este reto.

La dirección de inicio de la función win() se ve en la figura anterior, en el desensamblado de la misma, y es: ‘0x80484d6’.

Tal y como he dicho anteriormente, la dirección de retorno de la función vuln() se encontraría con un desplazamiento de 0x3e bytes desde la dirección de inicio del ‘buffer’, con lo que el tamaño del relleno de la cadena que debo incluir antes de la dirección de inicio de la función win() es de 62 bytes.

Ya tengo todo lo necesario para construir un pequeño ‘exploit’. Para ello, creo un ‘script’ en python que envíe 62 bytes (0x3e) de relleno y luego la dirección de inicio de la función win() (‘0x80484d6’), con lo que sobrescribiré la dirección de retorno de la función vuln() con la anterior, se bifurcará a la función win() y se abrirá una ‘shell’:

from pwn import *

payload = 'A' * (0x3e)

payload += '\xd6\x84\x04\x08'

p = remote('chal.2020.sunshinectf.org', 30002)

p.sendline('')

p.sendline(payload)

p.interactive()

Lo ejecuto:

A partir de que se abra la ‘shell’, lo único que queda por hacer es buscar la flag en el servidor. Veo que hay un fichero llamado flag.txt que contiene la solución a este reto: sun{warmness-on-the-soul-3b6aad1d8bb54732}