Todo empezó con la ilusión de montar un canal de YouTube compartido con mi amigo David Caro. La idea era hacerlo con algo especial, algún tipo de hardware molón con un toque de tecnología novedosa. Supimos de la existencia de cámaras que grababan en 360 grados al ver que se ofrecía la posibilidad de adaptar contenido de ese tipo tanto en Facebook como en YouTube, entonces empezamos a revisar las especificaciones de varias en búsqueda de una “finalista”, y la candidata final fue la 360fly 4k.
No os la voy a “vender” ni cómo la mejor, ni cómo la peor, simplemente se ceñía a nuestras necesidades. El producto nos satisfacía y cumplía con lo que leímos, pero algún “ángulo muerto” se ocultaba en ella.
El misterio de la password de la cámara
Un día, después de terminar una sesión de grabación, mi amigo David me pidió la cámara para pasar-se los vídeos directamente por USB en lugar de transferir-los por la red, ya que al grabar en 360 y resolución 4K, hace que aumente considerablemente el peso de los clips. Cuando la tuve de nuevo en mis manos, algo raro vi que me descuadró. Un pop-up en la app me decía que la “password” era incorrecta, y yo no la había cambiado.
Le pregunté a mi amigo David si la había cambiado él, a lo que me dijo que no, que intentó con la app mediante conexión Wi-Fi, Bluetooth, pero nada, y que fue el cable USB el que logró hacer las “paces” con los datos, y la transferencia prosiguió. ¿Qué hace uno cuando el método tradicional no funciona antes de hacer un reset? Pues probar y ver que otros recursos tenía, a lo que me dije, voy a ver si puedo cambiarla (mediante la app oficial para Android), seguro que me dirá que no… ¡ahí va!
Se la tragó con patatas, inserté una nueva y como si nada. Aí fue cuando pensé que o me quedo con la intriga o investigo, y como me conozco opté por resolver el enigma que me tenía absorto. Durante el “shock” y la incomprensión, me vino un flash sobre un proyecto que se mantuvo un tiempo “top secret” de Chema Alonso y su equipo de ElevenPaths, el ya popular DirtyTooh Hack, que me inspiró para seguir con esto.
Un punto clave era la conexión Bluetooth, ya que cuando la password fue cambiada no se hizo por Wi-Fi, sino por Bluetooth, así que, teniendo eso en cuenta, lo primero era empezar por esta tecnología y el rol que ejerce en este modelo de cámara.
Aprendiendo del enemigo por BlueTooth
A nivel de usuario entendía lo justo, pero tenía cero experiencia en analizar nada con Bluetooth. Me tocaba hacer de “dentista” y sacar “la caries azulada”. Indagando, en busca de algún tipo de sniffer, me topé con Ubertooth One. Esa no era mi parada ya que me estaba pasando de largo. no digo que sea una mala herramienta pero no era la adecuada para lo que necesitaba yo con mi experiencia en el tema. Buscando más, vi que tenía el sniffer más cerca de lo que pensaba. Resulta que el propio sistema operativo Android, a partir de la versión 4.4 ya incorpora un sniffer de tipo activo (es decir, en una conexión controlada/vinculada o pareada).
Se activa en las opciones del desarrollador, y se genera un fichero con nombre btsnoop_hci.log (que en mi caso lo guardaba en la raíz de la memoria del terminal). Tras activarlo me puse a cambiar otra vez la password para luego dar una ojeada en Wireshark, y hacer una búsqueda por la palabra que había puesto como nueva contraseña.
En la imagen se puede ver la password en claro a ASCII. ¡BINGO! Lo tenemos. ¿¡Y ahora qué!?¿Cómo interactúo y con qué? Esos paquetes capturados se trataban de una versión de BlueTooth más moderna, por así decirlo, se trata del Bluetooth Low Energy. Esta variante de Bluetooth, empieza a partir de la versión 4.0. Diseñado para reducir el consumo de energía en comparación con la versión antigua y nacido para adaptarse en el mundo del IoT. Funciona algo distinto al Bluetooth “clásico”. Se basa en una estructura de GATT: Generic Attribute Profile para la transferencia de datos.
Su organización se estipula en: perfiles, servicios y características.
Otro valor valioso es el handle, de 16 bits y usado para ser distinguido en el servidor GATT (en la cámara) y va asociado con un UUID en cada una de las características, como si se tratase de un alias cortito para facilitar su uso. Los servicios tienen un rango de handles, este rango se asocia sólo a un UUID (un servicio conlleva un rango e identificado por un UUID) así pues, podremos saber a qué servicio pertenece dicha característica handle. Vamos a clarificarlo en la práctica de manera visual junto a la siguiente figura.
En los servicios (= primary) tenemos un handle, que empieza por 0x0001 y acaba en 0x0005. Este servicio, llamado “Generic Attribute”, tiene el UUID 1801. El UUID de la característica con nombre “Service Changed” es 2a05 con handle 0x0003, este handle está comprendido en el rango que va desde 0x0001 a 0x0005. En definitiva, la característica “Service Changed” forma parte del servicio “Generic Attribute”. Más claro así, ¿verdad?
PoC en acción
Ya va siendo hora de ponerse manos a la obra, viendo por donde van “los tiros”. Veamos cómo manejarlo bajo Kali Linux. Se puede hacer por la propia app cómo método más fácil para el PoC, pero desde escritorio aporta otras cosas. El resumen de lo que haremos es:
Fase 1: Cambiando la Password
Ponemos en pie la pila Bluetooth con: systemctl enable bluetooth.service y systemctl start bluetooth.service.
Verificamos que todo esté correcto como puede verse en la figura siguiente con hciconfig
Escaneo en busca de la cámara con hcitool lescan.
Convertir la password en formato hexadecimal (que usaremos más tarde) con: echo StrongPassword | xxd –p
Conectar con la cámara mediante gatttool a modo interactivo: gatttool –I y connect [mac cámara]. Como veis, no requiere de password, el método de conexión es “Just Works”. ¡Qué fácil!, ¿no? Eso mismo pensé yo.
 |
