EvilSSDP: Cómo poner dispositivos maliciosos en la red en un ejercicio de Red Team

El año pasado presentamos en BlackHat Europe 2019 una herramienta llamada HomePwn. A finales de 2018 estuve estudiando un poco el funcionamiento del protocolo SSDP. Un protocolo que sirve para que las máquinas puedan descubrir de manera sencilla otros dispositivos en una red. Es fácil, cuando cualquier usuario se compra, una tele, bombillas inteligentes, un NAS, una tostadora conectada a Internet, etcétera, tiene que existir un procedimiento sencillo para que los dispositivos se encuentren y conozcan los servicios que otros ofrecen.

Figura 1: EvilSSDP: Cómo poner dispositivos maliciosos en la red en un ejercicio de Red Team

Empecé a estudiar el SSDP gracias al ChromeCast, otro dispositivo de “conéctame a una red” y disfruta. Aquí surgió HomePwn, aunque algunos no lo sepan, y fue así como se hizo una prueba de concepto en Ruby. Más tarde, llevé el proyecto a mis compañeros de Ideas Locas donde se hizo un gran trabajo. El objetivo de HomePwn principal era aprovechar este tipo de protocolos y otros para enumerar dispositivos en una red, sobretodo, dispositivos que no fueran ordenadores al uso. El objetivo era integrar módulos de Ethical Hacking para dichos dispositivos.

Figura 2: HomePwn Paper

Más tarde, fueron surgiendo nuevas ideas y llegó la idea del pentesting a todos esos dispositivos que puedes tener en una empresa, que utilizan tecnologías que están en un nuestro día a día, pero que van más allá de un simple pentesting a una máquina al uso. Aparecieron módulos para tratar BLE, para jugar con NFC. HomePwn creció y llegó a BlackHat con un gran número de módulos y pruebas que mostraban el potencial de la herramienta. En el siguiente video se puede ver la demo de BlackHat con HomePwn.


Figura 3: Demo de HomePWN en BlackHat
En el artículo de hoy quería reflexionar sobre una de las opciones que se barajó con HomePwn y, que después de ver esta herramienta, se puede incorporar de manera sencilla. La herramienta EvilSSDP .

EvilSSDP

Esta herramienta implementa una prueba de concepto, mezclando el spoofing con el phishing con un objetivo: capturar credenciales mediante el spoofing de dispositivos en una red empresarial. La idea es muy interesante, ya que se abusa del protocolo SSDP para anunciar que hay un dispositivo en la red, cuando realmente éste no es tal.

Figura 4: EvilSSDP en GitHub

Es la herramienta EvilSSDP la que está “comportándose” como un dispositivo de red que no es. Cuando el usuario accede a dicho dispositivo se encontrará con un panel de login, digamos que “el que toque” en función de la plantilla o “spoofing” hecho.

Figura 5: Libro de "Empire: Hacking Avanzado en el Read Team" de 0xWord

Como se puede ver la idea es sencilla, pero bastante potente de cara a un Ethical Hacking o un ejercicio de Red Team. Como se indica en la descripción del proyecto EvilSSDP permite hacer spoof sobre SSDP y crear dispositivos UPnP “fake”. El objetivo es “robar” credenciales e incluso jugar con el protocolo SMB para credenciales de red, en ese caso.

Probando EvilSSDP

La instalación es trivial, simplemente hacer un git clone sobre la URL y tendremos descargado EvilSSDP. Es importante que tengamos Python3 en el equipo, ya que es un requisito. Viendo la ayuda de la herramienta, tal y como se puede ver en la imagen donde lo hemos instalado en nuestro Kali Linux, queda claro la sencillez de la herramienta.

Figura 6: EvilSSDP en nuestro Kali Linux

La herramienta trae una carpeta denomina templates. Esta carpeta muestra las diferentes plantillas que pueden ser utilizadas para spoofear dispositivos. Este es el mecanismo por el que la herramienta puede crecer. Crear plantillas es algo sencillo y que, simplemente, con incluir en dicha carpeta estaría preparado. Al final, cada template consta de:

- El fichero XML device. Aquí viene la descripción de la lista de servicios y la URL de presentación. Apunta también al fichero present, en el tag “presentationURL”. 

- El fichero XML service. 

