martes, 26 de enero de 2010

"Hacking Techniques, Exploits & Incident Handling" de SANS en Madrid

Hace algunas semanas, personal del SANS Institute en europa se puso en contacto conmigo para organizar cursos en Madrid. Como seguramente muchos ya sabreis, el SANS Institute es uno de los centros de investigación y formación en seguridad más prestigiosos del mundo. Entre los recursos que ofrece (algunos gratuitos y otros de pago) ofrece cursos de todo tipo relacionados con la seguridad, algunos de ellos son los más técnicos que podemos encontrar hoy en día.

De entre ellos, se me ha solicitado por parte de SANS impartir el curso "SEC504: Hacker Techniques, Exploits & Incident Handling" en modalidad Mentor. En esta modalidad, los estudiantes dispondrán de una copia impresa de los materiales (en inglés) y de un DVD con las máquinas virtuales, herramientas, etc necesarias para realizar los ejercicios. Además de este material de auto-estudio, el Mentor (yo) impartirá una clase semanal de dos horas durante 10 semanas comprendidas entre el 24 de Marzo y el 2 de Junio (la semana que coincide con las conferencias BlackHat de Barcelona no habrá clase, por si hay gente que quiera apuntarse al curso y a su vez asistir a las conferencias). El objetivo principal de las clases es resolver dudas, mostrar como se usan las herramientas y la realización de ejercicios adicionales que favorezcan la comprensión de las técnicas y las herramientas, todo ello en Español. Las clases se realizarán los miércoles de 20:00 a 22:00 en las instalaciones de Telefónica Ingeniería de Seguridad, situadas en la calle Condesa de Venadito 7, bajo, en Madrid capital.


Por su parte, el SANS Institute ya ha publicado el curso para que la gente se apunte, pero si os interesa antes de apuntaros poneros en contacto conmigo en jselvi@pente... (vamos, pentester.es, pero lo pongo así para que no me hagan Spam). Si os interesa no tardeis en apuntaros o poneros en contacto conmigo, porque en función de la gente interesada el curso se realizará o no.

Y a todo esto... ¿Qué es el Incident Handling?

El Incident Handling, traducido como gestión de incidentes, son todas aquellas acciones a realizar con el fin de minimizar el impacto y corregir el problema que nos ha llevado a sufrir un incidente de seguridad. En mi experiencia como Incident Handler, han sido muchas las veces que una empresa ha requerido estos servicios tras sufrir una intrusión, una infección por malware o cualquier otro tipo de incidente de seguridad.
Cuando esto se produce y todo el mundo pierde los nervios, un Incident Handler debe mantener la sangre fria y analizar la situación, determinar el origen de la amenaza y manera en que se produjo el incidente, aplicar las medidas de contención, recoger las evidencias necesarias y finalmente solucionar el incidente de tal forma que se haya eliminado tanto la amenaza como la vulnerabilidad que permitió que dicho incidente se produjera. Como podeis imaginar, la gestión de este tipo de incidentes requiere el uso de una metodología apropiada, así como unos conocimientos profundos de técnicas de hacking, intrusión y/o malware que nos permitan reconocer la situación, lo cual será imprescindible para tomar unas medidas de contención y erradicación eficaces y, por tanto, para dar por resuelto el incidente.

Más información en la web de SANS.

Es importante que las personas interesadas se pongan en contacto conmigo, ya que les tengo que dar un código para que lo metan en la web de SANS cuando haya que apuntarse.

Actualización (I): SANS ofrece poder realizar la certificación GIAC GCIH, valorada en 450€, totalmente gratis si te apuntas al curso antes del 28 de Febrero.

Actualización (II): A fecha 9 de Marzo, 2 semanas antes de empezar el curso, se completa el aforo, por lo que SANS Institute dará por cerrado el curso a lo largo del día de hoy. Gracias a todos por vuestro interés en este curso, que ha permitido que sea un COMPLETO ÉXITO.

lunes, 25 de enero de 2010

Ficheros flash vulnerables en la selva (Internet)

Hará cosa de un mes ví en la lista websecurity un mensaje con el título "XSS vulnerabilities in 8 millions flash files". El artículo lo podéis encontrar en el blog de un ucraniano y resumiendo, explica cómo encontrar a través de Google ficheros flash vulnerables en la selva (Internet).

