Módulo 5 Duración: 8 Horas 90% Práctica Técnica Red Team Avanzado

Ataques del Mundo Real, Hoteles y Relay Attacks

Auditoría de saldos y máquinas vending (Hex Diffing), el caso Unsaflok en cerraduras hoteleras (Dormakaba Saflok) y Relay Attacks transcontinentales con NFCGate sobre TCP/IP.

🎯 Objetivo Operativo del Módulo:

Ejecutar vectores de ataque de alto impacto en infraestructuras físicas reales: revertir y recargar saldos offline mediante ingeniería inversa de volcados, comprender la derivación de llaves maestras en cerraduras electromecánicas sin conexión, y puentear credenciales a kilómetros de distancia mediante Relay Attacks.

📑 Índice de Contenidos del Módulo

Manipulación de Saldos y Transacciones Offline
- Metodología de 4 pasos: Dump A → Consumo → Dump B → Hex Diffing
- Sumas de verificación (Checksums CRC16/XOR) y contadores anti-replay
- Lab 5.1: Localización de bloques de saldo con vbindiff y recarga manual
Estudio de Caso: Vulnerabilidad Unsaflok en Cerraduras de Hotel
- Cerraduras Saflok (Dormakaba) y el problema del funcionamiento offline
- KDF débil basada en el UID de la tarjeta y generación de llaves maestras
- Lab 5.2: Simulación de forja de llaves maestras a partir de dos tarjetas caducadas
Relay Attacks a Larga Distancia con NFCGate
- Principio Man-in-the-Middle de extensión del campo magnético sobre TCP/IP
- Ventanas de timeout ISO 14443 Frame Waiting Time (FWT)
- Lab 5.3: Despliegue de PoC con dos terminales Android y servidor de relevo

1. Manipulación de Saldos y Transacciones Offline

Miles de lavanderías comunitarias, máquinas de café y taquillas de gimnasio funcionan de forma completamente offline (sin conexión a internet ni a base de datos central). Toda la lógica de negocio y el saldo monetario residen en la tarjeta MIFARE.

🎯 Objetivos de Aprendizaje

Metodología de auditoría de estado: Dump inicial -> Consumir servicio -> Dump final -> Hex Diffing.
Identificar checksums propios, XORs y contadores de recarga.
Entender el peligro de clonar saldos y los controles de reconciliación en backoffice.

🔑 Conceptos Clave

Hex diffing Little Endian vs Big Endian Two-complement Value Block Replay de transacciones offline

🧰 Herramientas de este Laboratorio

Vbindiff / ImHex MCT Android Proxmark3

1.1 Metodología de Hex Diffing

┌────────────────────────────────────────────────────────────────────────────────────────┐ │ METODOLOGÍA DE REVERSIÓN DE SALDOS OFFLINE │ ├────────────────────────────────────────────────────────────────────────────────────────┤ │ │ │ PASO 1: Dump Inicial (Snapshot A) │ │ Saldo real conocido: 10.00 € (1000 céntimos = 0x03E8). │ │ Guardar: dump_A.bin │ │ │ │ PASO 2: Transacción Física Controlada │ │ Consumo de un café de 1.50 €. Nuevo saldo: 8.50 € (850 céntimos = 0x0352). │ │ │ │ PASO 3: Dump Posterior (Snapshot B) │ │ Guardar: dump_B.bin │ │ │ │ PASO 4: Diffing Binario (vbindiff dump_A.bin dump_B.bin) │ │ Localizar los únicos bytes que han variado. Encontraremos: │ │ - El valor del saldo (en formato Value Block o entero custom). │ │ - Un contador de transacciones (incrementado en +1 para evitar rollbacks). │ │ - Un checksum (CRC16 o XOR) que valida la integridad de los datos. │ └────────────────────────────────────────────────────────────────────────────────────────┘

🛠️ Lab 5.1: Localización y Modificación de Saldo con vbindiff

Ingeniería Inversa Hex

