OpenWifiPass: Hacking iPhones con WiFi Sharing Protocol

En el artículo de hoy vamos a hablar de OpenWifiPass, que es una prueba de concepto que se ha publicado recientemente y está ligada con los trabajos “Wi-Fi Sharing for All: Reverse Engineering and Breaking the Apple Wi-Fi Password Sharing Protocol” y “Disrupting Continuity of Apple’s Wireless Ecosystem Security: New Tracking, DoS, and MitM Attacks on iOS and macOS Through Bluetooth Low Energy, AWDL, and Wi-Fi” centrados en analizar el uso que Apple hace las tecnologías BLE. 

Figura 1: OpenWifiPass: Hacking iPhones con WiFi Sharing Protocol

En el pasado en Ideas Locas ya tomamos una investigación similar, la popular apple_bleee, como base para crear Airdrop Crazy y añadirlo a la lista de herramientas y utilidades para usar en cualquier proyecto de Hacking iOS: iPhone & iPad, y en este caso esta PoC se basa en las dos citadas, además de utilizar el mismo conjunto de protocolos.

Figura 2: Libro de Hacking iOS (iPhone & iPad) 2ª Edición
de Chema Alonso, Alejandro Ramos, Igor Lukic, Ioseba Palop.

-

Hoy hablaremos del proyecto OpenWifiPass el cual permite escanear en busca de peticiones Bluetooth de dispositivos iPhone/iPad que están solicitando contraseña de WiFi para conectarse a una red. Esta es una característica de los dispositivos de Apple que si tienes un iPhone, seguramente la hayas utilizado en algún momento. Imagínate que estás en casa de un amigo y en vez de darte la contraseña para que la introduzcas, tu iPhone solicita que le compartan la contraseña de la WiFi al dueño de la casa, que también tiene un iPhone.

Figura 3: Opción de compartir la clave de la WiFi en iPhone

Como se indica en el Github del proyecto de OpenWifiPass es una prueba experimental de ingeniería inversa del proyecto Open Wireless Link. El código se proporciona con fines de investigación y educativos. Como prueba de concepto que es el proyecto no ha sido probado y está incompleto, aunque funcional para la prueba de concepto. ¿Qué es incompleto? Realmente el código no verifica la identidad del solicitante de la contraseña a través del protocolo.

Requisitos para probar el proyecto

Los requisitos para probar el proyecto son pocos, nos vale con tener a mano una Raspberry Pi 4 y disponer de Raspbian o cualquier distro GNU/Linux que ejecutemos en una Raspberry. Desde el punto de vista de dependencias se hará uso de bluepy, pero el proceso de instalación es realmente sencillo, por lo que no habrá problemas. El código de la herramienta está escrito en Python.

Figura 4: "Raspberry Pi para Hackers & Makers: PoCs & Hacks Just For Fun"
de Amador Aparicio, Pablo Abel Criado y Héctor Alonso

El hacerlo con Raspberry es por darle un toque "maker" y hacerlo "portable" y porque tiene el adaptador de Bluetooth integrado y va a ser rápido montar el proyecto, pero podría hacerse en cualquier entorno con un adaptador Bluetooth compatible. El adaptador debe poder utilizar Bluetooth Low-Energy.

Figura 5: Repositorio GitHub de OpenWifiPass

¿Cómo instalamos el proyecto? Este paso es uno de los más sencillos, para el tipo de herramientas o pruebas de concepto con los que nos movemos generalmente. Lo primero será hacer el git clone del proyecto y, posteriormente, ejecutar la siguiente instrucción pip3 install ./openwifipass. La instalación es bastante rápida y nos prepara un módulo llamado openwifipass. Para la ejecución de la herramienta debemos ejecutar la instrucción:

sudo -E Python3 -m openwifipass --ssid [nombre SSID de la rea a compartir contraseña WiFi] --psk [contraseña que se quiere enviar al dispositivo].

Cuando lo arrancamos, veremos que se queda en “Start Scanning” un rato, y parece que no ocurre nada. Esto es normal, ya que debemos esperar a que desde un iPhone/iPad nos soliciten la contraseña WiFi de una red conocida. Nosotros, en el ejemplo, estamos ofreciendo la red bit_up, por lo que cuando un iPhone/iPad en nuestro alcance, intente conectarse a la red se produce el intercambio de información.

Figura 6: Arrancando OpenWifipass 

Nos estamos haciendo pasar por un dispositivo de Apple y estamos negociando y entregando la contraseña WiFi que el usuario quiere, y en el momento en que algún dispositivo se quiera conectar a la red, se entrega la password que hemos decidido nosotros.

Figura 7: Un dispositivo ha pedido la password y se la hemos entregado

Mientras tanto en el dispositivo móvil encontramos lo siguiente, la contraseña se configura automáticamente y se conecta contra la red WiFi. En la imagen no se visualiza, pero en el apartado de “contraseña” faltarían los puntos de la contraseña introduciéndose y conectando con la red.

Figura 8: Contraseña entregada al iPhone

