Auditoría y Hacking Bluetooth Low-Energy (BLE)

Llegó el 27 de noviembre y llegaron los 4 días de Cybercamp 2019. En esta ocasión Valencia se vestía de centro de la ciberseguridad a nivel nacional. Por sexto año podía disfrutar de este evento, lo que me llena de orgullo, ya que he tenido el honor de estar en todos: Madrid por dos veces, León, Santander, Málaga, y en esta ocasión, Valencia. Como veis uno se va haciendo mayor y ya cuenta con nostalgia los años y el poder estar en eventos año tras año.

Figura 1: Auditoría y Hacking BlueTooth Low-Energy (BLE)

En esta ocasión, tocaba impartir un taller técnico y una charla. El taller técnico estaba dedicado a la Auditoría y hacking de dispositivos Bluetooth Low-Energy, con diversos ejemplos y casos prácticos de lo que puede ser un ejercicio de Red Team dentro de una empresa utilizando estas tecnologías. Este taller se celebró a las 10:00 del viernes 29 de noviembre.

Figura 2: El Red Team de la empresa

Por la tarde, me tocaba irme al auditorio para impartir la charla: “Emulación de adversarios: De entender ATT&CK a construir tu propia emulación”. Para mí eran dos retos puestos en el calendario y lo vamos a tratar en dos entradas. Primero hablemos de la auditoría y el hacking.

Auditoría de dispositivos con BlueTooth Low Energy (BLE)

El taller de auditoría y hacking a dispositivos BLE mostraba cómo llevar a cabo una serie de pruebas para identificar el nivel de seguridad de dispositivos que utilizan esta tecnología. Además, se mostraba como poder ‘sniffar’ tráfico BLE desde dos puntos de vista: desde nuestro propio dispositivo Android o “escuchando” el aire con placas Micro:Bit y la herramienta BTLEJack.

Antes de esto, se dieron una serie de conceptos y teoría necesaria para entender, mínimamente, el mundo de Bluetooth Low-Energy como, por ejemplo, los canales de BLE, el channel map, la address access, el intervalo de salto, el incremento de salto, el algoritmo de salto, los roles de los dispositivos, etcétera. Como comentaba, el sniffing puede verse desde dos puntos de vista:

1) Tengo una aplicación móvil y un dispositivo BLE y quiero ver cómo interactúan

Puedo hacer uso de la función del sistema operativo Android “Enable Bluetooth HCI snoop log”, la cual se puede encontrar en las opciones del desarrollador en ajustes. Si activamos esta opción, todo el tráfico Bluetooth del dispositivo se deposita en un fichero en la memoria interna o en al sdcard. 

Figura 3: Activación de log BlueTooth en Android

Por ejemplo, en la ruta /Android/Data podemos encontrar un fichero denominado *snoop.log. Simplemente, con renombrarlo a PCAP, podríamos abrirlo con Wireshark y analizar el tráfico.

2) No tenemos aplicación móvil o no tenemos el dispositivo BLE

Y requerimos estudiar las tramas que se pueden capturar a través del medio de compartición: el aire. En este caso, podemos rápidamente hacer uso de diferentes dispositivos como, por ejemplo, Ubertooth. En este caso, hacemos uso de placas Micro:Bit y BTLEJack para capturar el tráfico.

El modo de funcionamiento de BTLEJack nos permite capturar el tráfico de conexiones nuevas y el tráfico de conexiones ya existentes. Con la opción –c podemos poner el dispositivo a la escucha en los canales de Advertisement BLE. Es decir, los canales 37, 38 y 39. Si tenemos 3 placas Micro:Bit con BTLEJack podemos poner cada placa a la escucha en un canal, no perderíamos la posibilidad de capturar un paquete de conexión contra un dispositivo BLE.

Con la opción –s podemos empezar a enumerar las conexiones y sus Access Address. De este modo podemos ver el número de conexiones que y el número de paquetes que se están enviando. Podemos detectar actividad o no en las conexiones. Además, descubrimos cuál es el Access Address.

