Good day to everyone. I will start with the background that led me to conduct this research, but first, I must warn you: all practical actions were carried out with the consent of the managing authorities. Any attempt to use this material for unauthorized access to restricted areas is a criminal offense.
It all began when I was cleaning my desk and accidentally placed the RFID key for the entrance on the NFC reader ACR122 β I was amazed when Windows played a sound indicating a new device was detected, and the LED lit up green. Until that moment, I had thought these keys only operated on the Proximity standard.
But since the reader recognized it, the key must comply with one of the protocols on top of the ISO 14443 standard (also known as Near Field Communication, 13.56 MHz). I quickly forgot about cleaning since I saw an opportunity to completely get rid of the keychain and keep the entrance key on my phone (the apartment has been equipped with an electronic lock for a long time). Diving into research, I discovered that the plastic concealed an NFC tag Mifare 1k β the same model used in access badges for enterprises, transport cards, etc. My initial attempts to access the sector contents were unsuccessful, and when I finally managed to hack the key, I found that only the 3rd sector was used, which contained a duplicate of the chip's UID. It seemed too simple, and it turned out to be so; there wouldn't be an article if everything had gone as planned. Here I obtained the insides of the key, and there were no issues if I needed to copy the key onto another identical one. But the task was to transfer the key to a mobile device, which I set out to do. This is where the fun began β we have a phone β iPhone SE with iOS 13.4.5 Beta build 17F5044d and some custom components for seamless NFC operation β I won't dwell on this for certain objective reasons. If desired, everything mentioned next is also applicable to the Android system, but with some simplifications.
Task list to solve:
- Access the contents of the key.
- Implement the ability to emulate the key with the device.
While the first one was relatively straightforward, the second presented challenges. The initial version of the emulator didn't work. The issue was quickly identified β mobile devices (both iOS and Android) in emulation mode have a dynamic UID, which varies regardless of what is hardcoded in the image. The second version (running with superuser rights) fixed the serial number on the chosen device β the door opened. However, I wanted to make everything perfect, and ultimately I assembled a complete version of the emulator that could open Mifare dumps and emulate them. Succumbing to a sudden impulse, I changed the sector keys to arbitrary ones and tried to open the door. And it... OPENED! After a while, I realized that it opened any doors with this lock, even those for which the original key did not work. Consequently, I created a new task list to accomplish:
- Find out which controller is responsible for working with the keys
- Understand if there is a network connection and a common database
- Determine why an actually unreadable key becomes universal
After talking to an engineer from the management company, I learned that simple controllers Iron Logic z5r are used without connection to an external network.
Reader CP-Z2 MF and controller IronLogic z5r
I was given a set of equipment for experiments:
As it is clear from here β the system is completely autonomous and extremely primitive. At first, I thought that the controller was in learning mode β the idea being that it reads the key, stores it in memory, and opens the door β this mode is used when all keys need to be recorded, for example, when replacing a lock in an apartment building. But this theory was not confirmed β programmatically this mode is turned off, the jumper is in operational position β and nevertheless, when presenting the device, we see the following:
Screenshot of the emulation process on the device
β¦ and the controller signals that access has been granted.
This means the problem lies in the software of either the controller or the reader. Let's check the reader β it operates in iButton mode, so we'll connect the security board Bolid β we will have the opportunity to view the output data from the reader.
The board will be connected later via RS232
Through multiple attempts, we find that the reader transmits the same code in case of unsuccessful authorization: 1219191919
The situation starts to become clearer, but at this point, itβs unclear to me why the controller responds positively to this code. There is a hypothesis β that when filling the database, either accidentally or deliberately, a card with different sector keys was presented, causing the reader to send this code and the controller to save it. Unfortunately, I do not have a branded programmer from IronLogic to check the controller's key database, but I hope I have drawn attention to the fact that the problem exists. A video demonstration of the vulnerability is available. .
P.S. The theory of accidental addition is refuted by the fact that in one business center in Krasnoyarsk, I was also able to open the door using this same method.
Source: habr.com
