What are the risks of vulnerabilities in access control systems with facial identification?

Modern access control systems have learned to recognize employees by face. It is convenient: you do not need to wear an RFID-chip badge around your neck and apply it to the reader at every closed door. It seems that the future has come: you can walk around the office with your head held high, and the doors will open themselves, recognizing you. We examined several popular face recognition access control systems and found a whole bunch of vulnerabilities. We will tell you about the most dangerous problems in this post.

image

Card or face: fundamental differences

The operation algorithm of a classical access control system looks like this:

  1. the person brings the card to the reader;
  2. the reader receives the card number and sends it to the server;
  3. the server checks the permissions for this key and, if access is allowed, returns the “OK” status;
  4. the lock controller receives a command to unlock the door.

If we apply this algorithm, replacing the card number with a face image, a local apocalypse will ensue, because the picture is much larger than the card number. This means that its transfer to the server will take longer, and matching images in the database on the server is much more than finding the key number. If there are many employees in the office who are constantly moving, there is a non-zero probability that you will have to smile at the lock while waiting for the door to open for several minutes.

To avoid this, instead of a simple IP camera, they use an intelligent device that is powerful enough for face recognition, and the database of faces is stored on the device. Typically, such a device is a powerful Android gadget or a compact PC running Windows or Linux.

In this case, the central server is used to synchronize the visitor databases, update the reader software and administer the entire system.

Moving the processing load from the server to the external edge eliminates the need to send sensitive data, such as images, for processing. Response times are acceptable and bandwidth requirements are reduced.
However, along with the processing power, other tasks move to the edge nodes. This change adds two notable issues:

  • at the border nodes, in addition to the primitive operations of reading the card and opening the door, a full-fledged business logic is added, which is a source of potential vulnerability;
  • a more functional device requires a more serious approach to physical protection, since a compromise would have much more dire consequences.

We also want to be in the future as soon as possible, where to buy a ticket it is enough to smile at the turnstile, but we consider it necessary to exclude the situation when someone else smiled and the money was debited from you.

As our research shows Identified and Authorized: Sneaking Past Edge-Based Access Control Devices, access control systems with face identification have many unpleasant vulnerabilities: they can be hacked, deceived, presented instead of a person’s face with his photo on the iPhone screen, and even become an administrator and remove all bosses from the list of admitted to the premises.

Consider one of the most vulnerable devices in our study – ZKTeco FaceDepot 7B

image
Access control system ZKTeco FaceDepot. Source: Trend Micro

The device comes in a solid metal case with a screen and a front camera aimed at the visitor. Face recognition takes place inside the device. Photos taken during authentication are not sent to the central server – the processor power of the tablet is enough to carry out the recognition on its own.
A typical deployment of the ZKTeco FaceDepot ACS includes several such devices and a central server through which the user base is synchronized between devices.

Unsecured USB port

The metal case protects the ACS from physical interference, but the open USB port at the bottom of the device spoils everything. It is designed to service the device.

image
Vulnerability # 1 – open USB port. Source: Trend Micro

Outdated Android version

Another global vulnerability of ZKTeco is the device firmware, which is based on Android Lollipop 5.1.1 version released in April 2016. Today, the current version of Android is the tenth. Over the years, the OS has received many security-related improvements. Obviously, in the fifth version nothing of the kind is provided.

image
Screen with Android version on ZKTeco FaceDepot SKD. Source: Trend Micro

The ability to install APK packages

Since this is Android, the user can go to the home screen and launch the app. For example, he can launch ApkInstaller and install any Android APK package from a media connected to a USB port.

image
APK Installer running on ACS. Source: Trend Micro

The manufacturer of the device limited the ability to access the menus and applications only for users with administrator rights, but as a further study of the device showed, this is not a problem, because the device still communicates with the server and does so via HTTP.

Unencrypted exchange with the server

