Censys uncovered over 2,000 devices whose primary purpose is to manage and monitor a system’s electrical sockets remotely. In many cases, the only thing between a server’s physical off-button and a malicious user is a simple login form, and in a handful of cases, no authentication or security at all.
As engineers, we often talk about the methods and means used to execute and thwart an attack. We question our products, we run security scans against our software, and we load-test our services. We spend an extraordinary amount of time planning for the worst and hoping for the best; we fill our heads with questions like, “do we have redundancy?”, “how do we handle authentication?” and “is our edge sufficiently protected from a network attack?”.
But we often forget to ask ourselves elementary questions like: “can an attacker flip the power switch?”. You could have all of the security and DDoS mitigations in the world, and it wouldn’t matter if some random person could just walk into your data center and turn your servers off. It may sound ridiculous, but the threat is real.
Whether you want to access a network device that has lost external connectivity or you’re sitting on your couch wishing for the lights to be a different hue of red, there is probably an affordable device to do just that. The class of such devices ranges from “Out of Band” (OOB), “Integrated Lights Out” (iLO), to just plain old “Network Power Switch.” Still, they all share a common goal of networking offline devices for emergency administrative purposes.
While not inherently insecure, the primary risk is that devices like these can easily be forgotten about or overlooked due to their form factor. At best, an attacker could use the information gleaned from these devices to understand a potential target’s infrastructure. At worst, an attacker could find a vulnerability in one of these devices to execute a more sophisticated attack or denial-of-service. A would-be attacker could find a remotely exploitable bug in a devices’ software and use it as a jumping point to attack other hosts on the local network.
Analysis
Starting with a simple product search on a retail website for “IP Remote Power,” Censys began to look for identifiers that would reliably return results containing internet-accessible hosts which manage physical power outlets. Censys found a handful of consumer-grade networked power solutions to answer this broad question of potential attack surfaces. These products ranged from professional rack-mounted hardware to small inconspicuous black boxes with a web-based administration panel.
To better understand the hardware running these services, Censys downloaded the available firmware and documentation from several vendors to identify any piece of information that could assist in the search.
Vendors like Dataprobe, using the ARM family of processors (specifically a Beagleboard), kept its initial server configurations, including SSL certificates in the directory “/etc/ibootbar2”, while supporting PHP software could be found in “/var/iBB2-WebPages”. On the other end of the spectrum, devices like Megatec, using a low-end MIPS processor, stored SSL certificates in the file “/etc_ro/1024_RSA_(KEY|CERT).pem” and held all associated CGI as compiled ELF objects in “/etc_ro/web/cgi-bin.”.
Starting with the default SSL certificates that come preloaded on these devices as an initial search term, we found other unique characteristics the devices used to identify themselves. Many devices that included a web administration panel would announce its WWW-Authenticate header as the device’s name. In contrast, others would place its exact version information in the title of a webpage:
Devices managed via a remote console, such as a telnet server, had weaker security; and, in some cases, were completely unauthenticated! One such vendor had 73 internet-accessible ports, 50 of which would drop you into a management shell upon connecting.
Overall, Censys found 2,617 active networked power switches listening on routable IPv4 addresses using a rudimentary set of search terms. The following chart displays the vendor along with the number of ports found to be serving administrative panels.
Most of the operating system information we discovered from these Internet-facing hosts did not match the suspected device’s underlying OS. This common discrepancy is likely because the physical devices sit behind a router or some sort of proxy service. It is most likely that these hosts were exposed accidentally by misconfiguration, automatic port forwarding with UPnP, port re-use, or even lenient “allow-HTTP” access-lists.
What can I do about it?
- Continually monitor your infrastructure manually with Censys Search, or automatically using Censys ASM to identify unintentionally exposed ports and services.
- Permanently disable UPnP on your gateway devices.
- Adjust firewall rules to only allow trusted hosts to connect.
- Disable or restrict administration services for any device connected to the network
