Hacking Inalámbrico: Ataques a Wi-Fi, Bluetooth y Protocolos RF

El espectro radioeléctrico es ahora superficie de ataque

Durante años, la seguridad inalámbrica fue territorio del equipo de hardware. La AppSec se quedaba con el código del backend. En 2026 esa frontera se rompió: los repositorios de firmware viven en el mismo monorepo que el portal, comparten el mismo CI, las mismas revisiones de código y el mismo pipeline de release. Si su empresa empieza a fabricar productos con Wi-Fi, Bluetooth o un radio IoT, alguien tiene que escanear ese código. Ese alguien es usted.

Este artículo es un recorrido riguroso por las seis superficies inalámbricas que importan en cualquier programa de AppSec moderno: Wi-Fi, Bluetooth Classic, Bluetooth Low Energy (BLE), RF sub-GHz, NFC / RFID y los transportes IoT (Zigbee, MQTT, CoAP, LoRa). Para cada superficie cubrimos los ataques famosos que conviene conocer por nombre, simulaciones realistas paso a paso de qué hace un atacante en cada caso, ejemplos de código antes y después de mitigar, y — con honestidad — qué puede y qué no puede detectar un escáner estático sobre el código que ya tiene en git.

El laboratorio del libro — cómo se ve un banco de pruebas inalámbrico

Stravos & Zephyrion abren su libro con algo que pocos manuales explican bien: cómo es un laboratorio inalámbrico real. No es una caja con USBs sueltos, es una pequeña arquitectura de tres bloques. Un investigador con su workstation y su cuaderno de bitácora a la izquierda; una cadena de radios — una por banda — en el medio; y una zona blindada al fondo donde viven los dispositivos bajo prueba (DUT) aislados del resto de la oficina. Si va a auditar Wi-Fi, BLE y RF en serio, necesitará algo parecido a esto:

Este laboratorio es imprescindible si su trabajo es validar fallas de capa física — KRACK, KNOB, BleedingBit, Crypto1 sobre MIFARE, ataques de replay 433 MHz. Pero hay una observación incómoda que el propio libro hace al cerrar el capítulo: el 70% de los hallazgos críticos en productos inalámbricos vive en el código fuente, no en el aire. SSIDs y PSKs hardcodeados, BLE_GAP_IO_CAP_NO_INPUT_NO_OUTPUT, MIFARE Classic todavía permitido, ZigBeeAlliance09 sin reemplazar, brokers MQTT en claro — todo eso se detecta sobre el repositorio, sin encender una sola antena. Esa es la grieta donde entra SF365.

Las seis superficies, en una sola vista

"Inalámbrico" es una categoría, no un protocolo. Los modelos de amenaza de cada superficie son lo bastante distintos como para que agruparlos sea exactamente la forma en que se pierden vulnerabilidades. Manténgalas separadas:

Wi-Fi: donde más equipos siguen fallando

WPA2-PSK ganó la guerra de estándares y entonces todo el mundo dejó de prestarle atención. Pero la superficie de configuración es amplia y los modos de fallo son persistentes. WEP y WPA-TKIP siguen apareciendo como "SSID de compatibilidad" para una impresora del 2008 que nadie quiere reemplazar. WPS sigue activo en routers vendidos en 2024. Los SSID y PSK siguen apareciendo embebidos en el firmware. Y las Protected Management Frames (PMF / 802.11w) — obligatorias en WPA3 y un "deberías" desde 2009 — siguen apagadas en una cantidad alarmante de despliegues.

Anti-patrón clásico (ESP-IDF)

// firmware/main/wifi_init.c
#define WIFI_SSID  "AcmeCorp-Internal"
#define WIFI_PSK   "verano2024"

wifi_config_t cfg = {
    .sta = {
        .ssid     = WIFI_SSID,
        .password = WIFI_PSK,
        .threshold.authmode = WIFI_AUTH_WPA_PSK,  // acepta TKIP
        .pmf_cfg = { .capable = true, .required = false }, // PMF opcional
    },
};

Tres problemas en seis líneas: el SSID expone el nombre de la organización, el PSK queda en el binario del producto, y el modo de autenticación acepta WPA — lo que permite a un AP malicioso forzar el downgrade a TKIP. El análisis estático detecta los tres sin necesidad de ningún radio.

// SSID + PSK provisionados en runtime (BLE / SmartConfig / QR)
wifi_config_t cfg = {
    .sta = {
        .threshold.authmode = WIFI_AUTH_WPA3_PSK,   // SAE
        .pmf_cfg = { .capable = true, .required = true }, // PMF obligatorio
    },
};
// credenciales obtenidas mediante esp_wifi_provisioning

