Mostrando entradas con la etiqueta DirtyTooth. Mostrar todas las entradas
Mostrando entradas con la etiqueta DirtyTooth. Mostrar todas las entradas

domingo, julio 12, 2020

Cómo Chema Alonso le "hackeó" la agenda de contactos a Kevin Mitnick y Moxie no pudo venir a cenar con Wozniak

Hace ya tres años de esta historia. La tenía guardada para ese día en el que voy a tener menos trabajo y voy a disfrutar de mucho más tiempo libre. Ese día en el que me voy a sentar a escribir mis memorias y dejar plasmadas todas las aventuras y desventuras de mis días. Pero especialmente las anécdotas – o microhistorias que dicen mis amigos Fran Ramírez y Rafael Troncoso – en el mundo de la tecnología, el hacking y los hackers.

Figura 1: Cómo Chema Alonso le "hackeó" la agenda de contactos
a Kevin Mitnick y Moxie no pudo venir a cenar con Wozniak

Pero creo que ese día nunca llegará, porque no tengo ni la más mínima gana de dejar de hacer lo que me gusta, así que el número de proyectos y cosas que sigo haciendo no solo no decrece, sino que aumenta día a día. Qué le vamos a hacer. Hay que aceptarlo.

Y al final, mis memorias casi están escritas aquí en este blog. En artículos suelos. En párrafos hilados con cosas no dichas pero escritas, y también hay muchas cosas escritas, pero no dichas. Y secretos que encajan cuando pones la pieza adecuada del puzzle. Así que, ¿qué mejor forma de escribir esta anécdota en mis particulares memorias que publicarla en un post? Vamos a ello.

No hace falta que os diga que Kevin Mitnick y yo tenemos una relación de amistad muy cercana. Nos conocimos hace ya muchos años gracias a mi querida FOCA que él utilizaba en sus conferencias, y una de esas veces cuando pasó por Madrid nos conocimos y comenzamos a forjar una relación muy cercana.

Figura 2: Con Kevin Mitnick en 2011


En el año 2012 ya éramos muy buenos amigos, así que quedamos para que viera mi charla de Owning Bad Guys { & Mafia } using JavaScript Botnets en BlackHat USA 2012 y se lo pasó genial. Estuvo sentado en primera fila riéndose todo el rato con mis tonterías y mi mal acento inglés. Y luego nos fuimos de cena, a una de esas fiestas de Las Vegas y hablamos, como siempre, de nuestros proyectos, de hacks, de herramientas. De nuestras cosas. De cómo usar las demos en una charla. De cómo hacer algo nuevo. Nos pusimos de acuerdo en pasarnos trucos y herramientas. Así que, a lo largo de los años le hemos ido pasando trucos como el de Sappo o Dirty Business Card, además e la FOCA, que usa en sus charlas.

Pero hubo uno que le moló mucho cómo lo hice yo y me lo pidió también.  Se trataba de DirtyTooth y mi demo con el Speaker BlueTooth de año 2017. Se me había ocurrido ese hack en un momento raro. No sé por qué, pero estaba enfadado con algo. Y entonces me iban a llevar a algún sitio en un coche que no era el mío. Y entonces me quejé de la música y me dijeron:

- “Puedes conectar tu teléfono, te abro el BlueTooth”

Y entonces apareció en mi cabeza.

- “De ninguna manera. No conecto mi BlueTooth a nada extraño ni de broma”

El resto es historia, Apple en iOS no avisa del cambio de perfil BlueTooth de un dispositivo pareado, nosotros hacíamos pasar el altavoz de un perfil multimedia a un perfil de manos libre, y los contactos venían a nuestro altavoz uno tras otro. Y es curioso, porque un cabrero y mala música en un coche que no era mía me habían inspirado para un hack chulo que daría la vuelta al mundo y que obligaría a Apple a actualizar iOS para avisar en los perfiles BlueTooth que acceden a los contactos.

Figura 3: Ahora iOS pide confirmación para dejar a un
perfil BlueTooth acceder a los contactos

La presentación en escenario que hacía yo era curiosa. Sacaba el altavoz BlueTooth y le pedía a voluntarios que se conectaran para poner música. Luego hacía una votación con el público para mientras robarle todos los contactos de la agenda. Después explicaba la técnica de DirtyTooth y los voluntarios se iban poniendo muy nerviosos. Quedaba muy visual, y a Kevin Mitnick le apetecía tener esa demo entre su repertorio, así que me dijo que le hiciéramos un altavoz a él. Y comenzamos a preparárselo.


Figura 4: Presentación de DirtyTooth en 2017

No recuerdo si nos dio tiempo a terminar el suyo, o directamente le dejé el mío, pero el caso es que para la DefCON de ese año 2017, usamos a Felix Brezo y Yaiza Rubio de “porteadores”, y le llevaron a Kevin Mitnick el altavoz hasta Las Vegas. Allí se lo dieron, lo probaron… y no funcionaba. Porras. Le habíamos puesto una SIM que debía funcionar en USA, pero por lo que sea, no funcionaba. Así que después que lo probaran un rato, Felix y Yaiza nos lo trajeron de vuelta a España para que lo revisáramos.

Cuando llegó, se lo pasé a Pablo González y Álvaro Núñez-Romero de mi equipo de Ideas Locas para que lo diagnosticaran y me dijeran qué había pasado. Y la sorpresa fue que sí, había fallado la conectividad que lleva la SIM del altavoz con DirtyTooth para conectarse a los servidores en Internet donde dejábamos los datos capturados de los terminales iPhone. Pero la conexión BlueTooth y el hack de DirtyTooth sí que había funcionado, así que toda la agenda de contactos de Kevin Mitnick estaba en mi poder.