Si léis el artículo (cosa que recomiendo) veréis que lo que se busca son ficheros flash que tengan url y clickTAG como parámetro. El problema es que lo introducido detrás de alguno de estos parámetros "suele" pasarse a la función getURL(), que como sabréis permite también la ejecución de código javascript.

Como no podía ser de otra manera vamos a ver qué debería un pentester realizar en una auditoría web para ver si existen ficheros flash vulnerables en el dominio objeto de su auditoria:

Lo primero, sería realizar una búsqueda en los principales motores de búsqueda, acotada al dominio de nuestra auditoría buscando ficheros .swf

  • filetype:swf inurl:url site:dominio.com
  • filetype:swf inurl:clickTAG site:dominio.com
  • filetype:swf inurl:tagcloud.swf site:dominio.com
Lo segundo sería realizar una revisión manual de la página para ver que no exista ningún fichero .swf que no haya sido indexado por los motores de búsqueda por alguna circunstancia.

Lo tercero es descargar el fichero .swf y decompilarlo con la herramienta Flare y ver el parámetro url, clickTAG y si va a ser posible la inyección. A continuación os muestro un ejemplo de fichero decompilado y que sería vulnerable:



Y por último, como es evidente introducir en el parámetro url de la dirección, nuestro código script de la siguiente manera:

http://victima.com/fichero.swf?url=javascript:alert('XSS')


La verdad es que es asombroso ver la cantidad de ficheros flash que sufren de esta vulnerabilidad. Espero que esto os sirva para vuestras auditorias.

miércoles, 20 de enero de 2010

¿Aurora + Elevación de Privilegios?

Hace unos días publicabamos la existencia de un exploit Zero-Day que explotaba una vulnerabilidad no documentada hasta ahora en Internet Explorer 6, 7 y 8 que permitía la ejecución de código de forma remota.

El exploit utilizado en los ataques contra Google China solo parecía resultar efectivo para sistemas Windows XP con Internet Explorer 6, aunque la vulnerabilidad afecta y podría ser expotada en todos los sistemas y navegadores de Microsoft.

Algunos especialistas en exploiting como Dino A. Dai Zovi afirman disponer ya de un exploit funcional para Windows Vista e Internet Explorer 7, así como exploit funcionales que se saltan las protecciones de DEP, tal y como anuncia VUPEN Security.



Como podemos ver, tras modificar el exploit para que funcionara en Windows XP con Internet Explorer 7, Dino solo tardó 7 horas en hacerlo funcionar en Windows Vista, lo que nos demuestra que la mutación del exploit para que afecte a otros sistemas es MUY realista. No se puede tener constancia de cuantas horas ha costado a la compañía VUPEN Security saltarse las protecciones de DEP, pero ese exploit ya está disponible para aquellos que tengan contratado su servicio.

Por suerte, parece ser que hoy mismo Microsoft va a publicar las fechas de publicación del parche para esta vulnerabilidad, esperemos que sea lo antes posible.

Por otro lado, esta vulnerabilidad sin parche disponible para Internet Explorer coincide con la publicación en la lista de Full Disclosure de otra vulnerabilidad para la que no existe parche de Microsoft que afectaría a toda su familia de sistemas operativos y que permitiría elevación de privilegios y del cual ya existe un exploit publicado.

Aún no hemos podido probar este nuevo exploit, pero en cuanto lo hagamos pondremos un post dando más detalles y probando las medidas de mitigación que propone el investigador que ha descubierto la vulnerabilidad.

Ojito con lo que haceis, correr el Internet Explorer como usuario no privilegiado podría no ser suficiente.

Seguiremos informando.

domingo, 17 de enero de 2010

Aurora Zero Day (Internet Explorer)

Como ya sabreis, hace poco nos llegó la noticia a todos de los ataques recibidos por Google China, así como por un buen número de empresas de envergadura considerable.

El ataque consistía en lo que el Internet Storm Center (ISC) del SANS Institute llamó "targeted phishing" or "spearphishing", es decir, el envío de correos a personas determinadas de una empresa para intentar que realicen las acciones deseadas por el atacante, bien sea aprovechando vulnerabilidades de los navegadores, bien sea engañándoles para que ejecuten un fichero ejecutable, vean un video, etc.

