During one of the Red Team engagements, I got a chance to pentest a Biometric attendance device that the client often used to mark the attendance and restrict access to specific rooms.
I did not pop any zero-days here, but several misconfigurations were leveraged that allowed me to achieve root access on the device.
Following is the snapshot of the device I was testing.
Starting with the assessment, I found that the device was connected to the network, and I was able to get its IP address from the device’s network settings.
I performed a port scan on the device’s IP address and found telnet and a web server running on the remote host.
The only attack surface here was to either compromise the telnet or webserver running on the target. Moreover, I could not fingerprint the Telnet version. Also, I tried to brute-force the telnet service using default credentials, but that didn’t work. I then moved on to follow the webserver path.
The target was running ZK Web Server 3.0 on port 80. The only attack surface here was to either compromise the telnet or webserver running on the target. Moreover, I could not fingerprint the Telnet version. Also, I tried to brute-force the telnet service using default credentials, but that didn’t work. I then moved on to follow the webserver path.
The target was running ZK Web Server 3.0 on port 80.
The user manual turned out to be an excellent guide for me to understand the working of ZK Web Server 3.0. I soon found that the Web server was full of vulnerabilities such as access control issues, session fixation and brute-force attacks, to name a few.
Nevertheless, I was able to get access to the admin panel using the default credentials: administrator:123456.
I further navigated to the Backup device data section, which allowed me to download System and User Data.
Here comes the Worst part:
You can access the backup data by navigating to the URL without authentication due to improper access control.
The Backup System Data downloads a .dat file. The dat file contains ZKConfig.cfg file where Telnet credentials are hardcoded. 😛
I was able to log into telnet as root using the obtained credentials.
I mounted the entire file system on my local machine and analyzed all the files. The file system contained the source code for the webserver, which could then be analyzed to look for further vulnerabilities in the web service.
The file system also contained all the user data. The following images are of the people who used the device’s Biometric to access the restricted room.
The file system also contained SQLite database, which had user info, including their credentials as well as fingerprint and biometric data.
It was possible to modify and add an entry into the SQLite database to authenticate and access the restricted area.
I used Firmwalker to extract any further sensitive and valuable stuff I could retrieve from the file system.
Also, it was found that the IOT device backs up all the data into the cloud server using the API. Hence, the IOT device can further be used to pivot and access the cloud host where all the data is backed up.
Takeaways:
IOT devices are often misconfigured by vendors and may open doors for anyone to access sensitive data. In this case, the IOT device not only leaked out all the user info but also gave an opportunity for anyone to access or bypass the access control mechanism.