# Instalar vbindiff si no está en el sistema
sudo apt install -y vbindiff

# Comparar los dos volcados en paralelo
vbindiff dump_A.bin dump_B.bin

Se observa que en el Sector 2, Bloque 8:

dump_A.bin (10.00€): E8 03 00 00 17 FC FF FF E8 03 00 00 08 F7 08 F7
dump_B.bin ( 8.50€): 52 03 00 00 AD FC FF FF 52 03 00 00 08 F7 08 F7

¡Es un Value Block canónico! Para modificar el saldo a 50.00 € (5000 céntimos = 0x1388):

Valor v = 88 13 00 00
Valor invertido ~v = 77 EC FF FF
Bloque resultante: 88 13 00 00 77 EC FF FF 88 13 00 00 08 F7 08 F7

✅ Resultado Esperado

Identificación de la estructura de bloque de valor y reversión del saldo en entorno controlado.

2. Estudio de Caso: Vulnerabilidad Unsaflok en Cerraduras de Hotel

A principios de 2024, los investigadores Ian Carroll y Lennert Wouters publicaron la investigación Unsaflok, que demostró que más de 3 millones de cerraduras hoteleras Saflok (Dormakaba) en 131 países podían abrirse en cuestión de segundos debido a debilidades criptográficas en la derivación de claves sobre tarjetas MIFARE Classic.

🎯 Objetivos de Aprendizaje

Analizar la arquitectura de las cerraduras de hotel electromecánicas offline.
Entender cómo se combinan la clave de hotel (Property Code) y la fecha de expiración.
Aprender las medidas de mitigación que la industria hotelera está desplegando.

🔑 Conceptos Clave

KDF (Key Derivation Function) Master Key Generation Off-line audit logs en cerraduras Vulnerabilidad Unsaflok

🧰 Herramientas de este Laboratorio

Proxmark3 Flipper Zero con subGHz y NFC Tarjetas Gen2 CUID

2.1 El Funcionamiento Offline de las Cerraduras de Hotel

Las cerraduras de las habitaciones no tienen cable de red ni WiFi por razones de consumo de batería. Para que una cerradura sepa si una tarjeta es válida para la habitación 304 entre el lunes y el miércoles, la tarjeta lleva cifrados la fecha, hora de expiración y el número de habitación.

┌────────────────────────────────────────────────────────────────────────────────────────┐ │ EL FALLO CRIPTOGRÁFICO DE UNSAFLOK │ ├────────────────────────────────────────────────────────────────────────────────────────┤ │ │ │ 1. La tarjeta utiliza MIFARE Classic (cifrado roto Crypto-1). │ │ 2. Las claves del sector no son aleatorias: se calculan mediante una KDF │ │ (Key Derivation Function) basada en el UID de la tarjeta y una clave maestra. │ │ 3. El sistema Saflok emplea una secuencia de DOS tarjetas para reprogramar la cerradura:│ │ - Tarjeta 1: Sobreescribe la máscara de habitación de la cerradura offline. │ │ - Tarjeta 2: Activa el pestillo y abre la puerta. │ │ 4. Disponiendo de DOS tarjetas cualesquiera (incluso caducadas) de un mismo hotel, │ │ es posible derivar la clave del sistema y forjar una llave maestra que abra │ │ CUALQUIER habitación de esa propiedad. │ └────────────────────────────────────────────────────────────────────────────────────────┘

🛠️ Lab 5.2: Simulación de Generación de Llaves Maestras

Forense Unsaflok

Meta del Lab: Analizar dos tarjetas caducadas de hotel, identificar la firma del fabricante Saflok y comprender el vector de derivación de claves maestras.

# Inspeccionar el sector 1 de una tarjeta Saflok con Proxmark3
[usb] pm3 --> hf mf rdbl --block 4 -k A0B1C2D3E4F5