Como os podéis imaginar, la agenda de Kevin Mitnick es muy molona. Un sueño para que puedas conocer a todas tus estrellas del hacking. Pero no íbamos a hacer nada malo. Pero… sí que se me ocurrió una idea. Ya que en al agenda estaban Steve Wozniak y Moxie Marlinspike – además de Chema Alonso - , así que le pedí a Kevin Mitnick conocer a Steve Wozniak, que a la postre sería aquella cena de la que os hablé.

Figura 5: Chema (Alonso), Kim Dotcom, Dan Kaminsky y Jeff Moss en la agenda

Pero, no fue como yo la quise organizar. Y es que además de estar Kevin y Wozniak conmigo, también me llevé a mi boss, y quise invitar a Moxie Marlinspike. Con Moxie había tenido buena relación en DefCon, BlackHat, Ekoparty, ShmooCon y Hackon en Noruega, donde nos habíamos ido de vinos, cañas y cervezas. Habíamos dado charlas juntos y compartido muchos ratos en esos años de dar vueltas por el mundo CON tras CON, e incluso un día hice un truco que se me ocurrió para averiguar su verdadero nombre …. Pero os lo contaré en otra historia más adelante, que hay muchas microhistorias que aún no os he contado.

Figura 6: Con Moxie Marlinspike en 2009

El caso es que el teléfono de Moxie lo tenía, pero lo había perdido en alguno de los cambios de teléfono – nos conocimos Moxie y yo en el año 2008 -. Y me parecía que quién faltaba en esa cena era Moxie. Así que aproveché que lo había recuperado para contactar con él e invitarle a la cena. Y así hice. Le puse un mensaje por Signal y estuvimos hablando, pero no pudo venirse a la cena. Lástima.

Figura 7: Moxie & Woz en la agenda

Luego Kevin Mitnick y yo nos fuimos a la ToorCON, dimos la charla juntos con DirtyTooth, y ahí conocí a una persona que iba a entrar en el equipo de seguridad de Apple que acabaría encargándose de cerrar el bug de DirtyToothy luego seguí mi viaje..


Figura 8: Kevin & Chema en ToorCON hablando de DirtyTooth

Al final son momentos salpicados de una vida que voy coleccionando. Que voy uniendo. Que voy tejiendo uno a uno en el tapiz de mi existencia, porque cuando pasan de forma individual parece que no tienen tanta importancia, pero cuando los acabo por poner todos juntos en su lugar. Cuando conecto los puntos hacia atrás con todos ellos, la historia que se ve, la imagen del tapiz, se me antoja preciosa.

Saludos Malignos!

Autor: Chema Alonso (Contactar con Chema Alonso)

lunes, abril 01, 2019

2FWB: Second Factor Web Browsing [Parte 2 de 4] "Network Attacks"

Ya os he contado los trabajos que hemos venido haciendo con respecto a los Second Channels, ahora toca hablar de la parte de cómo protegerse contra los ataques en redes IPv4&IPv6. Ni que decir hay que en ElevenPaths, y en mi equipo de Ideas Locas de CDO trabajamos de continuo con todos ellos y hablamos largo y tendido. Desde ataques de Network Packet Manipulation, hasta ataques de phishing homográficos como los PunnyCodes, pasando por los procesos de Ethical Hacking con SSLStrip2 y Delorean o las investigaciones de HSTS, HPKP y Certificate Pinning.

Figura 11: 2FWB: Second Factor Web Browsing
[Parte 2 de 4] "Network Attacks"

Esto hace que la preocupación cuando Mi Hacker o Mi Survivor utilizan mi equipo en una red para conectarse a buscar algo en Internet sea máxima. Me preocupa y, además de fortificar el end-point, reviso periódicamente todo tipo de detalles para asegurarme que se están conectando al sitio correcto, que no hay ninguna inyección de scripts, que el DNS ha devuelto la dirección correcta, que el certificado digital es el que debe, etcétera. Verificaciones que seguramente también hacéis vosotros en vuestro día a día cuando navegáis por Internet.

Conexión Segura & SmartWiFi

Una de las primeras cosas que he hecho ha sido activar el servicio de Conexión Segura en casa. Este servicio permite que toda la navegación que se produce a través la conexión WiFi y la línea de fibra en los hogares con Movistar Fusión, sea analizado (sin romper HTTPs). Como cualquier servicio de seguridad no te da el 100% de garantías, pero sí que te permite añadir una capa de protección a la navegación y filtrar dominios maliciosos, o ataques comunes.

Figura 12: Gestión de Conexión Segura desde SmartWiFi

Este servicio, que se puede activar desde la app de SmartWiFi de forma gratuita para toda la navegación en la WiFi de Movistar, ha detectado ya que la mitad de los hogares, en los cientos de miles de navegaciones que están protegidas a día de hoy, hayan pasado por un contenido malicioso que ha sido bloqueado. Esto es un montón de peligros quitado. Un dominio que sirve un ransomware y es detectado, se bloquea para todos los clientes Movistar Fusión con Conexión Segura y evita que se expanda.

Figura 13: Gestión de seguridad de red WiFi con SmartWiFi

Es una capa de protección transparente para los hogares, y que yo tengo puesto a todos los familiares y amigos. Con un clic estás más protegido por defecto aplicando la seguridad desde un sitio estratégico, la red por la que circula el tráfico.

Un "Second Channel" para verificar el tráfico

Dicho esto, aún me queda el riesgo de todos ataques de red que se produzcan en la red local, o aquellos ataques al end-point que vengan por canales cifrados, o que no sean detectados por la solución EDR (Endpoint Detection and Response). En todos esos caso, además de hacer una fortificación del puesto de trabajo - recomendable el libro de Sergio de los Santos (@ssantosv) "Máxima Seguridad en Windows 4ª Edición" - queda la revisión manual de los mensajes de alerta, de los detalles de las conexiones, etcétera.