En este caso, este ataque explotaba una Vulnerabilidad Zero Day de Internet Explorer 6, 7 y 8 que permitía a los atacantes tomar el control de la máquina atacada. Concretamente, según afirma Microsoft en su Advisory, solo se han detectado ataques que explotan la vulnerabilidad exitósamente en Internet Explorer 6, aunque no se descarta que aparezcan próximamente ataques que realicen lo propio contra Internet Explorer 7 y 8, saltándose las protecciones de DEP.

El exploit de dicha vulnerabilidad completamente funcional para Internet Explorer 6 (aunque no para otras versiones, como hemos podido comprobar desde pentester.es, dadnos tiempo :P) ha sido publicado y ya existe modulo para metasploit disponible que ha sido anunciado recientemente en el blog de Metasploit. Podemos ver un ejemplo de su funcionamiento en el siguiente video:

[DELETED]

El exploit, si lo lanzamos desde Metasploit y conectamos con NetCat, podemos ver que se trata claramente de una vulnerabilidad en el motor de Javascript:


Más concretamente, como se ha podido saber, se trata de un fallo por el cual se podría acceder a un puntero inválido tras liberar el objeto al que apunta, es decir, declaramos un objeto, tenemos el puntero que apunta a él, liberamos el objeto, pero sin embargo seguimos teniendo la referencia al objeto y podemos escribir en memoria a través de dicha referencia.

Por tratarse de una Vulnerabilidad Zero Day, como su propio nombre indica, el fallo ha sido publicado antes de que Microsoft publique los parches necesarios para solucionarlo, por lo que no es posible aplicar ningún parche que corrija la vulnerabilidad.

Desde Pentester.es, recomendamos tomar las siguientes acciones:
  1. No confiar en que los exploits conocidos solo han resultado efectivos en IE6. Podrían existir otros exploits no conocidos que funcionaran en IE7 e IE8.
  2. Desactivar Javascript en los navegadores Internet Explorer, aunque no los estemos usando como navegador predeterminado, ya que por algún motivo el sistema operativo utiliza Internet Explorer en algunos casos aunque le hayamos especificado lo contrario. Así mismo pueden existir aplicaciones de terceros que conecten a Internet por medio de un Internet Explorer oculto (que no se muestra en pantalla), por lo que en cualquier caso deberiamos desactivar Javascript en Internet Explorer.
  3. Instalarnos la última versión de algún otro navegador como Firefox, Opera o Chrome, y utilizarlo hasta que Microsoft saque el parche.
Una vez sacado el parche, los usuarios habituales de Internet Explorer solo tienen que aplicar el parche, volver a activar Javascript y seguir usando su navegador favorito como hasta ahora.

jueves, 14 de enero de 2010

BeEF: XSS impact tool

La herraminta BeEF está realizada por la gente de Bindshell y permite recolectar zombies y lanzarle una gran diversidad de ataques a través de codigo script como pasarela; todo esto de una manera sencilla y rápida.Vamos a ver qué aspecto tiene, qué módulos incorpora y un escenario de ataque con video incluído que podréis ver abajo.

Cuadro de mando del atacante

BeEF ofrece un cuadro de mando con la siguiente estructura:



1. Frame donde se visualiza a los zombies cuando se conecta y permite seleccionarlos para lanzarles los ataques. Se observa tambien la posibilidad de activar el Autorun, lo que hace que una vez que un zombie se conecta a la página con el script lanzarle una acción de manera automática.

2. Zona donde veremos diferentes datos del zombie, todo lo que teclea sobre la página donde ha lanzado el ataque, el resultado de ciertos módulos, el código fuente de página etc.

3. Frame para ver el log de todo la interacción con los zombies.

4. Menús desplegabes donde encontraremos los modulos de detección, modulos de explotación, modulos de red, etc.

¿Qué puede hacer el atacante con BeEF?



Los modulos de BeEF los podríamos dividir en módulos de detección donde el atacante puede averiguar mas datos sobre la víctima, modulos de red donde podríamos destacar la posibilidad de escanear la red interna del zombie a través de BeEF y módulos de ataque al navegador donde encontraremos exploits sobre diferentes versiones de navegadores entre otros.

¿Cómo funciona BeEF? (posible escenario de ataque)



1. Un atacante encuentra una vulnerabilidad de Cross-Site Scripting Almacenado en la página www.victima.com. El atacante introduce un script que hace referencia a beefmagic-js.php que esta alojado en www.evil.com y es el primer paso para la comunicación que se va a producir entre entre la víctima y el cuadro de mando de BeEF en www.evil.com.