Figura 4: Enumeración con la opción -s

Como podemos ver en la imagen, cuando hay una conexión nueva podemos ver el paquete CONNECT_REQ enviado por un canal de anuncio. Se puede ver la BMac de origen y la BMac destino. Se puede ver claramente la Access Address, el CRC, el intervalo de salto (tiempo dedicado antes de saltar a otro canal), el incremento de canal y el mapa de canales, es decir, canales que podrán ser utilizados en la conexión, en función del ruido detectado durante la conexión.

Si queremos hacer que el tráfico se vuelque a Wireshark podemos utilizar los parámetros:

 –x nordic –o [nombre de archivo PCAP] –w [pipe para wireshark, ejemplo /tmp/ble]

De esta forma, aparte de capturar, el tráfico es volcado a Wireshark. Para esto tenemos que tener la herramienta preparada, es decir, abrir Wireshark ir a interfaces de red y añadir un pipe. El valor del pipe debe coincidir con el valor del parámetro –w de BTLEJack. Una vez se realizaba la captura de tráfico hacíamos un análisis del PCAP. Esto es importante, ya que debemos entender cómo se encapsula el tráfico BLE y las capas de Bluetooth.

Figura 5: Encapsulado de tráfico BLE y capas BlueTooth

Para el análisis haremos uso de Wireshark y podemos ver los paquetes de conexión, ver si la conexión está cifrada, si va en texto plano, la lectura de características BLE, la escritura de éstas y un poco toda la interacción que las aplicaciones tienen con los dispositivos.

Figura 6: Información capturada en la trama

Otro ejemplo de cómo podemos analizar cierto tráfico es con BTLEJack sabiendo interpretar este tráfico directamente, lo cual no es recomendable, ya que Wireshark nos va a dar todo ‘mascado’.

Figura 7: Interpretación en WireShark

Para ver qué se puede hacer dejo esta imagen dónde se pueden ver conceptos que se trabajaron en la parte de teoría del taller como: el valor del dato que se envía, el handle de la característica, el código de operación, el CID, las propiedades (si son de escritura, lectura, notificación, etcétera.).

Hacking a dispositivos BlueTooth Low Energy (BLE)

Dedicamos un apartado a los ataques de BLE partiendo de dos posibilidades: el tráfico puede estar sin cifrar o cifrado. En función de esta premisa, podemos ir por un camino o por otro. En el caso de ir un por el camino del tráfico cifrado, si conseguimos descifrar el tráfico podríamos ir, después, por el camino de tráfico no cifrado.

1) Ataques de Replay

Empecé hablando de los ataques de replay, los cuales ya hemos comentado en este blog. La idea es sencilla, si puedo capturar el tráfico no cifrado se puede intentar encontrar los comandos enviados a las características con propiedades “write” y volver a conseguir realizar acciones reutilizando dichos comandos. En el siguiente vídeo se puede ver la demo que se presentó en BlackHat.


Figura 8: Ataque de Replay en dispositivo BLE
En el taller de Cybercamp se hizo la demo con un SmartLock simulado en una placa Micro:Bit, pero este ataque sería exactamente igual en otros dispositivos, tal y como se mostró en el artículo de "Hacking in your life".


Figura 9: Envío de comandos por BLE
En ambos vídeos se hace uso de un código. Dicho código es obtenido a través de una captura BLE y un análisis del fichero PCAP resultante.

2) Session Hijacking

El segundo ataque mostrado era el de una Session Hijacking. ¿Esto se puede hacer en BLE? Sí, la idea es sencilla. Echar, literalmente, de la sesión a un dispositivo legítimo y reutilizar el Access Address para suplantar la conexión que había anteriormente.¿Cómo lo echa? El atacante genera una serie de timeouts y los envía al dispositivo conectado, hasta que éste pierde la conexión. Este ese instante se realiza el robo de la sesión haciendo uso de la Access Address. El esquema del ataque es el siguiente:

Figura 10: Session Hijacking en BLE