# Datos obtenidos del bloque de control del hotel:
Block 04: 01 30 04 65 D8 21 00 00 00 00 00 00 00 00 A1 F2
# 01 30 = Habitación 130
# 04 65 = Timestamp de validez
# A1 F2 = Checksum de control de cerradura

✅ Resultado Esperado

Apertura de la cerradura de pruebas mediante credencial sintética generada.

3. Relay Attacks a Larga Distancia con NFCGate

Un Relay Attack no rompe el cifrado de la tarjeta: simplemente engaña a la física. El atacante extiende virtualmente el campo magnético de 10 cm a miles de kilómetros encapsulando los paquetes APDU sobre sockets TCP/IP a través de internet (4G/5G/WiFi).

🎯 Objetivos de Aprendizaje

Entender el principio del ataque de intermediario (Man-in-the-Middle) en RF.
Montar un servidor NFCGate en la nube (relay server en Node.js/Python).
Medir la latencia de respuesta y comprender las defensas basadas en Distance Bounding.

🔑 Conceptos Clave

Relay Attack Distance Bounding Protocols Time of Flight (ToF) NFCGate architecture

🧰 Herramientas de este Laboratorio

2 Smartphones Android con Root / Xposed Servidor NFCGate Lector de control de accesos

┌────────────────────────────────────────────────────────────────────────────────────────┐ │ ARQUITECTURA DE UN RELAY ATTACK CON NFCGATE │ ├────────────────────────────────────────────────────────────────────────────────────────┤ │ │ │ [ LECTOR DE LA PUERTA ] [ VÍCTIMA CON LA TARJETA ] │ │ │ (Campo HF 13.56 MHz) │ (Campo HF) │ │ [ TELÉFONO A: EMULADOR HCE ] [ TELÉFONO B: READER MODE ] │ │ │ │ │ │ └───────────> [ SERVIDOR RELAY INTERNET ] <─────────────┘ │ │ (Sockets TCP/IP) │ │ │ │ 1. El teléfono A se acerca al lector de la puerta (emula ser la tarjeta). │ │ 2. El lector envía el desafío criptográfico (ej. AUTH). │ │ 3. El teléfono A retransmite los bytes al servidor de internet vía 5G. │ │ 4. El servidor envía los bytes al teléfono B situado junto al bolsillo de la víctima.│ │ 5. El teléfono B lee la tarjeta de la víctima y obtiene la respuesta criptográfica. │ │ 6. La respuesta viaja de vuelta al teléfono A y la entrega al lector de la puerta. │ │ 7. ¡LA PUERTA SE ABRE! La tarjeta original nunca estuvo físicamente en el edificio. │ └────────────────────────────────────────────────────────────────────────────────────────┘

⚠️ El Desafío de la Latencia (Frame Waiting Time - FWT)

El estándar ISO 14443-4 define un tiempo máximo que el lector esperará la respuesta de la tarjeta antes de cancelar la sesión por timeout (FWT, habitualmente entre 50 y 300 milisegundos). Para que un Relay Attack funcione sobre internet público, el ping de la red 4G/5G debe ser inferior al FWT configurado en el lector mural.

🛠️ Lab 5.3: Prueba de Concepto de Relay Attack con NFCGate

Ataque MitM

Configuración del Servidor de Relay en Linux:

# Clonar y compilar el servidor de retransmisión NFCGate en VPS con baja latencia
git clone https://github.com/nfcgate/nfcgate.git
cd nfcgate/server
python3 server.py --port 5566

En los smartphones Android con root y módulo NFCGate:

Dispositivo 1 (Attacker Torno): Modo HCE Emulation conectado a vps_ip:5566 con Session ID REDTEAM1.
Dispositivo 2 (Attacker Víctima): Modo Tag Reader conectado a vps_ip:5566 con Session ID REDTEAM1.
Aproximar el Dispositivo 2 a la mochila de la víctima y el Dispositivo 1 al lector de acceso: la puerta se abre de inmediato.

✅ Resultado Esperado

El lector valida el acceso a pesar de que la tarjeta física está en otra habitación.