Problems of autonomous access control systems - Where they did not expect

Good day to all. I will start with the background about what prompted me to conduct this study, but first I will warn you: all practical actions were performed with the consent of the governing structures. Any attempt to use this material in order to enter a closed territory without the right to be there is a criminal offense.

It all started with the fact that when I was cleaning the table, I accidentally put the RFID key to the entrance to the NFC-reader ACR122 - what was my surprise when Windows played the sound of detecting a new device, and the LED turned green. Until now, I believed that these keys work exclusively in the Proximity standard.

But once the reader saw it, it means the key meets one of the protocols on top of the ISO 14443 standard (It is Near Field Communication, 13.56 MHz). Cleaning was immediately forgotten, since I saw the opportunity to completely get rid of the keychain, and save the key to the entrance to the phone (the apartment has long been equipped with an electronic lock). Sowing the study, I found out that under the plastic is the NFC tag Mifare 1k - the same model as in the badges, badges of enterprises, transport cards, etc. Attempts to get into the contents of the sectors at first did not bring success, but when the key was still able to be cracked, it turned out that only the 3rd sector was used, and the UID of the chip itself was duplicated in it. It looked too simple, and it turned out and there would be no article if everything went exactly as intended. So I got the key offal, and there are no problems,if you need to copy the key to another one. But the task was to transfer the key to a mobile device, which I did. This is where the fun began - we have a phone -iPhone SE with iOS 13.4.5 Beta build 17F5044d installed and some custom components for NFC free work - I won’t dwell on this for some objective reasons. If desired, all of the following applies to the Android system, but with some simplifications.

The list of tasks to solve:

• Get access to the contents of the key.
• Implement the ability to emulate a key device.

If the first was relatively simple, then the second had problems. The first version of the emulator did not work. The problem was quickly detected - for mobile devices (iOS, Android) in emulation mode - the UID is dynamic and regardless of what is wired in the image, it floats. The second version (run as superuser) rigidly fixed the serial number on the selected one - the door opened. However, I wanted to do everything perfectly, and in the end I put together a complete version of the emulator that could open Mifare dumps and emulate them. Yielding to a sudden impulse, I changed the keys of the sectors to arbitrary, and tried to open the door. And she ... OPENED! After a while, I realized that anydoors with this lock, even those to which the original key did not fit. In this regard, I formed a new list of tasks to perform:

• Find out what controller is responsible for working with keys
• Understand if there is a network connection and a common base
• Find out why a virtually unreadable key becomes universal

After talking with the engineer of the management company, I found out that simple Iron Logic z5r controllers are used without connecting to an external network.

CP-Z2 MF reader and IronLogic z5r controller

:

As it is clear from here - the system is completely autonomous and extremely primitive. At first I thought that the controller is in the learning mode - the meaning is that it reads the key, stores it in the memory and opens the door - this mode is used when you need to record all the keys, for example, when replacing the lock in an apartment building. But this theory was not confirmed - this mode is turned off by software, the jumper is in the working position - and nevertheless, when we bring the device up, we see the following:

Screenshot of the emulation process on the device

… .

So the problem lies in the software of either the controller or the reader. Let's check the reader - it works in iButton mode, so we will connect the Bolid security board - we will have the opportunity to see the output from the reader.

The board will later be connected via RS232

Using the method of multiple tests, we find out that the reader broadcasts the same code with in case of authorization failure: 1219191919

The situation begins to clear up, but at the moment I do not understand why the controller responds positively to this code. There is an assumption - that when they filled the base - accidentally or specially brought up a card with other sector keys - the reader sent this code and the controller saved it. Unfortunately, I do not have a proprietary programmer from IronLogic to look into the controller key database, but I hope I managed to draw attention to the fact that the problem exists. A video demonstration of working with this vulnerability is available here .

PS Against the theory with a random addition is the fact that in the same business center in Krasnoyarsk I also managed to open the door by the same method.