This post will describe the general problem in having embedded devices in your network. Mitigation techniques and work-arounds will be shown how to reduce the risk introduced by them.
But to make it more interesting listen to this while reading.
So it all started with a network pen test which was like hiking in a rainforest and seeing all those weird animals and human-eating flowers that live there. All these creatures in the network were different very exotic embedded devices. They were really interesting as well as very much vulnerable.
Nowadays every equipment that has an ethernet (or any other network) interface will run at least a web server to offer some administration interface and often even more services. Most of the time administrators don’t even realize that they would run any service, they just plug in the ethernet cable, because because there is a port on the device.
The spectrum of embedded devices in an enterprise network is extremely wide. Just a few examples which I’ve seen here-and-there:
- Server racks with their administration interface where one can turn off cooling or shut down electricity.
- Security cameras with control interface and video stream.
- Thermostats to control the temperature of server rooms.
You might ask “Ok, but what’s the problem with the cool web interface of my server rack?”. The problem is threefold:
- Embedded devices usually have strict resource limitations. This means that the services running on them are as simple as possible to save resources, but usually simplicity comes from the lack of security features.
- The developers had the assumption that their product will run in a trusted environment, this way basically passing on the responsibility of securing the services to the operations team. However no environment is really trusted, is it?
- Since administrators often don’t use the built in services they don’t really care about it’s proper configuration and hardening. That means default users and passwods will be very likely available.
If you penetration testing a network and you find an embedded device here are few ideas you could try:
- Before exploiting the hell out of the devices first try to figure out exactly what kind of device is that. It is taunting to start immediately attack a service on a well known port, but these devices don’t really follow the best practice of service to port mapping. This means that a whole different service can listen on a port as you would expect and the guesses of nmap shouldn’t be trusted either.
- RTFM. The documentation is always a gold mine. You can find out default users/passwords and what kind of weird services are available. I could once find the administrator password and I could learn that an open port is for reprogramming the controller in the device of course without authentication.
- Understand the device from the business point of view. Try to attack or compromise those features that would hurt the most for it’s business goal. For instance in case of a security camera, try to manipulate the video stream, or turn it off.
And let’s see the other side of the river, what could an administrator do to protect these devices:
- Initialise the new device. Check which services are available. Turn off the services that are not needed. Configure the users properly, and not only the administrator user because there could be other default user (RTFM again).
- Never trust the embedded devices and always assume that they are insecure. Even if you configure for instance the management web application properly with strong password it is still very likely that the web app itself can be easily exploited to gain control over it.
- Put your embedded devices to a subnetwork which is not accessible from other networks.
- To access the devices in the separate subnetwork a dual homed jump-host can be used. It could be a linux machine which is accessible for the administrators and they could access the embedded devices from this machine. A great advantage of this method is that it will let you authenticate the people with their proper identity, because the jump-host could be integrated in the company’s identity management solution. This could be particularly useful in forensics situation when the logs of the embedded device would only show that root accessed it, but in the logs of the jump-host it would be also shown which user was logged in at that time.
If you still test a network where these devices are accessible then enjoy your pentest. I find always interesting when I see a weird device on the network. For instance finding the video stream of a security camera in a highly secured building by simple opening an unusual port in browser will make every penetration tester smile (at least).