viernes, julio 31, 2015

Cómo controlar un troyano en un equipo desconectado de la red usando SSIDs WiFi maliciosos #Hacking #WiFi

Dicen que un equipo desconectado de la red es un equipo seguro, pero según las situaciones esto puede ser cierto, o no serlo. En el caso de Stuxnet, el ataque se produjo por una conexión basada en la conexión de un USB, algo que podríamos llamar una conexión intermitente. En todos esos casos, al final, el equipo estaba desconectado de la red... pero no lo suficiente. De hecho, hace tiempo en este blog se habló de lo que se llamaron los Hidden-Links de las redes de una organización, muchas de ellas formadas por conexiones USB, enlaces Bluetooth, modems 3G/4G conectados a equipos, discos duros externos o enlaces a puntos de acceso WiFi.

Figura 1. Cómo controlar un troyano en un equipo desconectado de la red usando SSIDs WiFi maliciosos

Visto esto, la pregunta que quería responderme a mí mismo era, ¿hasta que punto podríamos estar expuestos estando fuera de Internet o de cualquier otro tipo de red? Pues no tan seguro ni tan aislado como se podría pensar. Si tenemos en cuenta los trabajos que se hacen con las técnicas Tempest, la información podría ser sacada con que alguien toque el equipo o, como se ha visto en el último trabajo de la Universidad Ben-Gurion en Israel hasta con un móvil antiguo y obsoleto que esté cerca es posible detectar cambios electromagnéticos de baja potencia producidos en la memoria del equipo para tener una comunicación que envía datos desde el equipo hacia otro destinatario remoto.

Un conexión de red inalámbrica sin conectar a ninguna red WiFi

Para probar un escenario similar, es decir, a tener una conexión de red sin llegar a establecer ninguna conexión de red WiFi decidí hacer mi propio experimento de comunicación entre un equipo troyanizado pero no conectado a ninguna red y un atacante externo. Es decir, supongamos que alguien en el caso similar al de StuxNet hubiera infectado un equipo que está desconectado de toda red, pero ahora quiere enviarle comandos al malware que está en el equipo. ¿Cómo hacerlo? Pues sencillo, la idea es la siguiente:
  1. Se infecta a un equipo con un malware especialmente creado. Por ejemplo vía USB.
  2. Este troyano utilizará las herramientas de red del equipo para buscar redes WiFi cercanas.
  3. Con este módulo se leerán la lista de nombres SSID que hay cercanos.
  4. Los comandos irán directamente en el SSID de las redes cercanas.
Esta técnica no solo puede estar utilizada por atacantes externos para hacer una control remoto de un RAT sin que haya ninguna conexión en el equipo, sino que puede ser utilizado también para, por medio de un programa que genere APs virtuales, sacar datos desde el equipo infectado hacia otro equipo controlado por el atacante.

Para esta Prueba de Concepto he dado el siguiente formato a las SSIDs, para que a través de sencillas expresiones regulares y utilizando las herramientas de red de nuestros sistemas - lo pongo en plural, porque el troyano está escrito en Java, y funciona en Linux, Windows y OS X -, el troyano obtenga una entrada de datos/comandos. Ejemplos usados en las demostraciones:

Figura 2 : Lista de comandos utilizados en las SSID

Gracias al troyano que hemos programado para este experimento - al que he llamado “TroWiSSID” -, podemos utilizar una nomenclatura especial en los SSIDs que tenemos ya prediseñadas, para poder ejecutar código de manera remota y pasiva por medio de comandos. A continuación os pongo un vídeo en el que se puede ver como un equipo troyanizado, el cual a la hora del ataque no tiene red, le ejecutan el primer y segundo comando de la tabla de más arriba por medio de SSIDs con comandos.


Figura 3: PoC de troyano controlado por SSIDs maliciosos en Linux, OSX y Windows

