Foro de elhacker.net

Hola. Edito mi pregunta para ser más preciso: Mi duda es: Puede el compilador agregar algo "de más" entre variables de la stack???

Tengo un Tiny C Compiler, sin protecciones ni a nivel de compilador ni a nivel de Windows XP.

Puede ser que algo llamado "alignment" esté haciendo fallar mi exploit?? He enviado la cantidad de bytes necesarios para desbordar mi propio TCP server. Cuando el buffer destino es de 20 bytes, funciona. Pero si es de 60, no lo hace.

Y estoy enviando la cantidad de bytes necesarios para desbordarlos + la shellcode, así, que en teoría debería hacer lo que quiero, pero en la práctica salta hacia un ret addr extraño.

Adjunto links a un sitio de tipo pastebin, para no abrumar aqui en el foro.
Aqui les dejo mis codigos fuente:

Todos ellos funcionan si el buffer small es de 20 y el big de 30. Cambiando el valor de ambos por 60 y 120, no funcionan. Ahi están mis sources, por si alguien los quiere ver.

(Uso winsock2.h, si alguna cosa lo renombran sin el 2)

Mi TCP server (source escrito por mi)
http://tny.cz/2dc66ee0

Mi TCP exploit
http://tny.cz/dc9295ba

Mi shellcode
http://tny.cz/c4426347

Aqui está el programa objetivo, ya compilado, a peticion de un usuario. Para que no digan que es que uno quiero que resuelvan por mi.
https://drive.google.com/file/d/0Bxshgu4STp1aUXpsYmMySWhqS3c/view?usp=sharing

Gracias de antemano por su atencion.

¿Cual es tu pregunta?  :laugh:

Mi pregunta es: ¿Estará el compilador cambiando algo que afecte la posicion de las variables??? en la pila??

Estoy usando Tiny C Compiler sin proteccion alguna, en Windows XP.

Es como si ebp y eip hubiesen sido movidos. Sera que el alineamiento de las variables hara algun efecto??

Es un small buffer de 60 bytes, y luego uno de 120 bytes. El mas peque declarado primero, y luego el otro.

Editare el post si es necesario.

Perdón pero no entiendo... si aumentas el buffer que recibe, es lógico que no consigas el overflow... o me equivoco? No estás indicando justamente eso?

Hola amigos, disculpen por ser tan impreciso, (editare ahora la pregunta).

Digamos que tengo un buffer de 20 bytes. Ahi pongo la shellcode + los bytes basura.
Y tengo exito.

Pero si tengo un buffer de 60 bytes, y lo lleno con shellcode + los bytes basura necesarios para desbordarlo y todo eso, se desborda pero no con el dato que le quise cargar.

Es como si el buffer tuviera bytes "de más" o algo asi. No sé como explicarlo, pero así me parece que es. Adjuntaré los sources en un sitio de parecido a pastebin, para que lo vean (no uso pastebin porque en mi pais pareciera estar bloqueado...)

Gracias por su atencion, y ahora editare la pregunta.

Puede estar una cosa llamada "aligment" interfiriendo aqui?? Estoy leyendo sobre eso, pero no estoy seguro y no soy muy ducho en estos temas.

No entendi muy bien tu pregunta , si te referis a hacer overflow en big_buffer , viendo un poco el codigo:

