Mensajes

Sí, es posible lee sobre buffer overflows y todo su entorno

Lo has compilado sin protecciones? puedes checkearlo con este script http://www.trapkit.de/tools/checksec.html ./checksec.sh --file ejecutable

PD. Tienes dos epilogos de función seguidos y con esto con solo pisar un byte de EBP puedes explotarlo (a no ser que esté la cookie antes). Tienes que poner en EBP un address - 4 de la pila donde se encuentre el offset apuntando a la shellcode, porque al hacer pop %ebp, esp incrementa en 4. Un ejemplo en pequeño..

Epilogo ->  mov %ebp, %esp
                pop %ebp
                ret

Con el primer epilogo en pop %ebp, coges lo sobreescrito y con el segundo epilogo mueves ebp a esp. Espero que se entienda..

  shellcode            0xbfffff00                          ebp=0xbfffff04                      ret
+----------------+----------------------------------+---------------------------------+---------------+
  0xbfffff00             0xbfffff08                          0xbfffff0C

Comienza con Start y ve mirando la pila, esto empieza en el main, con step vas instruccion a instruccion,  a ver si lo sacamos..

(gdb) Start

(gdb) x/20x $esp

PD. Como segunda opción puedes poner un bp en gets y en el ret del gets y mirar la pila

(gdb) break gets
(gdb) disass gets
(gdb) break *address

Puede ser que haya una pequeña diferencia entre las direcciones dentro de gdb y fuera. A mi me pasó probando con kali linux. Puedes jugar con este código para ir testeando con gdb y sin él.

Código (asm) [Seleccionar] Expandir


int reg_esp ;

__asm__ __volatile__ ("mov %%esp, %0"  : "=g"(reg_esp));
printf("ESP value before function: %p\n", (void *) reg_esp);

premio();

__asm__ __volatile__ ("mov %%esp, %0"  : "=g"(reg_esp));
printf("ESP value after function: %p\n", (void *) reg_esp);


Otra cosa que puedes probar es poner un bp en gets() e ir mirando la pila.

¿No se supone que se busca un JMP ESP en una DLL? Las DLLs no cambian su código :S...

Me refiero a que un push esp ret es también válido.

Imagina que hago un findjmp.exe kernel32.dll esp
Y me da una dirección, y con esa dirección hago un exploit y EIP tendría que apuntar a esa dirección, pero EIP resulta que apunta a otra.

Tienes que cuidar que el ret en la pila sea esa dirección.

Pero pueden tener programas antiexploits y tú no tienes forma de saber cuáles son, o un firewall, y hay muchos firewalls. Yo mismo tengo más de 1 firewall activo.

Programas antiexploits, pueden haber si, tendrás que atacar por otro lado si se diese el caso :/ los firewall son otro tipo de protecciones que también te impedirian pero si por ejemplo tu explotas un navegador haces una conexion inversa y depende de como este configurado el firewall dejará pasar la conexión.  

¿Qué me dices de la imagen?

No sé que contestarte, pero todo apunta a un final de cadena..

¿Se puede evitar que pete un programa por haber ejecutado un exploit?
Básicamente... Lo que haces con los JMP registro es saltar al stack (la RAM) y ejecutar ese código, ¿no?

Se podria evitar si, un ejemplo http://vimeo.com/25200425 y si, salta al espacio del stack y se ejecuta el código.

El código ensamblador está en el disco duro y el .data en la RAM, ¿no?

El programa entero está cargado en la RAM de una manera virtual y en el disco duro estará en modo fisico (para que me entiendas pero se dice al revés)

Acabo de terminar el paper de Rojodos, y me sale todo bien, pero el offset de jmp esp en kernel32.dll cambia nada más ejecuto algo, y así es imposible ejecutar system(), porque cuando ejecuto el exploit cambia el offset (en msvcrt.dll no tengo ningún jmp, y antes de suspender el portátil tenía calls, y ahora tengo push esp ret, eso es posible, ¿no? xD).

Sí.

Otra cosa, en el paper de Rojodos, cuando introduzco AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPPQQQQRRRRSSSSTTTTUUUU => EIP=TTTT, ESP=dirección que contiene UUUU, pero ESP != UUUU
En cambio, con el código de Rojodos a EBP sí puedo ponerle que apunte a 414141 por ejemplo.
Pero ESP no apunta (sólo contiene) y si uso JMP ESP, salta a la shellcode. Me ha parecido extraño. ¿Y eso?

