lunes, 20 de junio de 2011

Auditing Mobile Apps en la Universidad Europea de Madrid

La próxima semana, entre el 28 y el 30 de Junio, tendrá lugar en la Universidad Europea de Madrid el IV Curso de Verano de Seguridad y Auditoría Informática, en el que podremos disfrutar de charlas de todo tipo durante las agendas que se han preparado para cada uno de los tres días ([28], [29], [30]).

Tal y como se puede ver en la agenda, habrá de todo, seguridad web, comunicaciones móviles, malware y un largo etcétera.

Por la parte que me toca, estaré dando una charla titulada "Auditing Mobile Applications" el día 30 a las 12:30, justo antes de la comida.


En esta charla daremos un repaso por las particularidades que tiene auditar aplicaciones para móviles, centrándonos en iOS y Android (sobretodo Android), tanto en cuanto a sus comunicaciones como las propias aplicaciones.

Siguiendo estas directrices, nos daremos cuenta que, en muchos casos, nos encontramos en estos momentos en un panorama similar al que nos encontramos hace años con el surgimiento de las aplicaciones web, donde aparecían a un ritmo tan frenético que era fácil encontrar webs descuidadas y con muchos problemas de seguridad. En estos momentos estamos viviendo una situación parecida con las aplicaciones para móviles, en las que hay una enorme variedad, un montón de desarrollos hechos, pero que quizá no cumplan los requisitos de seguridad que se esperaría.

Para finalizar, y a modo de ejemplo de todo esto, veremos como es posible hacer Hijacking de cuenta (robo de la cuenta que utiliza otra persona  de una conocida aplicación de mensajería instantánea para móviles que probablemente estaremos usando gran parte de nosotros en estos momentos.

Toda la información sobre las otras charlas, ubicación, etc, la podéis encontrar AQUÍ, y concretamente la información para registrarse AQUÍ.
Espero veros allí!

P.D: Debí poner este post hace semanas, porque acabo de caer en que había descuentos por registrarse con antelación y la gente que se registre ahora ya no puede acceder a ellos. Mis disculpas.

lunes, 6 de junio de 2011

SANS Forensic Contest #8 (Solución)

Me encantan los retos de seguridad de todo tipo, de Hacking, de Forensics, de lo que sea, y concretamente siempre me parecen muy "reales" e interesantes los retos que pone la gente del SANS en su web ForensicContest.Com.

Hace poco pusieron su Puzzle #8, en el que nos proporcionaban una captura de red de una Wifi sobre la que ha ocurrido cosas extrañas. Concretamente, el único usuario legítimo de la red, con MAC 00:11:22:33:44:55, notifica que de repente no puede entrar a su propia red.

En el reto, te piden que contestes una serie de preguntas, pero como no tengo demasiado interés en participar en el reto yo me quedo con las preguntas que me parecen más interesantes:
  1. SSID y BSSID de la Wifi
  2. Clave de Citrado de la Red Wifi
  3. Clave de Gestión del Punto de Acceso
  4. Nueva Clave del Punto de Acceso
  5. Otras acciones
Bueno, pues como dijo Jack el Destripador, "vayamos por partes":

SSID Y BSSID DE LA WIFI

Podríamos irnos a fichero PCAP y extraer de ahí esta información, pero vamos ha hacerlo de una forma mucho más sencilla con Airodump, al que le podemos pasar como parámetro que lea de una captura de red en lugar de directamente de la red:

$ airodump-ng -r evidence08.pcap


Como podeis ver, de lanzar este comando ya podemos sacar gran parte de la información, entre ella que el SSID de la red es "Ment0rNet" y que el BSSID es "00:23:69:61:00:D0" (la MAC del punto de acceso).

Algo muy interesante que tiene esta manera de ver la captura de red es que vamos viendo "en tiempo real" como se van generando los paquetes y como fuere ocurriendo todo. Entre otras cosas podemos ver como los #Data crecen de forma rapidísima, lo cual, siendo un cifrado WEP nos hace ver que casi con toda seguridad se trataban de un ataque estadístico con inyección de paquetes ARP, pero eso lo vemos ahora enseguida.

ROTURA DEL CIFRADO

Como estábamos comentando, vemos que la cantidad de paquetes crecen de forma rapidísima. Esto es típico de los ataques que hacen replay de paquetes ARP para aumentar el tráfico de red y así obtener los IVs necesarios para romper la clave WEP de forma más rápida. Para comprobarlo vamos a ver como fueron los paquetes ARP de la captura de red que tenemos, a ver si se confirma nuestra teoría.

Abrimos el fichero de captura con Wireshark y nos vamos a la opción Statistics->Conversations->WLAN y ordenamos por la columna "packets" para que se nos quede la comunicación de más tráfico arriba. Filtramos por el tráfico intercambiado entre estas dos MACs y vemos muchísimos paquetes idénticos con destino a la dirección FF:FF:FF:FF:FF:FF que tienen toda la pinta de ser replays de paquetes ARP, porque además su contenido cifrado es idéntico en todos ellos:


Bueno, pues si este tío ha generado los suficientes IVs como para romper la clave WEP y acceder a la red... nosotros tenemos la captura con los mismos datos que él ha empleado para romper la clave, así que deberíamos ser capaces de romperla nosotros también, algo que va a ser necesario para poder ver lo que ha pasado una vez que el intruso ha entrado en la red.

En realidad, en una situación real, probablemente sería más correcto pedirle a nuestro cliente que nos proporcionara la clave, pero romperla siempre es más divertido :)