La prueba de concepto está genial. El trabajo es brillante y todos los detalles de la investigación se irán publicando por parte de sus investigadores, pero lo que nos queda claro es que es más que utilizable, por ejemplo, en un ejercicio de Red Team en múltiples escenarios. Pongamos que necesitamos ganar acceso a un sitio o conseguir información de un objetivo concreto, dentro del ejercicio de Red Team. 

Figura 9: El Red Team de la empresa
de Eduardo Arriols en 0xWord

El montaje de una red WiFi a través de un punto de acceso bajo nuestro control - un Rogue AP - con el SSID de “nombre_empresa” puede ser llamativo para muchos. En el momento que el usuario intente conectarse desde iOS, tendríamos montado la rasp con la PoC y le proporcionaríamos la contraseña al usuario. En ese instante, el usuario se conecta a nuestro punto de acceso WiFi y toda su comunicación pasa por nosotros en un esquema de Man in the middle. El esquema y el ataque mola, muy aprovechable en un ejercicio de Red Team, pero eso lo dejamos para otro artículo.

 

Saludos,

Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters: Gold Edition", "Hacking con Metasploit: Advanced Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root",  “Pentesting con Powershell (2ª Edición)”, "Pentesting con Kali Silver Edition" 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 - Conseguir 100 Tempos Gratis en MyPublicInbox

 Contactar con Pablo González

BlackHat Arsenal: Tools for Research & Pentesting [Parte 2 de 2] iBombShell

Y llegó la hora de iBombShell. La herramienta que presentamos en BlackHat 2018. Sobre iBombShell se contó cómo empezó y que se quería hacer al principio. El nacimiento del modo Everywhere, una shell para Ethical Hacking que descargásemos de forma dinámica y que nos permitiera disponer de una gran cantidad de funcionalidades de pentesting en cualquier lugar, gracias al uso de Powershell.

Figura 8: BlackHat Arsenal: Tools for Research & Pentesting [Parte 2 de 2] iBombShell

En el momento que necesitásemos de una nueva funcionalidad se descargara a memoria esta funcionalidad, sin pasar por disco duro en ningún instante. En esta imagen, se puede ver la arquitectura original de iBombShell.

Figura 9: Arquitectura de iBombShell

Todo ello, aprovechando las capacidades que, como os he dicho ofrece el mundo del Pentesting con Powershell, al que le dediqué un año de mi trabajo y que plasmé en este libro de 0xWord.

Figura 10: Pentesting con PowerShell

Hablando del modo Everywhere y del modo de trabajo se hizo una breve demo en la charla que contaba cómo se cargaba dinámicamente una consola de iBombShell en un Windows 10 y cómo se podía ir descargando diferentes funcionalidades en función de las necesidades.


Figura 11: iBombShell y UAC Bypass a Windows 10 con modo Everywhere
Después hablé del modo Silently y su nacimiento. Lo vimos claro, si tenemos una Shell de pentesting dinámica, ¿Por qué no convertirla en Warrior? ¿Por qué no verlo como un agente de post-explotación? ¿Una Powershell oculta? Así nació dicho módulo. De la mano de mi compañero Álvaro Nuñez-Romero empezamos a trabajar en el concepto del C2 escrito en el poderoso lenguaje de los pentesters: Python.

Figura 12: iBombShell en Python

El esquema de conexión en el modo Silently es realmente sencillo y utiliza peticiones HTTP para evitar mantener una conexión abierta. Esto es parecido al funcionamiento de Empire.

Figura 13: Funcionamiento de iBombShell en modo Warrior

Como últimas novedades sobre el proyecto quise recordar que disponemos de una rama Dev en el Github de iBombShell, donde se puede ver qué será lo próximo que estará en master. Por ejemplo, hablamos de AMSI y su bypass, entre otras cosas. Por último, hice una demo sobre esto y mostrar el potencial del modo Silently dentro de la fase de post-explotación.


Figura 14: PoC Cómo saltarse AMSI y desactivar Windows Defender
Para conocer los detalles concretos de todo el proyecto y cómo funciona cada uno de sus módulos, os dejo aquí incrustado el paper que publicamos en ElevenPaths sobre iBombShell para que lo conozcáis en mayor detalle.

Figura 15: iBombShell: Dynamic Remote Shell en ElevenPaths

Y para completar todo sobre iBombShell os dejo las referencias a los artículos que hemos publicado, con ejemplos de uso y ampliación:

- [GitHub] iBombShell
- [White Paper] iBombShell: Dynamic Remote Shell
- [Blog Post] Pentesting MacOS & Windows with iBombShell
- [Blog Post] iBombShell: Tu Shell de pentesting en MacOS con PowerShell
- [Blog Post] iBombShell: Creando una función para MacOS
- [Blog Post] iBombShell: Environment Injection in Windows 10
- [Blog Post] iBombShell: Crear módulo para extracción de claves SSH privadas
- [Blog Post] iBombShell: UAC Bypass con Mocking Trusted Directories
- [Blog Post] iBombShell: Nuevas funciones presentadas en BlackHat Europe 2018
- [Blog Post] iBombShell: Cómo saltarse AMSI y Windows Defender
- [Blog Post] iBombShell: Cómo hacer un popup phishing

