The Shellshock bug discovered on September 25 was one of the biggest cybersecurity stories in 2014. The bug is a vulnerability in Bash, which is a command shell used heavily in scripting and for when one program calls out to an operating system for certain kinds of services. Much of the attention around Shellshock has focused on how the bug is a threat to cybersecurity in general, lumping all practice areas together. But whereas applying the latest security patches to corporate networks is relatively easy, patching and updating critical control system networks can be a very difficult process.
Furthermore, little information is available about the impact of Shellshock on control system networks, leaving industrial security practitioners unsure of how to protect against these vulnerabilities. So how much trouble are we really in? Industrial control systems cover a huge variety of applications, networking gear and embedded systems. To be affected, a device or computer’s operating system first must have Bash installed:
- While many flavors of Bash are available for Windows systems, Bash is not a standard Windows component and is not installed on most Windows systems.
- The Mac OSX is based on Unix and uses Bash heavily.
- Essentially all Linux systems use Bash heavily.
- Bash is at least an option on all other Unix-based systems. If you run any non-Linux Unix you are probably, but not certainly, running Bash somewhere in the system, if not everywhere.
- A lot of network gear is based on Linux and BSD derivatives nowadays. Most of this gear uses Bash more or less heavily. CISCO has some advisories out for example.
Here are some examples of how a system might be affected:
- Web servers that use CGI scripts, especially the very popular Apache web server, pass information like the ‘user agent’ string to Bash. The user agent string can be set by some browsers, and can easily be set by command-line browser emulators such as ‘curl’ and ‘wget.’ Exploitation of vulnerable web servers is trivial. Exploitation is possible from any IP address with access to send a web request into the web server.
- DHCP clients on Linux, Unix and Mac OS use Bash in various steps of the process of acquiring an IP address and other configuration parameters. Often these DHCP scripts run as root. Corrupt a DHCP server and we can attack every machine on the network that uses DHCP. Don’t bother attacking the real DHCP server; just tell your laptop to become a DHCP server itself. Your laptop runs in competition with the real DHCP server and should eventually be able to attack every machine on the network as each machine makes regular DHCP requests.
- Escalation of privilege attacks on Linux and Unix systems using Bash are possible; there are reports that the CUPS printing system is affected. Modern Unix operating systems generally do not permit setuid scripts, which would make exploitation of the bash bug trivial. But – if we can find a program, like CUPS, that activates other executables by reaching through bash without first resetting all the environment variables, an attacker can use the Shellshock bug to execute commands as another user, or as root.
What does this mean for industrial sites? Well it’s not good news, but we knew that. Specifically:
- Everything with a web user interface that runs on Linux or some other Unix and passes user data into environment variables for a Bash shell (e.g. via CGI) can be trivially hacked by any machine that can connect to the web server. This includes some networking gear, and very likely firewalls, RTUs, PLCs and other equipment. The majority of higher-level software packages with web user interfaces run on Windows, but the fraction that runs on Linux or other Unix OSs has the same risks, particularly if they use CGI scripts.
- All Mac and Linux gear, and most Unix gear, that uses DHCP on industrial networks is vulnerable to attacks from the local network. This is a lower risk vector for control systems, because for decades control systems have been cautioned to use static IP addresses rather than DHCP, and because the most critical control systems are in physically secure areas, providing a degree of protection from random attackers wandering in with their laptops. Physical security is no panacea though. If an attacker misconfigures a trusted insider’s laptop and that insider walks through security and plugs the laptop in, we still have a problem.
- Any Linux or Unix control systems with Bash installed, especially older systems that still use setuid executables heavily, will likely have escalation-of-privilege vulnerabilities. These vulnerabilities require that an attacker gain a foothold on a system first through some other means, and then use the vulnerability to gain root privileges by manipulating environment variables passed to setuid executables such as CUPS executables, that activate additional executables via bash.
Advice as to how to fix this in the control system world is pretty classic:
- Apply software/firmware fixes as they become available, and as the site’s engineering change control discipline permits. As we all know, this is easier said than done.
- If possible, disable the affected functionality. But in this arena, I don’t see a lot that can be disabled. E.g., If there is a web server configured with ‘CGI’ scripts turned on, but the server in fact has no CGI scripts, we can very likely turn off the CGI feature with no impact on the server. But finding how to do this in ‘black box’ PLC’s, network gear and firewalls is difficult, and it is not clear what fraction of any devices have CGI turned on when they don’t need it.
- Apply compensating measures – cyber perimeter security and physical security being the most common.
On the cyber-perimeter compensating-measure side of things, disable all remote access to vulnerable equipment and systems. If it proves really painful doing without access to the data in these systems, consider replicating those systems to corporate networks via Unidirectional Security Gateways. IT can manage the replicas with the latest updates as they become available, while the originals on the sensitive operations networks are updated at the pace dictated by safety, reliability and equipment protection concerns.
And always control physical access to the affected systems. In particular, be deeply suspicious of every piece of equipment that crosses the physical perimeter. Be especially wary of every laptop and every new, used or repurposed computer crossing the perimeter. You may trust the owner or supplier, but that is no reason to trust the equipment she is carrying.
The Heartbleed and now Shellshock vulnerabilities drive home a very old point: all software has bugs, and some bugs are security vulnerabilities, and so in practice, all software can be hacked. Increasingly, industrial control system operators are asking which of their equipment is expendable enough to be protected with only software. Industrial users are increasingly deploying at least hardware-enforced perimeter protections.
This blog was written by Andrew Ginter, from Waterfall Security Website: Waterfall Security Solutions