- El fichero HTML present. Es la web que se presentará y que será el phishing.

Visto. Como se puede ver es fácil crear un dispositivo “fake”. Lo que hay que hacer es generar el spoof en la red, pero esto no es complejo, hay que generar el tráfico SSDP dando a conocer dicho dispositivo. Los replies se generan cuando hay peticiones de descubrimiento del SSDP, por lo que cuando el usuario acceda a “Network” en un sistema Windows, éste hará el descubrimiento automático y nuestro EvilSSDP responderá.

Lanzando EvilSSDP

Ahora vamos a probar a lanzarlo. Lo primero va a ser crear un dispositivo “fake” de escáner. El típico recurso como una impresora o escáner que podemos tener conectado a la red local en cualquier sitio. La sintaxis de ejecución es muy sencilla:

evil_ssdp.py [interfaz de red] –template [template a utilizar]

Figura 7: Usando la template scanner

En este instante, ya tenemos EvilSSDP en activo. En la siguiente imagen, se puede ver el anuncio y vemos una petición que viene de la dirección IP 10.0.0.2. Esa máquina es un Windows 7 que tenemos preparado. Se puede ver fácilmente, por el User-Agent que utiliza. Solicita la descripción a través del GET.

Figura 8: El usuario hace clic

Cuando el usuario haga clic sobre el dispositivo, se abrirá un navegador y se redirige a la URL de la directiva “PresentationURL” del fichero device.xml. En ese momento, se le presenta una web falsa que, en caso de que el usuario introduzca datos, estos son recogidos. Este tipo de técnica puede ser muy útil en un Ethical Hacking o en un ejercicio de Red Team, como comenté anteriormente. En la imagen siguiente se pueden ver las credenciales introducidas en el navegador del  equipo cliente con Windows 7 en el apartado de  “[CREDS GIVEN]".

Figura 9: Redirección a la URL controlada y Credenciales obtenidas

Ahora vamos a hacer un ejemplo con Office365. La plantilla que viene en EvilSSDP es para spoofear un Backup Online de Office 365. El procedimiento es igual que el anterior, solo que cambiando la plantilla. Como se puede ver en la imagen, veremos un dispositivo llamado “Office365 Backups”.

Figura 10: Falso dispositivo de Office365 backups

Si hacemos doble clic en ese dispositivo se nos abrirá un navegador con la siguiente web. Se puede ver fácilmente el ataque de phishing (o no) por la dirección URL. Pero... ¿tienes a todos tus usuarios entrenados para descubrir el ataque?

Figura 11: Phishing de Office365 en la red local

Al introducir credenciales obtendremos algo parecido a lo que hicimos antes. En la siguiente imagen se puede ver todo el intercambio de mensajes que nos da la aplicación con este caso. De nuevo, vemos el CREDS GIVEN.

Figura 12: Captura de credenciales en el ataque de Phishing

Lo más interesante de todo es proceso es el potencial que tiene esto en un Ethical Hacking o ejercicio de Red Team, ya que puede ser utilizado para encontrar caminos en el test de intrusión que antes no teníamos. Los vectores “no comunes” pueden aportar una gran cantidad de casos de éxito, ya que la concienciación y el conocimiento de las empresas pueden ir en su contra ante el pentester.

Figura 13: Hacking Windows

Sin duda, curiosa técnica de Hacking Windows que debemos controlar y, además, la herramienta permite fácilmente reutilizarla para el caso de trabajo que tengamos entre manos. Es decir, si estás en un pentesting y tienes que hacer uso de ella, pero la plantilla o el caso de uso que necesitas no está, puedes fácilmente incorporarlo. Metemos la herramienta EvilSSDP en la mochila del pentester.

Saludos,

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell” y de "Empire: Hacking Avanzado en el Red Team", Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDCO de Telefónica.  Para consultas puedes usar el Buzón Público para contactar con Pablo González

Figura 14: Contactar con Pablo González

HomePWN: Cómo resolver el CTF BLE de Sh3llCOn

El otro día, mi compañero Pablo González me propuso un reto, resolver el Reto BLE (BlueTooth Low Energy) del CTF (Capture The Flag) que presentó Pablo en la Sh3llCON y que explicó hace poco aquí. La única condición era utilizar exclusivamente HomePWN, herramienta que desarrollamos para el pentesting de dispositivos IoT.

