Probleme autonomer Zugangskontrollsysteme - wo sie nicht erwartet hatten

Guten Tag allerseits. Ich werde mit dem Hintergrund beginnen, was mich zur Durchführung dieser Studie veranlasst hat, aber zuerst werde ich Sie warnen: Alle praktischen Maßnahmen wurden mit Zustimmung der Regierungsstrukturen durchgeführt. Jeder Versuch, dieses Material zu verwenden, um ein geschlossenes Gebiet ohne das Recht auf Anwesenheit zu betreten, ist strafbar.

Alles begann damit, dass ich beim Reinigen des Tisches versehentlich den RFID-Schlüssel an den Eingang des NFC-Lesegeräts ACR122 steckte - was meine Überraschung war, als Windows das Geräusch der Erkennung eines neuen Geräts spielte und die LED grün wurde. Bisher habe ich geglaubt, dass diese Schlüssel ausschließlich im Proximity-Standard funktionieren.

Sobald der Leser es gesehen hat, bedeutet dies, dass der Schlüssel eines der Protokolle über dem ISO 14443-Standard (Nahfeldkommunikation, 13,56 MHz) erfüllt. Die Reinigung wurde sofort vergessen, da ich die Möglichkeit sah, den Schlüsselbund vollständig loszuwerden und den Schlüssel für den Eingang zum Telefon aufzubewahren (die Wohnung ist seit langem mit einem elektronischen Schloss ausgestattet). Als ich zum Lernen säte, fand ich heraus, dass sich unter dem Kunststoff das NFC-Etikett Mifare 1k befindet - das gleiche Modell wie bei den Abzeichen, Abzeichen von Unternehmen, Transportkarten usw. Versuche, in den Inhalt der Sektoren zu gelangen, brachten zunächst keinen Erfolg, aber als der Schlüssel noch geknackt werden konnte, stellte sich heraus, dass nur der 3. Sektor verwendet wurde und die UID des Chips selbst darin dupliziert wurde. Es sah zu einfach aus und es stellte sich heraus, dass es keinen Artikel geben würde, wenn alles genau so lief, wie es beabsichtigt war. Also habe ich den Schlüssel Innereien bekommen, und es gibt keine Probleme,wenn Sie den Schlüssel auf einen anderen kopieren müssen. Aber die Aufgabe bestand darin, den Schlüssel auf ein mobiles Gerät zu übertragen, was ich auch tat. Hier begann der Spaß - wir haben ein Telefon -iPhone SE mit installiertem iOS 13.4.5 Beta Build 17F5044d und einigen benutzerdefinierten Komponenten für NFC-freie Arbeit - darauf werde ich aus objektiven Gründen nicht näher eingehen . Falls gewünscht, gilt Folgendes für das Android-System, jedoch mit einigen Vereinfachungen.

Die Liste der zu lösenden Aufgaben:

• Erhalten Sie Zugriff auf den Inhalt des Schlüssels.
• Implementieren Sie die Fähigkeit, ein Schlüsselgerät zu emulieren.

Wenn der erste relativ einfach war, hatte der zweite Probleme. Die erste Version des Emulators funktionierte nicht. Das Problem wurde schnell erkannt - für mobile Geräte (iOS, Android) im Emulationsmodus - die UID ist dynamisch und schwebt unabhängig davon, was im Bild verkabelt ist. Die zweite Version (als Superuser ausgeführt) hat die Seriennummer fest auf der ausgewählten Version festgelegt - die Tür wurde geöffnet. Ich wollte jedoch alles perfekt machen und habe am Ende eine vollständige Version des Emulators zusammengestellt, mit der Mifare-Dumps geöffnet und emuliert werden können. Ich gab einem plötzlichen Impuls nach, änderte die Schlüssel der Sektoren auf willkürlich und versuchte, die Tür zu öffnen. Und sie ... GEÖFFNET! Nach einer Weile wurde mir klar, dass keineTüren mit diesem Schloss, auch solche, an die der Originalschlüssel nicht passte. In diesem Zusammenhang habe ich eine neue Liste von Aufgaben erstellt:

• Finden Sie heraus, welcher Controller für die Arbeit mit Schlüsseln verantwortlich ist
• Verstehen Sie, ob eine Netzwerkverbindung und eine gemeinsame Basis bestehen
• Finden Sie heraus, warum ein praktisch unlesbarer Schlüssel universell wird

Nach einem Gespräch mit dem Ingenieur der Verwaltungsgesellschaft stellte ich fest, dass einfache Iron Logic z5r-Controller verwendet werden, ohne eine Verbindung zu einem externen Netzwerk herzustellen.

CP-Z2 MF-Lesegerät und IronLogic z5r-Controller

:

Wie hier klar wird, ist das System völlig autonom und äußerst primitiv. Zuerst dachte ich, dass sich der Controller im Lernmodus befindet - die Bedeutung ist, dass er den Schlüssel liest, im Speicher speichert und die Tür öffnet - dieser Modus wird verwendet, wenn Sie alle Schlüssel aufzeichnen müssen, beispielsweise wenn Sie das Schloss in einem Wohnhaus ersetzen. Diese Theorie wurde jedoch nicht bestätigt - dieser Modus wird von der Software ausgeschaltet, der Jumper befindet sich in der Arbeitsposition - und dennoch sehen wir beim Hochfahren des Geräts Folgendes:

Screenshot des Emulationsprozesses auf dem Gerät

… .

Das Problem liegt also in der Software des Controllers oder des Lesegeräts. Lassen Sie uns den Reader überprüfen - er funktioniert im iButton-Modus, also schließen wir die Bolid-Sicherheitskarte an - wir haben die Möglichkeit, die Ausgabe des Readers zu sehen.

Die Karte wird später über RS232 verbunden

Durch die Methode mehrerer Tests stellen wir fest, dass der Leser im Falle eines Autorisierungsfehlers denselben Code sendet: 1219191919

Die Situation beginnt sich zu klären, aber im Moment verstehe ich nicht, warum der Controller positiv auf diesen Code reagiert. Es besteht die Annahme, dass der Leser diesen Code gesendet und der Controller gespeichert hat, als er die Basis gefüllt hat - versehentlich oder speziell eine Karte mit anderen Sektorschlüsseln aufgerufen hat. Leider habe ich keinen proprietären Programmierer von IronLogic, der in die Controller-Schlüsseldatenbank schaut, aber ich hoffe, ich habe es geschafft, auf die Tatsache aufmerksam zu machen, dass das Problem besteht. Eine Videodemonstration zur Arbeit mit dieser Sicherheitsanfälligkeit finden Sie hier .

PS Gegen die Theorie mit einer zufälligen Hinzufügung ist die Tatsache, dass es mir im selben Geschäftszentrum in Krasnojarsk auch gelungen ist, die Tür mit derselben Methode zu öffnen.