Como veis, la charla fue un resumen breve de nuestro trabajo en BlackHat Europe 2017 y 2018 presentado y mostrado de forma práctica. Ya trabajamos en el futuro, en nuevas ideas, pero intentamos mantener vivos los proyectos que arrancamos. Ahora de la mano de Josué Encinar que nos ayuda en lo que puede en nuevas ideas y antiguos trabajos. Estamos orgullosos de lo que hacemos, de lo que presentamos e intentamos ayudar en lo que podamos.

- BlackHat Arsenal: Tools for Research & Pentesting [Parte 1 de 2] UAC-a-Mola
- BlackHat Arsenal: Tools for Research & Pentesting [Parte 2 de 2] iBombShell

Autor: Pablo González Pérez (@pablogonzalezpe), escritor de los libros "Metasploit para Pentesters", "Hacking con Metasploit: Advance Pentesting" "Hacking Windows", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”, Microsoft MVP en Seguridad y Security Researcher en el equipo de "Ideas Locas" de la unidad CDO de Telefónica.

¿Qué iPhone has pareado a tu Windows o tu macOS/OSX?

Con la resaca de DirtyTooth aún presente y con una nueva charla en RootedCON disfrutada, seguimos trabajando en ElevenPaths y LUCA D3 para innovar, investigar y jugar con la tecnología diariamente. La semana antes de la charla de DirtyTooth  Chema Alonso me pidió que mirase cómo se guarda el Trusted File que genera Apple iTunes por cada dispositivo iPhone que conectamos y el equipo Windows o macOS  al que se conecta.

Figura 1: ¿Qué iPhone has pareado a tu Windows o tu macOS/OSX?

Estos pareados pueden ser peligrosos para los terminales iPhone, que pueden ser atacados como se explica en el libro de Hacking iOS: iPhone & iPad desde el equipo Windows o macOS pareado, y Chema Alonso quería que trabajásemos en una herramienta de despareado seguro. En esta charla con casi medio millón de visualizaciones cuenta más detalles de estos riesgos de parear el terminal con un equipo.


Figura 2: Tu iPhone es tan (IN)Seguro como tu Windows
El fichero donde se almacena es de tipo PLIST, en el que se almacena información interesante y que permite que el programa Apple iTunes pueda acceder al contenido del iPhone al conectarlo al equipo después de que este haya sido pareado,  sin necesidad de generar un nuevo proceso de confianza o de introducir el passcode.

En otras palabras, cuando una aplicación de Apple iTunes es marcada como de confianza, el dispositivo conectado se dejará observar y manipular por este equipo. Si nosotros conectamos nuestro dispositivo iPhone o iPad a un equipo de no confianza y confiamos en dicho equipo deberíamos tener en cuenta que, una vez desconecte el dispositivo, debería desparear o hacer perder dicha confianza entre mi iPhone y el equipo.

Figura 3: Proceso de pareado con equipo y confianza con el mismo

Lo primero que hice fue buscar la ruta dónde se almacena, tanto en macOS / OS X como en los sistemas Microsoft Windows, el fichero de confianza entre dispositivo y equipo. La ruta en Windows es %programdata%/Apple/Lockdown, mientras que en macOS/OS X la ruta es /var/db/lockdown.

¿Qué hay en esas rutas?

En estas rutas encontraremos dos tipos de archivos. El primer tipo es denominado SystemConfiguration.plist. Este archivo contiene el SystemBUID.plist, el cual es un token que se comparte entre el equipo anfitrión y los dispositivos que se conectan y con los que se genera la confianza. El segundo tipo de archivo es el fichero de confianza en sí. Es almacenado con el siguiente nombre [UDID dispositivo].plist. Es decir, por cada dispositivo con el que se genera confianza se almacena un fichero en el que se indica el UDID del dispositivo y tiene extensión PLIST.

Figura 4: Archivos en /var/db/lockdown

Con el UDID del dispositivo se pueden hacer cosas interesantes, ya que se podría preparar una aplicación para dicho dispositivo e intentar que la víctima instalara la aplicación. El UDID permite crear un Provisioning Profile, el cual si se instala en el equipo podría ejecutar dicha aplicación creada. Podemos ver el UDID de un dispositivo como un elemento interesante de cara a un APT por medio de un troyano para iPhone.

¿Qué hay dentro de los archivos PLIST?

En estos archivos se puede encontrar información interesante como el UDID, visto anteriormente, la MAC Address de la tarjeta de red WiFi y, por consiguiente, la MAC de la tarjeta Bluetooth del dispositivo y los certificados generados para dicha confianza. Otra de las pruebas a realizar es ver la posibilidad de copiar un fichero de confianza y llevarlo a otro equipo.

Figura 5: Sección de un fichero PLIST con información del pareado

Si esto funcionaría podríamos transferir la confianza entre dos equipos, sin que el dispositivo se diera cuenta. Esto es un problema, ya que se podría conseguir acceso al dispositivo, gracias a este tipo de archivos, por lo que, con acceso al equipo de un individuo, se podría acceder a la información del dispositivo.

