Bon dia a tots. Començaré amb els antecedents del que em va impulsar a dur a terme aquesta recerca, però abans us advertiré: totes les accions pràctiques es van dur a terme amb el consentiment de les estructures de govern. Qualsevol intent d'utilitzar aquest material per entrar a una àrea restringida sense dret a ser-hi és un delicte penal.
Tot va començar quan, mentre netejava la taula, vaig col·locar accidentalment la clau d'entrada RFID al lector ACR122 NFC; imagineu-vos la meva sorpresa quan Windows va reproduir el so de detectar un nou dispositiu i el LED es va tornar verd. Fins aquest moment, creia que aquestes claus funcionen exclusivament en l'estàndard de proximitat.
Però com que el lector ho va veure, vol dir que la clau compleix un dels protocols a sobre de l'estàndard ISO 14443 (també conegut com a Near Field Communication, 13,56 MHz). La neteja es va oblidar immediatament, ja que vaig veure l'oportunitat de desfer-me completament del joc de claus i mantenir la clau de l'entrada al meu telèfon (l'apartament fa temps que està equipat amb un pany electrònic). Després d'haver començat a estudiar, vaig descobrir que s'amagava sota el plàstic una etiqueta Mifare 1k NFC, el mateix model que a les insígnies d'empresa, targetes de transport, etc. Els intents d'entrar en el contingut dels sectors no van tenir èxit al principi, i quan finalment es va trencar la clau, va resultar que només s'utilitzava el 3r sector i s'hi va duplicar l'UID del propi xip. Semblava massa senzill, i va resultar ser així, i no hi hauria cap article si tot anés exactament com estava previst. Així que he rebut els menuts de la clau, i no hi ha problemes si cal copiar la clau a una altra del mateix tipus. Però la tasca era transferir la clau a un dispositiu mòbil, que és el que vaig fer. Aquí va començar la diversió - tenim un telèfon - iPhone ES amb instal·lat iOS 13.4.5 versió beta 17F5044d i alguns components personalitzats per al funcionament gratuït de l'NFC; no m'atendré en això en detall per algunes raons objectives. Si es vol, tot el que es diu a continuació també s'aplica al sistema Android, però amb algunes simplificacions.
Llista de tasques a resoldre:
- Accedir al contingut de la clau.
- Implementar la capacitat d'emular una clau pel dispositiu.
Si amb el primer tot era relativament senzill, amb el segon hi havia problemes. La primera versió de l'emulador no va funcionar. El problema es va descobrir amb força rapidesa: en dispositius mòbils (ja sigui iOS o Android) en mode d'emulació, l'UID és dinàmic i, independentment del que estigui connectat a la imatge, flota. La segona versió (executa amb drets de superusuari) va fixar rígidament el número de sèrie del seleccionat: es va obrir la porta. No obstant això, volia fer-ho tot perfectament i vaig acabar creant una versió completa de l'emulador que podia obrir els abocadors de Mifare i emular-los. Cedint a un impuls sobtat, vaig canviar les claus del sector per arbitràries i vaig intentar obrir la porta. I ella… OBERT! Al cap d'una estona em vaig adonar que estaven obrint qualsevol portes amb aquest pany, fins i tot aquelles a les quals no encaixava la clau original. En aquest sentit, he creat una nova llista de tasques per completar:
- Descobriu quin tipus de controlador és responsable de treballar amb les claus
- Entendre si hi ha una connexió de xarxa i una base comuna
- Descobriu per què una clau pràcticament il·legible esdevé universal
Després de parlar amb un enginyer de l'empresa de gestió, vaig saber que els controladors Iron Logic z5r senzills s'utilitzen sense connectar-se a una xarxa externa.
Lector CP-Z2 MF i controlador IronLogic z5r
Em van donar un conjunt d'equips per als experiments:
Com es desprèn d'aquí, el sistema és completament autònom i extremadament primitiu. Al principi vaig pensar que el controlador estava en mode d'aprenentatge - el significat és que llegeix la clau, l'emmagatzema a la memòria i obre la porta - aquest mode s'utilitza quan cal gravar totes les claus, per exemple, quan es substitueix el tancament en un edifici d'apartaments. Però aquesta teoria no es va confirmar (aquest mode està desactivat al programari, el pont està en posició de treball) i, tanmateix, quan aixequem el dispositiu, veiem el següent:
Captura de pantalla del procés d'emulació al dispositiu
... i el controlador indica que s'ha concedit l'accés.
Això significa que el problema rau en el programari del controlador o del lector. Comprovem el lector: funciona en mode iButton, així que connectem el tauler de seguretat Bolid, podrem veure les dades de sortida del lector.
La placa es connectarà més tard mitjançant RS232
Mitjançant el mètode de múltiples proves, descobrim que el lector emet el mateix codi amb en cas de fallada d'autorització: 1219191919
La situació comença a aclarir-se, però de moment no tinc clar per què el controlador respon positivament a aquest codi. Es suposa que quan es va omplir la base de dades -per accident o intencionadament es va presentar una targeta amb altres claus de sector- el lector va enviar aquest codi i el controlador el va desar. Malauradament, no tinc un programador propietari d'IronLogic per mirar la base de dades de claus del controlador, però espero haver pogut cridar l'atenció sobre el fet que el problema existeix. Hi ha disponible un vídeo de demostració del treball amb aquesta vulnerabilitat .
PS La teoria de l'addició aleatòria s'oposa al fet que en un centre de negocis de Krasnoyarsk també vaig aconseguir obrir la porta amb el mateix mètode.
Font: www.habr.com