Management. Control. It seems that you can’t stick five people in a room together without one of them trying to order the others around. This tendency towards centralized authority is not without reason, however – it is often more efficient to have one person, or thing, calling the shots. For an example of the latter, one needs look no further than Delta’s enteliBUS Manager, or eBMGR. Put simply, this device aims to centralize control for various pieces of hardware often found in corporate or industrial settings, whether it be temperature and humidity controls for a server room, a boiler and its corresponding alarms and sensors in a factory, or access control and lighting in a business. The advantages seem obvious, too – it can be configured to adjust fan speeds according to thermostat readings or sound an alarm if pressure crosses a certain threshold, all with little human interaction.
The disadvantages, while less obvious, become clear when one considers tech-savvy malicious actors. Suddenly, your potentially critical system now has a single point of failure, and one that is attached to a network, to make matters worse.
Consider for a moment a positive pressure room in a hospital, the kind typically used to keep out contaminants during surgeries. Managing rooms such as these is a typical application for the eBMGR and it does not take an overactive imagination to envision what kind of damage a bad actor could cause if they disrupted such a sensitive environment.
Management. Control. That’s what’s at stake if a device such as this is not properly secured. It’s also what made this device such a high priority for McAfee’s Advanced Threat Research team. The decision to make network-connected critical systems such as these demands an extremely high standard of software security – finding where it might fall short is precisely our job.
With these stakes in mind, our team went to work. We began by hooking up an eBMGR unit to a network with several other devices to simulate an environment somewhat true to life. Using a technique known as “fuzzing”, we then blasted the device with all kinds of deliberately malformed network traffic, looking for a chink in the armor. That is one advantage often afforded to the bad guys in software security; they can make many mistakes; manufacturers need only make one.
Perhaps unsurprisingly, persistence and creativity led us to discover one such mistake: a mismatch in the memory sizes used to handle incoming network data created what is often referred to as a buffer overflow vulnerability. This seemingly innocuous mistake rendered the eBMGR vulnerable to our carefully crafted network attack, which allows a hacker on the same network to gain complete control of the device’s operating system. Worse still, the attack uses what is known as broadcast traffic, meaning they can launch the attack without knowing the location of the targets on the network. The result is a twisted version of Marco Polo – the hacker needs only shout “Marco!” into the darkness and wait for the unsuspecting targets to shout “Polo!” in response.
In this field, complete control of the operating system is typically the finish line. But we weren’t content with just that. After all, controlling the eBMGR on its own is not all that interesting; we wanted to see if we could use it to control all the devices it was connected to. Unfortunately, we did not have the source code for the device’s software, so this new goal proved non-trivial.
We went back to the drawing board and acquired some additional hardware that the Delta device might realistically be charged with managing and had a certified technician program the device just as he would for a real-world client – in our case, as an HVAC controller. Our strategy quickly became what is often referred to as a replay attack. As an example, if we wanted to determine how to tell the device to flip a switch, we would first observe the device flipping the switch in the “normal” way and try to track down what code had to run for that to happen. Next, we would try to recreate those conditions by running that code manually, thus replaying the previously observed event. This strategy proved effective in granting us control over every category of device the eBMGR supports. Moreover, this method remains agnostic to the specific hardware attached to the building manager. Hypothetically, this sort of attack would work without any prior knowledge of the device’s configuration.
The result was an attack that would compromise any enteliBUS Manager on the same network and attach a custom piece of malware we developed to the software running on it. This malware would then create a backdoor which would allow the attacker to remotely issue commands to the manager and control any hardware connected to it, whether it be something as benign as a light switch or as dangerous as a boiler.
To make matters worse, if the attacker knows the IP address of the device ahead of time, this exploit can be performed over the Internet, increasing its impact exponentially. At the time of this writing, a Shodan scan revealed that over 1600 such devices are internet connected, meaning the danger is far from hypothetical.
For those craving the nitty-gritty technical details of how we went about accomplishing this, we also published what is arguably a novella here that delves into the vulnerability discovery and exploitation process from start to finish.
In keeping with our responsible disclosure program, we reached out to Delta Controls as soon as we confirmed that the initial vulnerability we discovered was exploitable. Shortly thereafter, they provided us with a beta version of a patch meant to fix the vulnerability and we confirmed that it did just that – our attack no longer worked. Furthermore, by using our understanding of how the attack is performed at a network level, we were able to add mitigation for this vulnerability to McAfee’s Network Security Platform (NSP) via NSP signature 0x45d43f00, helping our customers remain secure. This is our idea of a success story – researchers and vendors coming together to improve security for end users and ultimately reduce the attack surface for the adversary. If there’s any doubt they are interested in targets like these, a quick search will illuminate the myriad attempts to exploit industrial control systems as a top target of interest.
Before we leave you with “all’s well that ends well”, we want to stress that there is a lesson to be learned here: it doesn’t take much to make a critical system vulnerable. Thus, it is important that companies extend proper security practices to all network-connected devices – not just PCs. Such practices might include placing all internet-connected devices behind a firewall, monitoring traffic to these devices, segregating them from the rest of the network using VLANs, and staying on top of security updates. For critical systems that cannot afford significant downtime, updates are often pulled instead of pushed, putting the onus on end users to keep these devices up to date. Whatever the precise implementation may be, a good security policy often begins by adopting the principle of least privilege, or the idea that all access should be restricted by default unless there is a compelling reason for it. For example, before approaching the challenge of keeping a device like the eBMGR secure on the internet, it’s important to first ask if having it connected to internet is necessary in the first place.
While companies and consumers should certainly take the proper steps to keep their networks secure, manufacturers must also take a proactive approach towards addressing vulnerabilities that impact their end users. Delta Controls’ willingness to collaborate and timely response to our disclosure certainly seems like a step in the right direction. Please refer to the following statement from Delta Controls which provides insight into the collaboration with McAfee and the power of responsible disclosure.
The post From Building Control to Damage Control: A Case Study in Industrial Security Featuring Delta’s enteliBUS Manager appeared first on McAfee Blogs.