Generando la PoC para analizar los dispositivos iOS pareados

Lo primero fue hacerse un script sencillo en Ruby que me permitiera listar los dispositivos iOS que hubieran sido conectados y generado confianza con ellos en un equipo. El objetivo era listarlos y sacar algunos datos de interés, por ejemplo, su  dirección MAC de la  tarjeta WiFi y la dirección MAC de la tarjeta BlueTooth, que es siempre suele ser un valor más en la dirección MAC de la WiFi.

Figura 6: Las direcciones MAC WiFI y MAC BlueTooth suelen diferir en un bit en los iOS 

El corazón del script es realmente sencillo. En la imagen se puede ver la parte de parseo del PLIST, es decir, no es el script completo. Del nombre del fichero listado se obtiene el UDID y en el parseo del PLIST se puede obtener el resto de información, en este caso la dirección MAC de la WiFi.

Figura 7: Script para parsear la dirección MAC de la WiFi en el fichero PLIST

Si lanzamos el script contra una máquina macOS/OSX podemos observar que la máquina tiene una serie de dispositivos iOS de confianza almacenados. El script hace un parseo rápido y obtiene información de ellos.

Figura 8: Ejecución del script en Ruby para descubrir los terminales iOS pareados

Además, se nos ocurrió la posibilidad de utilizar esta información para alertar al usuario y poder eliminar dicha información antes de desconectar su iPhone o iPad.

Metasploit y un nuevo módulo de Post-Explotación

Al ver el script en funcionamiento,  el boos me sugerió que lo hiciera para Metasploit. Es un claro ejemplo de módulo de Metasploit para la post-explotación de un sistema. ¿El usuario del sistema tiene dispositivos iOS? ¿Pueden ser un vector de ataque? ¿Tendrá accesible la información de confianza? Con un script de Meterpreter que permita localizar estos ficheros y parsear la información sería suficiente para aprovecharse de un sistema comprometido.

Al migrar el script a Meterpreter, uno puede aprovecharse de algunas clases que Meterpreter ofrece y simplifican, en gran medida, el desarrollo y el potencial de los scripts. A continuación, se puede ver como el código ha sido migrado y logramos un comportamiento similar al anterior.

Figura 9: Ejecución de script para descubrir dispositivos iOS pareados en Metasploit

Además, podríamos incorporar de manera sencilla, mediante el uso del objeto client, la posibilidad de descargar automáticamente a nuestra máquina dichos ficheros, por ejemplo, con client.fs.dir.donwload(ruta fichero). El módulo puede encontrarse en mi Github, aunque se encuentra en versión beta y preliminar. Es realmente sencillo de modificar y ampliar funcionalidades.

Figura 10: Código del módulo de Metasploit de iPhone Pairing Detector

En la imagen, se puede ver un trozo de código del script. El funcionamiento del script de iPhone Pairing Detector es sencillo:

• Comprueba la plataforma. Aunque ahora mismo la versión subida, solo es para Windows, sería muy sencillo modificarlo para que en función de si es OS X o Windows se cargue una ruta u otra. 

• Una vez detecta que es Windows lista los ficheros que hay en la ruta dónde se almacenan los ficheros de confianza. 

• Se obtiene el UDID de los ficheros de confianza. 

• Se procesan los archivos y se obtiene el SystemBUID.

Ampliar la funcionalidad para que los ficheros con UDID se descarguen es sencilla, como se mencionó anteriormente. Por otro lado, también se podría promover el borrado de dicha información con el objetivo de asegurar el sistema y no dejar olvidado tu fichero de confianza, aunque esta funcionalidad, en este contexto, no tendría sentido y sí lo tendría en una herramienta de fortificación.

Figura 11: Libro de Hacking iOS "iPhone & iPad"

En resumen, un nuevo módulo que ayuda a recopilar información sobre un equipo en un proceso de post-explotación. Si quieres ampliar la funcionalidad, tienes disponible el módulo en mi fork de Metasploit en mi Github.

Autor: Pablo González Pérez (@pablogonzalezpe)
Escritor de los libros "Metasploit para Pentesters", "Ethical Hacking", "Got Root" y “Pentesting con Powershell”

Apple se olvida unas webs del Siglo XX en sus servidores #Apple #Descuidos

Como sabéis, Apple es una empresa que cuando le reportas las vulnerabilidades que descubres en sus tecnologías se lo toma bien. Eso sí, no es de los más famosos entre la comunidad de security researchers por sus bug bounties. Debido a que su entorno es grande y entretenido, y teniendo presente que son hacking friendly, cuando hacemos alguna prueba de alguna nueva idea solemos mirar a ver si a Apple le afecta. 

Figura 1: Apple se olvida unas webs del Siglo XX en sus servidores

