Our favorite Stuxnet researcher from Germany (since Siemens has been loathe to publish whatever Stuxnet research they might be doing) has come up with a new malware mitigation tool that addresses the primary target of the Stuxnet virus (no, not Iranian nuclear facilities), changes to PLC programming. He announced the availability of his Langner Controller Integrity Checker
in his blog this morning.
Inherent PLC Vulnerability
Ralph argues that the biggest threat from Stuxnet was not the numerous zero-day Windows vulnerabilities, which (but for one) have been corrected, but rather the public exposure of a serious design flaw (in hind sight) in almost all controllers in use today; they accept programming changes from too many sources. He fears, as do a number of people (myself included, for what that’s worth), that now that this flaw has been exposed it will be too tempting a target for the hacker community in general and those with specific reasons to target industrial control systems.
Langner has stated in a number of his blogs that this vulnerability is not a bug that can be patched. It is an inherent part of the design of the PLCs and the systems that control them. If this is true, then the only way to eliminate the problem is the wholesale replacement of the PLCs currently in use. Given the long product lifespan of these devices, their cost and the process cost of their replacement, this is not likely to happen (completely) for decades.
Now I’m sure that PLC venders and control system software venders are coming up with software fixes to this vulnerability. I would bet that they will focus on some form of limiting the communications between the PLC and the outside world. Given the complexity of many of the installations and such software fixes are going to be hard to implement and such large scale changes in communications protocols will probably wreck havoc with many industrial processes.
Mitigation not a Preventative
Ralph is careful in his blog post to state that the CIC will not prevent unauthorized re-programming of the PLCs. Apparently he does not want to tempt fates by fiddling with the communications protocols. Instead, he claims his device will alert on changes of the programming. This would allow a system administrator to note the change and decide if it was an authorized or an unauthorized change and take the appropriate responsive action.
I am not technically qualified to evaluate the effectiveness of Ralph’s new tool, nor does he provide anything in the way of technical details on how it completes the checking process. So, lets assume for the moment that it performs as advertised (which is probably a safe assumption, Ralph’s reputation is on the line after all) let’s look at what it could accomplish in a couple of different scenarios.
First we will start with an attack similar to the Stuxnet 417 attack code that Ralph described in some of his earlier blogs. This is a sophisticated attack designed to produce some sort of catastrophic process upset. To be effective the attack process change would have to wait for a specific set of process conditions to existed before it would implement its attack coding.
The CIC warning that Ralph describes in today’s blog would be most effective against this type of attack. It would provide an alert of the change in programming in, presumably, enough time to shut down the process before it reached the target process conditions and the process catastrophe would be averted.
Ralph has also previously described an unsophisticated attack where random changes were made to the PLC programming. This type of attack would not take any sort of detailed process knowledge or even understanding what the PLC programming actually does. It relies on the complexity of modern processes to ensure that random changes would produce random process upsets that would be economically disruptive.
The way Ralph describes the CIC tool, it does not seem to me to be very effective in preventing the intended damage from this type of attack. The alert that PLC programming changes had been made will result in an unscheduled process shut down, but this is precisely the targeted industrial behavior desired. To be fair, shutting down the process before the random change was executed would probably prevent the production of off-spec product or causing some sort of random safety problem.
Still I think that most process managers would rather have the option to shut down a process before someone’s attack code caused a process disruption. Not only that, but the alert would specifically tell the process management team what device was now ‘defective’. This would eliminate much of the need for an incident investigation to determine the source of the problem. A security investigation would still need to be completed but that would have been an add-on to the incident investigation in any case. It would still be a significant time and resource savings.
PLC Root Kit
Ralph does not talk about how this tool would deal with the issue of the root kit that was included in the Stuxnet attack. That root kit was advertised in the early investigation reports on Stuxnet as hiding the actual PLC programming changes from potential discovery by facility process investigators. I’m wondering how this tool deals with that issue.
Langner does say in his blog that the CIC tells you what changes have been made, simply that changes have been made. It might be that while the root kit can hide the details of the change that there is some sort of change signature that Ralph’s software detects. Actually that would make sense since he makes the point that the tool does not keep a copy of the PLC programming on file to check against.
This could mean that the Stuxnet style root kit does not hide this ‘change signature’ (my term not Ralph’s) so that it would not affect the operation of the CIC tool. Of course any respectable black hat will now start looking for that signature to see if there is a way to disguise it as well. Well, that’s how people like Ralph will stay in business; it is ever a competition between attackers and defenders.
Political Note
At the very end of Ralph’s blog post there is a single sentence that speaks volumes (sometimes I wish that I had Ralph’s command of the English language). He says, simply; “Export restrictions apply.”
This is, of course, not uncommon with security software. Presumably, though, this also specifically directed at potential customers in Iran. The EU’s restrictions on support for their nuclear industry would almost certainly apply to this software package. After all, everyone ‘knows’ that the target of the Stuxnet was the nuclear program in Iran and preventing such attacks in the future would not be in keeping with the avowed policy of preventing Iran from producing nuclear weapons.
Posts