Bluetooth Classic: el legacy pairing sigue vivo

Bluetooth 2.1 (2007) introdujo Secure Simple Pairing (SSP) y lo hizo obligatorio. Sin embargo, diecinueve años después, una cantidad deprimente de dispositivos — sensores industriales, periféricos médicos, gateways IoT antiguos — siguen emparejándose con un PIN de 4 dígitos. El ataque KNOB (CVE-2019-9506) permite negociar la entropía de la clave de cifrado a 1 byte y romperla por fuerza bruta en milisegundos.

Las pistas que delatan al firmware vulnerable

• PINs por defecto — 0000, 1111, 1234, 123456 hardcodeados en el código de setup.
• Legacy pairing — rutas de código que llaman a BTM_PIN_TYPE_FIXED y nunca a SSP.
• Discoverable permanente — setDiscoverable(0, ...) sin timeout. El dispositivo se anuncia para siempre.
• Reuso de link keys — misma clave en toda la flota, embebida en la imagen del firmware.
• Tamaño mínimo de clave 7 — el mínimo del spec, no el mínimo práctico. Configure min_key_size = 16.

BLE: el protocolo que hizo famoso al "Just Works"

El emparejamiento BLE tiene seis modos, y la elección importa. La pregunta de revisión es siempre: ¿cuál estamos eligiendo y es apropiado para los datos que manejamos?

El error más común

Un desarrollador quiere que el emparejamiento "simplemente funcione" durante el prototipo, configura las IO Capabilities a NoInputNoOutput, el dispositivo se empareja con su teléfono al instante, y la configuración nunca vuelve a revisarse. Un año después el producto sale al mercado con MitM trivial.

ble_hs_cfg.sm_io_cap   = BLE_HS_IO_NO_INPUT_OUTPUT;  // fuerza Just Works
ble_hs_cfg.sm_bonding  = 1;
ble_hs_cfg.sm_mitm     = 0;       // no exige protección MitM
ble_hs_cfg.sm_sc       = 0;       // LESC desactivado

ble_hs_cfg.sm_io_cap   = BLE_HS_IO_DISPLAY_ONLY;  // el dispositivo muestra passkey
ble_hs_cfg.sm_bonding  = 1;
ble_hs_cfg.sm_mitm     = 1;       // MitM obligatorio
ble_hs_cfg.sm_sc       = 1;       // LESC obligatorio (BLE 4.2+)
ble_hs_cfg.sm_our_key_dist   = BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID;
ble_hs_cfg.sm_their_key_dist = BLE_SM_PAIR_KEY_DIST_ENC | BLE_SM_PAIR_KEY_DIST_ID;

Sub-GHz RF: el lejano oeste

Sub-GHz es donde más fallan los instintos del AppSec porque no hay un SDK que escanear. Pero sigue habiendo código fuente. Los productos con mando a distancia que usan códigos fijos (const uint32_t REMOTE_CODE = 0x...) entregan al atacante todo lo necesario para clonarlos: un RTL-SDR de 25 USD captura el código una vez y lo reproduce con rtl_433. Las frecuencias ISM hardcodeadas (setFrequency(433.92e6)) por sí solas no son vulnerabilidades, pero combinadas con código fijo le dicen al atacante exactamente dónde escuchar.

Y luego está LoRa. LoRa es una capa física; LoRaWAN es lo que añade AES-128 con separación NwkSKey / AppSKey. Los paquetes de LoRa puros viajan en claro por el aire. Cualquier código que importa una librería de LoRa "raw" sin usar LoRaWAN para producción es una bandera roja.

NFC / RFID: el "es solo 10 cm" no es un argumento

"Es solo 10 cm" no es un argumento de modelo de amenaza, sobre todo en 2026 con ataques de NFC relay sobre Internet ya estables como proyectos de hobby. La firma estática más útil para detectar es MIFARE Classic en producción. El cifrado Crypto1 que usa MIFARE Classic fue roto académicamente en 2008 y armado en herramientas de retail como Proxmark3 y Flipper Zero. Cualquier código que aún referencia MIFARE_CLASSIC, claves por defecto FFFFFFFFFFFF, o construye la autorización solo sobre el UID es un hallazgo.

Transportes IoT: donde vive el blast radius

Wi-Fi te deja entrar a la red. Bluetooth te acerca al periférico. Pero el daño a nivel aplicación en dispositivos conectados se hace casi siempre sobre los transportes IoT:

Galería de ataques famosos — los nombres que conviene saber

Secretos IoT en el firmware — los 10 patrones que el SecretScanner debería tener

