Boa tarde a todos. Começarei com a história de como me levou a realizar esta pesquisa, mas antes, avisarei: todas as ações práticas foram realizadas com o consentimento das estruturas de gestão. Qualquer tentativa de usar este material para invadir uma área restrita sem permissão é um crime.
Tudo começou quando, ao limpar minha mesa, acidentalmente coloquei a chave RFID da entrada no leitor NFC ACR122 — para minha surpresa, o Windows reproduziu o som de um novo dispositivo detectado e o LED acendeu em verde. Até aquele momento, eu acreditava que essas chaves funcionavam exclusivamente no padrão Proximity.
Mas se o leitor a detectou — significa que a chave atende a um dos protocolos sobre o padrão ISO 14443 (também conhecido como Near Field Communication, 13,56 MHz). Esqueci rapidamente da limpeza, uma vez que vi a possibilidade de me livrar do monte de chaves e guardar a chave da entrada no telefone (o apartamento já estava equipado com uma fechadura eletrônica). Ao investigar, descobri que sob a plástica estava uma etiqueta NFC Mifare 1k — o mesmo modelo usado em crachás de segurança, cartões de transporte, etc. As tentativas de acessar o conteúdo dos setores inicialmente não tiveram sucesso, e quando finalmente consegui quebrar a chave — descobri que apenas o 3º setor é utilizado, e nele está duplicado o UID do chip. Parecia muito simples, e de fato era, e não haveria artigo se tudo tivesse ocorrido exatamente como planejado. Assim, obtive o interior da chave, e não há problemas se for necessário copiar a chave para outra igual. Mas a tarefa era — transferir a chave para um dispositivo móvel, o que comecei a fazer. Aqui começou a diversão — temos um telefone — iPhone SE com iOS 13.4.5 Beta build 17F5044d e alguns componentes personalizados para o funcionamento livre do NFC — não me deterei nisso por razões objetivas. Se desejado, tudo o que se dirá a seguir é aplicável também ao sistema Android, mas com algumas simplificações.
Lista de tarefas a serem resolvidas:
- Obter acesso ao conteúdo da chave.
- Implementar a possibilidade de emular a chave com o dispositivo.
Se a primeira parte foi relativamente simples, a segunda trouxe problemas. A primeira versão do emulador não funcionou. O problema foi rapidamente identificado — em dispositivos móveis (tanto iOS quanto Android) no modo de emulação — o UID é dinâmico e não importa o que esteja embutido na imagem — ele muda. A segunda versão (executada com privilégios de superusuário) fixava rigidamente o número de série escolhido — a porta abria. No entanto, eu queria fazer tudo perfeito e acabei montando uma versão final do emulador que podia abrir dumps Mifare e emulá-los. Impulsivo, mudei as chaves dos setores para aleatórias e tentei abrir a porta. E ela... ABRIU! Depois de um tempo, percebi que estão abertas qualquer porta com essa fechadura, até mesmo aquelas para as quais a chave original não servia. Em vista disso, formulei uma nova lista de tarefas a serem realizadas:
- Descobrir qual controlador é responsável pelo trabalho com as chaves
- Entender se há conexão com a rede e uma base de dados geral
- Descobrir por que uma chave que é basicamente ilegível se torna universal
Após conversar com o engenheiro da empresa de gestão, descobri que são utilizados controladores simples Iron Logic z5r sem conexão com uma rede externa.
Leitor CP-Z2 MF e controlador IronLogic z5r
Me foi fornecido um conjunto de equipamentos para testes:
Como se percebe, o sistema é totalmente autônomo e extremamente primitivo. A princípio, pensei que o controlador estivesse em modo de aprendizado — a ideia é que ele lê a chave, a armazena na memória e abre a porta — esse modo é usado quando é necessário gravar todas as chaves, por exemplo, ao trocar a fechadura em um prédio de apartamentos. Mas essa teoria não se confirmou — por software, esse modo está desativado, o jumper está em posição de trabalho — e mesmo assim, ao aproximar o dispositivo, vemos o seguinte:
Captura de tela do processo de emulação no dispositivo
... e o controlador sinaliza que o acesso foi concedido.
Então, o problema reside no software do controlador ou do leitor. Vamos verificar o leitor — ele funciona em modo iButton, então conectaremos a placa de segurança Bolid — teremos a oportunidade de observar os dados de saída do leitor.
A placa será conectada mais tarde via RS232
Através de múltiplos testes, descobrimos que o leitor transmite o mesmo código em caso de falha de autenticação: 1219191919
A situação começa a esclarecer-se, no entanto, neste momento, não entendo por que o controlador responde positivamente a esse código. Suspeito que, ao preencher a base, accidentalmente ou intencionalmente, apresentaram um cartão com outras chaves de setor, e o leitor enviou esse código e o controlador o salvou. Infelizmente, não tenho um programador original da IronLogic para verificar a base de chaves do controlador, mas espero ter conseguido destacar que o problema existe. Uma demonstração em vídeo desse vazamento está disponível. .
P.S. A teoria da adição acidental é contrariada pelo fato de que em um centro empresarial em Krasnoyarsk consegui abrir a porta usando o mesmo método.
Fonte: habr.com