Hoy no es una vulnerabilidad grande, ni mucho menos, pero sí que nos ha llamado la atención. Se trata de un par de copias de la página web de Apple del año 1999, que aún está disponible y en producción, aunque con extensiones cambiadas. La primera de ellas tiene la extensión .SAVE, está en esta URL y tiene el aspecto que veis a continuación.

Figura 2: Web de Apple de 1999 con extensión .SAVE

Como veis, es la página que Apple tenían en aquel año y que algún administrador decidió cambiar de extensión para hacer una copia o algún cambio. Esto no es nuevo ya que lo vimos también hace un tiempo con las extensiones .ORIGINAL que también se le quedaron a Apple en sus servidores.

Figura 3: Página web de Apple con extensión .ORIGINAL

La segunda, utiliza otra extensión clásica para hacer backups de archivos que no quieres borrar. Se trata de .OLD, y también es la web de Apple de aquel año, aunque con un ligero cambio con respecto a la anterior. Está disponible y haciendo clic en la imagen vas a la web en su publicación actual en los servidores de Apple.

Figura 4: La web de Apple con extensión .OLD

Estos pequeños olvidos en el caso de Apple no son más que curiosidades, pero denotan que no hay una comprobación férrea de todos los archivos que se exponen públicamente a través de los servicios web, ya que a día de hoy no están enlazados en ningún sitio, y solo están hay para que los encuentren los más curiosos de Internet. Eso sí, hay que reconocer que casi es como localizar un Huevo de Pascua al estilo de los que dejan los amigos de Apple en sus tecnologías a lo largo de la historia.  

¿Cómo se llegan a descubrir estas URLs?

Pues tan sencillo como aplicar un proceso de fuzzing dinámico a cada URL que se descubre en la web, tal y como se explica en este artículo y automatizarlo con un sistema de pentesting persistente como Faast que aplique un algoritmo voraz y pruebe todo desde un entorno Cloud.

Figura 5: Web actual de las notas de prensa de Apple

Y eso es todo, nada más que una curiosidad de cómo un poco de ingenio te puede llevar de nuevo a la época antes de Mac OS X y el mundo de los iMac. Y todo ello sin necesidad de usar Archive.org

Saludos Malignos!

10 años después descubres que hay que tapar la Webcam #malware #privacidad

Hace 11 años, exactamente en el año 2005 nació el popular RAT (Remote Administration Tool) Poison Ivy. Las herramientas RAT son un tipo de malware creado especialmente para controlar totalmente un equipo desde una consola centralizada. Su evolución natural les llevaría a convertirse en las populares Botnets de equipos Zombie, donde desde un Command & Control Panel se llegan a gestionar millones de equipos infectados. En el año 2005, cuando aparece la primera versión de Poison Ivy, se empiezan a extender las técnicas de Reverse Shell, o lo que es lo mismo, que el llamado "Server" que se instala en la máquina infectada, es quien realiza la conexión al panel de control para recibir las órdenes y no al revés, como se hacía en malware clásico anteriormente.

Figura 1: 10 años después descubres que hay que tapar la webcam

Poison Ivy fue muy popular durante los años en los que  estuvo en plena evolución, hasta llegar al año 2008 donde apareció su última release, la versión 2.3.2. Después vendrían muchos más que copiarían la mayoría de sus funciones. Entre las muchas que traía la herramienta Poison Ivy estaba un módulo de vigilancia que permitía al atacante activar tu Webcam y grabarte en tu intimidad - y este no fue el primero que lo hizo -. Aquí tenéis una captura hecha por la webcam de una persona infectada con Poison Ivy 2.3.2, del año 2008.

Figura 2: Webcam capture en Poison Ivy versión del año 2008

El primer día que yo descubrí que con herramientas como Poison Ivy era tan fácil para un atacante activar tu Webcam la tapé. Desde hace más de una década llevo la Webcam de todos mis equipos tapados, lo que me generó que mucha gente me preguntara desde ese momento por qué lo hacía. Las nuevas herramientas RAT que fueron siguiendo la estela de Poison Ivy fueron añadiendo todas la misma función, y ver ya esa opción entre la lista de posibilidades no sorprende a nadie de este mundo. En la imagen IndSocket y en este otro artículo tienes Incognito RAT que también funciona con equipos Mac OS X infectados e incluso se controlaba desde un iPhone.

Figura 3: Opción de Webcam Capture en IdnSocket RaT

En el año 2011, ya con mi blog abierto, descubrí la existencia de un foro en el que la gente se dedicaba a infectar personas con RATs, capturarles con la Webcam y compartir el material con todos. Las fotos eran brutales, e incluso había vídeos subidos a Youtube - hoy retirados - que mostraban el proceso completo. Si te aburres, abre Youtube y busca vídeos y tutoriales de RAT. Te sorprenderá ver la gran cantidad de esta familia de malware que existe con la capacidad de grabarte en tu casa y hemos visto que hasta vecinos lo usaban para espiar a sus víctimas.

Figura 4: Un caso de espionaje vía Webcam del año 2013 en España

A partir de ahí, sistemáticamente he ido explicando en multitud de ocasiones el riesgo de no taparse la Webcam, además de explicar que el número de fallos que aparecen y que pueden permitir a un atacante infectarte para activar la Webcam es alto. En el año 2011 un bug en Adobe permitía hacer lo mismo.

