Exploits & Vulnerabilities
Exploitable Flaws Found in Facial Recognition Devices
To gain a more nuanced understanding of the security issues present in facial recognition devices, we analyzed the security of four different models. Our case studies show how these devices can be misused by malicious attackers.
Biometric security solutions such as fingerprint readers, iris scanners, and facial recognition cameras are widely used to manage entry into restricted areas. But these biometric authenticators are typically computationally heavy. For example, traditional facial recognition security solutions use an external service for the computation required to validate a user; a camera on-site takes an image and then sends it to a cloud-based service that does the processing. In large-scale deployments, latency develops between the authentication and the validation of the user, and issues of network bandwidth consumption also arise from sending large quantities of image data to the authentication service.
To solve these issues, security solution manufacturers are using edge computing for facial-recognition-based access control devices. Under this architecture, devices are themselves edge nodes and are fully equipped to validate a user image directly. These edge-computing-capable devices rely on an external service only for coordination and maintenance tasks.
This architecture reduces latency and network bandwidth consumption since no user images are transferred on the network. However, there are security concerns about low-powered “dumb” devices being equipped with higher computational capabilities and more responsibilities in the validation process.
To gain a more nuanced understanding of the security issues present in facial recognition devices, we analyzed the security of four different models: ZKTeco FaceDepot-7B, Hikvision DS-K1T606MF, Telpo TPS980, and Megvii Koala.
The devices and their server components (if applicable) were set up in an isolated test network. Our arrangement simulated how these devices would normally operate in an enterprise environment. As illustrated in Figure 1, the setup has three components:
- Access control device: This is the access control device being tested.
- Man-in-the-middle (MitM) device: This device is used to transparently capture network packets between the access control device and the corresponding server component.
- Management server: The access control device usually comes with a software suite that includes a server component. The server component is installed in this management server.
Weak Points in Device Hardware
ZKTeco FaceDepot 7B Indoor Facial Recognition Station
Although the device itself comes in a ruggedized tablet form factor, an exposed USB-A port at the bottom of the device, as shown in Figure 2, leaves it open to misuse. Technicians who service the device use this USB port to update the device’s firmware, but a malicious user could potentially install an Android package (APK) on the device.
Telpo TPS980 Access Control Terminal
The device has a front-facing camera that is used for facial recognition; upgraded models come with two cameras and an optional infrared camera. As shown in Figure 3, at the back of the device are interfaces for RS-485, Wiegand, and digital output, and a USB port for debugging. Also visible at the back of the device is its serial number. In the following subsections, we detail how some of these features could be used in malicious attacks.
Abusing administrator access
The only protection for the administrative interface of this device is a password. By using the device’s visible serial number, we were able to use a cURL command to obtain the device password and other sensitive information from the Telpo cloud server:
After we obtained the password, we were free to administer the device. Possible actions that come with this level of access include creating a new user and changing device parameters such as liveness detection. (Liveness detection is a feature that differentiates between a static picture and an actual live person. Turning this off makes the device more susceptible to being tricked by static images.)
Also, since all devices connected to a Telpo cloud account share the same password, we were able to access other machines as well.
Using the client_secret information also obtained through the serial number (highlighted in the previous code snippet), we could also uncover the access_token key that can be used to remotely administer the device. We show this in the following cURL command:
With the access_token key, we could now remotely administer the connected devices. The possible remote administrative tasks include obtaining the list of users (including their photos), registering a new user, and updating a user’s details (such as name and photo). The only issue that might hinder a malicious actor when using this technique is that the key expires an hour after it is generated.
Loading malicious files through the USB port
The device functions like an ordinary Android device. This means that a malicious actor could use the USB port to enable MTP (Media Transfer Protocol) and transfer files to and from the device in its default configuration. Fortunately, Telpo disabled Android Debug Bridge (adb), a command-line tool that lets its user directly communicate with an Android device for app installations, system modifications, file transfers, and other device actions.
However, it is still possible to harvest user information by connecting to the USB port. The faces of registered users are stored in the path /Telpo_face/Registered Image/. An attacker could access these files, each of which is named using the user’s name and an internal ID, such as “John Doe-1368.jpg”.
Unencrypted and Unsecured Network Traffic
ZKTeco FaceDepot 7B Indoor Facial Recognition Station
The network traffic between the device and the server is done over plaintext HTTP. This leaves an avenue open for a malicious actor, who could then easily access the network leading to the IP camera device and sniff the network traffic between the device and the server. From there, the actor could obtain information needed to conduct attacks.
The most important data a malicious actor could collect in this case is the token value. This is a shared secret between the device and the server, set when the device first registers with the server. We were able to obtain the token value since it is attached to the cookie header with every HTTP request from the device, as shown in Figure 4.
From what we can observe, the only way the server recognizes an IP camera device is through this token value. If the token is acquired, any HTTP client could impersonate the access control device on the server. In our case, we used cURL to impersonate the access control device after acquiring the token. We also observed that the token value does not seem to expire. The same experiment, done two weeks later using the same token, still led to a successful attack.
Registering a new user via cURL
New users are added by someone with administrator access to the edge camera device. The admin takes the new user’s photo and personal details, and then the device uploads the information to the server. As previously mentioned, the server authenticates the device through the token value (easily harvested because of the plaintext nature of the traffic).
Using the token value we obtained, we were able to send an HTTP request to the server mimicking user registration traffic. The following sequence of cURL commands registers a new user to the server:
The first cURL command registers the metadata for our new user. In this case, the user ID and PIN are both set to “11111”, with the privilege set to “0” (normal user) and the name set to “Bogus”. The second cURL command sets the photo for our new user. This photo will be the basis for the facial recognition. The device uploads the image to the server, which then disseminates the photo to the other connected access control devices.
The userdata.post file contains the data that we submitted to the server via POST. In our case, the file contains the following:
On the next synchronization event between the server and the connected access control devices, the new user will be recognized by all the devices.
Promoting a user to administrator via cURL
Promoting a user to administrator can also be done with the token value. To this end, we used the following cURL command:
The cURL command sets the privilege to “14”, which is the value that makes a user an admin. After the next synchronization of the server and all connected IP cameras, the new admin will be recognized by all the devices.
As previously shown, anyone with an acquired token value can mimic the network traffic between the device and the server. We also found that it is possible to harvest user photos and grab data from update commands.
Megvii Koala Facial Recognition Gate
Megvii Koala comes in two versions: an online version where the database is hosted in the cloud, and an offline version where the user hosts the database on-premises. In the offline version, the network traffic between the access control device and the server is done over HTTP. Because of the plaintext nature of HTTP traffic, this version is susceptible to remote attacks.
We found that it is possible to impersonate a connected access control device and send the server data that it will recognize and validate. To do this, we used the device’s media access control (MAC) address, which can be found over the network in clear text, through Nmap, or (in some cases) printed on the back of the device. We sent cURL requests with the MAC address to trick the server into authenticating a registered user and opening the door. The following is an example of this technique:
It uses the following values:
- MACADDRESS: This is the MAC address of the connected access control device.
- 0: This is the value set for fmp_threshold to disable the liveness detection routines.
- mugshot.jpg: This is a photo of the registered user, taken beforehand. The server will use this image for its facial recognition routines.
If the action is successful, the server will return the following JSON data:
The important part of the returned JSON data is the following:
If the value of can_door_open is “true”, this will signal the door to release the lock and open.
This method requires a malicious actor to first have an image of a registered user, which they can obtain quite easily — they can simply search social media platforms for a picture of a company employee. With the image, they could unlock the door remotely, even though the actual user is nowhere in the vicinity.
Hikvision DS-K1T606M Face Recognition Terminal
For this device, we noted that the communication with the server appears to be in an encoded custom binary format. There are indicators that the protocol is not encrypted; for example, the serial number of the device is readable from the network packets.
However, even though the protocol used is binary-encoded and not documented, it is still possible to obtain data from the network traffic between the server and the device. When a device is used by a new user to register their information and the image of their face, the device uploads that data to the server during the next server sync. During the sync process, it is possible to obtain the user information and even the facial recognition picture from the network traffic.
Best Practices and Mitigation Measures
Security practices acquired for a specific technology seldom transfer into different mediums. This is clear when we look at the use of HTTP for API communications. HTTP was introduced in the 1990s for desktop web browsers, and through the years there have been improved security practices: hardening the protocol, making sure communications are encrypted, and ensuring sessions are not reusable, among others. Edge computing is a relatively new medium for a relatively old technology, and many manufacturers of edge devices have not yet adopted such security practices. Our case studies show how a critical device such as an access control camera relies on a tried and tested protocol such as HTTP, but the systems deployed miss certain security points.
To mitigate the risks involved in relying on these devices, enterprise users can follow secure deployment guidelines such as the following:
- Check the security of the devices themselves and perform risk analysis for any edge-based installation.
- Manage hardware weak points such as visible device information and accessible ports.
- Isolate edge devices and their servers in the network space, and make them inaccessible from external parties.
- Employ network-based IP filtering — in the form of firewalls or access control lists, for example — to allow communication only from approved network endpoints.
We uncover more security issues and expound on other mitigation measures in our research paper “Identified and Authorized: Sneaking Past Edge-Based Access Control Devices.”