$ aircrack-ng evidence08.pcap


La clave WEP es "D0:E5:9E:B9:04", así que teniendo la clave de la Wifi ahora lo que tenemos que hace es descifrar todo el tráfico para poder analizar la captura de red.

Podríamos hacerlo con las opciones de Wireshark, pero casi que prefiero tener un PCAP descifrado como si fuera tráfico ethernet, para así poder analizarlo con el programa que quiera, así que mejor vamos a seguir utilizando herramientas de la suite Aircrack:

$ airdecap-ng -e Ment0rNet -w "D0:E5:9E:B9:04" evidence08.pcap
Total number of packets read 133068
Total number of WEP data packets 56692
Total number of WPA data packets 0
Number of plaintext data packets 0
Number of decrypted WEP packets 56692
Number of corrupted WEP packets 0
Number of decrypted WPA packets 0

Esto nos ha generado un fichero "evidence08-dec.pcap" que contiene el tráfico que estaba cifrado con esa clave WEP, pero descifrado, como si lo hubiéramos capturado desde una interface ethernet.

CLAVE DE GESTIÓN DEL AP

Ahora que ya tenemos el tráfico descifrado, vamos a abrirlo con Wireshark. Como sabemos que algo raro ha pasado con el AP, es bastante probable que el intruso haya accedido a él, así que filtramos por la IP del Gateway (192.168.1.1) y vemos tráfico HTTP entre este y una IP desconocida, con una MAC diferente a la del usuario legítimo.

Observando cualquiera de las peticiones que hace y haciendo un "Follow Stream" podemos ver la clave que se ha utilizado para acceder al punto de acceso:


Como se puede ver se trata de Autenticación Basic, que por definición simplemente se trata del usuario y la contraseña separados por dos puntos y codificado todo en Base64, así que solo tenemos que decodificar esa Base64 para saber que contraseña tenía el AP:

$ echo YWRtaW46YWRtaW4= | openssl base64 -d
admin:admin

Como no... parece que la contraseña de gestión del AP era la contraseña por defecto, o al menos tiene toda la pinta, así que el intruso lo ha tenido bastante más fácil para acceder. Veamos que hizo el intruso con el AP...

NUEVA CLAVE DEL AP

Para ver todas las peticiones HTTP podemos usar el filtro de Wireshark "http.request", y veremos a la derecha todas las peticiones. Pasamos de todo lo que sea gif y similar, y buscamos peticiones GET con parámetros o peticiones POST, y al final llegamos a una petición POST.


Parámetros POST:
SecurityMode=3&CipherType=1&PassPhrase=hahp0wnedJ00&GkuInterval=3600&layout=en

Bueno, parece que la clave la tenemos, pero además de la clave vemos que ha cambiado más opciones, como "SecurityMode" y "CipherType", que podemos sospechar que son pero que mejor si nos aseguramos, así que vamos a mirar el referer de esta petición a ver si vemos el formulario que ha estado tocando el atacante:


Vale, pues vamos a mirar la petición a WSecurity.htm y vamos a salvarla en un fichero, a ver que pinta tiene. Yo personalmente para estas cosas suelo utilizar Xplico, una herramienta que me gusta bastante para hacer análisis forense de red, pero en esta ocasión no me ha sacado las cosas como yo quería (reportaré el bug), así que vamos a sacarlo un poco a mano, así que vamos a buscar en el cuerpo del HTML como se llaman los campos del formulario que el intruso ha cambiado:

SecurityMode=3 -> WPA2 Personal
CipherType=1 -> AES
PassPhrase=hahp0wnedJ00 -> WPA SKey

Parece ser que lo que ha hecho nuestro intruso es cambiar el cifrado del punto de acceso a un cifrado WPA2, y por supuesto a partir del momento del cambio de clave no vamos a ver nada en el fichero de captura que hemos sacado descifrando el cifrado WEP.

OTRAS ACCIONES

Sin embargo... tenemos la clave WPA, así que podemos descifrar el tráfico igual que hemos hecho antes. Vamos a ello!

$ airdecap-ng -e Ment0rNet -p "hahp0wnedJ00" evidence08.pcap
Total number of packets read 133068
Total number of WEP data packets 56692
Total number of WPA data packets 0
Number of plaintext data packets 0
Number of decrypted WEP packets 0
Number of corrupted WEP packets 0
Number of decrypted WPA packets 0

Joder... que aguafiestas estos del SANS... no nos han metido el tráfico WPA en la captura, con la curiosidad que tenía en saber que más había hecho el intruso... en fin...

Como digo siempre, si tenéis comentarios que hacer o formas en la que lo hubierais hecho de forma más sencilla... decídmelo!