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.
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.
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
2) No tenemos aplicación móvil o no tenemos el 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.
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:
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.
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’.
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:
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.
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.
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.
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:
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
 |
| 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 pairingComo 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.
• 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
 |
| 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
No hay comentarios:
Publicar un comentario