Postada por: cuamckuuA recuperação do conteúdo do mapa e o trabalho com equipes de EMV podem ser interessantes não apenas para fins de pesquisa. Existem vários tipos de ataques a cartões bancários sem contato, cuja implementação será discutida sob o corte.
1. Introdução
Este ano, fiz um estágio no Summer of Hack 2019 na Digital Security e trabalhei no tópico de pesquisa em cartões EMV sem contato. Durante o estágio, foi melhor aprender como funcionam os cartões bancários e criar um novo utilitário para trabalhar com cartões sem contato. Uma demonstração do modo de leitura de dados pode ser encontrada
aqui .
Tipos de ataques
O cartão e o terminal se comunicam usando o padrão EMV (Europay + MasterCard + VISA), desenvolvido para aumentar a segurança dos pagamentos. Nesse sentido, não há muitos vetores de ataque em cartões sem contato. O artigo se concentrará no seguinte:
- Vincular o cartão de outra pessoa na loja online
- Etapa auxiliar na engenharia social
- DoS sem contato que transforma um cartão em um tijolo
Tais ataques são possíveis ao interagir com o cartão de acordo com o padrão EMV. Muitos cartões permitem que você leia com facilidade as informações particulares do usuário, em particular o PAN, a data de validade e o nome do titular. Os dados lidos são suficientes para mapear o cartão em algumas lojas online, por exemplo, Amazon. E os dados privados recebidos podem ser usados para phishing mais personalizado ou para o envio de spam.
De maneira semelhante, um ataque de DoS é implementado. Chamar os comandos EMV necessários permite que você exceda o contador interno de transações ou simule a entrada incorreta do código PIN, o que leva ao bloqueio do cartão.
Por que reinventar a roda?
Antes de iniciar o desenvolvimento, decidiu-se estudar as soluções existentes. Em particular, eles consideraram:
RFIDIOt / ChAP.py ,
Jaccal ,
nfcmillionaire ,
Conference PoC ,
script "Ruby" ,
aplicativos / bibliotecas Android .
A maioria dos programas revisados tenta simular a operação de um terminal POS e usa dicionários com identificadores de cartões suportados, portanto, muitas vezes essas soluções funcionam apenas com Visa e MasterCard.
Outro problema é ler uma pequena parte dos dados em vez de descarregar um despejo completo. Quase todos os programas tentam analisar o maior número possível de EMV em tempo real e cometer erros de análise.
Se algum dos problemas estiver ausente ou não for tão pronunciado, provavelmente estamos falando de um aplicativo / biblioteca para Android e você precisará de um telefone com um leitor NFC, que nem todo mundo possui.
Os problemas descritos podem ser resolvidos, para isso é necessário:
- Detectar tipo de mapa dinamicamente, em vez de usar dicionários
- Adicione vários modos operacionais para leitura completa de arquivos
- Não tente desmontar o padrão EMV em tempo real
- Use um leitor barato PN532 (~ 5 $)
Recuperando dados do cartão
Já existem artigos sobre Habré descrevendo em detalhes o processo de interação entre o cartão e o terminal (
um ,
dois ,
três ), por isso tentarei não me repetir e focar na parte prática.
Para se comunicar com o cartão, usaremos o leitor PN532 devido ao preço agradável e à biblioteca libnfc. Vá direto ao assunto. Os dados no mapa estão organizados da seguinte forma:
Ambiente -> Aplicativos -> Arquivos -> Registros.
O objetivo da leitura é obter dados de todos os registros, para isso você precisa passar por uma cadeia completa, e a escolha do ambiente e do aplicativo ocorre apenas uma vez no início da comunicação.
O mesmo processo em termos de comandos EMV:
- SELECT PPSE // Selecione um ambiente sem contato
- SELECIONAR APLICATIVO // Selecione um aplicativo da AID
- READ RECORD // Especifique o arquivo e o número do registro
Considere o exemplo da formação de uma das equipes. O primeiro comando para selecionar um ambiente sem contato é sempre o mesmo e fica assim:
byte_t const command[] = { 0x40, 0x01,
Exemplo de resposta: 6F 23 84 0E 32 50 41 59 2E 53 59 53 2E 44 44 46 30 31 A5 11 BF 0C 0E 61 0C 4F 07 A0 00 00 00 03 10 10 87 01 01 90 00
Para chamar o próximo comando, precisamos analisar a resposta do comando anterior.

Estamos interessados no AID do identificador de aplicativo. Nós o memorizamos e formamos uma nova consulta SELECT, mas desta vez passamos o AID recebido para o comando SELECT, e não o PPSE, como no primeiro comando.
Exemplo: 00 A4 04 00 07 A0 00 00 00 03 10 10 00
Como mencionado anteriormente, é importante obter o AID dinamicamente, em vez de usar um dicionário preparado; é provável que seu aplicativo consiga ler diferentes tipos de cartões, por exemplo, cartões MIR.
Após a seleção da aplicação, podemos ler os registros necessários usando o comando READ RECORD e passando o número do arquivo e o número do registro como parâmetros.
Um exemplo de formação de equipe:
(mais sobre isso pode ser encontrado no padrão. EMV Book1. 11.2 LEIA O REGISTRO) byte_t const sfi_param = (sfi << 3) | (1 << 2); byte_t const command[] = { 0x40, 0x01,
Exemplo de chamada: 00 B2 02 14 00
Observe que nem um byte completo é alocado para o número do arquivo, respectivamente, pode haver 31 (2 ^ 5 - 1) arquivos no total e 255 entradas.Os arquivos do 1º ao 10º são alocados para armazenamento de dados internos e os demais são alocados para armazenamento log de transações, se o cartão suportar log.
Agora, usando dois loops aninhados, podemos obter os dados de todos os registros do mapa chamando o comando READ RECORD para cada par. O processo de pesquisa pode ser acelerado significativamente se você prestar atenção à palavra de status retornada pelo cartão (os últimos dois bytes da resposta). O status pode nos dizer que o arquivo não existe (SW = 0x6A82) ou que não há mais entradas nesse arquivo (SW = 0x6A83).
Na prática, verificou-se que faz sentido considerar apenas o caso de um arquivo inexistente, pois às vezes existem cartões que usam incorretamente o código de status para entradas ausentes. Depois de ler os dados, você pode enviá-los para um dos analisadores online, gostei
deste .
Fragmento de dados extraídos dos registros do mapa:

Os dados lidos são suficientes para mapear o cartão em algumas lojas on-line (principalmente em lojas estrangeiras), e as informações obtidas podem ser usadas para um ataque mais personalizado usando a engenharia social.
Organizamos DoS sem contato
Prosseguimos para o próximo tipo de ataque. Existem pelo menos 2 métodos de implementação para o DoS-a.
Caminho lento
Para implementar o método lento (o ataque levará cerca de 4 minutos), é necessário sobrecarregar o contador interno de transações com cartões (ATC). Para fazer isso, ligue para:
- SELECT PPSE // Selecione um ambiente sem contato
- SELECIONAR APLICATIVO // Selecione um aplicativo
- GET DATA // Descubra quanto resta antes do estouro do ATC (opcional)
- OBTER OPÇÕES DE PROCESSAMENTO // Iniciar Transação
- ...
- OBTER OPÇÕES DE PROCESSAMENTO // Repita as transações até o estouro
Considere as etapas com mais detalhes. A escolha do ambiente e do aplicativo sem contato é semelhante ao item com extração de dados, a única diferença é que desta vez precisamos processar a resposta do comando SELECT APPLICATION.

Estamos interessados no campo PDOL, pois será necessário para a chamada subsequente do comando GET PROCESSING OPTIONS, que aumentará o contador de transações para cada chamada.
No PDOL, o cartão solicita informações sobre o terminal e o pagamento a nós.
No exemplo acima, o mapa nos pergunta:
- 9F66 04 // Qualificador de transação do terminal (4 bytes)
- 9F02 06 // Quantidade (6 bytes)
- 9F37 04 // Número imprevisível (4 bytes)
- 5F2A 02 // Código da moeda da transação (2 bytes)
Como implementamos o DoS, e não um pagamento real, não podemos nos preocupar com a correção dos valores e apenas usar os valores pré-preparados que o cartão aceitará. Leia mais sobre os valores exigidos no padrão.
(Livro EMV 3. Anexo A Dicionário de Elementos de Dados).Para conveniência do uso prático, cito a tabela:
Depois de formar os dados solicitados pelo cartão, estamos prontos para ligar para o GPO.
Exemplo: 80 A8 00 00 12 83 10 79 00 40 80 00 00 00 10 00 00 82 3D DE 7A 01 24 00
Resposta: 77 4F 82 02 20 00 94 0C 10 02 03 00 18 01 01 00 10 04 04 00 57 13 42 76 55 00 66 83 25 13 D2 00 52 01 14 89 36 20 00 00 1F 5F 20 02 20 2F 9F 10 07 06 01 11 03 80 20 00 9F 6C 02 30 00 9F 26 08 33 33 89 D5 70 A3 DF 37 9F 27 01 00 9F 36 02 02 48 48 90 00
Repita a chamada GPO 65 536 vezes e o cartão está bloqueado. Você pode reduzir o número de chamadas necessárias lendo primeiro o valor ATC atual usando GET DATA.
Maneira rápida
A maneira rápida é muito mais conveniente (e mais perigosa), já que levará cerca de 2 segundos para bloquear o cartão, portanto, uma análise detalhada dos detalhes da implementação permanecerá nos bastidores.
O método é semelhante ao anterior, mas desta vez será necessário diminuir o contador de tentativas de inserir o código PIN, em vez de aumentar o contador de transações. O valor do PIN do Try Counter também pode ser obtido por meio de GET DATA, mas nesse caso não haverá aumento significativo na velocidade.
Operações necessárias:
- SELECT PPSE // Selecione um ambiente sem contato
- SELECIONAR APLICATIVO // Selecione um aplicativo
- GET DATA // Descubra quantas tentativas de inserir um PIN
- OBTER OPÇÕES DE PROCESSAMENTO // Iniciar Transação
- VERIFIQUE // E digite o PIN errado
- ...
- VERIFICAR // Até o cartão estar bloqueado
Sumário
Durante o estágio, foi possível criar uma nova ferramenta para trabalhar com cartões bancários sem contato e resolver vários problemas presentes nas soluções existentes, e o uso de um leitor barato reduz significativamente o custo de um kit de pesquisa e pode ajudar a atrair novas pessoas para pesquisar a segurança dos cartões bancários sem contato. O código fonte do programa
está disponível no Github .