Good day to all. I'll start with the background, about what prompted me to conduct this study, but before that, I'll warn you: all practical actions were carried out with the consent of the governing structures. Any attempt to use this material to enter a closed area without the right to be there is a criminal offense.
It all started with the fact that while cleaning the table, I accidentally placed the RFID entry key on the ACR122 NFC reader - what was my surprise when Windows played the sound of detecting a new device, and the LED turned green. Up to this point, I believed that these keys work exclusively in the Proximity standard.
But since the reader saw it, it means that the key corresponds to one of the protocols on top of the ISO 14443 standard (aka Near Field Communication, 13,56 MHz). Cleaning was immediately forgotten, as I saw an opportunity to completely get rid of a bunch of keys and keep the key to the entrance in the phone (the apartment has long been equipped with an electronic lock). Having sat down to study, I found out that the Mifare 1k NFC tag is hidden under the plastic - the same model as in enterprise passes, badges, transport cards, etc. At first, attempts to get into the contents of the sectors 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 that there would be no article if everything went exactly as planned. So I got the offal of the key, and there are no problems if you need to copy the key to another one of the same. 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 established iOS 13.4.5 Beta build 17F5044d and some custom components for the free operation of NFC - I will not dwell on this in detail due to some objective reasons. If desired, all of the following is applicable to the Android system, but with some simplifications.
List of tasks to solve:
- Get access to the contents of the key.
- Implement the ability to emulate a key by a device.
If everything was relatively simple with the first, then there were problems with the second. The first version of the emulator didn't work. The problem was quickly discovered - for mobile devices (both iOS and Android) in emulation mode - the UID is dynamic and no matter what is wired in the image - it floats. The second version (launched with superuser rights) rigidly fixed the serial number on the selected one - the door opened. However, I wanted to make everything perfect, and ended up building a complete emulator that could open Mifare dumps and emulate them. On a sudden impulse, I changed the sector keys to random ones and tried to open the door. And sheβ¦ OPENED! After a while, I realized that they were opening Π»ΡΠ±ΡΠ΅ doors with this lock, even those that the original key didn't fit. In this regard, I have formed a new list of tasks to perform:
- Find out which 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 generic
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
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 meaning is that it reads the key, stores it in memory and opens the door - this mode is used when all keys need to be written down, for example, when replacing a lock in an apartment building. But this theory was not confirmed - this mode is programmatically disabled, the jumper is in the working position - and nevertheless, when the device is brought up, we see the following:
Screenshot of the emulation process on the device
... and the controller signals that access has been granted.
So the problem lies in the software of either the controller or the reader. Let's check the reader - it works in iButton mode, then we will connect the Bolid security board - we will have the opportunity to see the output from the reader.
Board, will later be connected via RS232
Using the method of multiple trials, we find out that the reader broadcasts the same code with in case of authorization failure: 1219191919
The situation is starting to clear up, but at the moment it is not clear to me why the controller responds positively to this code. There is an assumption - that when the base was filled - by accident or on purpose they brought 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 database of controller keys, but I hope I was able to draw attention to the fact that the problem exists. A video demonstration of how to work with this vulnerability is available. .
PS Against the theory with a random addition is the fact that in one business center in Krasnoyarsk I also managed to open the door by the same method.
Source: habr.com