There is a truism in information security, and it is that everything will eventually be found to be vulnerable.
I believe the lesson here should be, ‘plan to patch.’ It is tragically common in the embedded device space that vendors don’t take this advice. There is still an awful lot of embedded industrial control systems equipment being manufactured today which has no way to even apply update.
Today’s big news story in the infosec space is the ‘Bash bug’. In a nutshell, the bash bug is a mistake in command-line processing. A lot of embedded industrial control components will end up being affected. Basically, any industrial control system that runs embedded Linux, and which features a protocol that ends up calling GNU utilities will likely be vulnerable. Primarily the vulnerability will affect webservers that allow configuring and reading interesting information from a device, and protocols such as potentially CoDeSys which may end up calling other applications by using a shell for some vendor’s products.
Legally speaking, any control system vendor which sells a device running GNU software has to provide a notice with the device informing the end user what software is in use (and that the source code to said software is available from the vendor). Unfortunately not all vendors play nice by providing this notice. The only real way to know what is vulnerable is to test it.
Digital Bond Labs has a nice test environment with a variety of equipment in various forms of hackedness. One such device is Wago’s 758-870 series PLC. The product runs Linux and includes a version of bash that is vulnerable, as demonstrated above. It also runs an embedded webserver which executes cgi scripts (even calling execve() during some webapp command executions), so we will likely find a way to exploit the bash bug on these systems. Although, this system already has documented backdoor accounts, and Wago has already decided that they will not produce firmware updates for this product, so exploiting the bug here really has no point.
I think that the lessons we can draw from both the Bash Bug and Heartbleed is simply that vendors need to consider security upgrades in their product design. Bugs such as the Bash Bug provide a potential way to gain command-line access to some of these embedded systems. This access may be the only thing preventing unauthorized access to or even unauthorized cloning of a vendor’s product. Vendors owe it to themselves to protect their intellectual property, and owe it to customers to provide patches when the inevitable happens.
Be sure that whatever product you are rolling out to your control systems environment can at least have upgrade applied. Worrying about when you can apply a patch is a much better problem than worrying whether your IDS/IPS rule can be evaded because the patch will never come.
Pumpkin image by kams_world