Figura 1: HomePWN: Cómo resolver el CTF BLE de ShellCOn

Como ya contó Pablo, el objetivo de este CTF es obtener un flag resolviendo una serie de retos, para ello se interactuará mediante BLE con una tarjeta MicroBIT cargada con el script de la prueba tal y como explicamos en este anterior post.

Figura 2: HomePWN en GitHub. Herramienta de penttesting IoT

Empecé el reto confiado, ya que como hemos escrito anteriormente, HomePWN dispone de una gran cantidad de módulos orientados al BLE, así que abrí una máquina virtual con la herramienta, cogí un USB BlueTooth y me puse manos a la obra.

Resolución del CTF BLE

Lo primero fue cargar el módulo discovery/ble, aquí no tuve que modificar las opciones por defecto, ya que la interfaz estándar es la hci0 y no quería filtrar dispositivos por intensidad. Una vez ejecutado el módulo, estos fueron los resultados.

Figura 3: Resultados del módulo discovery/ble

Ya en esta lista podemos ver el dispositivo que estamos buscando, y podremos referenciarlo en los sucesivos módulos gracias a la dirección MAC. Lo siguiente sería cargar un nuevo módulo para ver sus atributos. Nos dirigimos a ble/read-characteristics y metemos las opciones necesarias.

Para este módulo deberemos introducir la dirección capturada (en este caso f4:c5:11:e3:5c:23) y poner como tipo de atributo genérico aleatorio, como nos indicaba el módulo anterior. Al ejecutar el comando run obtenemos lo siguiente.

Figura 4: Resultados del módulo ble/read-characteristics

Viendo esta lista de características, quise suscribirme a la penúltima de ellas para escribir en la última, con la esperanza de que me devolviera un resultado. El problema es que, debido a la implementación de los módulos, al suscribirme bloqueaba la Micro:bit, impidiendo la escritura. ¿Qué hacer ahora?. Pues es buen momento de crear un nuevo módulo para resolver el problema.

La suerte es que en HomePWN es muy sencillo crear un nuevo módulo. Lo único que hay que hacer es coger el "Template" que se encuentra en el fichero modules/_template.py y copiarlo al nuevo documento que hemos creado en la carpeta donde queremos agrupar nuestra nueva funcionalidad. En nuestro caso dentro de modules/ble.

Figura 5: Libros de Python para Pentesters y Hacking con Python

Llamaremos a nuestro módulo subscribe-and-write, y primero rellenaremos la información sobre él en el diccionario information. Luego hay que añadir los argumentos que queremos manejar en el módulo, dentro del diccionario options. Además, añadiremos la función auxiliar update_complete_set para autocompletar algunos de estos argumentos.

Figura 6: Módulo ble/subscribe-and-write

Después modificaremos el script de ble/subscribe, en este caso para que se suscriba a la característica y en la misma conexión envíe los paquetes, evitando así el bloqueo del dispositivo. Por último añadiremos una función auxiliar para transformar los bytes recibidos en hexadecimal y ASCII y así mejorar la visualización.

Con el módulo terminado, pude continuar el reto. Primero ejecuté este nuevo módulo creado, eligiendo como uuid-subcribe la característica con propiedad INDICATE y para escribir seleccioné la característica con propiedad WRITE NO RESPONSE WRITE. Por último escribí en el campo de data 0#, ya que es el mensaje que quería enviar. Al ejecutarlo vi este resultado.

Figura 7: Resultado de la ejecución del módulo

A partir de aquí ya conocemos el procedimiento del post anterior. Solo había que cambiar el campo data hasta que dar con el número que nos devuelve el flag con el que completamos el CTF.

Figura 8: Flag conseguido

Como habéis podido ver, es muy sencillo completar este reto con HomePWN, y es bastante asequible crear un módulo específico para ampliar la funcionalidad de la herramienta.

Espero que os haya gustado, os animo a descargaros la herramienta e intentar resolver el reto por vuestra cuenta.

¡Un saludo!

Autor: Lucas Fernández Aragón (@lucferbux) Security Researcher del equipo de Ideas Locas de CDCO en Telefónica.

Figura: Contactar con Lucas Fernández Aragón