Con BTLEJack se puede hacer este ataque a través de la ejecución de btlejack –f [access address] –t. Si tenemos más datos de la conexión como, por ejemplo, el mapa de canales, el CRC o el intervalo de salto se puede añadir a Btlejack con el objetivo de simplificar el procesamiento y el descubrimiento de dichos datos.

Figura 11: Session Hijacking a dispositivo BLE 

Como se puede ver en la imagen, se proporciona, además, el mapa de canales ya que fue capturado anteriormente. Una vez que el ataque tiene éxito, se obtiene una consola donde se pueden ejecutar ciertos comandos, por ejemplo, discover.

3) Ataque de Jamming

Con este comando se hace un descubrimiento de características disponibles y sus propiedades en el dispositivo con el que se ha conseguido sesión. Podemos escribir o leer cualquier característica que tenga dichas propiedades, por lo que si tenemos conocimiento de acciones que se pueden hacer, se podrían realizar contra el dispositivo.

Figura 12: Ataque de jamming

Otro ataque que pudimos ver en el taller es el jamming. Este ataque es, parcialmente, utilizado en el ataque de hijacking. La idea es generar una serie de timeouts para que se pierda la conexión y el dispositivo móvil conectado contra el dispositivo BLE quede desconectado.

4) Descifrando una conexión cifrada

¿Y si la conexión está cifrada? Esto empieza a complicarse. Puede estar cifrada de varias formas: con un PIN de 6 dígitos, el cual es utilizado para hacer un pairing entre ambos dispositivos, utilizando cifrado de 128 bits o con ECDH keys. En el primer caso, y si se dan las circunstancias adecuadas, podemos aprovecharnos y descifrar el tráfico.

Figura 13: Captura de tráfico BLE cifrado

En la captura se ve claramente que el tráfico está cifrado, ya que no podemos ver ningún paquete Bluetooth Attribute Protocol o ATT. En la imagen superior, se puede ver el paquete cifrado y debajo el paquete descifrado. Para ello necesitamos capturar:

• Una petición de pairing
• La respuesta de pairing
• Dos confirmaciones de paquetes de pairing
• Dos paquetes random de paquetes de pairing
• Un paquete con el flag LL_START_ENC_REQ

Como vemos, nuestra captura debe tener al menos esto, junto al paquete de conexión, el CONN_REQ. Teniendo la Temporal Key y los datos anteriores, se puede lograr la LTK y STK, es decir, la clave de largo plazo y la de corto plazo. Una vez tenemos el PCAP, se lo podemos pasar a la aplicación crackle, la cual podemos encontrar en su GitHub.

Figura 14: Descifrando una conexión BLE cifrada usando crackle

Después de esto hablamos de las posibilidades de suplantación en el ámbito Bluetooth y las contramedidas que podemos tomar para poder fortificar entornos BLE desde el diseño de la aplicación o dispositivo.

Saludos,

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

Data Loss Detection, Google User Content y tus documentos confidenciales en la Caché

Las opciones de indexación de documentos por los motores de búsqueda como Google, a veces son un "problema" hasta para Google. El tener que jugar con las opciones de configuración de los ficheros robots.txt a nivel de dominio, con las etiquetas META NoIndex a nivel de documento HTML y con los HTTP Headers X-Robots-Tag a nivel de recurso en servidor web, hace que no siempre se consiga evitar que cosas que no debían aparezcan en las bases de datos de Google o Bing, haciendo las delicias de los amantes de las técnicas de hacking con buscadores.

Figura 1: Data Loss Detection, Google User Content y tus documentos confidenciales en la caché de Google

De esto ya os he contado en el pasado muchas historias. Os conté los problemas que tenía Facebook con la indexación, los problemas que tenía WhatsApp y hasta el propio Gmail, que poco a poco fue eliminando los resultados de primero Google y luego BING. Son muchos los problemas con documentos almacenados en la caché de los buscadores y problemas con documentos almacenados en el índice de los buscadores (que no es lo mismo). En la presentación de "No me indexes que me cacheo" tienes muchos ejemplos de esto, y hasta en ElevenPaths sacamos una pequeña herramienta llamada Google Index Retriever que permite sacar datos de un índice (que no de la caché) de Google.