| Figura 1: BluedIoT: Cómo hackear 360Fly Action Cameras usando BlueTooth Low Energy [CVE-2017-8403] |
No os la voy a “vender” ni cómo la mejor, ni cómo la peor, simplemente se ceñía a nuestras necesidades. El producto nos satisfacía y cumplía con lo que leímos, pero algún “ángulo muerto” se ocultaba en ella.
El misterio de la password de la cámara
Un día, después de terminar una sesión de grabación, mi amigo David me pidió la cámara para pasar-se los vídeos directamente por USB en lugar de transferir-los por la red, ya que al grabar en 360 y resolución 4K, hace que aumente considerablemente el peso de los clips. Cuando la tuve de nuevo en mis manos, algo raro vi que me descuadró. Un pop-up en la app me decía que la “password” era incorrecta, y yo no la había cambiado.
 |
| Figura 2: Alerta de contraseña erronea |
Le pregunté a mi amigo David si la había cambiado él, a lo que me dijo que no, que intentó con la app mediante conexión Wi-Fi, Bluetooth, pero nada, y que fue el cable USB el que logró hacer las “paces” con los datos, y la transferencia prosiguió. ¿Qué hace uno cuando el método tradicional no funciona antes de hacer un reset? Pues probar y ver que otros recursos tenía, a lo que me dije, voy a ver si puedo cambiarla (mediante la app oficial para Android), seguro que me dirá que no… ¡ahí va!
 |
| Figura 3: Cambiando la contraseña desde la app oficial de Android |
Se la tragó con patatas, inserté una nueva y como si nada. Aí fue cuando pensé que o me quedo con la intriga o investigo, y como me conozco opté por resolver el enigma que me tenía absorto. Durante el “shock” y la incomprensión, me vino un flash sobre un proyecto que se mantuvo un tiempo “top secret” de Chema Alonso y su equipo de ElevenPaths, el ya popular DirtyTooh Hack, que me inspiró para seguir con esto.
Un punto clave era la conexión Bluetooth, ya que cuando la password fue cambiada no se hizo por Wi-Fi, sino por Bluetooth, así que, teniendo eso en cuenta, lo primero era empezar por esta tecnología y el rol que ejerce en este modelo de cámara.
Aprendiendo del enemigo por BlueTooth
A nivel de usuario entendía lo justo, pero tenía cero experiencia en analizar nada con Bluetooth. Me tocaba hacer de “dentista” y sacar “la caries azulada”. Indagando, en busca de algún tipo de sniffer, me topé con Ubertooth One. Esa no era mi parada ya que me estaba pasando de largo. no digo que sea una mala herramienta pero no era la adecuada para lo que necesitaba yo con mi experiencia en el tema. Buscando más, vi que tenía el sniffer más cerca de lo que pensaba. Resulta que el propio sistema operativo Android, a partir de la versión 4.4 ya incorpora un sniffer de tipo activo (es decir, en una conexión controlada/vinculada o pareada).
 |
| Figura 4: Activando el log de conexión BlueTooth en Android |
Se activa en las opciones del desarrollador, y se genera un fichero con nombre btsnoop_hci.log (que en mi caso lo guardaba en la raíz de la memoria del terminal). Tras activarlo me puse a cambiar otra vez la password para luego dar una ojeada en Wireshark, y hacer una búsqueda por la palabra que había puesto como nueva contraseña.
 |
