In this article, we are going to discuss the process followed by our ethical hacker team to bypass the protections of some access control devices identified during the security audit in the internal network of one of our clients.
A few days ago, our team of ethical hackers was performing a security audit in the internal network of a client and discovered some devices from ZKTeco that were used for employee access control. As usual, when our team detects a new device, they follow their audit methodology in order to try to identify the services that the device provide and then, try to exploit each of them. The result was that these devices could suppose a severe security threat due to authentication problems and it may be possible to obtain full control of these devices.
The devices where discovered after a first enumeration scan performed with nmap. The scanner was able to identify two services in the devices: telnet (port 23) and a web server (port 80). Both of these services are insecure due to the lack of encryption in the communications, the lack of encrypted services like SSH or HTTPS give us a hint about the security considerations of the manufacturer, if they do not implement secure protocols it is very likely that their code will be poor in terms of security.
This first scan was also able to extract some useful information from the devices, from example, for one of them, it was able to detect it as a fingerprint reader from ZKSoftware model ZEM500 and that it is running a Linux kernel version 2.4.20.
After identifying that it is an access control device, our team performed a full scan of the device in order to detect all the TCP and UDP ports in use; this led to the discovery of two extra UDP ports, UDP ports 4370 and 4371. Apparently, these ports are used for communication with the control software.
The device uses a custom protocol for the communication using the port 4370, due to that, our team had to analyze the communication software in order to identify how the communication was performed. The analysis showed that the communication does not require authentication and therefore we were able to forge some custom UDP packets using Scapy.
These packets contain payloads discovered in the software and we were able to receive responses from the devices without authentication! It was possible to extract information like the identifiers of the employees. Despite of being able to obtain information, it was difficult to read due to needing a tool like Wireshark to capture the responses and the manual parsing of the data.
With all this information, our team started to search for custom implementations of the communication protocol used by the device and discovered an unofficial library for python called pyzk. The library is very complete and with just some modifications on the code, we were able to easily perform any action on the device without authentication, for example, it was possible to disable the device, add users, clear data…
An attacker with malicious intentions could, for example, create a new user allowing him to access the building like an employee, or may be able to cause problems with the device disabling it or removing the data from the users.
After discovering this security problem our team did not stop, the discovery of the insecure protocol motivates us to find some vulnerabilities in the web server.
When we first tried to access the web server, a login page appeared, the first impression was good, at least the web server implemented an authentication mechanism.
The login page was https://
The initial though was that the web server may provide this information without authentication due to being non-sensible information, however, we tried to request some of the resources that were referred in the menu and as a result we were able to obtain private information from the device without being authenticated, for example, the users data.
In a next step, our team tried to perform unauthenticated actions, and the web server allowed it. During the scanning of the website, two interesting sections were discovered, the backup section and the restore section. In the backup section, we could find two options that could be exercised sending POST requests, we tried to perform a backup without authentication and as a result, we obtained two backups files!
The backup section of the web server does not provide any information of the format of these backups, due to that, we had to scan the downloaded files using binwalk which identified both files as gzip compressed data, knowing the compression mechanism we were able to decompress them using tar. The files extracted were logs and configuration files with sensitive information that should not be disclosed without authentication.
The restore section of the web server provide a function to restore the backups generated in the backup section but there is no integrity check to verify that these backups have not been modified, this could lead to the upload of modified backups, with tampered files or additional files.
An attacker could exploit this fact to extract files into the filesystem. For example, this could be used to create a custom shadow file with a known root password, compress it with the data of the backups so when the server decompress the backup, the original shadow file would be replaced. This would allow an attacker to use the telnet service to log into the device as root with a custom password and execute arbitrary commands.
Our team determined that trying to exploit this vulnerability could perform DoS in the device if there is any problem parsing the new shadow file and therefore, it was not tested. Despite of that, after all the analysis performed in these devices, the lack of security in the other functions seems to indicate that it may be vulnerable.
After the audit of these devices, the conclusions obtained were that these devices are insecure and should be isolated in order to avoid unauthenticated actions performed by an attacker.