Figura 14: Máxima seguridad en Windows [4ª Edición]

Es decir, navegar de forma conjunta con ellas para ver qué está pasando en el equipo con un ojo crítico con el que buscar hasta el más mínimo detalle que pueda ser el indicador de un ataque. Y eso no escala. Mi tiempo no es infinito, y no puedo hacer todas las comprobaciones manualmente siempre, así que había que automatizar este proceso.

Verificar todo significaba estar siempre sentado a su lado y ver todo lo que pasaba. Pero, ¿y si para revisar todo en vez de estar sentado en su mismo equipo usamos de manera continua dos canales? De esta forma podríamos automatizar en otro equipo las verificaciones de "papapete" para saber si estamos sufriendo un ataque de red.

Figura 15: Idea detrás de 2FWB: Second Factor Web Browsing

La primera idea que se me vino a la cabeza fue que estaría bien tener un equipo con dos tarjetas de red, y tener siempre una conexión a él para ir recibiendo en la pantalla lo que está viendo en su navegación. Algo así como los equipos de "manos remotas" que tenemos en muchos equipos importantes en la red de comunicaciones.

Pero la mayoría de los portátiles - como la Microsoft Surface que le tengo puesta a Mi Hacker - viene con la WiFi solo. Podría comprar una segunda tarjeta, pero debería montar en todo momento una red y conectarla a mi equipo también con dos tarjetas, y además mi equipo debería conectarse a otra red distinta. Esto podría ser fácil, porque yo me suelo conectar vía "hotspot" a mi teléfono móvil vía BlueTooth. No es casualidad que se me ocurriera la malvada idea del DirtyTooth que presentamos en RootedCON 2017, era un power-user de ello.


Figura 16: DirtyTooth en RootedCON 2017

Pero para montar esta verificación de la navegación en tiempo real era demasiado lío el tener que poner el equipo de Mi Hacker o de Mi Survivor conectado al mío por una segunda red creada entre ellos y luego conectar mi terminal vía BluetTooth para usar una conexión de red LTE - que vistos los ataques a redes móviles usar otra red no es del todo seguro - que permitiera tener una segunda visión de los servicios de Internet a los que se conectan y verificar que todo está ok.

¿Y si lo simplificamos?

Al final, si tenemos una conexión vía BlueTooth+2G/3G/4G a Internet tenemos siempre un Second Channel en todos los equipos, y la verdad es que yo siempre llevo mi smartphone y todos los equipos que usamos vienen con BlueTooth. Es fácil conectar el equipo que usan mis hijas con mi SmartPhone utilizando BlueTooth y ver dónde están navegando y qué están viendo, para poder comprobar que lo que están recibiendo es lo que deben recibir.

Esta comprobación podríamos hacerla desde el propio termina móvil donde haríamos las comprobaciones, o mucho mejor, haciéndolo desde un servicio en la nube que haría esas verificaciones para todas las instancias de esta app. Las dos arquitecturas tienen ventajas e inconvenientes. Tener toda la lógica en la cloud simplifica la construcción, pero da un elemento más en el sistema que podría ser atacado en un posible esquema de DDOS al servidor en cloud que recoge la inteligencia para detectar los ataques.

Figura 17: Arquitectura de 2FWB con protección de app en smartphone

Por otro lado, tener toda la lógica en el terminal móvil obliga a desplegar nuevas apps o nueva lógica al dispositivo cuando hay nuevas reglas de detección de ataques. Pero hace el atacante deba conseguir vulnerar la red del equipo desde el que se navega a Internet más la conexión a Internet del smartphone. Un doble ataque más difícil de realizar, sobre todo si no estás cerca geográficamente para atacar al dispositivo móvil - ver libro de Ataques a redes de comunicaciones móviles GSM/2G/3G/4G de nuestros amigos de Layak -.

Figura 18: Libro de hacking y seguridad en comunicaciones móviles
GSM/GPRS/UMTS/LTE (2G/3G/4G)

Con es doble canal usando una conexión a Internet de navegación vía red WiFi o Ethernet, y un segundo canal vía BlueTooth+3G/4G, podríamos realizar dos conexiones al mismo servidor desde dos puntos diferentes, usando dos redes distintas. Usar este doble canal tiene cierta similitud con el doble factor de autenticación en los sistemas de login, donde se busca que el atacante deba vulnerar dos elementos distintos para aumentar su dificultad. En este caso, el tráfico del primer canal debe generar respuestas similares y con propiedades similares al que se obtiene por el segundo canal y si no, generamos una alerta.

Esta idea, permite detectar ataques de red en el canal primario, como un DNS Spoofing, un ataque de Phishing, un dominio marcado en un servicio de seguridad como peligroso por usar ficheros JS de  cryptominnig, ataques de bypass HSTS, o de Certificado Falso. Solo necesitamos saber qué es lo que se está recibiendo como respuesta en el canal primario y hacer una comprobación en el canal secundario.

Arquitectura en el end-point