Figura 2: No me indexes que me cacheo de Chema Alonso

Dicho esto, mi amigo rootkit - amante de los dorks - me escribió para contarme como es posible localizar documentos en la caché de Google que estuvieran indexados en Google. Suena un poco extraño, pero al final es una forma de saber qué documentos han sido cacheados, y como las opciones de indexación de GoogleUserContent.com, lo permiten, se puede buscar por él. Es decir, sería como utilizar el buscador de Google para encontrar que documentos están en la caché de Google porque las opciones de indexación de Googleusercontent.com lo permite y porque las opciones de caché en el sitio donde estuviera el documento lo permitieron. Triple rizo mortal hacia atrás.

Figura 3: El servidor de Googleusercontent.com, a día de hoy, no usa etiqueta X-Robots-Tag: noindex

Es decir, un sitio tiene un documento con las opciones de caché no protegidas. La URL le llega a Google que lo cachea. La URL de la visualización en caché Google es indexada por Google, porque las opciones de indexación de Googleusercontent.com no están fortificadas. Como resultado, cualquiera puede buscar URLs de la caché indexadas en el buscador de Google.

Figura 4: Más de 100.000 enlaces en Googleusercontent.com

Si haces clic en los enlaces, la mayoría no están disponibles, ya que se trata de un contenido que ha sido visualizado dentro de cualquier lugar. Eso sí, donde se ha visualizado esa o

Figura 5: Documentos accesibles vía caché de Google

Como veis, hay hasta documentos confidenciales, a los que se puede acceder vía caché en este caso. Por lo que cualquiera puede verlos en Internet.

Figura 6: Documentos privados indexados y cacheados en Googleusercontent.com

Estos son los tipos de documentos que los servicios de Data Loss Detection al final deben investigar. Que aparezca un documento confidencial de tu empresa publicado en un sitio de Internet debe ser monitorizado por los servicios de Ciberseguridad que - en lugar de mirar por la cámara de seguridad para ver si la puerta del garaje se abre o se cierra - miran por Internet a ver qué ha pasado que afecte a tu empresa.

Figura 7: Documento confidencial indexado, cacheado y accesible vía Googleusercontent

En este caso son documentos PDF, que si se han marcado de forma segura con una tecnología como Shadow, es fácil de investigar, ya que el documento PDF tiene incrustada una marca oculta y cifrada con los datos de a quién fue entregado dicho documento, como podéis ver en la demo que hicimos en el Security Innovation Day 2016.

Figura 7: Demo de Shadow para detectar filtraciones de documentos

Al final, por culpa de una mala configuración de los permisos - como le pasó al tipo que se dejó las passwords en un doc en Evernote y quedó cacheado durante meses -, y un mal uso del enlace del documento en el que se visualiza el contenido, sumado a unas opciones de indexación y cacheo laxas, puede que haga que un documento o un archivo que no te interese acabe estando a disposición de todo el mundo en Internet. Take care.

Saludos Malignos!

Shadow: Cómo localizar al que filtra la información en tu empresa

Durante el pasado Security Innovation Day 2016 hubo muchas noticias que merece la pena que os vaya desgranando. De todas ellas, hoy quiero destacar lo que muchos habéis podido leer ya en los medios de comunicación: La adquisición de la tecnología Shadow del Centro de Tecnológico de Galicia, Gradiant y que pasa a formar parte de la familia de soluciones que tenemos para la protección de la información que circula en documentos.

Figura 1: Shadow. Cómo localizar al que filtra la información en tu empresa

La estrategia que hemos seguido durante estos años para construir nuestro portfolio de soluciones se ha basado en la construcción de soluciones a problemas mediante la generación de alianzas estratégicas con empresas de referencia, más el enriquecimiento de nuestra oferta desarrollando nuestros productos, adquiriendo tecnologías o invirtiendo en empresas, como representa esta imagen que utilicé en la presentación del evento y que recoge un poco la línea temporal de adquisiciones, inversiones y desarrollo de productos.

