What dangerous security vulnerabilities can access control systems have?

Facial recognition mesh

Modern access control systems can recognize employees by their faces. This is very convenient. People do not need to wear a badge with an RFID chip around their necks all the time and use the card with every closed door. It seems that the future has come. Employees can walk around the office with their heads held high, and the doors will open by themselves.

But it turns out that many access control systems that use facial recognition technology have security vulnerabilities. In this article, you will read about the most dangerous problems.

Access card vs. face recognition

The algorithm of the classic access control system looks like this:

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

If you use the same equipment and apply this algorithm, replacing the card number with a face image, a local apocalypse may come since the picture is much larger than the card number. This means that it will take more time to transfer data to the server. Besides, matching images in the database on the server is a much more complex process than looking up a key number. If many employees in the office are constantly moving, there is a non-zero chance that you will have to wait several minutes for the door to open.

To avoid this, instead of a simple IP camera, an intelligent device is used. Its power is sufficient to cope with face recognition, and the face database is stored on the device. Typically, such a device is a powerful Android gadget or a compact PC running Windows or Linux. In addition, the central server is used to synchronize visitor databases, update reader software, and administer the entire system.

Moving the processing mechanism from the server to the outer edge eliminates the need to send sensitive data, such as images, for processing. Response time becomes acceptable, and bandwidth requirements are reduced.

However, along with computing power, other tasks also move to edge nodes. This change adds two significant problems:

  • In addition to the primitive operations of reading the card and opening the door, full-fledged business logic is added to the edge nodes. This is a source of potential vulnerabilities.
  • A more functional device requires a more serious approach to physical protection since a compromise can have more dangerous consequences.

Access control systems with face recognition can have many unpleasant vulnerabilities. They can be breached, deceived, presented with a person's photo on the phone screen instead of an actual face.

Let’s take a typical access control system. The device often comes in a rugged 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 a central server. The processor power of the tablet is enough to carry out recognition on its own. The typical deployment architecture includes several such devices and a central server through which the user base is synchronized between devices.

Unprotected USB ports

The metal case protects the device from physical interference, but an open USB port can ruin everything. It is designed to service the device. Malefactors can connect their devices and install spyware or execute rogue code.

An old version of the Android OS

Another global problem is the device's firmware, which is sometimes based on an outdated version of Android released several years ago. Over the years, the OS has received many security-related improvements. OS vulnerabilities are one of the main factors devices get breached.

Possibility to install APK packages

Since such devices are often based on Android, the user can go to the home screen and launch an app. For example, crooks can run popular ApkInstaller and install an Android APK from a USB stick. The device manufacturer can limit the ability to access menus and applications only to users with administrator rights. However, as practice shows, this is not always a problem, as many devices still interact with the server and do it over an insecure HTTP protocol.

Unsecure communication with the server

There are still many access control systems in which the device communicates with the server via HTTP. All information is transmitted in a clear form and can be intercepted. Worst of all, administrative commands are also transmitted in clear text.

An attacker who has gained access to the network to which the tablet is connected will be able to intercept network traffic between the ACS and the server and obtain the information necessary to carry out attacks. Hackers can register a user, assign an administrator role to a user, delete a user, and start synchronization.

It is sad, but some developers manage to further increase the vulnerability associated with the lack of data encryption. They make a completely weak device authentication procedure.

Vulnerable authentication

According to common practice, a sign of the legitimacy of a device on the server is a security token. The token is set when the device first registers with the server and often never changes.

Considering that the "secret" token is transmitted in clear text, any HTTP client can impersonate a legitimate access control system. With a simple command-line utility like curl, a malicious actor can register a new user on the system.

User photos downloads

Very often, the URLs of the photos stored on the server are predictable. Listing all the URLs and downloading the photos is an elementary task. No authentication is required to access these URLs. To collect images, malicious actors can create a simple script that will iterate through user IDs from "0" to any number and download all the photos available in the system.

Introduction of a false server

In systems where all communication between the device and the server is conducted via HTTP, it is relatively easy to redirect all ACS devices to a fake server using ARP poisoning.

Once the attackers get the target device to interact with the fake server, they can send the device the updates they want during one of its regular sync sessions. This technique can be used for various attacks. For example, attackers can add a photo of a user to whom they want to grant illegal access to company premises.

Security recommendations for ASC manufacturers and their customers

Unfortunately, there are still many devices today that contain security vulnerabilities. Logically, doubts arise as to whether they can be used to create truly secure access to company premises. Very often, vulnerabilities found in devices are included in the Top 10 Web Application Security Risks list compiled by the OWASP project. For ASCs, the most common vulnerabilities are:

  • Lack of encryption by default or disabled encryption on the server side.
  • Vulnerable authentication and session management.
  • Outdated OS versions.

To make access control devices more secure, it is advised to follow these guidelines:

  • Hide sensitive information from the surface of devices. Serial numbers, model numbers, or any similar information should not be visible.
  • Use a VPN or any other secure connection option to encrypt traffic between devices and management servers.
  • Take care of offsite backups.
  • Protect devices physically. There should be no open USB ports.
  • Regularly update device and server software and use current OS versions.
  • Limit the ability to access device menus and apps only to users with administrator rights.

Image credit: metamorworks / Shutterstock

Alex Vakulov is a cybersecurity researcher with over 20 years of experience in malware analysis. Alex has strong malware removal skills. He writes for numerous tech-related publications sharing his security experience.

Comments are closed.

© 1998-2024 BetaNews, Inc. All Rights Reserved. Privacy Policy - Cookie Policy.