Figura 5: Security Innovation Day 2014. En esta charla hacemos la demo de infectar a la víctima con un documento Excel y capturar la webcam con Metasploit

En muchas demostraciones, como en el evento de Creo en Internet en el año 2011 o en el Security Innovation Day 2014, he hecho demos con malware que infecta el equipo y activa la Webcam usando Metasploit, que tiene módulos para eso desde hace infinidad de tiempo, e incluso algún ciberespía ruso ha salido retratado en un proceso de doxing con el que le han activado hasta la webcam de su casa - con sus cortinas último nivel de moda -.

Figura 6: Supuesto ciberespía ruso grabado en su casa

Algunos creen que las Webcam con las luces son más que suficientes, porque si se enciende la luz lo ves, pero incluso hay muchos casos que han demostrado cómo es posible llegar a encender la Webcam sin encender la luz. Al final si hay software de por medio hay posibilidad de que haya un bug para saltarse el proceso.

Figura 7: Recomendaciones de la NSA sobre la Webcam y el micrófono en OS X

Otros creen que por tener Linux ya no es necesario tapar la Webcam como si el software fuera diferente en ellos. Lo curioso es que hace años, pudimos ver ya documentos de la NSA que recomendaban a todos los miembros del gobierno que taparan la webcam y el micrófono para evitar este tipo de espionaje.

Figura 8: Equipo de Moxie Marlinspike en Twitter con la Webcam tapada

Entre los hackers esto es muy común desde hace años y en esta foto tomada al equipo de Moxie Marlinspike cuando era responsable de seguridad de Twitter se podía ver que él hacía lo mismo con  la Webcam de su Mac OS X.

Figura 9: Equipo MacBook de Mark Zuckerberg con la Webcam y el micrófono tapado

Ahora la gente ha visto que Mark Zuckerberg también tapa la webcam y el micrófono de su MacBook y ha vuelto la gente a preguntarse si será excesivo o no hacer esto con su equipo, tablet y dispositivo móvil, que el malware para Android también puede hacer estas cosas.

Figura 10: El iPatch de Latch que tapa mi Webcam

Yo llevo mucho tiempo con la mía tapada, e incluso regalamos para los eventos el popular iPatch con Latch para los asistentes, pero tú eres libre de hacer lo que quieras. Eso sí, "Si no tapas tu Webcam, ponte sexy para salir en Internet".

Saludos Malignos!

Atacar la seguridad HTTPs con un Delorean en Python

Entre la lista de conferencias que se han dado este año en DefCon 23 hay una que tenía ganas de revisar, ya que la daba uno de los mejores hackers españoles, el gran José Selvi. Sus trabajos son siempre elegantes e ingeniosos, como cuando migró JailBreakMe a JailOwnMe para ownear los terminales iPhone - tanto me gustó que le pedí que lo detallara paso a paso para incluirlo en el libro de Hacking iOS -. En esta ocasión, su charla en Las Vegas versaba sobre cómo romper la seguridad de las conexiones HTTPs por medio de un Delorean, una que ya había impartido en Black Hat Europe 2014 pero que no había podido ver todavía.

Figura 1: Atacar la seguridad de HTTPs con un Delorean en Python

Sí, el uso de un Delorean es una forma de hacer entender a todo el mundo que el ataque tiene que ver con las medidas de seguridad que dependen de la fecha del sistema operativo y que, por fallos de seguridad en el protocolo NTP, pueden ser manipuladas para hacer viajar en el tiempo al sistema. Si cuando hablamos de Leap Seconds vimos lo mal que le podía venir a al sistema un segundo introducido, os podéis imaginar si hacemos viajar en el tiempo a los sistemas informáticos durante más tiempo. 

Figura 2: Saltar la seguridad de HSTS con un Delorean

La presentación de la charla la tenéis colgada dentro de la recopilación que han hecho nuestros amigos de Cyberhades con todo el material de DefCon 23, y merece la pena que la veas - incluidas las preciosas fotos de esa ciudad de Valencia tan bonita que tenemos en España -, y en la web de BlackHat Europe 2014 tienes acceso a un WhitePaper donde se recoge el trabajo.

Implementaciones de NTP en sistemas operativos

En la lista de sistemas operativos que ha analizado José Selvi se encuentran Ubuntu, Fedora, OS X y Windows. Todos ellos hacen uso de una forma u otra del protocolo NTPv3 o NTPv4 con configuraciones susceptibles de sufrir un ataque de man in the middle. Esto quiere decir que, un atacante, podría interceptar la petición de sincronización NTP emitida por el sistema operativo y darle una hora arbitraria para configurar de forma maliciosa la hora del sistema operativo.

Figura 3: Petición NTPv4 de Ubuntu vulnerable a man in the middle