Figura 2: Descripción de inversiones, adquisiciones y creación interna de productos en ElevenPaths.

En concreto, dentro de la solución de Data Protection, durante los últimos años hemos estado avanzando en la gestión documental segura en las empresas para proteger la información que circula en archivos. Con MetaShield Protector comenzamos un camino para evitar la fuga de información por medio de metadatos, información oculta y datos perdidos, que hemos ido extendiendo para tener una familia tan grande como la que tenemos hoy en día.

Figura 3: Familia de MetaShield Protector para gestión documental

Con al adquisición de las tecnologías SealSign ampliamos el ámbito de protección con la posibilidad de gestionar la firma digital por medio de sistemas centralizados de certificados digitales más la potencia de usar firma manuscrita biométrica con SealSign BioSignature, como os conté ayer mismo.

Shadow: Marcado de documentos con trazas de seguimiento

Ahora con Shadow añadimos a la familia la opción de implantar en documentos impresos o compartidos en formato postscript marcas de seguimiento que permiten realizar una traza hacia el origen del documento en caso de que se produzca una fuga del mismo con solo hacerle una fotografía. Cada documento lleva incrustada marcas de traza que se añade en el momento de imprimir los archivos, que no son visibles a simple vista, pero que utilizando el algoritmo de Shadow a partir de una una simple imagen del documento, es posible saber la información de la marca que hay guardada en él. 

Figura 4: The Shadow Files "The Truth is IN there"

Para presentar su funcionamiento hicimos una demo en dos pasos. Primero, contamos esta historia que podéis ver en este vídeo en la que se explica cómo un documento se imprime seis veces con seis marcas de Shadow y uno de ellos se filtra fuera de la organización mediante una fotografía hecha al documento original (previamente cortado), manchado de café y enviado vía WhatsApp. Queda irreconocible a simple vista, pero aún así, sigue manteniendo las características de la marca Shadow que hay en él.

Figura 5: Descripción de la tecnología de impresión con trazas Shadow

La segunda parte, que hicimos en el evento, consistía en averiguar quién de los seis miembros de la reunión había filtrado la documentación. El resultado, por supuesto es que el documento aún mantiene la traza y puede ser recuperado para sacar de él el nombre de la persona a la que se le ha entregado ese documento, y que se inyectó durante el proceso de impresión mediante técnicas de esteganografía documental.

Servicios de Document Loss Detection (DLD)

En este caso podría ser él mismo el filtrante, o que alguien se lo hubiera quitado a él, pero deja a los analistas una línea de investigación clara para lograr descubrir quién y de qué forma se ha producido la fuga de información.

Figura 6: Descripción del servicio de Document Loss Detection dentro de los procesos de Vigilancia Digital en nuestra oferta de CyberThreats

Este servicio, por supuesto, nos ayuda a completar el servicio de Document Loss Detection que ya incluimos en nuestro servicios de CyberThreats, por el que los analistas de seguridad investigan las fugas de información de los documentos de nuestros clientes. Para este servicio, como ya sabéis porque lo contamos en el evento de Mayo, habíamos invertido en la empresa 4IQ.

Figura 7: Anuncio de la inversión de Telefónica en 4IQ

Pero no solo eso, un sistema como Shadow también ayuda a localizar los documentos que se imprimen internamente dentro de una organización para localizar a los empleados que no estén siguiendo las políticas de "Paperless Office" dentro de empresa o que estén dejando documentos olvidados dentro de la propia empresa. Un simple proceso de recogida de documentos olvidados en el que el personal de limpieza se lleve aquellos que estén dejados al azar,  para que el equipo de seguridad interna pueda incidir en las buenas prácticas de seguridad de la empresa en las personas que no están teniendo cuidado de ellos. Pero también incluido con un plugin que modifique los adjuntos en el correo electrónico en el MTA para marcar la salida de ficheros o como un agente que monitorice los ficheros cuando se graban en el disco o... en cualquier punto del ciclo de vida del documento en tu empresa.

Saludos Malignos!