Online enabled devices or the “Internet of Things” as it is now being called is all the rage. Take that fancy hardware gizmo, add an embedded web server and blamo you can view and control it from anywhere in the world – What a great idea! But sadly with the mad rush to make things more user friendly and convenient, security is being left aside, even in devices that are being used to protect facilities!
Physical security devices are used to help secure important buildings, rooms, data or material. These hardware devices along with security personnel help defend a company from thieves & trespassers, and also protects employees, equipment and data.
These items include:
- Motion detectors
- Windows & door alarms
- Smoke & fire detectors
- Security cameras
- Electronic locks
With the convenience of the internet and mobile devices, it just makes sense to give these devices an online interface so that they can be more easily monitored by reduced security staff, small business owners that are out of the office, or home owners that are away on vacation.
But what if these devices themselves were not secure? Worse, what if these devices themselves were a security threat to your network?
I recently ran into a very feature rich physical security device and to boot it was internet enabled so it could be monitored from anywhere or from any smart device. Just having this thing at your facility gave you the warm fuzzies. But with a little research I found that the device wasn’t that secure at all.
The device was being run on a Local Area Network (LAN), but the manufacturer recommended that the device be allowed outside your firewall so it could be monitored from anywhere via smart devices. And why not, it had all the surface hallmarks of security. Layers of passwords were needed to access the device, and you could even set up account access allowing some users guest viewing privileges and various levels of configuration access to manager or admin level employees.
This item seemed very secure, and why wouldn’t it be? It was a physical security device, it must also have very strong online protection. But a quick pentest of the device (took about 15 minutes) painted a totally different picture.
To test it, I first ran a standard nmap probe against the device and found that it had several open ports. A couple common ports and several high level ports were open. That partially made sense, it would need some open to be able to be monitored and configured over the web. But the sheer number of open ports just didn’t seem right.
I then ran a more indepth nmap scan to determine what software and version numbers were running on the open ports:
nmap -v -A 192.168.1.130
From the returns, I could see that the device was running some pretty standard services.
I picked the Telnet server software name and version that nmap displayed and did a quick Google search for exploits.
Low and behold the Telnet server on this manufacturer’s device seemed to have used the same default password on all devices at one time. The post even listed the default password. But this article was from 2012, there is no way that brand new devices would still use this password, or would it?
To be sure, I tried to connect to the Telnet service on the device using Netcat and the default password that I found. From a Kali Linux terminal prompt I started Netcat with the IP address and port of the device:
nc 192.168.1.130 23
It then prompted me for the username and password.
host login: root
I then received this:
BusyBox built-in shell
Enter ‘help’ for a list of built-in commands.
Typing “help” returned this screen:
A quick “whoami” command tells us all we really need to know:
We have “root” or god level access rights to the device.
The password the manufacturer used to protect the root level account was not only publicly available, it was also a short simply password, under 6 characters, and all lowercase letters! Just imagine if this “Physical Security Device” was allowed outside our firewall?
A quick view of the device password file (cat /etc/password) showed that the developer created over 40 usernames(!), what is the chance that they used simple passwords for all of the other users too? Worse yet, they were notified about the root password being publicly displayed over two years ago and still haven’t rectified the issue.
All embedded or online enabled devices must be tested for basic security compliance along with your workstations, software and servers. With the rush to make everything “online enabled”, basic security practices are being brushed aside in the name of convenience… or maybe even incompetence.
To learn more about basic security check out the book, “Basic Security Testing with Kali Linux“.