Para hacer esto, hay que utilizar algún esquema de man in the middle en redes IPv4 o IPv6 que permita interceptar la petición NTP del cliente. Aceptando que en una red insegura - sin IPSec o sin posibilidad de bloquear los ataques de man in the middle - el protocolo NTP es vulnerable, las medidas de mitigación que tienen los sistemas operativos se basan por tanto en reconocer si alguna de estas peticiones puede reconocerse como maliciosa.

En las diferentes implementaciones Fedora es que más fácil lo pone, ya que hace una petición cada minuto y por tanto se le pueden hacer cambios en la fecha del sistema constantemente. En el caso de Ubuntu la sincronización es cuando se levanta la conexión de una nueva red o se produce un reinicio. En OS X se hace cada ciertos minutos, pero en las últimas versiones depende de la carga de trabajo que tengo el sistema.  Windows es el que lo pone más complicado, ya que tarda días en hacer las peticiones, además de que no permite cambios muy grandes en los tiempos, desechando las peticiones que vienen con grandes saltos, dejando una ventana muy pequeña de ataque.

Figura 4: Cuatro de los cinco modos de funcionamiento que tiene Delorean para viajar en el tiempo

Visto esta primera parte, el resumen sería que, con mayor o menor grado de exposición, si un equipo se conecta a una red insegura, su fecha del sistema puede ser alterada de forma maliciosa por medio de una herramienta escrita en Python, que José Selvi ha bautizado como Delorean.

Ataques a HSTS con el Delorean

Visto esto, que un equipo tenga una fecha maliciosa puede ser aprovechado por un atacante para hacerle mucho daño a un equipo. Uno de los ejemplos que propone José Selvi es el de atacar el protocolo HSTS. Este protocolo cierra la posibilidad de ataques Man in The Middle que se producen cuando se utilizan conexiones HTTP, ya que con HSTS se fuerza al navegador a que la conexión sea siempre por HTTPs cuando un dominio esté en la lista. Esto se hace mediante la configuración del HTTP Header HSTS que envía el servidor web en la primera conexión. A partir de ese momento se le impide al navegador conectarse a un dominio por HTTP mientras el TTL configurado por el HSTS sea mayor que cero. Es decir, que no haya caducado.

Desde las URLs internas de Google Chrome, puedes consultar el estado de la política HSTS que tiene tu navegador para cada dominio, así como los datos del certificado que se espera encontrar al otro lado para que no le den uno falso. Es decir, no solo la política de HSTS, sino también cuál es el certificado del que se está haciendo Certificate Pinning.

Figura 5: Configuración de HSTS para el dominio www.gmail.com en Google Chrome

Sin embargo, usando el Delorean alguien puede llevar la fecha más allá en el tiempo, hacer que caduque el TTL de la configuración HSTS y conseguir una petición HTTP a un dominio para lograr hacer, ahora sí, un ataque de SSLStrip, como el que hacía yo con Evil FOCA para robar las cuentas de Facebook o Gmail usando el ataque de WPAD.

Figura 6: Si consigues deshabilitar HSTS puedes conseguir que el navegador pida Facebook por HTTP

A día de hoy esto no es posible con todos los dominios, ya que algunos navegadores tienen listas preconfiguradas en el código, es decir, hardcodeadas, de conexiones HSTS que no van a realizarse nunca por HTTP - ni la primera vez -. Esta lista la gestiona Google Chrome y la utilizan otros navegadores. Además, cualquiera puede solicitar estar en esa lista mediante este sitio web.

Figura 7: Configuración de política de expiración en lista precargada de certificados

Por suerte o por desgracia, los certificados de esa lista también dependen del tiempo y expiran - y no tardando mucho ya que algunos son horas, otros como Google Chrome 10 semanas -, así que es posible hacer caducar la lista precargada en los navegadores y forzar la conexión HTTP a un sitio web para lograr interceptarla y hacer un man in the middle a esa conexión.

Usando certificados digitales expirados

Otra de las cosas curiosas que se pueden hacer es la de llevar con el Delorean la fecha del sistema a un tiempo en el pasado, con el objeto de lograr que los certificados que hubieran expirando antaño o que hayan sido marcados como caducados, vuelvan a ser válidos. 

Figura 8: Certificado de Diginotar firmado para Google.com que se bloqueó

Así, por ejemplo, José Selvi explica cómo se puede engañar a un navegador para que vuelva a dar por válidos los certificados robados a Diginotar que se hicieron para firmar dominios como Google.com o Live.com. Pero también para conseguir que certificados de las listas CRL que han sido marcados como caducados vuelvan a poder usarse.

Los planificadores de tareas y las actualizaciones de seguridad

Por último, una de las cosas más curiosas que se producen es que, si un equipo cambia su fecha y su hora, todo su planificador de tareas puede dejar de funcionar. Esto hace que las tareas de mantenimiento puedan no realizarse a tiempo o incluso no hacerlo nunca. En el caso de Windows, una de las cosas que se puede hacer es llevar la fecha del sistema a un tiempo en el futuro, y cuando se planifique la siguiente actualización de software mediante Windows Update, volver a llevar el sistema a su hora actual. Esto, como efecto lateral dejaría a un equipo sin actualización de parches de seguridad.