2. La víctima como cualquier otro día visita la web www.victima.com.

3. La víctima recibe la página que incluye el regalito (script que apunta a beefmagic-js.php) que hace referencia al dominio www.evil.com.

4. La víctima de manera inconsciente accede a www.evil.com.

5. La víctima de manera constante solicita trabajo (por describirlo de alguna manera) para hacer mediante peticiones GET. Todo esto mientras se mantenga en la página vulnerable.

6. El atacante envía acciones a realizar sobre la víctima.

7. La víctima devuelve el resultado de la acción solicitada.

Hace cosa de un mes y medio tuve la oportunidad de explicar esto mismo en unas conferencias, así que os dejo el enlace a las slides y al video de la demo, donde espero que quede aún mas claro el impacto que puede tener un XSS con herramientas como BeEF y mostrar que no solo tienen impacto para la imagen como ha sido el caso reciente del XSS reflejado en la página de la presidencia Europea y que podéis leer en detalle en SecuritybyDefault.

Conclusión

Lo que podemos ver con esta entrada es lo que un atacante podría realizar con un XSS y la herramienta BeEF sobre usuarios que visitan una web vulnerable. Por tanto queda patente el impacto que tiene un XSS sobre los usuarios finales y la responsabilidad que tienen los que ponen en un producción una aplicación web frente a sus usuarios.

lunes, 11 de enero de 2010

BackTrack 4 Final

Después de muchos meses de trastear con la BackTrack 4 Beta, por fin los chicos de Remote-Exploit han liberado la release final de la versión 4 de una de las distribuciones de seguridad más conocidas: BackTrack v4.


Como siempre, la podemos descargar en dos formatos, tanto directamente como a través de Torrent:
  • LiveCD: Para arrancar en cualquier equipo nuestras herramientas, perfectamente listas para utilizar.
  • VMWare: Para los que disfrutamos añadiendo nuevas herramientas y tuneando nuestra distro, esta imagen VMWare contiene ya instalada toda la distro, incluidas VMWare Tools.

Además de esta liberación, BackTrack estrena nuevo dominio, ya que a partir de ahora podemos encontrar todo lo referente a nuestra distro de seguridad favorita en http://www.backtrack-linux.org

Yo ya tengo descargando la imagen VMWare :)

lunes, 4 de enero de 2010

WhatWeb: Fingerprinting de aplicaciones web

Muchas veces a la hora de realizar una auditoría de una web nos encontramos con que los desarrolladores usan gestores de contenidos o aplicaciones web OpenSource ya conocidas para aplicar modificaciones sobre ellas y conseguir acelerar el desarrollo. Sin embargo, desde el otro lado, cuando nos encontramos con una aplicación de este tipo al realizar un pentest, nos podría resultar muy útil conocer sobre que versión de que producto ha sido construida la aplicación web, ya que dicha versión podría contener vulnerabilidades que hayan sido publicadas pero no corregidas en este desarrollo "pseudo-a-medida" (algo muy habitual).

Para realizar este reconocimiento de la versión, llamado comúnmente Fingerprinting, vamos a utilizar una herramienta llamada WhatWeb, de la que he tenido constancia recientemente y que me encuentro en la actualidad probando.

Para utilizar la herramienta solo hay que descargarla e instalarla y llamarla de la siguiente manera:

# cd /opt/whatweb
# ./whatweb http://www.web.com/aplicacion/

Por supuesto, este es el funcionamiento básico, pero existen multitud de opciones que podemos usar para ajustar su funcionamiento, para pedirle que sea menos exahustivo, etc:

# ./whatweb
WhatWeb - Next generation web scanner.
Version 0.3 by Andrew Horton aka urbanadventurer, MorningStar Security
www.morningstarsecurity.com

Usage: whatweb [options]