La tabla de comandos expuesta, es una pequeña muestra de lo que se puede hacer, pero el límite es la imaginación. Las instrucciones más atractivas para un atacante serían el envío de comandos multi-línea, ya que por ejemplo, hubiéramos tenido troyanizado un OS X - como se ve en el vídeo -, podríamos ejecutar el exploit de conseguir la elevación de privilegios y haber obtenido acceso root para hacer lo que nos plazca, inclusive sin que este hubiera tenido red.  Como resumen, os dejo aquí algunos pros y contras de este experimento:
- Podemos controlar un objetivo sin que este esté conectado a ninguna red.- Se pueden sacar datos de un equipo usando APs virtuales y SSIDs 
- No se requiere una buena cobertura WiFi sobre el objetivo, pero sí una cierta cercanía. 
- Usando antenas de gran potencia, se pueden controlar equipos o transferir datos desde muy lejos. 
- Si alguien visualiza los SSIDs sería necesario implementar técnicas para que no secuestren el troyano.
Conclusión

Tras este experimento, habría que tener claro que tener una tarjeta WiFi escuchando SSIDs es exactamente igual que tener el equipo conectado a la red, por lo tanto no está desconectado 100% y en el mapa de Hidden Links de una red habría que añadir todos los SSIDs cercanos a los equipos con tarjeta de red WiFi. Para ello, lo mejor es controlar muy bien el espacio de red WiFi que se tiene en la zona geográfica en la que están los equipos que se quieren tener "desconectados". Con un simple dispositivo móvil es posible tener el control de los SSIDs con comandos y sacar datos o enviar órdenes a los equipos infectados de una red. En tus proceso de fortificación de Linux o de fortificación de Windows, acuérdate de apagar la WiFi si no la usas.

Un saludo,

Autor: Christian Prieto, escritor del BlogX86.NET

8 comentarios:

Anónimo dijo...

Un momento, esto me suena... ¿No hacian algo parecido en el último capítulo de Mr. Robot al infectar el ordenador de un policía y usando el 3/4G, de alguna forma acceder a la red de una prisión?

Anónimo dijo...

Justo y acabo de terminar ese capitulo de Mr. Robot ( "br4ve-trave1er.asf" ) y me surgio la misma duda, Saludos Chema!

Sinkmanu dijo...

Interesante.. Estaría bien hacer la prueba de concepto también con Android :)

Anónimo dijo...

El post muy bueno, pero la pega que tiene es que en los entornos de alta seguridad siempre se debe deshabilitar todas las comunicaciones (GPUs controlando las comunicaciones, desinstalción de drives, incluso desconesión física de elementos de red y comunicación del PC) a parte de que por procedimiento las buenas prácticas recomiendan hacer auditorias periódicas sobre las redes Wi-Fi, etc. Buena PoC pero no le veo mucha aplicación práctica a entornos de alta seguridad (entornos aislados), aunque cada organización es un mundo.

Pablo González dijo...

Interesante Christian.

Gran artículo ;)

Anónimo dijo...

Hay cosas,como esta, que diferencian a los que saben de los dicen saber.
Interesante pq permite introducir un equipo infectado "dormido" en un entorno seguro
y con una buena señal "despertar" el troyano que puede hacer cosas más útiles q mostrar mensajes.
Muy bueno y , creo yo, q abre múltiples posibilidades.
¿ Sería buena idea activar el troyano un tiempo determinado despues de encender el equipo (usando cron) y mantenerlo activo durante, pj 1h, y si en este tiempo no recibe peticiones matar el proceso?

Anónimo dijo...

Algo muy similar habían hecho el año pasado.
http://www.labofapenetrationtester.com/2014/08/Introducing-Gupt.html

Anónimo dijo...

he encontrado en un blog que han hecho algo parecido y ademas es open source por lo que parece
http://codingnice.blogspot.com.es/2015/08/malware-que-funciona-sin-conexion.html

Entrada destacada

10 maneras de sacarle el jugo a tu cuenta de @MyPublicInbox si eres un Perfil Público

Cuando doy una charla a algún amigo, conocido, o a un grupo de personas que quieren conocer MyPublicInbox , siempre se acaban sorprendiendo ...

Entradas populares