Menú principal

lunes, 2 de julio de 2012

Lion: Ataque con Applet y Portal Cautivo en Metasploit

Mac OS X Lion ofrece un sistema de auto-reconocimiento de portales cautivos, que en una red insegura puede ser utilizado para preparar un esquema de ataque. Un portal cautivo es una página web a la que los usuarios son redirigidos cuando se unen a una red, normalmente WiFi, para autenticarse antes de poder utilizar el servicio.  Se suelen encontrar en sitios como hoteles, cafeterías, universidades, centros comerciales, aeropuertos, etcétera. Esta característica también está disponible en iOS.

Esta función, en una red insegura puede representar un riesgo de seguridad general del equipo y del usuario, tal y como explican en Secure State, ya que es perfecta para preparar un ataque. El ataque es posible, ya que es conocida la prueba que Mac OS X Lion realiza para detectar la existencia del portal cautivo, que es la petición de la URL:
http://www.apple.com/library/test/success.html
Cuando esta petición falla se abre una ventana especial en el navegador para el portal cautivo. Este tipo de comportamiento está preparado para los portales cautivos que se ofrecen en redes inalámbricas abiertas, no con cifrado WEP o WPA, y un atacante puede utilizarlo como vamos a ver ahora mismo.

La descripción general del ataque

Los atacantes pueden controlar la página del portal cautivo mediante el uso de técnicas ya conocidas, como las empleadas, por ejemplo, por el script Karmetasploit. Se pueden configurar servidores DHCP y DNS, para manejar las comunicaciones de la víctima, incluso monitorizar el tráfico completo, una vez que se ha conseguido un esquema de man in the middle.

El objetivo es interceptar la petición al dominio www.apple.com que realiza Mac OS X Lion para detectar el portal cautivo. Así, una vez que el atacante puede redirigir el tráfico del cliente al sistema del atacante, en lugar de a Apple, se puede realizar una variedad enorme de ataques client side attack.

Con el módulo auxiliary/server/http se podrían capturar cookies de la víctima, mediante el uso de alguna página gancho. Pero quizá uno de los más interesantes es el uso de un Applet de Java y conseguir una shell reversa con Meterpreter para Mac OS X.

Este ataque no es nada nuevo, y simplemente se reduce a que a la víctima le saldrá una ventana con un Applet que pedirá autorización simulando ser parte del portal cautivo. Cuando la víctima acepte, se ejecutará la sesión de Meterpreter devolviendo el control a la máquina del atacante. 

El escenario

Supongamos que nos situamos en una famosa tienda de café. Los usuarios van con sus equipos Mac OS X Lion y aprovechan para navegar, consultar el correo, realizar sus gestiones bancarias, lo típico de un café. Es razonable suponer que CoffeShopX podría ser un SSID válido recordado por su Mac Book Air/Pro. Un atacante establece un rogue AP abierto de WiFi emitiendo el SSID CoffeShopX, mientras que también hace de DHCP y DNS. Una vez que la víctima con su Mac se une a la red inalámbrica - el atacante se aprovecha de la no validación del BSSID por parte de Mac OS X Lion y esto propicia múltiples esquemas de ataque -, la solicitud a www.apple.com será redireccionada al atacante. ¿Cómo conseguir la shell de MeterpreterMediante el uso de los siguientes pasos.

  • Conectar a una red inalámbrica. El atacante creará su propia red con un rogue AP spoofeando el SSID original, por ejemplo con Karmetasploit. Para garantizar que el AP original sea inútil, se puede hacer antes un ataque de agotamiento de direcciones IP en el servidor DHCP original.
  • Utilizar el módulo auxiliary/server/dhcp para ejecutar el servidor rogue DHCP.

Figura 1: Configuración DHCP

  •  Utilizar el módulo auxiliary/server/fakedns para configurar un servidor DNS que falsifique las peticiones de resolución de nombres. La dirección IP que se devolverá será la del atacante. 

Figura 2: Configuración DNS

  • Utilizar el módulo exploit/multi/browser/java_signed_applet para configurar un servidor web malicioso. La variable SRVPORT se deja en el puerto 8080, el URIPATH se establece en /portal y no hay que configurar mucho más, simplemente indicar que SRVHOST es la dirección IP del atacante.

Figura 3: Configuración del módulo java_signed_applet

  •  A continuación, en un servidor Apache, se debe configurar una página web, index.html. Esta página será la mostrada por el atacante cuando se realicen las peticiones al dominio de Apple, al puerto 80. Esta página redirige al exploit de Java

Figura 4: Código de la página web montada en Apache

  •  Toca esperar las conexiones de los usuarios, el proceso pasará a ser automático y se conectarán nada más entrar a la red. 

Figura 5: Sesión inversa de Meterpreter

El ataque funcionará si el usuario dispone de Java en su equipo, cosa no muy dificíl después de que se encuentre en billones de dispositivos en el mundo según el eslogan de Java. Cuando los usuarios que se conectan a la falsa red ven la carga de Java dentro de su navegador en la página del portal cautivo, tendrán 2 opciones permitir la ejecución o no, si pulsan en permitir se creará la sesión inversa de Meterpreter.

Figura 6: El supuesto portal cautivo solicitando autorización para el Applet Java

Os recomendamos que controléis el BSSID real al que se conecta nuestro equipo, y sobretodo extremeis las precauciones en hoteles, cafeterías, aeropuertos, etcétera. Esta técnica, aunque tiene una parte basada en la ingeniería social, es probable que engañe a muchos, que piensen que es la manera normal de conectarse al portal. Si ya te has conectado antes a ese portal cautivo... no piques.

Si quieres aprender más sobre cómo funciona Metasploit, puedes leer el libro de Pablo González Metasploit para Pentesters

No hay comentarios:

Publicar un comentario

Entrada destacada

Proteger tu cuenta de Google y de Gmail con Latch Cloud TOTP #Latch #Gmail #Google

La semana pasada se liberó la nueva versión de Latch y nuestro compañero Chema Alonso hizo un repaso de todo ello en su artículo Latch...

Otras historias relacionadas

Entradas populares