Bo día a todos. Comezarei cos antecedentes sobre o que me impulsou a realizar esta investigación, pero antes avisarei: todas as accións prácticas foron realizadas co consentimento das estruturas de goberno. Calquera intento de utilizar este material para entrar nunha zona restrinxida sen dereito a estar alí é un delito penal.
Todo comezou cando, mentres limpaba a mesa, coloquei accidentalmente a chave de entrada RFID no lector ACR122 NFC: imaxina a miña sorpresa cando Windows reproducía o son de detectar un novo dispositivo e o LED volveuse verde. Ata este momento, cría que estas chaves funcionan exclusivamente no estándar de proximidade.
Pero xa que o lector o viu, significa que a chave cumpre un dos protocolos que se integran na norma ISO 14443 (tamén coñecido como Near Field Communication, 13,56 MHz). A limpeza esqueceuse de inmediato, xa que vin a oportunidade de desfacerme completamente do conxunto de chaves e manter a chave da entrada no meu teléfono (o apartamento estivo equipado dende hai tempo cunha pechadura electrónica). Comezando a estudar, descubrín que escondida debaixo do plástico hai unha etiqueta Mifare 1k NFC, o mesmo modelo que nos distintivos empresariais, tarxetas de transporte, etc. Os intentos de entrar no contido dos sectores non tiveron éxito nun primeiro momento, e cando finalmente se rachou a chave, resultou que só se utilizaba o 3o sector, e nel duplicouse o UID do propio chip. Parecía demasiado sinxelo, e resultou ser así, e non habería artigo se todo fose exactamente como estaba previsto. Así que recibín os menullos da chave, e non hai problemas se precisa copiar a chave noutra do mesmo tipo. Pero a tarefa era transferir a chave a un dispositivo móbil, que é o que fixen. Aquí é onde comezou a diversión - temos un teléfono - iPhone SE con establecido iOS 13.4.5 versión beta 17F5044d e algúns compoñentes personalizados para o funcionamento gratuíto de NFC - Non vou determe sobre isto en detalle debido a algunhas razóns obxectivas. Se o desexa, todo o que se di a continuación tamén se aplica ao sistema Android, pero con algunhas simplificacións.
Lista de tarefas a resolver:
- Accede ao contido da clave.
- Implementar a capacidade de emular unha clave polo dispositivo.
Se coa primeira todo era relativamente sinxelo, coa segunda houbo problemas. A primeira versión do emulador non funcionou. O problema descubriuse con bastante rapidez: en dispositivos móbiles (xa sexa iOS ou Android) en modo de emulación, o UID é dinámico e, independentemente do que estea conectado á imaxe, flota. A segunda versión (executa con dereitos de superusuario) fixou de forma ríxida o número de serie do seleccionado: abriuse a porta. Non obstante, quería facelo todo á perfección e acabei por montar unha versión completa do emulador que podería abrir vertedoiros de Mifare e emulalos. Cedendo a un impulso repentino, cambiei as chaves do sector por outras arbitrarias e tentei abrir a porta. E ela… ABERTO! Despois dun tempo deime conta de que estaban abrindo calquera portas con esta pechadura, mesmo aquelas ás que non lles cabía a chave orixinal. Neste sentido, creei unha nova lista de tarefas para completar:
- Descubra que tipo de controlador é responsable de traballar coas teclas
- Comprender se hai unha conexión de rede e unha base común
- Descubra por que unha clave practicamente ilexible se fai universal
Despois de falar cun enxeñeiro da empresa de xestión, aprendín que os controladores Iron Logic z5r simples úsanse sen conectarse a unha rede externa.
Lector CP-Z2 MF e controlador IronLogic z5r
Déronme un conxunto de equipos para os experimentos:
Como se desprende de aquí, o sistema é completamente autónomo e extremadamente primitivo. Ao principio pensei que o controlador estaba en modo de aprendizaxe - o significado é que le a chave, gárdaa na memoria e abre a porta - este modo utilízase cando é necesario gravar todas as chaves, por exemplo, ao substituír o pechadura nun edificio de apartamentos. Pero esta teoría non foi confirmada (este modo está desactivado no software, o puente está na posición de traballo) e aínda así, cando levamos o dispositivo, vemos o seguinte:
Captura de pantalla do proceso de emulación no dispositivo
... e o controlador indica que o acceso foi concedido.
Isto significa que o problema reside no software do controlador ou do lector. Comprobamos o lector -funciona en modo iButton, así que conectemos a placa de seguridade Bolid- poderemos ver os datos de saída do lector.
A placa conectarase máis tarde a través de RS232
Usando o método de probas múltiples, descubrimos que o lector emite o mesmo código en caso de falla de autorización: 1219191919
A situación comeza a aclararse, pero polo momento non me queda claro por que o controlador responde positivamente a este código. Suponse que cando se encheu a base de datos -por accidente ou a propósito presentouse unha tarxeta con outras claves de sector- o lector enviou este código e o controlador gardouno. Desafortunadamente, non teño un programador propietario de IronLogic para buscar a base de datos de claves do controlador, pero espero que puiden chamar a atención sobre o feito de que o problema existe. Hai un vídeo de demostración do traballo con esta vulnerabilidade .
PS A teoría da adición aleatoria oponse ao feito de que nun centro de negocios en Krasnoyarsk tamén conseguín abrir a porta co mesmo método.
Fonte: www.habr.com