Avoiding Shellshock In The Cyber Battlefield

Newly discovered security flaws in Unix-based systems affecting SCADA deployments should be fixed before an attack is launched.
Published: Tue 28 Oct 2014

With increasing awareness of cyber security, more and more vulnerabilities are appearing in the standard IT packages that are being deployed in the energy sector and other critical infrastructure applications.

One such example is Shellshock – aka Bashdoor – which is a series of security vulnerabilities found in the Unix Bash shell program used by Linux and other operating systems such as BSD, Solaris and Mac OS X – all widely used in electrical and other infrastructure installations.

Revealed just a few weeks ago, these vulnerabilities have been around for a good 20 years or more – but as far as is known, had not been subject to any form of attack prior to disclosure (subsequently, more than 17,400 attacks were recorded in the first 24 hours).

“It’s good that we are seeing more and more standard practices and components from the IT industry in the energy sector, but we need to be aware of the associated risks,” explains Ilan Barda, CEO of the Israel-based security solution provider RADiFlow.

RADiFlow has just released a security report on Shellshock and introduced a signature to recognize it in its security gateway.

Shellshock in the energy sector

Barda explains that the initial focus with Shellshock has been on big servers, where Unix with the Bash package is most commonly used. In the energy sector, typical applications would include SCADA and other automation and OT systems, such as RTUs, PLCs, IP cameras and storage devices that sometimes use the Linux operating system.

Once the package is embedded in the software, the device may then be reached in multiple ways, Barda continues. These include HTTP, i.e. the web interface used to manage the device, SSH communication, and DHCP, which is commonly used for device registration.

“Any of these may be used to attack the device by getting access to the internals, enabling changes to the firmware or configuration, deletion of content, etc., or even taking full control of the device,” says Barda. “For example with the Stuxnet virus of 2010 the first critical step was updating the firmware of the PLC so it would damage the devices.”

Dealing with Shellshock

Barda says that following the disclosure of Shellshock, Unix vendors came out with relevant patches, while the classical enterprise security vendors provided signatures to identify the vulnerability.

However, patches aren’t necessarily practical, he notes. Generally it isn’t possible to do an update to operational networks on a crash basis, as it may create more problems than it solves, and normally this would need to be scheduled, potentially several months ahead.

RADiFlow’s answer is in its secure communications gateway, which is deployed at remote locations such as substations, with a built-in security engine that does service aware validation of multiple communications protocols utilizing a unique Deep-Packet-Inspection Firewall. “Initially our focus was on analyzing all the classical SCADA protocols as these are inherently insecure. With Shellshock we found we can use the same procedure to analyze the management protocols and to identify and block a Shellshock attack.”

Cyber security looking ahead

Barda says that this is unlikely to be the last such vulnerability to be identified – prior to Shellshock was Heartbleed – and the next one is likely to be barely months away – and most likely it will be of a similar type exploiting an internal vulnerability.

To minimize the risk of attack, some security best practices include:

  • To achieve adequate protection, there is a need for multiple distinct layers of defence. Even with a security layer such as the RADiFlow gateway, any software patches should also be installed so that the latest software version is in place.
  • Once a vulnerability is found, it is expected that attackers won’t waste time. Fast patching is imperative but might not be realistic for critical utility devices, and preferably security should be implemented in a separate device in which the firewall rules can be easily updated.
  • As the attacks get more sophisticated, a service-aware analysis of the data-flow is required in order to detect them. A standard L4 firewall will open valid data sessions for operational purposes that might be used by the attacker acting as an insider to inject malicious commands.

Barda also reiterates the need for physical security of assets, which can be as important as the cyber security protection.