| Figura 5: Paquete BlueTooth con la password enviada en texto claro |
En la imagen se puede ver la password en claro a ASCII. ¡BINGO! Lo tenemos. ¿¡Y ahora qué!?¿Cómo interactúo y con qué? Esos paquetes capturados se trataban de una versión de BlueTooth más moderna, por así decirlo, se trata del Bluetooth Low Energy. Esta variante de Bluetooth, empieza a partir de la versión 4.0. Diseñado para reducir el consumo de energía en comparación con la versión antigua y nacido para adaptarse en el mundo del IoT. Funciona algo distinto al Bluetooth “clásico”. Se basa en una estructura de GATT: Generic Attribute Profile para la transferencia de datos.
 |
| Figura 6: Estructura GATT |
Su organización se estipula en: perfiles, servicios y características.
1.-Perfil: Describe el tipo de dispositivo basado en sus servicios.
2.-Servicio: Define función/es del dispositivo, un servicio tiene una colección de características.
3.- Característica: Contiene un valor y se utiliza para el transporte de los datos. Contiene también propiedades para controlar el comportamiento de la característica (lectura, escritura, notificación) para designar los permisos adecuados, y los descriptores para describir en más detalle mediante línea/s de texto tipo string.Los servicios y las características tienen un UUID para ser identificados. Bluetooth SIG (Special Interest Group) usa 16 bits del UUID para la especificación de sus nombres como normativa. 128 bits son personalizados, destinados para el fabricante. 360Fly tiene su distintivo como miembro aprobado, usando 16 bits de su UUID como servicio.
Otro valor valioso es el handle, de 16 bits y usado para ser distinguido en el servidor GATT (en la cámara) y va asociado con un UUID en cada una de las características, como si se tratase de un alias cortito para facilitar su uso. Los servicios tienen un rango de handles, este rango se asocia sólo a un UUID (un servicio conlleva un rango e identificado por un UUID) así pues, podremos saber a qué servicio pertenece dicha característica handle. Vamos a clarificarlo en la práctica de manera visual junto a la siguiente figura.
 |
