Wild Wild WiFi "Dancing with Wolves": 1.- Mummy

Era el año 2010 cuando estuvimos jugando con las redes Wi-Fi. Por aquellos años ya se conocía una gran cantidad de ataques a redes inalámbricas, y sin embargo las redes Wi-Fi inseguras estaban muy extendidas. En aquellos años pensamos que era posible hacer, o añadir protecciones en el cliente Wi-Fi que venía con los sistemas operativos, y trabajamos en hacer un pequeño cliente para Windows que añadiera algunas protecciones extras.

Figura 1: Wild Wild WiFi "Dancing with Wolves": 1.- Mummy

Para comenzar el artículo, vamos a analizar qué hicimos en aquel trabajo del año 2010, para luego ir viendo qué hemos ido haciendo en ese área de seguridad después. Comencemos por Mummy.

1.- Living in the Jungle

Para explicar todo lo que teníamos en mente, hicimos un paper al que llamamos "Living in the jungle: Legitimate users in legitimate, insecure Wireless Networks", que acompañamos con una pequeña herramienta, en modo PoC, llamada Mummy.

Figura 2: Living in the Jungle: Legitimate users in Legitimate Insecure Wireless Networks

El trabajo, que podéis leer en el documento adjunto, recogía una pequeña matriz de riesgos en redes Wi-Fi inseguras en aquellos tiempos, donde se quedaban fuera del estudio las redes empresariales, ya que estábamos focalizados en redes legítimas inseguras. Podríamos haber mirado redes EAP-MS-Chapv2 o similares redes de infraestructura con vulnerabilidades conocidas, pero nuestra opción fue centrarnos en las más comunes, así que miramos las redes OPEN, WEP, WPA-PSK, WPA2-PSK.

Figura 3: Matriz de riesgos en "Living in the jungle" (2010)

Como la inseguridad de las redes WPA-PSK y WPA2-PSK en aquellos tiempos dependía de la facilidad o dificultad de crackear la clave mediante ataques al proceso de autenticación, metimos un pequeño estudio de lo difícil que sería para un atacante romper la contraseña. En los artículos de Atacar redes WPA/WPA2-PSK y Crackear WPA/WPA2-PSK hablábamos en el año 2009 de estas cosas.

Figura 4: Estudio de complejidad de contraseñas en WPA/WPA2-PSK

También miramos el comportamiento de los vecinos conectados a la red, añadiendo detección de ataques de ARP-Spoofing, 0-Attack, o inyección de paquetes en redes WEP para saber si teníamos un atacante activo en la red.

Figura 5: Cliente Mummy con nivel de riesgo de la red Wi-Fi

Todo eso lo implementamos en Mummy, con el objeto de que el cliente Wi-Fi diera más información sobre la red a la que nos estábamos conectando para tomar una mejor decisión. Por supuesto, aunque la red fuera muy segura, y no pasara absolutamente nada en este momento, hace falta recalcar que la red Wi-Fi podría tener un "insider" previo que hubiera conseguir la clave con anterioridad, y ahora no estuviera activo, y puede ser que el AP ya estuviera comprometido desde origen. Cosas que no tenían nada que ver con este trabajo.

Figura 6: Alertas de seguridad en Mummy

Aquello se quedó en 2010, pero las tecnologías Wi-Fi, y lo relativo a su seguridad, siguió avanzando, a veces con mejoras positivas, otras con empeoramientos en términos de seguridad en pro de la usabilidad.

2.- Clientes Wi-Fi en Windows, iOS y OSX/macOS empeorados

Con la popularización de los smartphones vimos que los clientes que venían con iOS eran bastante pobres en seguridad, como escribía yo en un artículo de Seguridad Apple del año 2011, donde se echaban en falta las siguientes posibilidades.

Figura 7: Carencias del cliente Wi-Fi en iOS

De hecho, en 2012, cuando hicimos los ataques basados en JavaScript Botnets a dispositivos iOS (iPhone & iPad), lo hacíamos utilizando Rogue APs que explotaban esas debilidades, y en el libro de Hacking iOS: iPhone & iPad, detallamos cómo robar datos de la navegación desde Safari para iOS en un iPad o iPhone usando estas técnicas.