The device communicates with the server via HTTP. All information is transmitted in clear text and can be easily intercepted. Worst of all, administrative commands are passed in clear text – user registration, assigning an administrator role to a user, deleting a user, and synchronization.
An attacker gaining access to the network to which the tablet is connected will be able to listen to network traffic between the ACS and the server and obtain the information necessary for carrying out attacks.
Sadly, the device developers managed to further increase the vulnerability associated with the lack of data encryption: they made a completely leaky device authentication procedure.

Vulnerable device authentication

The only sign of a device’s legitimacy on the server is the token that is passed in the cookie. The token is installed when the device is first registered on the server and, according to our data, never changes.

image
The token value is stored as a cookie. Source: Trend Micro

Given that the “secret” token is transmitted in clear text, any HTTP client can impersonate a legitimate ACS. We used curl in our experiments, a simple command line utility.

For example, this is how we registered a new user in the system and set an image for him:

image
The first command registers a user named Bogus on the server, the second sets a photo for him. Source: Trend Micro

The userdata.post file contains the data that we have sent to the server via POST. In our case, the file contains the following data:

image
The content of the image file for transfer to the server. Source: Trend Micro

Registering an administrator with curl

An existing administrator can promote a new user to administrator using the console on the device. The current administrator must first log into the device through facial recognition and then access the system console to start the promotion process. As soon as the user is promoted to administrator level, the device sends a report to the server, notifying him of the status change.
But since any user who owns the token can simulate legitimate network traffic between the device and the server, nothing prevents him from running the following command and making any user an administrator:

image
Setting privilege = 14 makes the user an administrator. Source: Trend Micro

After the next synchronization of the server and all ACS devices registered on it, the new administrator will be recognized in the entire office network.

Upload all user photos

The URLs of the photos stored on the server are predictable, so listing all the URLs and uploading the photos is a breeze. No authentication is required to access these URLs.
For example, at the following URL, the server will send a photo of the user with the ID “11111”:

image

To collect images, you can make a simple script that will iterate through user IDs from “00000” to any number and download all the photos available in the system.

Fake server injection

Since all communication between the device and the server is over HTTP, it is relatively easy to redirect all ACS devices to a fake server using ARP (Address Resolution Protocol) poisoning.
After we forced the target device to communicate with our fake server, we were able to send the device the updates we needed during one of its regular sync sessions. This technique can be used for a variety of attacks. For example, you can slip end devices with a photo of a user for whom you want to organize illegal access to a company premises.

Access by photo of a legal visitor

Considering the number of possible attack options, testing this method was already somewhat overkill. But given the simplicity and availability of such an attack even for a person who is far from technology, we nevertheless checked whether it would be possible to deceive the ACS using a photograph of a person registered in the system with access to the office. And they were very surprised when, after going through several options, the attack worked: the ZKTeco FaceDepot camera turned out to be supportive of the photos shown on the iPhone X and iPhone XS, but refused to skip the same photo on the screen of smartphones iPhone 6, Samsung A10, Samsung S8, Samsung S9 , Samsung S10, Samsung S10 + and Samsung Note 10.

Recommendations to manufacturers

The ZKTeco FaceDepot access control device is not the only one tested in our study. Unfortunately, other devices also contained serious vulnerabilities that cast serious doubts as to whether they could be used to create a truly secure perimeter of physical access to company premises.
All vulnerabilities found in devices are included in the list Top 10 Web Application Security Riskscompiled by the OWASP project:

  • no default encryption and disabling server-side encryption;
  • vulnerable authentication and session management system;
  • outdated OS versions.

To make access control devices more secure, manufacturers should follow these guidelines:

  • hide sensitive information from the surface of devices – serial numbers, model numbers or any similar information should not be visible;
  • use encryption in the exchange between devices and management servers;
  • protect devices physically – there should not be any open USB ports;
  • regularly update the device and server software, use the latest OS versions.

Similar Posts

Leave a Reply

Your email address will not be published. Required fields are marked *