| Figura 7: Estructura con la herramienta gatttool |
En los servicios (= primary) tenemos un handle, que empieza por 0x0001 y acaba en 0x0005. Este servicio, llamado “Generic Attribute”, tiene el UUID 1801. El UUID de la característica con nombre “Service Changed” es 2a05 con handle 0x0003, este handle está comprendido en el rango que va desde 0x0001 a 0x0005. En definitiva, la característica “Service Changed” forma parte del servicio “Generic Attribute”. Más claro así, ¿verdad?
PoC en acción
Ya va siendo hora de ponerse manos a la obra, viendo por donde van “los tiros”. Veamos cómo manejarlo bajo Kali Linux. Se puede hacer por la propia app cómo método más fácil para el PoC, pero desde escritorio aporta otras cosas. El resumen de lo que haremos es:
1. Cambiar la password de la Wi-Fi mediante Bluetooth Low Energy.
2. Tomar una foto y guardarla (para el recuerdo ;) ).
3. ¡Borrarlo todo! (simulando que no se deja huella).(Nota: Importante tener en cuenta de que se use Bluetooth mínimo versión 4.0 Low Energy para que funcione, si no se está seguro, revisad con el comando hciconfig –a [interfaz]
Fase 1: Cambiando la Password
Ponemos en pie la pila Bluetooth con: systemctl enable bluetooth.service y systemctl start bluetooth.service.
 |
| Figura 8: Activando BlueTooth con Kali Linux |
Verificamos que todo esté correcto como puede verse en la figura siguiente con hciconfig
 |
| Figura 9: Revisando el estado del hardware BlueTooth |
Escaneo en busca de la cámara con hcitool lescan.
 |
| Figura 10: Buscando la cámara 360 con BlueTooth LE |
Convertir la password en formato hexadecimal (que usaremos más tarde) con: echo StrongPassword | xxd –p
 |
| Figura 11: ASCII a HEX de la password |
Conectar con la cámara mediante gatttool a modo interactivo: gatttool –I y connect [mac cámara]. Como veis, no requiere de password, el método de conexión es “Just Works”. ¡Qué fácil!, ¿no? Eso mismo pensé yo.
 |
| Figura 12: Conectando a la cámara con gatttool |
Ahora toca cambiar el password con el handle que ya sabemos porque “snifamos” dicho paquete anteriormente: char-write-cmd 0x0048 [password en hexadecimal]
 |
| Figura 13: Cambio de password mediante ghatttool |
Fase 2. Tomando foto y guardándola
Ahora nos conectamos a la Wi-Fi sin más con la password que sabemos, en este caso hemos puesto StrongPassword.
Ahora que estamos dentro de la red de la cámara toca seguir jugando. Accederemos al Web Server de la cámara que le gusta usar la dirección IP 192.168.2.1. Accedemos mediante navegador, Mozilla Firefox que ya viene de serie en Kali Linux.
 |
| Figura 14: Navegando por el Web Server de la cámara |
Usaremos la herramienta curl como cliente ReST para jugar con las opciones de la cámara. ¿Que te preguntas que cómo lo hemos sabido? Nos podemos poner a hacer un man in the middle como el jueves, interceptando el tráfico, o bien basta con leer documentación y hacer una visita a la ReST API, de la cámara que es pública. Tomemos una captura y a sonreír :D : curl –X POST --insecure https://192.168.2.1/360fly/camera/photo
 |
| Figura 15: Tomando la foto con cliente ReST. |
En este caso se utiliza:
-X: para indicarle el tipo de método de solicitud POST en este caso.Para saber si ha ido bien, verificaremos refrescando el navegador, aparecerá un nuevo .JPG con prefijo “FLY” y pulsando encima, podremos ver nuestro retrato:
--insecure: lo mismo que –k para saltar la verificación de certificado que no tenemos en el almacén de confianza.
Podemos añadir de manera opcional –i o --include para obtener la información de las cabeceras.
 |
| Figura 16: Mostrando la foto |
Para guardarla, hagámoslo fácil, simplemente botón derecho y guardar en el lugar que más os guste (¡ojo!, si estáis con Kali Linux en modo live, aseguraros de guardarla en partición no temporal de memoria).
Con solo una línea, eliminaremos todo el contenido que hay en la cámara, lo que puede ser un verdadero problema si alguien está haciendo, por ejemplo, el reportaje de nuestra vida: curl –X DELETE --insecure https://192.168.2.1/360fly/media/file
 |
| Figura 17: Eliminando el contenido de la cámara |
Y si fue bien, al refrescar la Web, veremos el típico Error 404 Not Found :S ¡Y eso era todo amigos, pero... aún hay más!
En la siguiente imagen tienes en una tabla otros comandos interesantes para el PoC - no todos los disponibles - para usar ambos: Bluetooth Low Energy y Wi-Fi.
 |
| Figura 18: Algunas de las funciones bajo BlueTooth y Wi-Fi de la cámara |
Si solo usamos BLE (Bluetooth Low Energy), atacar a otras funciones es posible sin ser requisito la función de cambio de password Wi-Fi (cosas como poder hacer grabación, activar GPS, etcétera) ya que GATT nos permite enviar los valores correspondientes. Eso sí, tendremos derecho de descarga si además accedemos al Wi-Fi como hemos visto en la PoC.
Y podría seguir enrollándome como persiana en bucle, por eso, si queréis profundizar más en detalle, aquí tenéis un artículo que hice exponiendo lo investigado.
Lo llamé BluedIoT, (haciendo juego con IoT) cómo una situación idiota por el hecho de juntar BLE con Wi-FI, en este caso porque de nada te sirve poner un super mega password con WPA2 si el Bluetooth lo cambia cuando le da la gana. A la vulnerabilidad se le atribuyó el CVE ID: CVE-2017-8403
 |
| Figura 20: CVE-2017-8403 del bug de360fly 4K |
Y aquí un vídeo que también realicé, con lo que hemos expuesto en este artículo, con un aire un tanto cinéfilo para darle un poco de entusiasmo.
Figura 21: Vídeo de la PoC del Hack de la 360Fly 4k
Aún suelo escuchar aquellos que dicen ¿Pero quién va a querer entrar si no tengo nada que esconder? Sí, quizá tengan razón, la probabilidad puede ser muy baja. En España esta cámara puede que no la tenga mucha gente, pero yo la tengo, y quiero un producto con unos mínimos de calidad a nivel de seguridad ya que, está en juego la confidencialidad del contenido multimedia y de otras muchas cosas que pueden dar lugar a ciertos negocios más oscuros. Pueden hacerte daño moralmente borrándose así tus memorias, tus mejores instantes.
Uno también puede pensar que la cámara esta defectuosa si se ha sido víctima de ello, enfureciendo al usuario final y culpando al fabricante. Como veis, todos perdemos, sólo gana el ciberdelincuente, una persona muy mala. Sed buenos… ¡Sed hackers!
Autor: Gerard Fuguet
Buenísima la entrada. Muchas gracias por compartirla con nosotros.
ResponderEliminarUn saludo.
Buen estudio del caso.
ResponderEliminarGracias por la publicacion.