La historia del "AWS root key filtrado en GitHub" ya se contó. La versión 2026 de esa historia es "Azure IoT Hub Device SAS filtrado en un mirror del firmware", y los escáneres genéricos no la detectan porque las credenciales IoT no parecen credenciales convencionales: SAS tokens con campos HostName=..., URIs MQTT con usuario y contraseña embebidos, JWTs scoped a projects/…/registries/….

Wireless Security Baseline — 24 controles auditables

Los marcos de cumplimiento existentes no cubren bien la superficie inalámbrica. NIST SP 800-153 cubre Wi-Fi. NIST SP 800-121 R2 cubre Bluetooth. NIST SP 800-97 cubre 802.1X. IEEE 802.11i es la base criptográfica. Pero ninguno los costura en una sola lista que un líder de hardware pueda usar como checklist. SF365 publica una: el Wireless Security Baseline con 24 controles.

Tabla parcial — el baseline completo incluye los 24 controles, mapeados cada uno a su fuente NIST/IEEE.

¿Cuánto puede detectar un escáner estático realmente?

La respuesta honesta es: todo lo que sea configuración o constante en código, nada que dependa del aire. Pero esa frontera cubre una fracción sorprendentemente grande del riesgo:

• Detectable estáticamente (16 de 24 controles): elección de cifrado Wi-Fi, estado de WPS, presencia de PMF, SSID/PSK fijos, IO Capabilities BLE, LESC, flags GATT, passkeys hardcodeados, claves de bonding, código fijo en RF, MIFARE Classic, claves Zigbee por defecto, URIs MQTT/CoAP en claro, Wi-Fi creds en sdkconfig.
• Verificable por procedimiento (8 de 24): migraciones planeadas, decisiones de threat model documentadas, ciclos de provisionamiento, validación de certificados servidor en EAP-TLS.

Lo que no puede hacer un escáner es lanzar un KRACK, montar un Evil Twin o ejecutar KNOB — eso necesita radio. Pero sí puede — y debe — detectar las decisiones de configuración que hacen esos ataques triviales.

Cómo SF365 cubre las seis superficies

Security Factor 365 es la primera plataforma de AppSec con un motor dedicado a estas seis superficies. Lo llamamos el Wireless Security Engine y es el motor número 12 del ScanOrchestrator (junto con SAST, SCA, DAST, IAST, IaC, Secrets, Config, Container, API, AI Security y 12-Factor IaC).

• 18 reglas de detección distribuidas en las seis superficies.
• 10 patrones nuevos en el SecretScanner para credenciales IoT cloud (Azure IoT, AWS IoT, GCP IoT, Particle, Tuya, SmartThings, HomeKit, MQTT, ESP-IDF), totalizando 91 patrones precompilados.
• Wireless Security Baseline con los 24 controles auditables del marco anterior, exportable como PDF.
• Dashboard dedicado en /wireless-security con KPIs por superficie, hallazgos top, cobertura del baseline, tablas y gráficos.
• Reporte Wireless Assessment PDF con resumen ejecutivo, KPIs por superficie, top 20 hallazgos, baseline de 24 controles, recomendaciones y referencias a NIST + IEEE.
• Targets de benchmark deliberadamente vulnerables: IoT-Goat (OWASP), DVRF (Damn Vulnerable Router Firmware) y BLE CTF, con un solo clic para clonar y escanear.
• Simulaciones educativas en el Attack Lab: Evil Twin, BLE Just Works MitM, KNOB, RF replay, MIFARE clone (sintéticas, sin radio).

Recomendaciones — por dónde empezar mañana

1. Inventario sincero de qué radios usan realmente sus productos. La mitad de los equipos que creen que "envían Wi-Fi" también envían BLE para commissioning y se les olvidó.
2. Para cada superficie, ponga por escrito qué amenazas están en alcance y cuáles son riesgo aceptado. "Aceptamos Just Works en características no sensibles" es una posición; "no sabemos" no lo es.
3. Añada reglas estáticas a CI para los modos de fallo descritos. La mayoría son strings exactos o regex superficiales.
4. Adopte un baseline auditable (el de 24 controles de SF365 o uno propio). El punto es que la respuesta a "¿cómo estamos en Wi-Fi?" sea evidenciable, no impresión.
5. Corra benchmarks contra targets vulnerables conocidos — IoT-Goat, DVRF, BLE CTF — para demostrar que sus detecciones efectivamente disparan.
6. Pase un escaneo SF365 sobre su monorepo de firmware. Suele aparecer al menos un secreto IoT que nadie esperaba.

Referencias