ESP es una dirección de la pila y lo que contiene es lo que tu le metes a través del overflow si le metes UUUU la dirección de ESP contendrá UUUU. La verdad no te entiendo bien esta pregunta a que te refieres.

Por cierto, se dice que no hay que sustituir el EIP por una dirección de memoria, ya que cambia muy a menudo la pila.
Vale, eso lo entendería, pero si los Arguments que pongo antes del EIP son carácteres y siempre van a ser los que ponga en la pila... ¿por qué la dirección que ponga como EIP, que al fin y al cabo introduzco 4 bytes igualmente, cambia a la que yo puse?

Lo que metes en la pila por el overflow no cambia, lo que cambia es el address del jmp esp en la dll en cada service pack (actualizaciones) o cada vez que inicia windows (Aunque en XP no viene implementado, lo verás cuando te toque bypassear ASLR)

Me da la sensación que según qué compilador, qué protección de software, la ruta que habrá usado un servidor, cambia el exploit, y aunque esté claro el PoC, hacer un exploit funcional en un sistema remoto puede no funcionar aunque sepas mucho...

No creo que hagas un exploit para atacar a ciegas, si no testeando en el software vulnerable antes, que ya ha sido compilado y se ejecutará con las mismas protecciones en todos los SO familia windows por ejemplo (No sé si me explico). Por lo tanto si será efectivo.

Y qué decir... ¡Muchísimas gracias! Voy a seguir investigando en estos temas que son muy interesantes .

De nada tiuuu!! Dale duro si que lo son

[lo ocupa una 'A']

1. ¿Por qué si MyVar necesita 128 bytes, Dev-C++ reserva 98? (sub esp,98) [Página 14]

128 bytes en decimal, 98 en hexadecimal = 152 bytes

2. En teoría, si ejecuto el exploit, éste se mete en la pila hacia abajo, pero en la imagen tengo que se mete hacia arriba de la pila (los 41 deberían estar donde están los 43 y viceversa):

Es posible que se haya usado la variable de las Aes anteriormente y por eso lo tengas así. No se meten hacia arriba.

Además, si strcpy termina en '\0', entonces 26074 As / 4 Bytes = 6518.5, y debería dar 6518.75, así está claro que el último byte es el carácter nulo, pero ese 0.25 que nos falta lo ocupa una 'A'

¿Qué ocurre?

¿Podrías enseñar esa zona de la pila?

PD. No vas a terminar el otro?

[Dudas referentes al exploit:]

Vaya parece que son 80 Aes para pisar el return en vez de 76 sorry, pon 80 y otra cosa que ha surgido en la lista crackslatinos y que puede ser esto. La cookie del stack. Pon un bp en IsDebuggerPresent y comenta si para ahi y después termina el programa, ok? Comenta después.

Dudas referentes al exploit:
Se sustrae a ESP 64 bytes
se pushea el ret address porque hemos llamado a strcpy
; push ebp ; Esto no interviene
; mov ebp,esp ; Esto no interviene
Se van metiendo en la pila las 76 As. Si lo compilo con MCV++ se meten hacia abajo, ¿no?

Si, se meten hacia abajo en el espacio que se reservó para el buffer.

Me refiero a que con gcc deberían meterse hacia arriba hasta un punto en que arriba se sustituye el ret address por lo que pongamos nosotros (que será un jmp esp)

No, no se pushean, se sobreescribe en el buffer.

Pero si "metemos", y no "pusheamos" los datos, por qué ESP apuntará a nuestra shellcode?  Porque se terminará alguna parte o algo, pero no termino de verlo.

La instrucción leave es la que se encarga de dejar todo "como estaba" y desapila el marco quedando ya solo el ret que ahí tendrás un return que apunta un jmp esp en la dll y ésta hará saltar a la shellcode. No sé si se entiende si eso vuelve a preguntar.

[76]

Me parece que te hacen falta 76 Aes justo para pisar el return, pruébalo y comenta el resultado, si te quita la función Aes de la pila etc. Paciencia ya saldrá.

De nada para eso estamos. Me refería a la pila no al desensamblado, me interesa más que enseñes la pila. Justo cuando te pares en la función strcpy antes de entrar saca imagen para ver el buffer disponible que te queda para pisar el return, etc..