Para conseguir los datos de seguridad útiles para la detección de ataques, necesitamos en el equipo a proteger tener una extensión en el navegador que nos permita capturar las cabeceras HTTP y datos del DOM de la página HTML de la respuesta, más alguna información de red que recibimos del sistema, como direcciones IP resueltas por el DNS, datos del DNS que responde, tablas ARP, etcétera. Toda esta información se captura usando dos elementos.
- Extensión de navegador (en este caso Google Chrome): Este elemento extrae la información que necesitamos del D.O.M. (Document Object Model, y se lo envía al Agente. Además, recibe del Agente las ordenes de bloquear o no bloquear la sesión de navegación con un mensaje de alerta.
- Agente en el sistema (en este caso escrito en Node JS): Establece la conexión vía BlueTooth con el 2FWB y le envía la información recibida de la Extensión del navegador, además de información del sistema para que el 2FWB le diga el resultado de la evaluación. Después, recibe la información desde el 2FWB y manda las órdenes a la Extensión del Navegador para que bloquee o no la sesión.
Con esta arquitectura, tenemos la ocasión de que las verificaciones que haría yo mismo de forma manual para comprobar que está viendo lo que debe de ver en cada momento, de tal manera que si algo no cuadra, o se detecta un fallo en el certificado, el nombre del dominio, la dirección IP del servidor, los ficheros incrustados en el DOM del documento, etcétera, se bloquea la navegación con un aviso que llega a la pestaña del navegador en la que está visualizando el contenido.




A post shared by Chema Alonso (@chemaalonso) on

He de decir que hicimos pruebas con BluetTooth Low Energy y con un solo componente basado en la extensión de Google Chrome, pero la realidad es que teníamos dos problemas con esto:
1.- Volumen de datos: Con el protocolo BLE el volumen de datos que podíamos enviar era muy limitado y lo que necesitamos enviar y a la velocidad que lo necesitábamos nos limitaba mucho a la hora de hacer verificaciones de seguridad.
2.- Datos de red del sistema: Para poder detectar ciertos ataques como ARP Spoofing, ataques MITM en IPv6 con SLAAC, etcétera, necesitábamos información del sistema operativo así que necesitábamos un agente en el sistema.
Así que por eso se eligió usar un perfil BlueTooth desde el Agente y tener la extensión de Google Chrome para acceder a la información de la web que se estaba navegando y ver los datos en tiempo real del DOM. Tener las cabeceras HTTP, información del certificado, los archivos scripts inyectados, etcétera es algo que desde la extensión es posible realizar.

Saludos Malignos!

*****************************************************************************************
- 2FWB: Second Factor Web Browsing [Parte 1 de 4] "Second Channels"
- 2FWB: Second Factor Web Browsing [Parte 2 de 4] "Network Attacks"
- 2FWB: Second Factor Web Browsing [Parte 3 de 4] "2FWB Mobile App"
- 2FWB: Second Factor Web Browsing [Parte 4 de 4] "Modo Centinela"
*****************************************************************************************

miércoles, diciembre 13, 2017

Dirtytooth for Rasperry Pi v2: Soporte Raspbian Stretch para versiones iOS inferiores a 11.2

El pasado 17 de agosto salió una nueva versión de Raspbian llamada Raspbian Stretch. Una nueva versión del sistema operativo más utilizado en Raspberry Pi y que llegó para sustituir a Raspbian Jessie después de dos años sin tener una actualización mayor. Dentro de las novedades hay una que hacía que nuestro DirtyTooth for Rasperry Pi - que habíamos sacado el 10 de Agosto - no funcionara correctamente en esta nueva versión. Lo que sucedía es que los controladores de Bluetooth habían sido modificados, especialmente los relacionados con el audio. Había que buscar una solución y aprovechar las nuevas características de Bluetooth que ofrece Raspbian Stretch.

Figura 1: Dirtytooth for Rasperry Pi v2: Soporte Raspbian Stretch para versiones iOS inferiores a 11.2

La versión anterior utilizaba PulseAudio junto a un módulo para habilitar la conexión de audio Bluetooth, sin embargo la comunicación con ALSA (Advanced Linux Sound Architecture) en ocasiones provocaba cortes en la transmisión de la señal y ralentizaciones en el buffer de sonido.

Novedades en Dirtytooth for Rasperry Pi v2

Ahora es posible utilizar ALSA junto al proyecto bluez-alsa para realizar la conexión de audio Bluetooth. Este proyecto hace una integración directa entre la pila de Bluetooth de Linux (bluez) y el software de sonido por defecto en Linux, ALSA. El uso de este paquete mejora el streaming de audio Bluetooth con respecto a PulseAudio y además permite controlar el volumen desde el propio iPhone.

Figura 2: DirtyTooth for Raspberry Pi v2

Otro problema que se soluciona es esta versión es la captura de los datos. En la versión anterior se recogían todos los datos en una única tarjeta VCARD. Normalmente la captura de los datos se hace rápidamente, sin embargo, se podían experimentar problemas con las agendas que tuvieran muchas fotos asociadas a contactos. En estos casos se podía llegar incluso a interrumpir la conexión y en ese caso no se capturaba ningún dato. Para solucionar este error, ahora se capturan los contactos uno a uno, por lo que si ocurre alguna interrupción en la transmisión es posible visualizar la parte de los datos capturados.

Figura 3: Extracción de fotos de las VCARD de iOS < 11.2

Aprovechando el fallo de las fotos, nos dimos cuenta que podíamos conseguir también esta información. La información aparece en la VCARD bajo la etiqueta PHOTO y está codificada en BASE64 que habrá que convertir a JPEG para ver el resultado. En el siguiente vídeo tenéis un ejemplo de cómo funciona esta nueva versión.


Figura 4: DirtyTooth for Raspberry v2

Y como última mejora menor, es posible cambiar el nombre al altavoz a través de la linea de comandos utilizando:
sudo dirtytooth -n “My dirty speaker”
Después de la presentación del nuevo DirtyTooth en BlackHat Europa se pone a disposición de todos los que quieran probar este truco con los iPhone todavía compatibles, ya que se recuerda que Apple ha arreglado esto en la última versión de iOS, la versión 11.2, dejando deshabilitado por defecto la opción de sincronizar contactos. Aún así, sigue siendo un truco a sumar a la lista de todas las técnicas de Hacking iOS: iPhone & iPad.


Figura 5: Opción de sincronizar contactos por defecto deshabilitada en iOS 11.2

Esto, es algo que ya esperábamos desde el día que se hizo pública la técnica de DirtyTooth Hack, y Chema Alonso lo dijo el mismo mes que lanzamos el proyecto, como se puede ver en este vídeo.


Figura 6: Sobre lo que haría Apple con DirtyTooth

Esta es la lista de completa de novedades:
- Funcionamiento con Raspbian Stretch
- Mejora del streaming de audio bluetooth
- Control de volumen a través del iPhone
- Cambio de nombre del altavoz desde linea de comandos
- Posibilidad de obtener las fotos asociadas a los contactos
- Recogida de contactos uno a uno para evitar perder los datos si se interrumpe la conexión
Al igual que con la versión anterior, es posible editar el fichero .bashrc para hacer que el daemon de DirtyTooth arranque automáticamente al iniciar la terminal, muy práctico si se pone el login automático y en modo terminal desde la utilidad raspi-config.
DIRTY=$(ps cax | grep -v grep | grep dirtyagent)  
if [ "$DIRTY" == "" ] ; then 
sudo dirtytooth --start 
fi
Enjoy it!

Autor: Álvaro Núñez - Romero (@toolsprods), Security Researcher en ElevenPaths

miércoles, diciembre 06, 2017

Apple comienza a arreglar nuestro DirtyTooth Hack

Ya os dije en el articulo de "Weaponizing Features" que había tenía una conversación con gente de seguridad de Apple, y que al ver la charla que habíamos dado Kevin Mitnick y yo en San Diego, dentro de la ToorCON 19, me había dicho que, definitivamente, habría que hacer algo. Y parece que están avanzando en arreglar de una vez por todas el DirtyTooth Hack

Figura 1: Apple comienza a arreglar nuestro DirtyTooth Hack

Si has seguido los artículos de DirtyTooth Hack que se publicaron en este blog, verás que la técnica se aprovecha de un conjunto de características por defecto que permiten la "weaponización" del ataque. La primera de ellas es que no exista ninguna alerta de acceso a los contactos por parte de un dispositivo BlueTooth, ni cuando lo hace por primera vez, ni cuando se cambia de un perfil BlueTooth tipo speaker a uno tipo HSP (HandSet Profile) o PBAP (Phone Book Access Profile).


Figura 2: Charla de Chema Alonso & Kevin Mitnick at ToorCON 19

Esto no era así, en los dispositivos con Android, como podéis ver en el artículo de DirtyTooth Hack, pero en iOS no existía ninguna alerta. Sin embargo, Apple comenzó a arreglarlo en la release de iOS en Octubre, donde en los perfiles HSP añadió un alerta de acceso a los contactos, como la que podéis ver a continuación.

Figura 3: Apple pide confirmación para permitir a un perfil BlueTooth acceder a los contactos

Pero no tocó nada con el PBAP... por el momento. Así que nuestro DirtyTooth Hack siguió funcionando, hasta la release 11.2, donde ha hecho un cambio nuevo. Ahora ya no permite hacer la sincronización de contactos por defecto, así que debe ser el usuario el que lo autorice.


Figura 4: iOS 11.2 evita el cambio de perfil BlueTooth

Es decir, una vez que el Rogue BlueTooth Speaker se conecta con un perfil HSP o un PBPA y no ha sincronización de contactos por defecto, lo que imposibilita el truco con el que se engañaba al usuario. Aquí tienes el vídeo de la charla completa sobre DirtyTooth Hack de presentación en sociedad por primera vez en la RootedCON de Madrid.


Figura 5: DirtyTooth Hack en RootedCON 2017

Bien por Apple que ha tomado medidas para fortificar algo que estaba mal, y pone más difícil la weaponización del ataque. El ataque sigue funcionando en versiones anteriores de iOS, así que sacaremos una última versión del código de DirtyTooth Hack para extraer las fotos de los contactos, que ya encontramos la forma de hacerlo. Y recuerdo, aún hay muchos trucos de Hacking iOS que siguen funcionando.

Saludos Malignos!

jueves, noviembre 02, 2017

DiityTooth en iOS 11.0.3 y 11.1 aún funciona & cómo configurarlo en Raspberry Pi

Estos días hemos tenido una nueva versión de iOS, en concreto la versión iOS 11.0.3 y 11.1, y hemos querido comprobar que nuestro querido DirtyTooth Hack seguía funcionando prefectacmente sobre él. Es decir, que las demos que hice en la pasada 8dot8 de Chile siguen dando los mismos resultados. Y así ha sido.

Figura 1: DiityTooth en iOS 11.3 aún funciona & cómo configurarlo en Raspberry Pi

En primer lugar os dejo una grabación [No oficial] de mi charla en la 8dot8 de Chile, donde se explica DirtyTooth en detalle y se hacen unas demostraciones con versiones anteriores a iOS 11.0.3 y 11.1.


Figura 2: DirtyTooth en 8dot8 [Grabación no oficial]

En segundo lugar, os dejo la prueba que hemos hecho esta misma mañana con iOS 11.1 en la que se ve que sigue siendo vulnerable al DirtyTooth Hack.


Figura 3: DirtyTooth Hack en iOS 11.1. Sigue funcionando

Y por último, por si quieres aprender a montar exactamente lo que monté en la 8dot8 de Chile os dejo la Codetalk4Devs que explica cómo está programado y funciona DirtyTooth for Raspberry Pi.

Figura 4: Configuración de DirtyTooth para Raspberry Pi

Y eso es todo por ahora. En breve os contaré cuáles son los juguetes nuevos que estamos creando, que seguro que os gustan.

Saludos Malignos!

martes, septiembre 05, 2017

"Weaponizing" Features

El sol estaba en lo alto. El cielo era azul. La ciudad de San Diego estaba viva. Y había amigos, conocidos y hackers en la ToorCON. Los astros se alinearon y el fin de semana quedó para disfrutarlo. Visité Little Italy, comí y cené con amigos, y enredé con mi gran amigo Kevin Mitnick, al que había conseguido “engañar” para que se viniera a dar la charla de DirtyTooth Hack conmigo.

Figura 1: "Weaponizing" Features

Durante la misma tuvimos que lidiar con problemas no esperados – así son las demos en real – pero al final acabaron saliendo las demos y nos lo pasamos de maravilla. Y luego a tomarse unas cervezas para relajarnos y reírnos un poco al ver que me daban el Oscar al “Best Body” por la broma de todas las horas que desde hace un tiempo meto en el gimmasio para compensar los excesos con los amigos.

A post shared by Chema Alonso (@chemaalonso) on

Entre cerveza y charlas de hackers uno de los asistentes quiso hablar conmigo para ver cómo Apple podría arreglar el tema del DirtyTooth Hack. Hablamos un rato. “Es un bug”, me dijo. “Que un dispositivo cambie el BlueTooth Profile y consiga acceder a la agenda de contactos sin una alerta es un bug”, insistió. Y puede que tenga razón, pero hace tiempo que esos detalles son menos importantes para mí. “No lo sé, para mí es como funciona el sistema iOS, y lo único que he hecho es automatizar  un pequeño leak para hacer un juguete". El insistió que si había podido "weaponizarlo" como lo hacen los Rogue BlueTooth Speakers que son parte de DirtyTooth Hack, entonces es un bug.


Figura 3: DirtyTooth Hack en RootedCON 2017

Lo cierto es que este trabajo no es tan diferente a lo que hicimos con la primera versión de la FOCA. “Weaponizar” los pequeños leaks que se producen en los metadatos de los documentos publicados para convertirlo en una herramienta que pintaba parcialmente el mapa interno de una organización. Algo que se puede evitar limpiando los metadatos de los documentos que van a hacerse públicos en una web o al ser enviados por correo electrónico.

Figura 4: Mapa de red interno pintado por FOCA

Y no es nada distinto del estudio que hicimos con los discos de almacenamiento USB que se conectan a los equipos y generan hidden links en las redes de las empresas. Recoger pequeños datos y “automatizar” o “weaponizar” lo que se obtiene de esas fugas de información.

El último de esta serie, por no extenderme demasiado en los ejemplos, es el caso de la posibilidad que existe de saltarse el bloqueo del envío de mensajes de WhatsApp utilizando una tercera persona. No es un bug en sí, pero si se “weaponiza”, es decir, si alguien crea el sitio web automatizado como el que yo cree como PoC (que nunca publiqué ni publicaré), el bloqueo de contactos deja de tener sentido en WhatsApp. ¿Es un bug? No lo sé. Es solo una “weaponización” de una característica del servicio.


Figura 5: Desbloquéame WhatsApp


Por supuesto, hacer manualmente el ejemplo de WhatsApp tiene la vida muy corta, pero hacerlo con una plataforma automática como hicimos nosotros anula por completo el sentido del bloqueo. ¿Se debe arreglar eso? Pues no seré yo quién lo defina. Cada uno debe tener su opinión.

¿Qué se debe hacer?

En la mía, creo que en iOS la compartición de contactos con un dispositivo BlueTooth cuando este lo pida no debe ser YES por defecto. Apple hace revisión a todas las apps para ver cuáles piden permisos de acceso a información personal – como por ejemplo la agenda de contactos – y luego además pone permisos extras que el usuario puede gestionar. En el caso del dispositivo BlueTooth no hay ninguna revisión por parte de Apple y además el usuario no dispone de ese control para decir no a la compartición de los contactos.

Vale, sí que existe ese "toogle" para decir no, pero si el dispositivo ofrece la conexión con un perfil BlueTooth y en el futuro lo cambia para acceder a los contactos, el usuario no se entera. Y además, el acceso a los contactos es discreto. Es decir, el dispositivo Rogue BlueTooth Speaker puede esperar un tiempo aleatorio antes de convertirse en un PBAP (PhoneBook Access Profile), extraer los contactos y volver a comportarse con un perfil BlueTooth de escucha de audio. ¿Se enteraría el usuario? ¿Podría controlarlo? Lo dudo mucho.

¿Y en el caso de WhatsApp? Pues lo mismo. Como ya dije existen dos aproximaciones válidas. La primera es que si el usuario A bloquea al usuario B, entonces el usuario B no pudiera enviarle mensajes ni cuando estuviera en un grupo, pero eso sería un leak de información de todas las personas que están en ese grupo que podrían llegar a darse cuenta de que A está bloqueando a B y… quién sabe, tal vez se pudiera “weaponinizar” y hacer algo más automático.

La otra opción es la que aplica Telegram y que para mí tiene todo el sentido. Permitir al usuario de WhatsApp bloquear la opción de ser incluido en grupo si no lo hace una persona que él mismo tenga en la lista de contactos. Sencillo y funcional para anular la “weaponización” que hicimos con “Desbloqueamé”. ¿Debería hacerlo?

Figura 6: Opción de Telegram que evita el "desbloquéame"

La verdad es que, viendo cómo va el mundo, seguro que acabarán haciéndolo. Apple acabará poniendo algún control al cambio de perfiles BlueTooth y acceso a la agenda de contactos vía PBAP y seguro que WhatsApp acaba haciendo alguna cosa de las que he dicho o similares. Al final esa es la gracia de la weaponización. Algo que de forma discreta parece una “chorrada”, si alguien es capaz de automatizarlo y reducir las barreras de explotación de ese “leak” o “feature”, lo convierte en algo que incrementa seriamente el riesgo.

Saludos Malignos!

martes, agosto 29, 2017

Chile & Chema: Tres eventos después de ToorCON

Ya se acaba el mes de Agosto, y con la llegada de la cuesta de Septiembre se avecinan actividades, así que aprovecho el último post de este mes - me voy a saltar el de artículo de mañana por problemas de agenda - para contaros algunas de las actividades que tengo previstas hacer en mi próxima visita a Chile.

Figura 1: Chile & Chema. 3 Eventos después de ToorCON

Estoy actualmente de viaje por la Costa Oeste de EEUU y el fin de semana bajaré a San Diego para desde ahí ir a, Sao Paolo, Santiago de Chile y Buenos Aires. Será en estos son los lugares donde yo voy a estar dando charlas, y a falta de definir mi evento en Argentina, os dejo la agenda que tengo confirmada.

02 de Septiembre: ToorCON en San Diego

Como ya os conté, yo estaré dando una charla - lo mismo con un co-speaker sorpresa - el día 2 de Septiembre en ToorCON. Hablaré de DirtyTooth Hack, y además estará mi compañero Santiago dando otra charla con un tema más que interesante para el pentesting de redes Windows.

Figura 2: ToorCON 2017 en San Diego

05 de Septiembre: 5º Summit País Digital en Santiago de Chile

El 5 llego a Santiago de Chile, y participaré con una charla en el 5º Summit País Digital, donde daré una keynote hablando de .... aún por decidir. Que no tengo claro si hablaré de CiberSeguridad o de algún tema de Transformación Digital. Ya veremos.


Figura 3: 5º Summit País Digital en Santiago de Chile

05 de Septiembre: Dialogando en la Universidad de Chile

Ese mismo día, pero por la tarde y abierto al público, estaré en la Universidad de Chile hablando en una sesión de preguntas y respuestas, en la que contestaré a las cuestiones que me hagan desde el acto todos los participantes.

Figura 4: Registro para la charla en la Universidad de Chile.

06 de Septiembre: Security Innovation Day en Chile

Al día siguiente, aún en Chile pero pensando en nuestros clientes, vamos a organizar el Security Innovation Day de ElevenPaths en Santiago de Chile. Una mañana entera para hablar de ciberseguridad y servicios profesionales en la que estaré con mis compañeros Rames y Gabriel Bergel, entre otros.

Figura 5: Security Innovation Day 2017 en Santiago de Chile

08 de Septiembre: Buenos Aires

El Viernes 8, aún está sin confirmar definitivamente, pero lo más probable es que por la tarde participe en una sesión abierta al público para que el que quiera pueda pasarse. En cuanto tenga la información final os la paso.

Además, a primeros de Septiembre os dejaré también el calendario de eventos Online, para que puedas apuntarte a lo que más te apetezca.

Saludos Malignos!

jueves, agosto 24, 2017

Ahora en Vídeo: "It´s Only Rock'N Roll, but I like it". @chemaalonso en la @rootedCON #DirtyTooth

En la pasado RootedCON 2017 que tuvo lugar en Madrid, yo aproveché para presentar por primera vez el DirtyTooth Hack que tanto juego nos ha dado, que presenté en la OpenExpo 2017 y en la próxima ToorCON en SanDiego.

Figura 1: Ahora en Vídeo: "It´s Only Rock'N Roll, but I like it"

Desde la organización han publicado ya los vídeos de la conferencia, editados y a alta calidad, que podéis ver desde ya en Youtube. Así que aquí os las dejo.

Figura 2: It´s only Rock'N Roll but I like it

Y por si acaso, aquí está la versión doblada al inglés, que la organización realiza para que haya una mayor difusión internacional de los contenidos que allí se presentan.

Figura 3: It´s only Rock'N Roll but I like it [ENG]

Por último, aquí os dejo la lista de enlaces de interés al respecto del DirtyTooth Hack, que aún va a sufrir alguna evolución más.

*********************************************************************************
- Dirtytooh hack site
- Libro de Hacking iOS: iPhone & iPad [2ª Edición]
- Conferencia DirtyTooth Hack en OpenExpo 2017
- Conferencia DirtyTooth Hack en RootedCON 2017
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (I de V)
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (II de V)
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (III de V)
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (IV de V)
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (V de V)
- DirtyTooth Hack: Reemplazar el módulo Bluetooth en Marshall Killburn
- DirtyTooth Hack: Seminario en Vídeo
- DirtyTooth para Raspberry Pi
*********************************************************************************

Saludos Malignos!

jueves, agosto 10, 2017

La implementación de DirtyTooth Hack para Raspberry Pi: Cómo convertir Raspberry Pi en Rogue BlueTooth Speaker

En la pasada RootedCON presentamos el DirtyTooth Hack, un ataque basado en Rogue BlueTooth Speakers para los dispositivos iPhone. Como hacer la integración hardware con algunos BlueTooth Speakers no es trivial - como vimos con el Marshall KillBurn -, decidimos hacer una implementación del DirtyTooth Hack en Raspberry Pi. Y ya está liberado el código de DirtyTooth para Raspberry Pi.

Figura 1: La implementación de DirtyTooth Hack para Raspberry Pi.
Cómo convertir tu Raspberry Pi en un Rogue BlueTooth Speaker

Con una Raspberry Pi 3 u otra Raspberry Pi anterior con un dongle USB BlueTooth, podemos convertir nuestra Raspberry Pi en un Rogue BlueTooth Speaker y poder llevarnos de regalo los contactos de todos los dispositivos iPhone que se conecten a él.

Figura 2: DirtyTooth para Raspberry Pi

Para instalar el paquete dirtytooth.deb necesitamos tener un Raspbian Jessie y las dependencias necesarias instaladas que podemos instalar con:
sudo apt-get updatesudo apt-get install pi-bluetooth libbluetooth-dev python-dev python-dbus python-pip python- gobject python-gobject-2 git pulseaudio pulseaudio-module-bluetooth
Y tras realizar la instalación de las dependencias, instalarlo el paquete con dpkg:
sudo dpkg -i dirtytooth.deb
Figura 3: Instalación del paquete DirtyTooth

Se pueden realizar todos estos pasos de manera automática utilizando el script install.sh que acompaña. Para el funcionamiento son necesarias algunas librerías para Python que se descargarán automáticamente al instalarse el .deb, pero en caso de tener algún problema con la instalación, por ejemplo si se cae la conexión a Internet en medio de la instalación o los enlaces al GitHub se hubieran caído o cambiado, son PyBluez, nOBEX y psutil. La librería PyBluez y psutil pueden instalarse directamente desde pip en las versiones testeadas:
sudo pip install pybluez==0.22 sudo pip install psutil==5.2.2
Sin embargo, nOBEX la descargaremos desde su GitHub y las instalaremos manualmente, ya que no existe actualmente en los repositorios pip:
git clone https://github.com/nccgroup/nOBEX.git cd nOBEX
git reset --hard 0583c72
sudo python setup.py install
Nota: Nos posicionamos en el commit 0583c72 porque es el que hemos probado que funciona. Si en un futuro hay cambios en el repositorio no podemos asegurar el funcionamiento, por tanto instalamos desde el commit probado.
Una vez instalado, el funcionamiento de DirtyTooth es muy sencillo. Podemos consultar su ayuda del paquete para tener más detalles: dirtytooth --help 

Figura 4: Ayuda de DirtyTooth Package

Aquí vemos que la forma de utilizarlo es muy simple, podemos activar o desactivar el agente, que es necesario para poder encontrar el Rogue BlueTooth Speaker que hará el DirtyTooth Hack y también podemos obtener la agenda si sabemos la dirección MAC del dispositivo. Para el iniciar y parar el agente debemos ejecutarlo con: sudo dirtytooth --start

Figura 5: DirtyTooth Hack en ejecución, capturando datos de un dispositivo conectado

Una vez que el proceso está arrancado, cada vez que se conecte un dispositivo por BlueTooth se llamará automáticamente a la ejecución de dirtytooth con la dirección MAC del dispositivo conectado y se guardarán los resultados en la carpeta /root/dirtytooth.

Es necesario saber que para ejecutar el comando manualmente con una dirección MAC específica, el dispositivo tiene que estar conectado en ese momento y ejecutarlo con el siguiente formato:
sudo dirtytooth --mac AA:BB:CC:DD:EE:FF
Los resultados que se guardan son dos: la agenda de contactos y el histórico de llamadas. Al tratarse de Bluetooth 2.1 o superior (Bluetooth 4.0 en el caso concreto de la Raspberry Pi 3) no es necesario poner el PIN o Token de Pareado y se conectará automáticamente al intentar realizar la conexión con el dispositivo.

Figura 6: Instalación y Uso de DirtyTooth Package en Raspberry Pi

El resultado final ya lo conocemos, una vez que el móvil se conecta a nuestro “Rogue BlueTooth Speaker” al cabo de unos segundos se cambiará el perfil de audio por el PBAP accediendo a la agenda del teléfono conectado y guardando una copia de los contactos. Posteriormente se pueden usar los datos recogidos para hacer OSINT y obtener información de interés sobre los contactos obtenidos. En este charla tenéis las demos y la explicación completa.

Figura 7: DirtyTooth Hack: It´s Only Rock'n Roll but  I Like it en Open Expo 2017

Para una mejor experiencia de uso, se puede poner un arranque automático del dirtytooth cada vez que iniciamos la terminal, especialmente útil en un sistema lite como Raspian Jessie Lite y con la configuración de inicio de sesión automático, ya que de esta manera arrancará el agente nada mas encender la Raspberry Pi y el altavoz estará preparado. En el caso de la versión con escritorio, se arrancará al iniciar la terminal. Para hacer esto basta con añadir las siguientes lineas al fichero .bashrc:
DIRTY=$(ps cax | grep -v grep | grep dirtyagent) if [ "$DIRTY" == "" ] ; then
pulseaudio -D
/usr/lib/dirtytooth/start fi
Enjoy it!

Autor: Álvaro Núñez - Romero (@toolsprods), Security Researcher en ElevenPaths

*********************************************************************************
- Dirtytooh hack site
- Libro de Hacking iOS: iPhone & iPad [2ª Edición]
- Conferencia DirtyTooth Hack en OpenExpo 2017
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (I de V)
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (II de V)
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (III de V)
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (IV de V)
- DirtyTooth Hack: It´s only Rock'n Roll but I like it (V de V)
- DirtyTooth Hack: Reemplazar el módulo Bluetooth en Marshall Killburn
- DirtyTooth Hack: Seminario en Vídeo
- DirtyTooth para Raspberry Pi
*********************************************************************************

Entrada destacada

Hacking IA: Jailbreak, Prompt Injection, Hallucinations & Unalignment. Nuestro nuevo libro en 0xWord

Pocas veces me ha hecho tanta ilusión que saliera un nuevo libro en 0xWord como con este libro de " Hacking IA: Jailbreak, Prompt Inje...

Entradas populares