Ignition Vulnerability Advisory Published by ICS-CERT

I don’t know how I missed writing about this before now, I mean the headline is incredibly catchy, but last Friday the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published an advisory about an information disclosure vulnerability in Inductive Automation’s Ignition software. The vulnerability was discovered by Ruben Santamarta and it allows unauthorized users to remotely download system and project information (including authorized usernames and password hashes) via a simple connection to a specific URL address.

Inductive Automation has developed an upgraded version of the Ignition software which is available for download.

I’m always amazed at the ability of security researchers to discover these vulnerabilities in complex control system software. It takes a peculiar twist of the mind to be able to read code as if it were one’s birth tongue rather than a foreign language learned late in life. My hat’s off to Ruben for the effort and ability that went into discovering this obscure but potentially devastating vulnerability. I’m glad that he’s working on the disclosure side of that skill set, not the exploitation side.

BTW: Yesterday ICS-CERT published an update of their Siemens PLC vulnerability summary advisory that I discussed earlier. They corrected an apparent typo on page 8; substituting the word ‘interoperability’ for ‘inoperability’. Interestingly this is one of the specific sentences in the advisory that Ralph Langner took objection to in his blog post criticizing this advisory and somehow he read it the way that ICS-CERT intended it to read (as corrected here) not how it was actually published.

How Simple Can Stuxing Be?

Over the last week or so I have been talking about how easy random stuxing of a control system could be. Yesterday Ralph Langner, the man responsible for identifying the man-in-the-middle component of the Stuxnet attack, demonstrated in his blog just how easy that attack could be. He provided us with just 4 lines of code for a Siemens PLC that would shut down the output of the PLC on a predetermined date.

This is, in effect, the bullet that an attacker would use to Stux a control system. Additional code could be hung on this bullet to make it more effective, but this could certainly disrupt manufacturing operations.

If this is the bullet, the attack still needs a method of getting it to the PLC. Ralph shares some thoughts on how that could be accomplished, but it is clear that little more than access to the network upon which the PLC resides is all that is required to deliver that bullet to the intended target.

Stuxing is moving just this much closer to reality.

Ralph Langner Review

Readers of this blog will be well familiar with the name of Ralph Langner who has done so much work on decoding the targeting tools of the Stuxnet worm. I’ve written about his blog posts on a number of occasions. Well, Ralph has finally combined his descriptions of the various parts of that worm into a single article available at ControlGlobal.com. While this article was written for control systems engineers (and thus contains a lot of ‘code injection’, data block names, and other technical information) in my opinion the most important part of the article is the less technical discussion found in the last section.

Once again Ralph makes a very strong case for his warning that the Stuxnet codes can be re-used by skilled attackers. This could allow them to craft new attack codes that could be used to attack completely different process systems. He explains that the most effective attacks would still require similar levels of target process knowledge, but that generic attacks could be executed with next to no process information. I have discussed both of these possibilities in earlier blogs, but Ralph’s technical background and detailed Stuxnet knowledge lends much more credence to this prediction.

Ralph provides a very brief description of what he thinks it will take to defend against these Stuxnet-like attacks. He briefly dismisses ‘defense-in-depth’ because it doesn’t address the issue of controller compromise. I think this dismissal may be a little overdone because these techniques may make the compromise of controllers more difficult. But Ralph is correct, current cyber security measures do not specifically prevent controller level problems.

Ralph does, however, provide a brief description of a more effective preventive measure:

“The most effective prevention of controller hijacking would be digitally signed controller code and configuration. With today's technology, this can be implemented easily [emphasis added]. It can be expected that controller vendors will see this as a major business opportunity because the outlook to replace millions of controllers before end-of-lifetime with upgraded product versions means a multi-million dollar market.”

Since English is a second language for Ralph (though he uses it better than many native speaking bloggers) it is hard to tell if the use of the term ‘implemented easily’ is sarcasm or just grossly understating the difficulties involved. He does mention the cost of the controllers, but completely ignores the process upsets that whole sale replacement of controllers would cause.

I do love the final sentence of the article, though. Ralph writes:

“Less efficient, but much cheaper solutions have just become available that detect and report configuration and code changes of network-attached S7 controllers.”

Readers of this blog will remember that Ralph’s company is the one that is selling this ‘solution’. Ralph has been clear that it does not prevent someone from modifying controller programming, but it does alert the user to any such change, hopefully allowing the controller to be shut down before there is any serious damage done to the process. Of course, in many chemical processes that shutdown may cause serious repercussions.

Recommendation

In any case, anyone that is responsible for security of control systems ought to read this article. I also think that congressional staffers working on cyber security legislation also need to take note of what Ralph is talking about. We can no longer afford to ignore control system cyber security when we discuss protecting computer systems.

Langner Introduces New ICS Malware Mitigation Tool

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.

Stuxnet Target to be Announced

Both Dale Peterson at DigitalBond and Walt Boyes at ControlGlobal carried a bit of interesting news today; it seems that Ralph Langner, a security researcher in Germany, has come up with some interesting information. Unfortunately neither Walt nor Dale can tell us exactly what that information is. All that they can tell us, all that Langner’s web site tells us, now is that Langer believes that Stuxnet was targeted at a specific control system installation.

Announcement Next Week

In many ways it is entirely appropriate that Langner will be announcing the target (with supporting details) next week at the 10th ICS Cyber Security Conference in Rockville, MD. It is appropriate that it will be announced here since the conference organizer, Joe Weiss, has been the person who has been the point man for industrial control system cyber security for so many years. There are many others in the field now, but Joe was the one who was singing ICS Security when ICS Security wasn’t cool (I’m sorry, I couldn’t resist).

I’m sure that Weiss and Langner will have much to say next week about what all of this means. Depending on the target, this could explain how this complex worm/malware came to be developed; whether it was for industrial sabotage, revenge for a real or imagined corporate slight, or maybe even a State attack on a foreign weapons development project.

Stuxnet Consequence

In any case, it doesn’t alter the significance of Stuxnet; in fact it enhances it. Before it was the first malware to specifically target an ICS system. While it may have been designed for a specific attack, it has spread (as these things do) and it is in the wild and will almost certainly be modified for use in other attacks. In short, no one can say any longer that industrial control systems are immune from a cyber attack due to their complexity; the threshold has been breached.

We’ll watch the Tweets and posts from next weeks conference with real interest. Even Joe couldn’t have asked for better publicity for a security conference than this.