Figura 8: Owning bad guys {and mafia} using Javascript Botnets
Además, los sistemas operativos OS X/macOS habían rebajado el nivel de seguridad en el cliente Wi-Fi, eliminado del sistema la comprobación de BSSID del AP en el perfil de conexión almacenado. Esto tiene riesgos importantes que aprovechan los ataques de Rogue AP tal y como reflexionamos en este otro artículo. Sin embargo, algo que Windows sí hacía, fue a peor en términos de seguridad y a "mejor" en términos de usabilidad, y la comprobación de BSSID también se eliminó de los sistemas operativos Windows 10.


Figura 9: Raúl Siles en 2013 analizando los clientes Wi-Fi
Es decir, no solo no habíamos mejorado la seguridad, sino que habíamos ido empeorándola poco a poco haciendo que el control que un usuario tiene sobre las conexiones a las redes Wi-Fi es menor cada vez y las implementaciones son bastantes pobres. En la charla de Raúl Siles de RootedCON 2013 se puede ver como de "pobres" eran esos clientes Wi-Fis.

¿Se puede mejorar esto? Pues de muchas formas, y nosotros jugamos con esto durante estos años haciendo cosas de todo tipo. Os lo iré contando en las siguientes partes.

Saludos Malignos!

****************************************************************************
- Wild, Wild, WiFi: 1.- Mummy
- Wild, Wild, WiFi: 2.- SSID Pinning
- Wild, Wild, WiFi: 3.- PsicoWifi
- Wild, Wild, WiFi: 4.- WEP/WPA*-TOTP
- Wild, Wild, WiFi: 5.- WEP/WPA/WPA2-TOTP-Biometry
****************************************************************************

SnapChat te avisa de que graban tus mensajes pero NO del todo

Hace un par de años, después de usar durante tiempo Reflector para hacer desde equipos macOS/OS X en muchas presentaciones de Latch en las que necesitaba mostrar la pantalla de un iPhone, me di cuenta de lo sencillo que era grabar los mensajes con autodestrucción de Telegram y Snapchat. A pesar de que ellos tienen una detección que le dice al usuario cuándo se ha hecho una captura de pantalla.

Figura 1: SnapChat te avisa de que graban tus mensajes pero no del todo

Con la llegada de la opción de Screen Recording en iOS 11, los mensajes de SnapChat pudieron grabarse de nuevo sin que el emisor de los mismos recibiera ninguna alerta, pero la actualización a la última versión de SnapChat ya detecta esta opción de grabación.

Figura 2: Opción de Screen Recording en iOS 11

Es decir, si una persona envía por SnapChat un mensaje con autodestrucción y la otra persona hace una captura de pantalla, bien con el método tradicional en iOS de pulsar el botón de encendido y el botón Home al mismo tiempo, como si utiliza la opción de Screen Recording de iOS 11, el que envió el mensaje recibirá el iconito verde que se puede ver a la derecha del mensaje.

Figura 3: Icono a la derecha que indica que el destinatario ha grabado el mensaje

Sin embargo, existen otras formas de hacer la grabación de la pantalla de un iPhone sin usar ninguna de las dos opciones anteriores, como es usar la posibilidad de Movie Recording de QucikTime en macOS o un software de terceros como Reflector que es lo que yo utilicé en su día.

Figura 4: PoC de grabación de mensajes de SnapChat en iOS 11

Así que hicimos unas pocas pruebas en mi equipo de PoCs & Hacks y probamos el comportamiento de SnapChat. Como podéis ver en el vídeo, detecta tanto el uso de Screen Recording, como cuando se usa QuickTime Movie Recording, pero cuando se usa Reflector.... nada de nada. El sistema de SnapChat no es capaz de detectar que la pantalla ha sido grabada y el mensaje está circulando ya por grupos de WhtatsApp.

Saludos Malignos!

MacPhish: Hacking macOS / OSX con macros de Office para Mac y AppleScript