while((ret = recv(from_client_socket, big_buffer, sizeof(big_buffer), 0)) > 0) {
        strcpy(small_buffer, big_buffer);
 

Creo que el big_buffer lo limitas como se debe hacer , entonces no podes desbordar nada.
Desbordas cuando haces el strcpy de big_buffer a small_buffer  sin comprobar el tamaño.

Lo mire por arriba , posiblemente me equivoque.

Si tu problema es el calculo del buffer , desensambla el server y mira como lo ensamblo tu compilador , cuanto espacio va a reservar en el stack para esas variables , y luego calcula.

LORdP3I:
Si tienes razón en decir que solo se desborda con strcpy(...). Y lo hice así porque pensé que sería más fácil de depurar con Olly si usaba un TCP.

Encontré algo curioso: He intentado variar un poco la shellcode, y depende de lo que sea funciona o no. No sé si esto tendrá que ver con el alignment. Solo le agregue una instruccion más, y dejo de funcionar. Estoy rellenando con basura hasta sobreescribir EBP, y poner EIP con mi valor deseado.

(Hecho con Flat Assembler)

Shellcode que NO funciona. (21 bytes)

use32
 
mov eax, 0xDEADBEEF
mov ebx, 0xDEADBEEF
mov ecx, 0xDEADBEEF
mov edx, 0xDEADBEEF
int3
 
 

Shellcode que si funciona: (15 bytes)

use32
 
mov eax, 0xDEADBEEF
mov ebx, 0xDEADBEEF
mov ecx, 0xDEADBEEF
int3
 
 

He hecho todo lo posible para hacer funcionar la que es un poco más larga, pero no deja de falla. No sé si tendrá que ver con los bytes que contiene la shellcode 2, pero la revisé no hay ningún nulo por ahí. En teoría debería funcionar.

Será que habrá otros caracteres que puedan detener strcpy??? Revisé y no hay nulos allí, no sé si habrá otro que interfiera.

Estoy en proceso de entender la parte en donde reserva espacio en stack, pero el codigo es un poco largo y no lo encuentro. Supongo que sería un sub esp, x bytes, o no???

Bueno, espero su respuesta. Seguiré leyendo sobre como sacarle provecho a Olly en encontrar subrutinas.

No deberia ser muy dificil :
.Rastrear el call a vulnerable()
Vas a ver :
.Prologo(Para crear el stack frame)push ebp mov ebp,esp
.Reseva espacio(Quizas alinea antes para que sea mas eficiente el proceso de lectura de memoria)sub esp,0xALGO
.Acciones que hace vulnerable()
.Epilogo(Libera argumentos si es que tiene(debido a la convencion de parametros) , vuelve a main)

Si tu shellcode no tiene bytes null , no deberia suceder nada raro con ella.
Partiendo de la premisa que tenes espacio para ella.
Si no tenes espacio , ya tenes que recurrir a otras tecnicas.(egg hunting).

En fin , debe ser que el compilador te esta alineando para que sea mas veloz la lectura de datos en memoria.Si bien recuerdo el parametro -a te permitia configurar el alignment.Pero es buena practica fijarse en el olly o en algun desensamblador(IDA), ver como lo alineo, ya que si te dan el binario y no el source , ¿como haces?

Perdona mi ignorancia , no soy de explotar mucho en windows.

LORDPEI:

Oye, he estado tanteando y encontré que el programa reserva 280 bytes de stack, aparentemente (tomando tal cual el valor que me dio Olly, que no sé realmente si es decimal o hexadecimal). Pienso yo que está bien, aunque me costóp un poco seguir la subrutina.

Bueno, pareciera ser el alignment: ¿Puedes ayudarme a lograr que mis shellcodes no fallen por culpa de esto?? Reemplaze las 'A' de relleno por NOPs, pero igual.

Hice un cambio en la shellcode, agregando unas cuantas instrucciones, y funciona. Pero pareciera depender del tamaño de la shellcode: Hice una de 26 bytes, y funciona. Hice otra como de 15 bytes, y funciona.

Pero una de 21 bytes, y no funciono, saltando a una direccion rara que no tengo ni idea de donde salió.

Es como si el "tamaño" la afectara. ¿Como puedo lograr que la shellcode se ejecute bien a pesar del tamaño??? No puedo andar modificando el programa vulnerable, porque si fuera uno real no puedo.

He mirado lo que he hecho, y pareciera estar bien: Rellene con basura hasta alcanzar el limite, hay espacio suficiente, cargue bien la shellcode y la envié...Pero nada.

Importante:
Estoy usando FASM como ensamblador, y Tiny C Compiler. No sé si eso puede afectar, aunque lo compile con GCC e igual falla.

Gracias por tu ayuda, perdona por el mensaje extenso.

Puedes subir el programa compilado? el que hay que explotar? saludos

OK. Lo vas a revisar?? Bien. Bueno, ahí te lo envío.

Lo puse en Google drive

https://drive.google.com/file/d/0Bxshgu4STp1aUXpsYmMySWhqS3c/view?usp=sharing (https://drive.google.com/file/d/0Bxshgu4STp1aUXpsYmMySWhqS3c/view?usp=sharing)

Pensaba pornerlos en uno de esos sitios anonimos, pero tienen virus. Mejor que lo haya puesto en Google drive, o no??

Mientras tanto seguiré leyendo por internet a ver si consigo cuál es el problema.

Gracias por tu ayuda.

hola harry_the_blogger, mmm te lo van a bloquear desde gugl, por estar ya compilado... alguna cuenta en mega u otro servicio podría ser. saludos

(agrego) tal como te indicaba harry_the_blogger, el enlace no esta disponible:
(http://oi59.tinypic.com/351b8f4.jpg)

Gh057:

No sabrás alguna forma de hacer funcionar la shellcode?? Estoy trabajando en esto y me parece dificil. Ah, y en serio bloquean desde gogle??? Es un archivo que no está listado en internet, solo accesible por links.

No creo que cause algun problema, bueno, si alguna cosa más tarde lo actualizaré y subiré a Mega. Gracias por la advertencia. Puede el moderador bloquearlo?? Alguien me lo pidió.

Podrías subirlo a Mega no te aseguro nada pero quiero tener el ejecutable vulnerable compilado como lo tienes tú, quiero ver que puedo hacer (estoy muy oxidado en esta área y quiero retomar)

Saludos

Mismo por aqui.

logré explotarlo (de forma temporal sin anti DEP) ya que lo compilé con gcc para Windows pero cada compilador y dependiendo de su configuración de parámetros compila de forma diferente, por lo cual mi exploit es funcional en mi vulnerable.c compilado.

¿Podrías subirlo a Mega, mediafiare u otro uploader?

Saludos

https://mega.co.nz/#!utF2CDyD!FUKZQAX4xJG7b0Fov_4dOtj2ExvYwJG-hN2891wuu7c (https://mega.co.nz/#!utF2CDyD!FUKZQAX4xJG7b0Fov_4dOtj2ExvYwJG-hN2891wuu7c)

Aqui está. Disculpen por subirlo tan tarde. Aún no he podido encontrar la falla. Aquí está por si ha alguien le interesa. Gracias de antemano.

http://foro.elhacker.net/bugs_y_exploits/solucion_server_vuln_de_harrytheblogger-t428358.0.html