Figura 9: Configuración de Windows Update para febrero de 2016

Mis más sinceras felicitaciones a José Selvi por este trabajo. De que forma tan sencilla ha enlazado los ataques de man in the middle, las debilidades NTP - que ya eran conocidas - con la seguridad de HTTPs para lograr, con una herramienta sencilla escrita en Python cargarse su seguridad en ciertos entornos. Me encanta.

Saludos Malignos!

JavaRuleSetter: Un "firewall" para los Applets de Java

Si llevas algo de tiempo en seguridad, con certeza habrás visto cómo el mundo de los Exploits Kits o el malware han utilizado bugs de Java para conseguir la ejecución de código remotamente. Muchos de esos exploits están en los arsenales de los Metasploit de los pentesters para que estos puedan conseguir acceso a los equipos que no han tomado la precaución de mantener actualizado el framework de Java. Aún así, el riesgo de que aparezca un 0day y te afecte es muy alto, y por eso Java ha intentado poner medidas paliativas para que un administrador gestione listas blancas de sitios a los que va a permitir que ejecuten Applets de Java o no.

Figura 1: JavaRuleSetter, un "firewall" para los Applets de Java

Las medidas que actualmente se pueden aplicar para crear listas de seguridad son dos, tal y como se explica en el blog de Eleven Paths y vamos a ver cómo funcionan y cómo se pueden configurar cómodamente con JavaRuleSetter.

Deployment Rule Set y Exception Site List 

Para que nos hagamos una idea, la primera de ellas es una forma de conseguir que un Applet se ejecute automáticamente sin generar ninguna alerta por medio de la firma digital del mismo. No son sencillas de configurar ya que hay que generar un fichero XML con un formato concreto, hay que firmarlo digitalmente y ubicar los ficheros en determinadas ubicaciones, pero permiten que se hagan despliegues de aplicaciones a través de Internet por medio de Applets en modo lista blanca. Esta configuración requiere permisos de administrador en la máquina y está disponible a partir de Java 7u51.

Figura 2: Configuración de nivel de seguridad en Java y Exception Site List

La segunda de las configuraciones de seguridad es la Exception Site List, que permite indicar un conjunto de sitios de lista blanca a los que se les permitirá rebajar el nivel de seguridad. El número de alertas y las restricciones que tendrán esos Applets dependerán del nivel de seguridad que se haya elegido en la configuración de Java en el sistema. Estas configuraciones se pueden hacer a nivel de usuario y están disponibles a partir de la versión de Java en Enero de 2014. Su funcionamiento es muy similar al bloqueo de ActiveX que introdujo Internet Explorer 8 hace tiempo.

Figura 3: Árbol de decisión en la ejecución de Applets dependiendo de la configuración de seguridad

Al final, el árbol de decisión sobre la ejecución de un Applet Java hoy en día es bastante complejo, y dependiendo de la configuración del nivel de seguridad de Java, la lista de sitios de excepción y las Deployment Rule Set que se hayan configurado, el resultado a la hora de proteger el sistema contra la explotación de un ataque proveniente de un Applet malicioso puede ser muy distinto.

JavaRuleSetter

Para hacer esto mucho más sencillo, desde el laboratorio de Eleven Paths hemos publicado una herramienta llamada JavaRuleSetter que permite gestionar las listas blancas como si de un firewall se tratara. Para ello, la herramienta configura una regla por defecto en la que se activa el nivel alto o muy alto de seguridad en Java y cualquier Applet que venga a ejecutarse debe cumplir los requisitos de esos niveles o estar en la lista blanca.

Figura 4: Configuración de bloqueo de Applets en JavaRuleSetter

En este ejemplo, con la regla por defecto que activa el máximo nivel de seguridad, cualquier intento de ejecución de un Applet será bloqueado, tal y como se aprecia en la imagen siguiente donde se intenta ejecutar un Applet proveniente de Java.com.

Figura 5: Mensaje de alerta de bloqueo de ejecución de un Applet de java.com

Para conseguir que se pueda ejecutar, basta con meter una regla con la excepción para ese sitio, tal y como se ven en la imagen siguiente.

Figura 6: Adición de una regla de excepción para ejecución del Applet desde Java.com

A partir de este momento, con esta herramienta, cualquier administrador que requiera utilizar Java en su día a día, puede reducir cualquier riesgo de ataque añadiendo únicamente el permiso de ejecución de Applets Java en las URLs de los sitios con los que deban trabajar sus empleados. Por supuesto, si se quiere configurar una regla de despliegue para que no salga absolutamente ninguna alerta, se puede crear una regla en Advanced Mode para ajustar la granularidad que se quiera.

Figura 7: Configuración de una regla de despliegue en modo avanzado

La herramienta está escrita en Java - faltaría más - y por tanto es totalmente funcional en plataformas OS X y GNU/Linux, con las que el equipo de QA de Eleven Paths ha hecho las pruebas pertinentes. Esperamos que os sea de utilidad y consigáis fortificar un poco más vuestros equipos de trabajo.

Saludos Malignos!