|
Título: Error en Buffer Overflow Publicado por: Lodos76 en 27 Febrero 2014, 17:43 pm Buenas gente.
Verán, estaba siguiendo el tutorial de Rojodos sobre buffer overflow (http://www.todopsp.com/foros/showthread.php?t=23953 (http://www.todopsp.com/foros/showthread.php?t=23953) , hay que darle a "Premum Download" y se descarga), y... claro, sé ensamblador y entiendo lo que dice, pero a la hora de poner muchas AAAAAAs (90 As por ejemplo) con el CMD y darle a "más detalles", el offset no es "41414141", y no entiendo el porqué. He probado a ejecutarlo en un Win8 físico y en una máquina virtual con WinXP Professional SP1 (que no tiene ni siquiera el DEP, al ser SP1), y a debuggearlo con OllyDbg 1.10 y con Immunity Debugger, pero me da el mismo resultado. En concreto, cuando intento debuggear con Olly sin argumentos, el exit code es 0, y cuando le pongo 90 As y le doy a F9 (run), el exit code es C0000409 He compilado el código fuente desde la consola de MVC++ 2005 (cl.exe /TC vuln1.c). Subo el ejecutable por si queréis echarle un vistazo: http://bayfiles.net/file/17EMR/HuI4La/vuln1.exe (http://bayfiles.net/file/17EMR/HuI4La/vuln1.exe) El código compilado es el siguiente: Código
He probado a seguir el tutorial de Coreland, y con el programa ya compilado del PDF nº 1 sí me funciona lo de modificar el EIP, pero si lo compilo yo no, y no sé por qué. Gracias de antemano :) Título: Re: Error en Buffer Overflow Publicado por: soez en 27 Febrero 2014, 22:16 pm Tienes que dar más datos, que observas en la pila, esta el buffer de Aes por algun lado? Pon un bp en strcpy y tracea.
Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 27 Febrero 2014, 23:01 pm Tienes que dar más datos, que observas en la pila, esta el buffer de Aes por algun lado? Pon un bp en strcpy y tracea. Vale, hay un problema aquí: Abro Olly Pongo 90 As y Restart A debuggear! (http://www.subeimagenes.com/img/1-859844.png) CommandBar -> BP strcpy (no da ningún error) Pero no encuentro por el ejecutable la llamada a msvcrt.strcpy o a user32.strcpy, en cambio, cuando compilaba con GCC (Cygwin) sí que me saltaba a una biblioteca suya y a la función strcpy. Pero bueno, vayamos a la ejecución de código: Le doy a run y sale esto (http://www.subeimagenes.com/img/2-859845.png), PUES NADA, a debuggear paso por paso. Sigo ejecutando y salen en la pila las As: (http://www.subeimagenes.com/img/3-859847.png) , sigo ejecutando y me encuentro con esto: (http://www.subeimagenes.com/img/4-859848.png), aunque luego en la pila sólo están las 90 que yo puse). Ya estoy más cerca. Pero sigo ejecutando y me encuentro con que ya no están en la pila las As (http://www.subeimagenes.com/img/5-859849.png) y con IsDebuggerPresent!! pues como no veo saltos condicionales después del call, sustituyo la función por NOPs y continuo ejecutando, y ahora se pushea el ExitCode y se llama a TerminateProcess, y finaliza con el ExitCode que posteé en la entrada del tema (C0000409), (http://www.subeimagenes.com/img/6-859850.png) Salu2 Título: Re: Error en Buffer Overflow Publicado por: soez en 28 Febrero 2014, 00:15 am Has pasado la función strcpy traceando? me parece que si, pon una imagen justo en el call del olly antes de entrar a la función strcpy.
Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 28 Febrero 2014, 10:31 am Has pasado la función strcpy traceando? me parece que si, pon una imagen justo en el call del olly antes de entrar a la función strcpy. Es lo que te comentaba, no aparece la función como una llamada, no sé si es que se implementa en el ejecutable como código o qué... Sólo he encontrado interesante la función kernel32.LCMapStringA. Click derecho --> Search for --> All intermodular calls Código: Found intermodular calls P.D.: He tenido que actualizar a WinXP SP3, aunque no importa, ya que el resultado es el mismo (las imágenes y todos los datos que he puesto son con el SP3). Título: Re: Error en Buffer Overflow Publicado por: soez en 28 Febrero 2014, 16:21 pm Tiene que aparecerte la función strcpy, mira en la pestaña B si tienes el breakpoint a strcpy. O si no search for -> names in all modules. Puedes enseñarme el call justo antes del 00401041?
Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 28 Febrero 2014, 22:59 pm Tiene que aparecerte la función strcpy, mira en la pestaña B si tienes el breakpoint a strcpy. O si no search for -> names in all modules. Puedes enseñarme el call justo antes del 00401041? Vaya, aparece :P. BP strcpy --> mirar Pestaña B Código: 7C90248D ntdll Always PUSH EDI Colocado :D Presiono run (F9) y --> exitcode C0000409, y termina el programa. Quizá alguna protección de software me lo bloquee... Click derecho --> Search for --> Name in all modules Código: 7C90248D ntdll .text Export strcpy Imagen antes del CALL 00401041 (http://www.subeimagenes.com/img/7-860833.png) Título: Re: Error en Buffer Overflow Publicado por: .:UND3R:. en 28 Febrero 2014, 23:03 pm En cuanto a la compilación, desactivaste GS?, DEP está desactivado para tal ejecutable?, desmarcaste todos los saltos de excepciones el el debugger?, ya que si no los quitas, el depurador intentará saltarlos y así no podrás percatarte de donde se ha producido el error (que valor toma EIP), más tarde le echaré una mirada, saludos.
Título: Re: Error en Buffer Overflow Publicado por: soez en 28 Febrero 2014, 23:14 pm Pon un bp en 00401032 y aprieta run y sacale imagen cuando pare. Te pongo aqui este ollydbg parcheado para que no detecte el IsDebuggerPresent (No me acuerdo si era el parcheado 4 o 5 si eso avisa) por ir eliminando posibilidades. Aunque este DEP activado debería parar en strcpy y ya después se ve. Si, deberias destildar todas las excepciones, puedes mirar la pestaña L log para ver que ha pasado también.
http://ricardonarvaja.info/WEB/OTROS/HERRAMIENTAS/L-M-N-O-P/Parcheado%204.rar Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 28 Febrero 2014, 23:17 pm En cuanto a la compilación, desactivaste GS?, DEP está desactivado para tal ejecutable?, desmarcaste todos los saltos de excepciones el el debugger?, ya que si no los quitas, el depurador intentará saltarlos y así no podrás percatarte de donde se ha producido el error (que valor toma EIP), más tarde le echaré una mirada, saludos. Whaaat? ¿Desmarqué? ¿Cómo hago todo eso? No me importa leerme todo lo que me pases, quiero aprender. He buscado por "desmarcar saltos debugger", "desmarcar jmp debugger" (también en inglés) y no sale nada que me pueda servir. Y perdón, ahora estoy en SP3, pensé que no se activaría solo... Ya está DEP desactivado. Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 28 Febrero 2014, 23:32 pm Pon un bp en 00401032 y aprieta run y sacale imagen cuando pare. Te pongo aqui este ollydbg parcheado para que no detecte el IsDebuggerPresent (No me acuerdo si era el parcheado 4 o 5 si eso avisa) por ir eliminando posibilidades. Aunque este DEP activado debería parar en strcpy y ya después se ve. Si, deberias destildar todas las excepciones, puedes mirar la pestaña L log para ver que ha pasado también. http://ricardonarvaja.info/WEB/OTROS/HERRAMIENTAS/L-M-N-O-P/Parcheado%204.rar Lo que no sé es por qué Olly no me coloreaba y marcaba dónde estaba la llamada a strcpy. Lo que me pediste: (http://www.subeimagenes.com/img/8-860849.png) He entrado al CALL y creo que hace un loop muchas veces para comparar muchas veces, y luego se va a IsDebuggerPresent y continua normal y tal, pero luego presiono run y me sale el exitcode C0000409 (termina), y la pila no la he visto con muchos 41414141 (no he visto ningún 41)... Título: Re: Error en Buffer Overflow Publicado por: soez en 28 Febrero 2014, 23:39 pm Con paciencia, tienes que parar justo cuando en la pila te salga algo asi ojo lo estoy poniendo a boleo pero es algo así, saca imagen.
| call to strcpy | src = 00331274 | dst = 0012FF28 He visto en tus imagenes que el buffer se ha copiado con exito en la pila asi que habrá pasado por ahí, aunque que no te pare en strcpy al darle a run me parece muy raro. Puede ser que no te este marcando strcpy por tener alguna opción desactivada.. Título: Re: Error en Buffer Overflow Publicado por: .:UND3R:. en 1 Marzo 2014, 00:01 am Whaaat? ¿Desmarqué? ¿Cómo hago todo eso? No me importa leerme todo lo que me pases, quiero aprender. He buscado por "desmarcar saltos debugger", "desmarcar jmp debugger" (también en inglés) y no sale nada que me pueda servir. Y perdón, ahora estoy en SP3, pensé que no se activaría solo... Ya está DEP desactivado. Que felicidad, leer eso. Para colorear, debes hacer clic derecho e ir a Aparence, luego en hightlight poner light jumtp and calls, no recuerdo muy bien, en cuanto a las excepciones debes irte a options, debugger optiones y dentro de esta opción te vas a la pestaña Exceptions dentro de ella deberías destildar todo, aunque precisamente es Memorya access violation, ya que es esa excepción la que se genera al sobre-escribir el EIP. Deja terminar una parte del tutorial de corelan (estoy estudiando al igual que tú, en realidad repasando pero a full) e intento ayudarte, saludos. Título: Re: Error en Buffer Overflow Publicado por: soez en 1 Marzo 2014, 00:11 am aunque precisamente es Memorya access violation, ya que es esa excepción la que se genera al sobre-escribir el EIP. +1 Título: Re: Error en Buffer Overflow Publicado por: .:UND3R:. en 1 Marzo 2014, 01:51 am Lo revisé y al parecer debe haber sido compilado con alguna opción extraña, no sé en realidad, cuando lo probé compilando con gcc sin nada extraño, funcionó sin problemas.
Nota: vuln1.exe tiene SafeSEH ON, aunque no debería afectar en nada ya que no estamos sobre-escribiendo el SEH. Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 1 Marzo 2014, 17:33 pm Primero que nada, muchas gracias por la ayuda que me estáis dando. Me quiero dedicar a la seguridad pero nunca he podido completar ningún exploit por cosas de estas...
Hecho: 1. Jumps'n'calls coloreados (pero me refería a que no veía ningún call que ponga a la derecha strcpy funtion, como pasa con las otras funciones de las DLLs de Windows). 2. Destildadas todas las excepciones (sólo tenía tildada la opción "ignore memory access violations in KERNEL32"). ¿Compilado con alguna opción extraña? Qué raro... sólo lo compilé como código C (cl.exe /TC vuln1.c). Aunque con gcc creo que va bien, el problema es compilar con MCV++. Respecto a esto: Código: | call to strcpy Bueno, abro vuln1.exe en el OllyDbg parcheado contra IsDebuggerPresent, pongo un breakpoint en strcpy y F9. Vale, ahora se detiene el programa en: 00401032 - CALL 0040150 F7 (entro en el CALL) Ejecuto algunas instrucciones y entro en el bucle donde se copian los carácteres (podríamos decir que está ejecutando la función strcpy) Ejecuto unas cuantas veces el bucle y esta esto es lo que veo (http://www.subeimagenes.com/img/9-861280.png) Continúo ejecutando el bucle --> Continúa sobreescribiéndose la pila Continúo ejecutando el bucle hasta el JE SHORT 004010E9 que esta vez NO coge, y si yo he introducido 90 As, en la pila veo 22 valores 41414141 en la pila (aunque 90As/4Bytes=22.5 direcciones con 41414141, no sólo 22, pero bueno). Imagen de donde me encuentro ahora: (http://www.subeimagenes.com/img/10-861281.png) Continúo ejecutando y ya se llena el 0.5 que faltaba en la pila (byte,byte,41,41). Me encuentro en 00401041 - CALL 0040120D Lo cojo! Entro al call a ver qué pasa ;) Veo muchos MOVs de registros a direcciones que me quitan mis 41414141 de la pila, sigo ejecutando, hago un F8 (ejecutar sin entrar) al CALL de IsDebuggerPresent y sigo ejecutando instrucciones. Bien, me veo un CALL, y después POP ECX y PUSH 0, luego SetUnhandlerExceptionFilter, luego UnhandledExceptionFilter,ExitCode=C0000409, luego GetCurrentProcess y TerminateProcess, así que entro a ese call a ver qué pasa. Ese CALL contenía un AND y una instrucción RET, pues nada, sigo ejecutando y termina el programa. ¿Y ahora qué? :/ Título: Re: Error en Buffer Overflow Publicado por: soez en 1 Marzo 2014, 18:49 pm De nada para eso estamos. Me refería a la pila no al desensamblado, me interesa más que enseñes la pila. Justo cuando te pares en la función strcpy antes de entrar saca imagen para ver el buffer disponible que te queda para pisar el return, etc..
Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 1 Marzo 2014, 20:40 pm De nada para eso estamos. Me refería a la pila no al desensamblado, me interesa más que enseñes la pila. Justo cuando te pares en la función strcpy antes de entrar saca imagen para ver el buffer disponible que te queda para pisar el return, etc.. (http://www.subeimagenes.com/img/11-861398.png) Título: Re: Error en Buffer Overflow Publicado por: soez en 1 Marzo 2014, 22:10 pm Me parece que te hacen falta 76 Aes justo para pisar el return, pruébalo y comenta el resultado, si te quita la función Aes de la pila etc. Paciencia ya saldrá.
Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 2 Marzo 2014, 17:37 pm Me parece que te hacen falta 76 Aes justo para pisar el return, pruébalo y comenta el resultado, si te quita la función Aes de la pila etc. Paciencia ya saldrá. Abro Olly parcheado Arguments -> 76As Restart Pongo un BP en el CALL a strcpy (00401032). Pero una pregunta, si yo hago Search for --> Name in all modules, busco strcpy y le pongo un breakpoint, me pone un breakpoint a 7C90248D, no a 0040120D. Entonces, ¿cómo supiste que tenía que hacer un breakpoint a 0040120D a partir del breakpoint a la otra dirección? RUN Entro al CALL strcpy y se pushea 0012FF1C - RET ADDRESS 00401037 Continúo ejecutando el CALL Se ponen todas las As en la pila y llego al JE SHORT que no coge el salto: (http://www.subeimagenes.com/img/12-862124.png) (http://www.subeimagenes.com/img/13-862125.jpg) Ahora llegamos a JE SHORT 00401140, y entro a ver qué ocurre dentro Ejecuto la primera instrucción, que era un MOV, y ahora los dos ASCII "AAAA..." que había en la pila tienen la misma longitud Ejecuto algunas instrucciones hasta llegar a una instrucción RET, entonces la ejecuto y el RET ADDRESS 00401037 se quita de la pila. Ahora estoy así: (http://www.subeimagenes.com/img/14-862126.png) Ejecuto ADD ESP,8 y desaparecen los dos ASCII "AAAA..." que había en la pila Entro al último CALL (CALL 0040120D), continúo ejecutando y llega SUB ESP,328 lo ejecuto y desaparecen todos los 41414141 de la pila :/ (http://www.subeimagenes.com/img/15-862127.png) Salimos del CALL y unos cuantos CALLs e instrucciones después salimos del programa con nuestro querido ExitCode C0000409 Título: Re: Error en Buffer Overflow Publicado por: .:UND3R:. en 2 Marzo 2014, 19:50 pm 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
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 Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 2 Marzo 2014, 21:18 pm 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 ;). Título: Re: Error en Buffer Overflow Publicado por: .:UND3R:. en 2 Marzo 2014, 21:59 pm 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 (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. Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 2 Marzo 2014, 22:09 pm 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. Título: Re: Error en Buffer Overflow Publicado por: soez en 3 Marzo 2014, 20:29 pm 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. Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 3 Marzo 2014, 23:57 pm 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): (http://www.subeimagenes.com/img/01-864113.png) 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
Título: Re: Error en Buffer Overflow Publicado por: .:UND3R:. en 4 Marzo 2014, 02:59 am 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
Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 4 Marzo 2014, 10:03 am 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. Título: Re: Error en Buffer Overflow Publicado por: soez en 4 Marzo 2014, 14:12 pm 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? Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 4 Marzo 2014, 23:22 pm Era hexa, qué fail ;D.
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í. (http://www.subeimagenes.com/img/01-864113.png) 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 :). Título: Re: Error en Buffer Overflow Publicado por: soez en 4 Marzo 2014, 23:48 pm 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). Sí. 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? ESP es una dirección de la pila y lo que contiene es lo que tu le metes a través del overflow si le metes UUUU la dirección de ESP contendrá UUUU. La verdad no te entiendo bien esta pregunta a que te refieres. 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 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) 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, hacer un exploit funcional en un sistema remoto puede no funcionar aunque sepas mucho... 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. Y qué decir... ¡Muchísimas gracias! Voy a seguir investigando en estos temas que son muy interesantes :). De nada tiuuu!! Dale duro si que lo son ;) Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 5 Marzo 2014, 02:26 am 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 Título: Re: Error en Buffer Overflow Publicado por: soez en 5 Marzo 2014, 03:13 am ¿No se supone que se busca un JMP ESP en una DLL? Las DLLs no cambian su código :S... Me refiero a que un push esp ret es también válido. 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. Tienes que cuidar que el ret en la pila sea esa dirección. 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. Programas antiexploits, pueden haber si, tendrás que atacar por otro lado si se diese el caso :/ los firewall son otro tipo de protecciones que también te impedirian pero si por ejemplo tu explotas un navegador haces una conexion inversa y depende de como este configurado el firewall dejará pasar la conexión. ¿Qué me dices de la imagen? No sé que contestarte, pero todo apunta a un final de cadena.. ¿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? Se podria evitar si, un ejemplo http://vimeo.com/25200425 (http://vimeo.com/25200425) y si, salta al espacio del stack y se ejecuta el código. El código ensamblador está en el disco duro y el .data en la RAM, ¿no? El programa entero está cargado en la RAM de una manera virtual y en el disco duro estará en modo fisico (para que me entiendas pero se dice al revés) Título: Re: Error en Buffer Overflow Publicado por: .:UND3R:. en 5 Marzo 2014, 06:47 am Creo que te estás enredando y confundiendo tu mismo, debes ir paso a paso y estas haciendo preguntas que con tu nivel de conocimiento, tanto una respuesta bien detallada te llevara a confundirte más y generará más preguntas, un círculo vicioso recursivo.
Yo no soy partidiario de que las cosas son así por que sí, pero intenta de buscar otro plan estratégico estás mirando desde abajo hacia arriba y te está cayendo mucho conocimiento desde el cielo, el cual no es necesario en este momento y solo te llevará a sentirte una hormiga que no sabe absolutamente nada. Debes entender lo siguiente, un desbordamiento de pila consiste en modificar el flujo normal de un programa a través de un código mal formado (para el programa) capas de modificar el Instruction Counter/Program Counter en Intel este valor lo posee un registro que se llama EIP. Para modificar EIP debes hacer que el programa recupere el valor de una CALL, ya que como te comenté cuando se llama a una CALL se debe dejar en la pila la dirección de retorno, o si no el programa nunca sabrá donde retornar una vez ejecutada las instrucciones de la call. Citar instruciones ... .. .. Call Sumar continuar. .. .. .. Sumar: guardaré los datos proporcionados para no perderme aquí se suma ahora debo volver recuperaré los datos proporcionados para devolverme a debo ir a continuar. Buffer Overflow Citar instruciones ... .. .. Call Sumar continuar. .. .. .. Sumar: guardaré los datos proporcionados para no perderme aquí se suma ahora debo volver recuperaré los datos proporcionados para devolverme a debo ir a "AAAAAAAA". Es una metáfora y debes tenerlo así mentalizado, no es el momento que aprendas los alineamientos, los marco de pilas, como se reserva espacio en el stack para trabajar con variables locales, etc. NO! Una vez que lograste modificar el PC, requieres redireccionar el programa hacia tu payload o código de carga que se encargará de hacer lo que tu desees, ¿en donde está?, en la pila, para ello debes utilizar instrucciones que se encarguen de direccionar el flujo hacia la pila, y aquí no es siempre JMP ESP, tal como comenta soez la limitación del salto hacia el stack es TU IMAGINACIÓN, no debes seguir al pie de la letra el tutorial, si no entiendes mucho está bien pero hay variables, partiendo por las direcciones de los SO Windows, por ello el tutorial es una referencia a como actuar. Código: JMP ESP Un poco de instrucciones. En Windows las direcciones de memoria varían de acuerdo a la versión del sistema operativo, esto provoca que si tomas una dirección de una API/función, lo más probable es que esta no esté. Aquí viene lo que se denomina instrucciones seguras o confiables y las no confiables. Si ignoramos todo mecanismo de protección, te recomiendo que utilices direcciones del programa, pero ¿cómo lo harás?, sencillo buscas las dll que hayan sido cargadas por el programa, inclusive el mismo programa podría ser utilizado, aunque no es muy recomendable a causa de que generalmente el ImageBase (dirección base de las dirección) contiene bytes nulos 0040xxxx por lo cual si estás explotando un buffer de string, estos se terminan con byte nulos, podría utilizarse si fuese el último parámetro en desbordar. Ahora estas direcciones no cambiarán ya que son direcciones del programa la única manera que cambie es que haya una actualización de esta de forma extrema, es decir cambiar casi todos sus módulos, etc, cosa que para ello deberías crear un nuevo explot, ahora que sabes que dirección es confiable y que no ya puedes usar un criterio. Ahora que JMP ESP no cambia, eso no se a que te refieres, las direcciones apuntan a instrucciones o buffer de datos, si estas direcciones son confiables, siempre deberían apuntar al mismo conjunto de instrucciones o buffer, por ello usar siempre direcciones del programa. Ahora hablemos de ASLR Address space layout randomization, esto modifica el Image Base siempre cuando el módulo lo permita si mal no me equivoco es una bandera 0x40 activada, que se activa con el compilador visual studio con un parámetro, no recuerdo exactamente, esto cada vez que se reinicie el equipo el Image Base se modificará por lo cual no podrás tener direcciones confiables, para ello como solución es trabajar con módulos sin ASLR, puedes usar plugins en el depurar que se encargan de listar las protecciones de compilación y enlace que poseen. Si todos los módulos están protegidos por ASLR, podrías basarte en la predicción del heap o montículo, esta técnica se llama heap spraying pero vez? no puedes aprender todo este en un simple post, debes leer y plantear tus dudas putuales del capítulo y toma sorbos de apoco quizás te termines quemando. Si tienes nuevas dudas, por favor hace un nuevo tema con la pregunta específica, este post solamente tiene un surtido de dudas que dificultan al lector. Duda nueva puntual, post nuevo puntual con la pregunta. Yo desisto de ayudarte más si no sigues las reglas que te he planteado a por cierto si no sabes ASM, no puedes aprender sobre exploit, sin tampoco decir que debes aprender Ingeniería inversa,ya que sin ella no podrás encontrar los fallos del programa y ataque remoto siempre se podrá si el puerto está abierto y es vulnerable, ahora el payload puede que sea detectado, esos sistemas de protección se llaman Antivirus y firewall, ahora pueden haber otros mecanismos que deben basarse en el análisis o comportamiento de un programa, pero desconozco sobre ellos. Si deseas aprender ensamblador hice un resumen hace unos años: http://www.mediafire.com/view/ijc4am0y48hbc4w/ASM.pdf (http://www.mediafire.com/view/ijc4am0y48hbc4w/ASM.pdf) Saludos Título: Re: Error en Buffer Overflow Publicado por: Lodos76 en 5 Marzo 2014, 13:54 pm 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
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: (http://www.subeimagenes.com/img/02-866366.png) ¿Y eso? |