Guten Tag, ich möchte mit einem Rückblick beginnen, was mich zu dieser Untersuchung bewegt hat. Zuvor möchte ich jedoch erwähnen, dass alle praktischen Handlungen mit Zustimmung der zuständigen Stellen durchgeführt wurden. Jeder Versuch, dieses Material zur unerlaubten Verwendung in geschützten Bereichen zu nutzen, stellt eine Straftat dar.
Alles begann damit, dass ich beim Aufräumen am Tisch zufällig meinen RFID-Schlüssel für den Eingang auf den NFC-Leser ACR122 gelegt habe – zu meiner Überraschung ertönte der Ton für ein neu entdecktes Gerät, und die LED leuchtete grün. Bis zu diesem Moment ging ich davon aus, dass diese Schlüssel ausschließlich im Proximity-Standard arbeiten.
Aber da der Leser ihn erkannt hat, bedeutet das, dass der Schlüssel einem der Protokolle über dem ISO 14443 Standard entspricht (auch bekannt als Near Field Communication, 13,56 MHz). Die Reinigung war sofort vergessen, denn ich sah die Möglichkeit, die Schlüsselbund loszuwerden und den Schlüssel zum Gebäude im Telefon zu speichern (die Wohnung ist bereits mit einem elektronischen Schloss ausgestattet). Während meiner Recherche stellte ich fest, dass sich unter dem Plastik ein NFC-Tag vom Typ Mifare 1k verbirgt – das gleiche Modell, das in Ausweisen, Transportkarten usw. verwendet wird. Die ersten Versuche, in die Inhalte der Sektoren zu gelangen, waren zunächst erfolglos, aber als es mir gelang, den Schlüssel zu hacken, stellte ich fest, dass nur der 3. Sektor verwendet wird und dort die UID des Chips dupliziert ist. Es schien zu einfach, und es wäre kein Artikel entstanden, wenn alles genau nach Plan gelaufen wäre. Also habe ich die Innereien des Schlüssels erhalten, und es gibt keine Probleme, wenn ich den Schlüssel auf einen anderen gleichen kopieren muss. Aber die Aufgabe war, den Schlüssel auf ein mobiles Gerät zu übertragen, womit ich dann begann. Hier begann der Spaß — wir haben ein Telefon — iPhone SE mit der installierten iOS 13.4.5 Beta Build 17F5044d und einigen benutzerdefinierten Komponenten für die freie Nutzung von NFC – darauf möchte ich aus bestimmten objektiven Gründen nicht im Detail eingehen. Bei Bedarf lässt sich alles Folgende auch auf das Android-System anwenden, jedoch mit einigen Vereinfachungen.
Liste der zu lösenden Aufgaben:
- Zugriff auf den Schlüsselinhalt erhalten.
- Die Möglichkeit zur Emulation des Schlüssels durch das Gerät implementieren.
Während das erste Problem relativ einfach war, traten beim zweiten Schwierigkeiten auf. Die erste Version des Emulators funktionierte nicht. Das Problem wurde relativ schnell erkannt – bei Mobilgeräten (sowohl iOS als auch Android) ist im Emulationsmodus die UID dynamisch und unabhängig davon, was im Image eingebettet ist – sie variiert. Die zweite Version (mit Superuser-Rechten gestartet) fixierte die Seriennummer auf die gewählte – die Tür öffnete sich. Ich wollte jedoch alles perfekt machen und schließlich eine vollständige Version des Emulators entwickelt, die Mifare-Dumps öffnen und emulieren konnte. Plötzlich entschloss ich mich, die Schlüssel der Sektoren willkürlich zu ändern, und versuchte, die Tür zu öffnen. Und sie... ÖFFNETE SICH! Nach einiger Zeit wurde mir klar, dass sich alle öffnen lassen. Türöffnungen mit diesem Schloss, selbst für Schlüssel, die ursprünglich nicht passten. Daher habe ich eine neue Aufgabenliste zur Durchführung erstellt:
- Herausfinden, welcher Controller für die Schlüsselverwaltung zuständig ist.
- Überprüfen, ob eine Netzwerkverbindung besteht und ob eine gemeinsame Datenbank vorliegt.
- Ermitteln, warum ein faktisch unlesbarer Schlüssel universal wird.
Nach einem Gespräch mit dem Ingenieur des Verwaltungsunternehmens erfuhr ich, dass einfache Controller vom Typ Iron Logic z5r ohne Verbindung zum externen Netzwerk verwendet werden.
Lesegerät CP-Z2 MF und Controller IronLogic z5r.
Ich erhielt ein Equipment-Set für Experimente:
Wie hier zu sehen ist, funktioniert das System völlig autonom und ist äußerst primitiv. Zunächst dachte ich, der Controller befände sich im Lernmodus — die Idee dahinter ist, dass er den Schlüssel liest, ihn speichert und die Tür öffnet — dieser Modus wird verwendet, um alle Schlüssel zu erfassen, beispielsweise beim Austausch eines Schlosses in einem Mehrfamilienhaus. Doch diese Theorie wurde nicht bestätigt — softwareseitig ist dieser Modus deaktiviert, der Jumper ist im Betriebsmodus — und trotzdem sehen wir beim Heranführen des Geräts Folgendes:
Screenshot des Emulationsprozesses auf dem Gerät.
… und der Controller signalisiert, dass der Zugang gewährt wurde.
Das bedeutet, dass das Problem in der Software entweder des Controllers oder des Lesegeräts steckt. Lassen Sie uns das Lesegerät überprüfen – es arbeitet im iButton-Modus, also schließen wir die Sicherheitsplatine Bolid an – wir haben die Möglichkeit, die Ausgaben des Lesegeräts zu beobachten.
Die Platine wird später über RS232 angeschlossen.
Durch mehrere Versuche stellen wir fest, dass das Lesegerät im Falle einer fehlgeschlagenen Autorisierung denselben Code überträgt: 1219191919.
Die Situation beginnt sich zu klären, aber derzeit ist mir unklar, warum der Controller auf diesen Code positiv reagiert. Es besteht die Vermutung, dass beim Befüllen der Datenbank versehentlich oder absichtlich eine Karte mit anderen Schlüsseln des Sektors angehalten wurde – das Lesegerät hat diesen Code gesendet und der Controller hat ihn gespeichert. Leider habe ich keinen Original-Programmierer von IronLogic, um in die Schlüssel-Datenbank des Controllers zu schauen, aber ich hoffe, ich konnte darauf hinweisen, dass ein Problem besteht. Eine Videodemonstration der Arbeit mit dieser Schwachstelle ist verfügbar. .
P.S. Gegen die Theorie der zufälligen Zugabe spricht die Tatsache, dass ich in einem Geschäftscenter in Krasnojarsk ebenfalls mit dieser Methode eine Tür öffnen konnte.
Quelle: habr.com
