Sammi De Blas | Knowledge Base

Control de accesos RFID y NFC - práctica

Dominio 2: Control de Accesos (RFID / NFC) Práctica

Este documento detalla desde la preparación del hardware hasta la explotación de vulnerabilidades y el análisis forense de sistemas de alta seguridad.

1. Fase de Preparación y Diagnóstico de Hardware

Antes de realizar cualquier ataque, es imperativo asegurar la integridad del ecosistema de auditoría para evitar errores de demodulación.

1.1. Flasheo del Firmware

Se utilizó el entorno ProxSpace v3.11 para cargar la rama de firmware Iceman/master, necesaria para ejecutar ataques avanzados de computación intensiva.

  • proxmark3 [port] --flash --image fullimage.elf

  • MCU Detectada: AT91SAM7S512 (512KB Flash), lo cual es un requisito indispensable para soportar diccionarios extensos y ataques tipo Hardnested.

1.2. Sintonización de Antenas (hw tune)

El comando hw tune mide la resonancia de las antenas para garantizar que el voltaje es suficiente para alimentar los chips pasivos sin generar ruido excesivo.

  • Resultados LF: 22.25V (Óptimo > 20V).

  • Resultados HF: 61.99V (Extremadamente alto, Óptimo > 15V).

  • Incidencia Técnica: El exceso de voltaje en la antena HF (~62V) provocó inicialmente saturación en los chips Mifare, impidiendo su lectura a corta distancia. Se resolvió aplicando la “Técnica del Francotirador”, alejando la tarjeta 3-4 cm del lector.

2. Auditoría en Baja Frecuencia (LF - 125kHz)

Los sistemas LF carecen de mecanismos de desafío-respuesta, transmitiendo su UID en texto claro tan pronto como reciben energía.

  • Identificación: Se ejecutó lf search para detectar modulaciones ASK/FSK.

  • Error reportado: Se detectó un falso positivo de tipo Indala debido a ruido electromagnético.

  • Lección aprendida: Los sistemas LF son altamente susceptibles a interferencias; es necesario realizar lecturas triples para confirmar la consistencia del UID antes de intentar una clonación.

3. Auditoría en Alta Frecuencia (HF - 13.56MHz)

3.1. Caso 1: Tarjeta de Gimnasio (Mifare Classic 1k)

Representa el modelo de “Ilusión de Seguridad”, donde la validación se basa exclusivamente en el UID.

  • hf search

  • Flags detectados: Prng detection… weak (Generador de números aleatorios vulnerable).

  • Vectores de Ataque:

  1. Ataque de Diccionario: Se ejecutó hf mf autopwn.

  2. Resultado: Se recuperaron todas las llaves de los 16 sectores en menos de 2 segundos.

  3. Hallazgo Crítico: Todas las llaves eran las de fábrica (FFFFFFFFFFFF), indicando negligencia en la configuración del sistema.

  • Análisis Forense: Mediante hf mf dump, se confirmó que la tarjeta no contenía datos de usuario, lo que implica que el torno de acceso solo valida el UID público.

3.2. Caso 2: Tarjeta de Transporte (Mifare DESFire EV1 4k)

Representa la arquitectura de seguridad robusta basada en estándares criptográficos reales (3DES/AES).

  • Identificación Avanzada: hf mfdes info.

  • Resultados del Análisis:

  • Algoritmo: 2TDEA (Triple DES de dos llaves).

  • Permisos: Se identificó la aplicación 010000 perteneciente al Consorcio de Transportes.

  • Explotación de Fugas de Información:

  • hf mfdes getfileids --aid 010000 --no-auth

  • Hallazgo: El sistema permite listar los IDs de los archivos sin autenticación, revelando 12 archivos internos (del 00 al 0b).

  • Error de Lectura: Al intentar hf mfdes read —aid 010000 —fileno 01 —no-auth, el sistema devolvió un error de comunicación.

  • Causa Técnica: El modo de comunicación es Full Encrypted, lo que significa que los datos viajan cifrados de extremo a extremo y requieren una llave AES/3DES válida para ser descifrados.

4. Persistencia y Clonación (Clonado del UID)

Para validar la vulnerabilidad del sistema de gimnasio, se procedió a la creación de un clon físico utilizando una Magic Card (Gen2).

  • Objetivo: Clonar el UID 72 56 E0 E2 en un llavero virgen.

  • hf mf csetuid -u 7256E0E2

  • Validación:

  1. hf search.

  2. Resultado: New UID… 72 56 E0 E2 (verified).

  • Conclusión de Persistencia: El clon es funcional y el sistema de acceso no tiene capacidad para distinguir entre el chip original y el emulado debido a la falta de autenticación en sectores de datos.

5. Resumen de Recomendaciones Técnicas (Blue Team)

  1. Migración Tecnológica: Abandonar Mifare Classic en favor de DESFire EV3, que implementa autenticación mutua y firmas de lectura única (SUN).

  2. Diversificación de Llaves: Eliminar el uso de llaves de fábrica (FFFF…) y generar llaves únicas por tarjeta derivadas de una llave maestra y el UID.

  3. Protocolos de Comunicación: Sustituir la interfaz Wiegand (texto claro) por el protocolo OSDP cifrado para evitar el sniffing de datos entre el lector y el panel de control

Fin de la Documentación. Para realizar estas prácticas de forma autónoma, asegúrese de mantener el Proxmark3 alejado de superficies metálicas y de utilizar tarjetas tipo T5577 para LF y Magic Gen2 para HF.

Vista Gráfica

Retroenlaces