Hackeado Herramienta Juaker
Hola a todos , primeramente les presumo que rediseñe el Blog Creando un Template al puro estilo 1337day jojojo, espero que les agrade , esta todo mas simple y solo tiene lo que se necesita, se aceptan sugerencias las cuales pueden hacer en el grupo de FaceBook :)
Bueno comenzemos con el Post:
Hace unas semanas se dio a conocer un articulo donde se presentaba un "0-day" en WinRar el cual permitia al atacante hacer una ataque de suplantacion, aqui la noticia.
En esta ocacion presentaremos un nuevo 0-day similar al de winrar que ayudara a los administradores a protejer sus sitios web en contra de los famosos escaneos de vulnerabilidades.
Muchos administradores de sitios web les diran que la mayoria de las exploraciones realizadas en contra de sus sitios se llevan acabo con herramientas automatizadas como son: Nessus, Acunetix, y Appscan.
El 0-day que aplicaremos y en el que nos enfocaremos hoy sera contra la herramienta de escaneo web mas popular de todo el mundo (dije popular , no dije que fuera la mejor) Acunetix.
El POC lo haremos con Acunetix 8 build (20120704), ya que esta fue la version mas crackeada y repartida por toda la web y la mas utilizada por hackers novatos que estan comenzando actualmente.
En este Post no solo se revelara una nueva vulneravilidad, si no que demostrare una persepcion totalmente nueva de tratar con ataques externos.
En lugar de estar protegiendo sus sitios web una y otra y otra vez o gastando su dinero en la compra de WAF (Web Application Firewall), vamos a darle a los atacantes una razon para tener miedo, y hacerlos pensar 2 veces antes de presiones el boton de "SCAN" :)
En este post no se los detallaren a full, a que me refiero? me refiero a mostrar a que no mostrare todos los escenarios de explotacion ni todos los sistemas operativos, pero si un decente POC que esperemos cresca en un nuevo esfuerzo de investigacion para las herramientas escaner de vulnerabilidades web.
Asi que manos a la obra !!
Acunetix es una poderosa herramienta para el análisis y la búsqueda de vulnerabilidades en sitios web.
Muchos atacantes novatos tienden a usar esta herramienta debido a la simplicidad de su uso.
Acunetix tambien ofrece a sus usuarios un simple escaneo que cubre muchos aspectos del análisis de vulnerabilidades.
Uno de los aspectos es la capacidad de escanear más dominios o subdominios relacionados con el sitio web escaneado.
Por ejemplo, si escaneamos mi blog "http://rootbyte.blogspot.mx/", obtendremos el resultado se muestra a continuación:
Después de investigar un poco acerca de esta opción, me di cuenta de que Acunetix inicia su asistente mediante el envío de una petición HTTP al sitio y muestra el resultado partir de la respuesta HTTP.
Además el asistente muestra los dominios relacionados externos, como las fuentes externas que utiliza el sitio, por ejemplo:
"
"
" "
Etc. ..
Un análisis detallado revela que si se utiliza una longitud mayor de 268 Byte’s o mas como nombre de dominio externo Acunetix se congela, por lo que si queremos provocar un accidente en el escaner de nuestro atacante lo único que tenemos que hacer es poner algún tipo de fuente externa en nuestro sitio, que tener la longitud de 268 bytes o más, por ejemplo:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA”>
Un vistazo rapido a esta aplicacion en el Inmmunity Debugger muestra que EDX se crasheo acausa de el fuzzing string que causo una violacion de acceso :D
A pesar de que la escritura corre sobre (SEH ) que probablemente se dará cuenta , mi consejo seria no ir por ese camino, creanme, lo intenté durante varios días y no tuve éxito (Debido al mecanismo SHE).
Sin embargo, tenemos otro problema con este exploit , y lo resumire en un apalabra: "ASCII" .
Acunetix obtiene su información sobre los dominios externos como una dirección URL.
Este hecho provoca que la cadena se convierte en explorador Web.
Mientras ASCII acepta caracteres como :
0x22 ( ") , 0x23 (#), 0x24 ($), 0x25 (%), 0x5C (\), 0x2F (/) y más ...
La cadena URL acepta sólo caracteres alfanuméricos imprimibles y "URL" convierte los caracteres especiales (pero con muy pocas excepciones).
Así que si mi fuente externa contiene uno de los caracteres especiales , que se convertirán en
"%RootByte".
Por ejemplo, el Char "comillas" (") se convertirá en 253.232 en la memoria porque es la traducción de 22 % .
Otro ejemplo que demuestra la codificación URL es: char "por ciento" (% ), que se convierte en 253.235 en la memoria.
Si quisieramos pasar por él tendria que ser mediante la construcción de un exploit que sólo contenga "AZ , az, 1-0 " y algunos caracteres especiales que no se conviertan en el proceso de URL ENCODE como:
" ! () = } {" .
(Y se los vuelvo a repetir; no es un trabajo sencillo :( )
En resumen, tenía que encontrar una manera de arreglar el flujo de la aplicación con el fin de evitar la SEH (debido a la imposibilidad de eludir la protección de seguro SHE con cadenas URL ASCII solamente).
En fin, por último , he encontrado una manera :D !!
Con el fin de fijar el camino, EDX se tuvo que ser sobreescrito con una legible dirección de memoria.
Sin embargo, es importante recordar que EDX jamas a sido utilizado como esto, pero menos 8.
MOVE ECX, DWORD PTR DS: [EDX-8];
Lo que significa que no importa qué dirección de memoria utilizemos, hay que añadir 8 a la dirección (en la explotación), convertir toda la dirección en imprimir String url, y esperemos lo mejor :)
Después de poco investigación (y mucho cafe) , encontré tal dirección.
La dirección estaba en "0x663030XX" y por suerte tenía la posibilidad de convertirse en el URL y sin malos caracteres especiales -> "F005".
Después de jugar con el código me encontré con que la ubicación exacta de ese EDX:
Así que por ahora nuestro exploit se ve así:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAA500fBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB”>
Puse a correr nuevamente el Acunetix con ese payload y este fue el resultado:
Como se podran ver arriba, la EIP se ha sobrescrito!
Parece que la idea de fijar el flujo se ha realizado correctamente, ya que me permitió estar en una mejor posición de ataque (Sobrescritura EIP)
Junto a ella, nuestro espacio potencial para el código shell se presenta ahora en EAX y ESP.
Cuando se trata de la decisión de la elección de ESP o EAX, ESP es la mejor opción a partir de dos aspectos diferentes:
1.- ESP está apuntando directamente al principio de la cadena.
2.- Hay un espacio mucho mas grande para un código shell.
Después de elegir ESP, necesitaba encontrar una instrucción de "JMP ESP" en una dirección de la memoria que pudiera escribir una cadena URL (ASCII limitada como menciónamos arriba).
La dirección deseada esta localisada: 0x7e79515d (SXS.DLL) – (EN ASCII) (“ ]Qy~ “).
Después de todo eso, nuestro código shell se supone que se veria así:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAA500fBBBB]Qy~BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB”>
500f = 0x66303035 : ubicación de memoria legible para la fijación del flujo de la aplicación que se ha dañado por el desbordamiento del búfer.
]Qy~ = 0x7e79515d (JMP ESP de SXS.DLL).
Bueno, en este momento estamos en la etapa semifinal, que ejecuta la aplicación en contra de la carga útil y que produce el siguiente resultado:
Genial !! aterrizamos exactamente en el inicio de la carga final.
El siguiente paso, será el uso del Windows shell adecuado, que se realizará sólo la cadena URL (ASCII limitada).
Dicha shell se puede generar con "Metasploit" y se llama "Alphanumeric Shell".
Lo importante a recordar durante el uso de tal carga útil, es que la dirección de inicio de la carga debe ser presentada en uno de los registros. Si la carga se presenta en el ESP, el primer código de operación de la shell tiene qué ser "PUSH ESP".
En mi prueba de concepto, usé simple "CALC.EXE" shell code generado por "Metasploit que me llevó a la etapa final que es, explotar!
Por otra parte, nuestra debilidad es sin pasar con éxito la protección DEP, simplemente seleccionando sólo las direcciones que no se compilan con DEP.
Y debido al hecho a que el propio Acunetix no cumple con el DEP, este exploit debería funcionar perfectamente en Windows XP (para varias jejejeje) .
Después de alcanzar con éxito todos nuestros objetivos, vamos a ver en el trabajo final :)
"XSS"
"CSRF"
Y así sucesivamente ...
Este tipo de nombres, probablemente llamaran la atencion del pirata informático.
El abajo esta el código escrito y demuestra lo engañoso:
.....................................................................
.....................................................................
...">
En conclusión,
Después de todo lo anterior, hemos creado una poderoso exploit que los hackers Newbie sin duda caeran.
Este exploit nos dará la capacidad de hacer todo contra los noobs que escanean nuestros sitios dia y noche, matando a nuestro tráfico o llenar todos los formularios del sitio web con pura basura y así sucesivamente ...
Además, puede ser utilizado con el fin de reunir información sobre las "fuerzas" hostiles que quieren atacar nuestra aplicación web.
PERO!
La más poderosa idea que me motivó a revelar este POC, es el hecho de que este exploit es como un poderoso Caza-noob! , Porque incluso si el atacante utiliza el mas seguro proxy en el mundo, como "TOR" aun asipodremos tener el pleno control de su máquina.
Gracias a todos por leer mi post, espero que les guste :)
PD
Aqui les dejo un video con un completamnete funcional esploit :)
Bueno comenzemos con el Post:
Hace unas semanas se dio a conocer un articulo donde se presentaba un "0-day" en WinRar el cual permitia al atacante hacer una ataque de suplantacion, aqui la noticia.
En esta ocacion presentaremos un nuevo 0-day similar al de winrar que ayudara a los administradores a protejer sus sitios web en contra de los famosos escaneos de vulnerabilidades.
Muchos administradores de sitios web les diran que la mayoria de las exploraciones realizadas en contra de sus sitios se llevan acabo con herramientas automatizadas como son: Nessus, Acunetix, y Appscan.
El 0-day que aplicaremos y en el que nos enfocaremos hoy sera contra la herramienta de escaneo web mas popular de todo el mundo (dije popular , no dije que fuera la mejor) Acunetix.
El POC lo haremos con Acunetix 8 build (20120704), ya que esta fue la version mas crackeada y repartida por toda la web y la mas utilizada por hackers novatos que estan comenzando actualmente.
En este Post no solo se revelara una nueva vulneravilidad, si no que demostrare una persepcion totalmente nueva de tratar con ataques externos.
En lugar de estar protegiendo sus sitios web una y otra y otra vez o gastando su dinero en la compra de WAF (Web Application Firewall), vamos a darle a los atacantes una razon para tener miedo, y hacerlos pensar 2 veces antes de presiones el boton de "SCAN" :)
En este post no se los detallaren a full, a que me refiero? me refiero a mostrar a que no mostrare todos los escenarios de explotacion ni todos los sistemas operativos, pero si un decente POC que esperemos cresca en un nuevo esfuerzo de investigacion para las herramientas escaner de vulnerabilidades web.
Asi que manos a la obra !!
Acunetix es una poderosa herramienta para el análisis y la búsqueda de vulnerabilidades en sitios web.
Muchos atacantes novatos tienden a usar esta herramienta debido a la simplicidad de su uso.
Acunetix tambien ofrece a sus usuarios un simple escaneo que cubre muchos aspectos del análisis de vulnerabilidades.
Uno de los aspectos es la capacidad de escanear más dominios o subdominios relacionados con el sitio web escaneado.
Por ejemplo, si escaneamos mi blog "http://rootbyte.blogspot.mx/", obtendremos el resultado se muestra a continuación:
Después de investigar un poco acerca de esta opción, me di cuenta de que Acunetix inicia su asistente mediante el envío de una petición HTTP al sitio y muestra el resultado partir de la respuesta HTTP.
Además el asistente muestra los dominios relacionados externos, como las fuentes externas que utiliza el sitio, por ejemplo:
"
"" "
Etc. ..
Un análisis detallado revela que si se utiliza una longitud mayor de 268 Byte’s o mas como nombre de dominio externo Acunetix se congela, por lo que si queremos provocar un accidente en el escaner de nuestro atacante lo único que tenemos que hacer es poner algún tipo de fuente externa en nuestro sitio, que tener la longitud de 268 bytes o más, por ejemplo:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAA”>
Un vistazo rapido a esta aplicacion en el Inmmunity Debugger muestra que EDX se crasheo acausa de el fuzzing string que causo una violacion de acceso :D
A pesar de que la escritura corre sobre (SEH ) que probablemente se dará cuenta , mi consejo seria no ir por ese camino, creanme, lo intenté durante varios días y no tuve éxito (Debido al mecanismo SHE).
Sin embargo, tenemos otro problema con este exploit , y lo resumire en un apalabra: "ASCII" .
Acunetix obtiene su información sobre los dominios externos como una dirección URL.
Este hecho provoca que la cadena se convierte en explorador Web.
Mientras ASCII acepta caracteres como :
0x22 ( ") , 0x23 (#), 0x24 ($), 0x25 (%), 0x5C (\), 0x2F (/) y más ...
La cadena URL acepta sólo caracteres alfanuméricos imprimibles y "URL" convierte los caracteres especiales (pero con muy pocas excepciones).
Así que si mi fuente externa contiene uno de los caracteres especiales , que se convertirán en
"%RootByte".
Por ejemplo, el Char "comillas" (") se convertirá en 253.232 en la memoria porque es la traducción de 22 % .
Otro ejemplo que demuestra la codificación URL es: char "por ciento" (% ), que se convierte en 253.235 en la memoria.
Si quisieramos pasar por él tendria que ser mediante la construcción de un exploit que sólo contenga "AZ , az, 1-0 " y algunos caracteres especiales que no se conviertan en el proceso de URL ENCODE como:
" ! () = } {" .
(Y se los vuelvo a repetir; no es un trabajo sencillo :( )
En resumen, tenía que encontrar una manera de arreglar el flujo de la aplicación con el fin de evitar la SEH (debido a la imposibilidad de eludir la protección de seguro SHE con cadenas URL ASCII solamente).
En fin, por último , he encontrado una manera :D !!
Con el fin de fijar el camino, EDX se tuvo que ser sobreescrito con una legible dirección de memoria.
Sin embargo, es importante recordar que EDX jamas a sido utilizado como esto, pero menos 8.
MOVE ECX, DWORD PTR DS: [EDX-8];
Lo que significa que no importa qué dirección de memoria utilizemos, hay que añadir 8 a la dirección (en la explotación), convertir toda la dirección en imprimir String url, y esperemos lo mejor :)
Después de poco investigación (y mucho cafe) , encontré tal dirección.
La dirección estaba en "0x663030XX" y por suerte tenía la posibilidad de convertirse en el URL y sin malos caracteres especiales -> "F005".
Después de jugar con el código me encontré con que la ubicación exacta de ese EDX:
Así que por ahora nuestro exploit se ve así:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAA500fBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB”>
Puse a correr nuevamente el Acunetix con ese payload y este fue el resultado:
Como se podran ver arriba, la EIP se ha sobrescrito!
Parece que la idea de fijar el flujo se ha realizado correctamente, ya que me permitió estar en una mejor posición de ataque (Sobrescritura EIP)
Junto a ella, nuestro espacio potencial para el código shell se presenta ahora en EAX y ESP.
Cuando se trata de la decisión de la elección de ESP o EAX, ESP es la mejor opción a partir de dos aspectos diferentes:
1.- ESP está apuntando directamente al principio de la cadena.
2.- Hay un espacio mucho mas grande para un código shell.
Después de elegir ESP, necesitaba encontrar una instrucción de "JMP ESP" en una dirección de la memoria que pudiera escribir una cadena URL (ASCII limitada como menciónamos arriba).
La dirección deseada esta localisada: 0x7e79515d (SXS.DLL) – (EN ASCII) (“ ]Qy~ “).
Después de todo eso, nuestro código shell se supone que se veria así:
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA
AAAAAAAAA500fBBBB]Qy~BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB
BBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBBB”>
500f = 0x66303035 : ubicación de memoria legible para la fijación del flujo de la aplicación que se ha dañado por el desbordamiento del búfer.
]Qy~ = 0x7e79515d (JMP ESP de SXS.DLL).
Bueno, en este momento estamos en la etapa semifinal, que ejecuta la aplicación en contra de la carga útil y que produce el siguiente resultado:
Genial !! aterrizamos exactamente en el inicio de la carga final.
El siguiente paso, será el uso del Windows shell adecuado, que se realizará sólo la cadena URL (ASCII limitada).
Dicha shell se puede generar con "Metasploit" y se llama "Alphanumeric Shell".
Lo importante a recordar durante el uso de tal carga útil, es que la dirección de inicio de la carga debe ser presentada en uno de los registros. Si la carga se presenta en el ESP, el primer código de operación de la shell tiene qué ser "PUSH ESP".
En mi prueba de concepto, usé simple "CALC.EXE" shell code generado por "Metasploit que me llevó a la etapa final que es, explotar!
Por otra parte, nuestra debilidad es sin pasar con éxito la protección DEP, simplemente seleccionando sólo las direcciones que no se compilan con DEP.
Y debido al hecho a que el propio Acunetix no cumple con el DEP, este exploit debería funcionar perfectamente en Windows XP (para varias jejejeje) .
Después de alcanzar con éxito todos nuestros objetivos, vamos a ver en el trabajo final :)
"XSS""CSRF"
Y así sucesivamente ...
Este tipo de nombres, probablemente llamaran la atencion del pirata informático.
El abajo esta el código escrito y demuestra lo engañoso:
..........................................................................................................................................
...">
En conclusión,
Después de todo lo anterior, hemos creado una poderoso exploit que los hackers Newbie sin duda caeran.
Este exploit nos dará la capacidad de hacer todo contra los noobs que escanean nuestros sitios dia y noche, matando a nuestro tráfico o llenar todos los formularios del sitio web con pura basura y así sucesivamente ...
Además, puede ser utilizado con el fin de reunir información sobre las "fuerzas" hostiles que quieren atacar nuestra aplicación web.
PERO!
La más poderosa idea que me motivó a revelar este POC, es el hecho de que este exploit es como un poderoso Caza-noob! , Porque incluso si el atacante utiliza el mas seguro proxy en el mundo, como "TOR" aun asipodremos tener el pleno control de su máquina.
Gracias a todos por leer mi post, espero que les guste :)
PD
Aqui les dejo un video con un completamnete funcional esploit :)
