Un café por replay: reversing y ataques Bluetooth en el mundo real

Author: Alberto Meléndez García

Hacking una máquina de café con Bluetooth

Charla de Alberto (analista en GMV, máster en UCM, CTF player) — sin fecha concreta, contexto de evento de seguridad

Idea principal

Un tío se quedó sin dinero para el café y en vez de pedirle otro euro a un compañero, decidió investigar la aplicación móvil que gestiona el pago. Lo que empezó como curiosidad se convirtió en un análisis completo: reversing del APK, sniffing Bluetooth y finalmente un replay attack que le sacaba café gratis (y KitKats).

Conceptos clave

• La app Android tenía casi 900 carpetas y 8.500 ficheros — no era un CTF de juguete
• Herramienta Mobsf para análisis estático: detectó datos hardcodeados y cifrado débil desde el primer vistazo
• La comunicación app-máquina va por Bluetooth (protocolo RF-COM, canal 6)
• Los mensajes van cifrados con AES-SCB sin padding, pero la clave maestra y el nonce estaban escritos en el propio código — fatal
• La clave de sesión es la misma para todas las máquinas que usen esa app
• Flujo legítimo: login → validación de crédito en cloud privado → handshake BT → secuencia de compra → café
• Con Android HCI Snoop Log activado (opciones de desarrollador) capturó todas las tramas BT en un .log legible con Wireshark
• Una vez descifrados los mensajes, reconstruyó la comunicación con un script Python que inyectaba 20€ de crédito
• También lo replicó con un Flipper Zero + módulo ESP32 (el Flipper solo soporta BLE, no RF-COM)

Desarrollo/contexto

La parte más interesante del análisis es que no hizo falta explotar nada raro: todo estaba ahí, en el código. Las claves hardcodeadas, el algoritmo de cifrado identificado, la estructura de los mensajes en JSON con campos como MSG_header... Básicamente el código te lo contaba todo si te ponías a leerlo con calma.

El replay attack en sí es sencillo de entender: captura una comunicación legítima, descifra los mensajes, los modificas (cambias el campo de crédito de 400 a 2000 en hexadecimal, que corresponde a 20€) y los reenvías a la máquina. Como el canal RF-COM está abierto y acepta conexiones sin autenticación extra, cuela. El detalle crítico es el timing: hay que inyectar el crédito en el momento justo del handshake, si no la máquina se queda colgada.

Lo del ESP32 tiene mérito: se dio cuenta de que el Flipper no soportaba el protocolo necesario y buscó una solución de hardware alternativa. Eso ya no es solo scripting, es meterse en el barro de verdad.

Términos técnicos

• APK reversing: descompilar una app Android para leer su código fuente
• RF-COM: protocolo Bluetooth clásico para comunicación serie
• HCI Snoop Log: log nativo de Android que registra todo el tráfico Bluetooth
• Replay attack: capturar una comunicación válida y reenviarla para engañar al sistema
• AES-SCB: variante de AES sin padding, más débil y predecible
• BLE: Bluetooth Low Energy, distinto al Bluetooth clásico

Conclusiones

Lo que me llevo es que los sistemas embebidos (máquinas de vending, IoT en general) suelen tener una seguridad bastante deplorable comparada con lo que se exige en aplicaciones web. Claves hardcodeadas en el APK, canales Bluetooth abiertos, sin autenticación mutua... son errores de diseño básicos. También me parece relevante el punto de que la misma clave funciona para todas las máquinas: un fallo así escala de forma brutal.

Para investigar más

• Cómo funciona RF-COM a bajo nivel y sus diferencias con BLE
• Frida para instrumentación dinámica de apps Android (lo mencionaron en preguntas y quedó pendiente)
• Hasta qué punto es atribuible el ataque: el ID de usuario viaja en los paquetes pero se puede modificar