Este artículo es digno de nuestro querido blog Seguridad Apple, y  útil para los que cuando hacéis las auditorías de red también estáis formados en el Hacking de macOS/OX y no solo de redes Windows. Hoy el artículo habla de una herramienta que puede ser utilizada en campañas de concienciación para empleados, con el objetivo de ver qué empleados caen en la tentación de ejecutar las macros de documentos que llegan de fuentes de no confianza o, por qué no, de fuentes de confianza suplantadas.

Figura 1: Hacking macOS / OSX con macros de Office para Mac y AppleScript

En El lado del mal ya hemos hablado de herramientas que pueden ayudar en las campañas de concienciación de las empresas como Weeman o Mercure, las cuales, además, son Open Source y hoy toca de otra similar para macOS/OSX. La herramienta MacPhish, que está escrita en Python por Paulino Calderón, permite generar payloads para Office for Mac. Esta herramienta puede descargarse desde su Github.

Figura 2: MacPhis en GitHub

La herramienta proporciona diferentes vectores de ataque para obtener ciertos privilegios, accesos o credenciales de una máquina que ejecuta Office for Mac y dónde el target es un empleado de una organización. Los vectores son: beacon, creds, meterpreter y meterpreter-grant.

Figura 3: Ayuda de MacPhish

El primer método que hablaremos es el de creds. Este método permite generar un Applescript directamente, para el caso en el que se necesite ejecutarlo directamente en una shell. La instrucción para este método es la siguiente:

macphish.py –lh [host a la escucha] –lp [puerto a la escucha] –a creds. 

Figura 4: Parte del payload para robar las credenciales en AppleScript

En el siguiente video, el autor muestra como el fichero generado con el script en la macro solicita al usuario sus credenciales y las envía vía HTTP.

Figura 5: PoC MacPhis para robar credenciales con un doc office malicioso

El segundo método es el beacon o señal baliza. Este método permite conocer cuando una máquina está viva o levantada. En otras palabras, si lo metemos como macro en un .doc generado para Office for Mac, el código nos proporcionará una señal al host que hayamos configurado. Para generar el código debemos ejecutar la siguiente instrucción:

macphish.py –lh [host dónde recibiremos la señal]

En la siguiente imagen, podemos ver el código generado y que debemos utilizar como macro. Hay que fijarse que utiliza curl por defecto, pero podría cambiarse para utilizar, por ejemplo, wget u otros.

Figura 6: Apple script para generar la señal

Otro método, quizá aún más interesante que los anteriores, es el del meterpreter. Es decir, la posibilidad de lanzar un meterpreter y poder ejecutar código en la máquina dónde se abre el documento ofimático. La forma más sencilla para llevar a cabo esto es utilizar la siguiente instrucción:

macphish.py –lh [host a la escucha] –lp [puerto a la escucha] –p [payload a ejecutar] -a meterpreter 

Otra variante de este método es el conocido como meterpreter-grant, el cual consiste en generar un meterpreter que será ejecutado al ejecutar la macro y que invoca a GrantAccessToMultipleFiles(), para ello se puede ejecutar la siguiente instrucción:

macphish.py –lh [host a la escucha] –lp [puerto a la escucha] –p [payload] –a meterpreter-grant

Para ejemplificar este hecho, podemos lanzar la siguiente instrucción macphish.py –lh [host] –lp [puerto] –p python/meterpreter/reverse_https –a meterpreter. Se obtendrá algo similar a lo que vemos en la siguiente imagen.

Figura 7: Ejecución de meterpreter vía AppleScript

En el video puede mostrarse un ejemplo de utilización de payload para lograr acceso a la máquina, tras la ejecución de la macro. Es bastante similar a la utilización de esta técnica en máquinas Windows.

Figura 8: Poc de MacPhis para obtención de una sesión meterpreter

Sería interesante analizar los resultados de los ficheros ofimáticos con el objetivo de ver el ratio de detección que tendríamos en nuestra prueba de concienciación. Quizá el menos intrusivo fuera el método beacon, por lo que podría ser más fácil de utilizar en una prueba de concienciación. Sin duda, una herramienta interesante para tener en los proyectos de Ethical Hacking y para ampliar el arsenal de técnicas y herramientas de Hacking macOS/OSX.

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en ElevenPaths