--input-file=FILE, -i Identify URLs found in FILE
--aggression, -a 1 passive - on-page
2 polite - follow on-page links if in the extra-urls list (default)
3 impolite - try extra-urls when plugin matches (smart, guess a few urls)
4 aggressive - try extra-urls for every plugin (guess a lot of urls)
--recursion, -r Follow links recursively. Only follows links under the path (default: off)
--depth, -d Maximum recursion depth (default: 3)
--max-links, -m Maximum number of links to follow on one page (default: 25)
--list-plugins, -l List the plugins
--run-plugins, -p Run comma delimited list of plugins. Default is to run all
--info-plugins, -I Display information about a comma delimited list of plugins. Default is all
--example-urls, -e Add example urls for each plugin to the target list
--colour=[WHEN],
--color=[WHEN] control whether colour is used. WHEN may be `never', `always', or `auto'
--log-full=FILE Log verbose output
--log-brief=FILE Log brief, one-line output
--user-agent, -U Identify as user-agent instead of WhatWeb/VERSION.
--max-threads, -t Number of simultaneous threads identifying websites in parallel (CPU intensive). Default is 5.
--help, -h This help
--verbose, -v Increase verbosity (recommended), use twice for debugging.


Ahora que ya tenemos la herramienta instalada y ya sabemos como usarla, vamos a hacer una pequeña prueba sobre algunas aplicaciones web que me rondan por la cabeza, a ver que tal detecta...

Aunque entiendo que tampoco debería haber ningún problema si pusiera las webs reales, pero comprendiendo que hay gente que no le gusta ver los datos de su web expuestos a todo Internet (sorpresa! es un servidor web, YA lo tienes expuesto a todo Internet), he cambiado los nombres de las webs y demás información que pudiera resultar identificativa de una web por asteriscos, pero podeis ver exactamente lo que saldría viendo la primera prueba (sobre este mismo blog).

Vamos a ello:

1) # ./whatweb www.pentester.es
http://www.pentester.es [200] Blogger, Google-Analytics-GA[6141658], md5[a367e7be8d94a46c85cbb7ed7e73259b], server-header[GFE/2.0], title[Pentester.es], uncommon-headers[x-frame-options,x-content-type-options,x-xss-protection]

De momento al cosa va bien, pentester.es está en Blogger, evidentemente.

2) # ./whatweb www.*****.com
http://www.*****.com [200] Google-Analytics-GA[*****], JQuery[1.3.2], Mailto, WordPress[2.8.4], md5[*****], meta-generator[WordPress 2.8.4], server-header[Apache], title[*****], uncommon-headers[x-pingback], x-powered-by-header[PHP/5.2.0-8+etch4]

La web de una empresa del mundo de la seguridad que utiliza un WordPress. Correcto.

3) # ./whatweb *****.com
http://*****.com [200] md5[*****], server-header[Apache], title[*****]

De este la aplicación no saca nada, pero es comprensible, es un gestor de contenidos de una compañía Española y que no está muy extendido pero con el que me he encontrado recientemente.

4) # ./whatweb http://www.*****.org
http://www.*****.org [301] md5[*****], redirect-location[http://www.*****.org/web/*****/], server-header[Apache]
http://www.*****.org/web/*****/ [200] md5[*****], server-header[Apache], title[*****], uncommon-headers[liferay-portal]

Gestor de contenidos LifeRay. Este no lo ha reconocido como tal, pero ha reconocido cabeceras extrañas que nos proporcionan el nombre del gestor de contenidos. Este SI ha sido modificado para ser adaptado.

5) # ./whatweb http://www.*****.org
http://www.*****.org [301] md5[*****], redirect-location[http://www.*****.org/wiki/Main_Page], server-header[Apache], uncommon-headers[x-vary-options], x-powered-by-header[PHP/5.2.10]
http://www.*****.org/wiki/Main_Page [200] Google-Analytics-GA[*****], probably index-of, md5[*****], meta-generator[MediaWiki 1.15.1], server-header[Apache], title[*****], uncommon-headers[x-vary-options], x-powered-by-header[PHP/5.2.10]

Un conocido Wiki del que saco información sobre análisis forense. Correctamente detectado.

6) # ./whatweb http://*****.*****.org/
http://*****.*****.org/ [200] Google-Analytics-GA[*****], md5[*****], server-header[Apache/2], title[*****], vbulletin[3.8.3], x-powered-by-header[PHP/5.2.8]

Esta es una conocida web con temas de seguridad. Parece correctamente detectado.

Lamentablemente no me vienen a la cabeza un gran número de webs que recuerde que usan gestores de contenidos o aplicaciones similares modificadas, así que si lo quereis probar y notificarnos los resultados... nosotros encantados, ya que hace muy poco tiempo que utilizamos esta herramienta y todavía no podemos hacer una valoración de su funcionamiento con más profundidad.

Disfrutadlo con salud!