The Spread of Stuxnet

I have been following Stuxnet since news became generally available last summer. I thought that I had a pretty good understanding of the general operation (but certainly not the technical details) of Stuxnet and readers have probably gotten the idea that I have been pretty concerned with the potential threat that this worm presents for the future. Realistically I have only been mildly concerned, that is until I read a recent paper published on-line by Byres, Ginter and Langill entitled: “How Stuxnet Spreads – A Study of Infection Paths in Best Practice Systems”. Now, I’m officially very concerned.

An Overview of the ‘Attack’

What these three men have done is taken the known information about how Stuxnet operates and applied that to a theoretical industrial control system that is following the current ‘best practices’ security guidance for that system. Using that knowledge and that construct they determined the routes that Stuxnet could use in the system to get from an attacker to a specific PLC to do its dirty work. As if that weren’t enough, at each step of the spread of the infection, they posit additional pathways that could have done the same thing.

Take for example, the initial attack vector, the zero point of the attack. Their main proposal should not surprise anyone; it is very similar to what has been assumed in the standard discussions of the Stuxnet worm – an infected USB. Their attack starts with (pg 14):

“In our primary scenario, a company employee returns from an off-site visit to a contractor’s facility with an infected USB flash drive. The employee has been given the infected drive deliberately by a saboteur employed at the contractor facility.”

The alternatives get a little more creative. The final one deserves special mention for reasons that will be obvious later in this blog. They propose a spear phishing attack with an email carrying an infected attachment. They even went so far as to “construct a proof-of-concept dropper for of Stuxnet that is based on an infected PDF”. That is scary thoroughness.

That’s the last I’m going to describe of the details of their analysis of the transfer mechanisms for the Stuxnet attack. You can (and should) get the document yourself and read their analysis. It’s free (registration required) from the Tofino Security web site (Abterra Technologies, and SCADAHacker.com link back to the Tofino site). I know that there have been some complaints about requiring a registration to read the paper, but it is a very small price to pay for an important piece of Stuxnet explication. Besides, if you’re really worried about compromising your privacy, just use a disposable email address and then never use it again.

Stuxnet and Night Dragon

The authors make the point a couple of times in this paper that the system they are describing is using the commonly accepted best practices available and suggested for that system. They also note that very few SCADA systems are protected as well as the construct that they use for their analysis. Given the business that each of these gentlemen are involved in, one might be forgiven for assuming that that claim might be a little self-serving.

That is, except for the recent report released by McAfee on the multi-year Night Dragon assault on multiple, large oil and gas company cyber-assets. The Night Dragon report makes it clear that even the largest companies, ones with the resources (both financial and technical) necessary to protect those systems, were sadly lacking in their ability to prevent the compromise of their cyber assets by relatively unsophisticated attack tools.

One of the many routes of entry into the cyber security perimeter described in the Night Dragon report is the spear phishing attack on various personnel within the organization. It is always amazing how effective these targeted email attacks can be. And remember that Stuxnet dropper in a .PDF file? What better attack vector in the real world.?

If you were to read these two reports, back-to-back, like I just did, you would be struck by just how vulnerable our industrial control systems are to a concerted attack. “How Stuxnet Spreads” shows how easily the worm could navigate a well protected (at least compliant) system. Just imagine how quickly it would spread through a system that was not compliant.

ICS-CERT Reviews 2010 in Cyber Security

Yesterday the DHS Industrial Control System Cyber Emergency Response Team (ICS-CERT) published a review of cyber security activities in 2010. This provides a quick overview of significant events in control system security from the point of view of ICS-CERT. As one would expect, Stuxnet receives prominent mention but the substantial increase in the discovery of vulnerabilities in control system software is mentioned only in passing.

Stuxnet

Many people have expressed concern over the last six months or so about the lack of detailed information on the Stuxnet worm coming out of ICS-CERT. The discussion of Stuxnet in this document will hardly improve their image with regard to Stuxnet. In fact the authors of this review will have actually aggravated the problem by stating in the ‘Lessons Learned’ section that: “Timely information sharing of threats and analysis is of chief importance in empowering and protecting public and private sector partners.” Hopefully ICS-CERT has learned this lesson.

Actually, the most valuable information on Stuxnet in this publication is found in the “Stuxnet Specific Resources” section found on the last page. Interestingly, ICS-CERT provides the Symantec “W32Stuxnet Dossier” the primary ranking (by listing it first) as source of information above the two ICS-CERT documents that have been criticized by many control system security experts as being very weak sources of information.

Fly-Away Teams

The year in review looks at the establishment of fly-away teams to assist asset owners in responding to actual cyber security incidents. Beyond the basic discussion of these teams, the ‘Lessons Learned’ section deserves special attention by the control system community.

• Many asset owners reported that they were not aware of the resources available to keep them informed of current threat information or vulnerabilities to ICS.

• A common understanding of the potential impacts of cyber vulnerabilities (loss or degradation of process control, loss of sensitive information, etc.) does not exist across all CIKR sectors.

• Asset owners need to employ consistent management of privileges on their networks – who has which privileges and on which part of the network they apply for each individual.

• Forensics analysis is enhanced when the organization has established a baseline dataset for network configuration and typical traffic; this allows for more effective identification of intrusions.

• Asset owners need to develop adequate policies and procedures to educate employees and reduce the potential of unintended cyber incidents resulting from untrained workforce.

Recommendation

I really do recommend that anyone with an interest in control system security read this document. It does provide some brief yet interesting discussions and the various ‘lessons learned’ listings provide some very concise, yet appropriate pieces of information about cybersecurity for control systems. It won’t directly make your security program any better, but it will provide a good list of talking/thinking points.

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.

Political Look at Stuxnet

Last week the folks at SCADASEC List published a link to a new look at the Stuxnet worm from an unusual source, the Congressional Research Service. Members of the technical community will find no new information in this report, but it wasn’t written with that community in mind. Rather than being a technical paper, the CRS has prepared an analysis that looks more at the political implications of this attack.

The CRS Report, “The Stuxnet Computer Worm: Harbinger of an Emerging Warfare Capability”, summarizes the publicly available information about Stuxnet without delving into a significant level of technical information. So it quotes from news reports and white papers from Symantec and ESET, but ignores work by researchers like Ralph Langner.

The writers of this paper have been careful to provide a reasonably balanced approach to presenting the various viewpoints of the Stuxnet discussion. It notes that some industry observers mark Stuxnet as the effective start of cyber warfare, while others believe that the risk of attacks on cyber control systems is overblown in the discussion of Stuxnet. It addresses the issue of the potential sources of Stuxnet without reaching any conclusions.

It addresses the issues of whether or not Congress should pass legislation regulating the security of industrial control systems without making a definitive statement of whether or not such legislation should actually be introduced, or what form that regulation might take. Of course the CRS is not supposed to advocate legislative action, but to provide the information that legislators would need to take such actions.

From a political viewpoint, this is a slightly disappointing report. There is no real discussion of the potential options that legislators have in defining the types of regulatory schemes that they might consider in the coming 112th Congress. To be fair, there has not been much talk about legislation for regulating ICS security. To date there has only been one bill, HR 6423 (there was another bill introduced last week that may address the issue, S 4021, but I have not yet seen an actual copy of the bill), that specifically addressed ICS security issues. It would have been helpful if the provisions of that bill had at least been mentioned as a possible legislative response to the issue.

This document will have little impact on congressional discussions this year. There are just too many high-profile controversial issues remaining on the plate of the lame duck session of the 111th Congress for ICS security to be actively considered. This document will be useful to Congress when it comes back with new faces and new agendas in January.

Stuxnet Secrets

Ralph Langner has an interesting post on his blog that discusses his recent interview conducted by Dale Peterson over at DigitalBond. In his own blog post, Ralph makes an interesting claim about why the DHS ICS-CERT people have not been more forthcoming about the research that they have conducted on the Stuxnet malware; he says the reason is that the information is classified. In fact, he says the fact that it is classified is, itself, classified. He says the reason that everything is so classified is that disclosing the classification of the research “would be evidence for US participation in Stuxnet.”

Now I have gone back and re-read Ralph’s words a number of times and he doesn’t ever really say that the ICS-CERT people had anything to do with the development of the Stuxnet worm, just that their post-release research is classified. I don’t know how Ralph reaches this conclusion, he doesn’t say.

Classified Information

Before I go any further lets talk a little about classified information in general. First there are a number of different reasons that something might be classified. Generally speaking information is classified because the release of the information could jeopardize National Security.

The reason for that can be quite apparent, for example codes used to transmit classified information must be kept classified. Failure to do so could result in someone being able to decode the information. Most often, the encrypting keys are classified, but the general method of applying the keys may be less critical.

The military used to use (and may still use) an authentication table to allow individuals to prove they were the good guys when transmitting information in the clear. How the authentication table was used was not classified; it was taught to every solider in basic training. The actual tables that changed every day were, however, classified.

Now other types of information are even more sensitive. The very existence of the information is vital to national security. The classic example from World War II is the development of the atomic bomb. The very existence of the Manhattan Project was a carefully protected secret. Now once the first weapon was deployed against Japan, the existence of the program was no longer classified; that loud noise, fire, smoke and destruction were just too hard to plausibly deny. The methods of making the modern counterparts of those weapons remains classified today, but not the existence of the weapons programs themselves.

Now if it was a nation-state that developed the Stuxnet malware (suspected but not known or proven) then they would have a very real national security reason for hiding that development. Even after it was deployed, it would be in their best interest for their involvement to remain classified. It would make it harder for some targeted entity to demand reparations, apologies or even seek retribution for the ‘dastardly sneak attack’

ICS-CERT and a Stuxnet Secret

I don’t have any contacts at ICS-CERT so there is no way for me to know how true this claim of Ralph’s is. If I were to ask them as a blogger/reporter, I know what answer they would be required to tell me if they did do classified research (which I would suspect that they might). They would be required to say something to the effect of the classic ‘we can neither confirm nor deny’. Anyone that has handled classified information knows the reason for that answer, but let me lay it out, by looking at the possibilities.

It’s not classified: if the facility does do classified work it can not confirm that something is not classified when asked a question like this. If they do and the same question is asked about a later project that is classified the inability to say that the second project is not classified becomes confirmation that it is classified. Even if the facility does not currently do classified work the potential for doing classified work in the future would require the ‘neither confirm nor deny’ response.

SIDE NOTE: They could of course lie, but lying is almost always counter-productive. It is almost always discovered and the lie is ultimately more damaging than revealing the classified information. Besides, few people can really lie effectively.

It’s classified: the development of a cyber weapon directed at critical control systems would certainly be classified and you never confirm or deny the existence of such classified weapon systems in development. Once deployed a country would want to deny that it had that capability to avoid retaliation. One would disclose the existence of such weapons that rely on a certain amount of stealth capability only after their existence was widely known and clearly traced back to the attacker. Then you just try to keep the details of the weapon system secret.

With cyber warfare becoming ‘the obvious next battlefield’, everyone must assume that the ICS-CERT people are or will be looking at either the development of control system cyber weapons and/or defeating such weapons. Even if they were just working on defensive measures, I would keep that information classified. The delineation between offensive and defensive capabilities in advance technology weapons is very hard to define. And any properly paranoid enemy would have to assume that a defensive lab was actually producing weapons; and that would require their work on a similar weapon.

Alternative Explanation for Secrecy

There is a very plausible alternative reason for a lab like ICS-CERT to keep their research on Stuxnet unpublicized. As Ralph himself has so clearly pointed out, the Stuxnet work has pointed out a couple of major vulnerabilities in the Siemens control systems, and in fact, any control system using modern PLCs. More importantly, Ralph has pointed out that there is currently no real way of preventing exploits of these vulnerabilities if access can be gained to the control system.

Now, if ICS-CERT has located additional vulnerabilities in their research into the Stuxnet malware they have long maintained that they would not disclose such vulnerabilities until they had a chance to work with the vender to come up with a counter to that vulnerability. This is done to protect the control system community against the ‘bad guys’ from using those uncorrected vulnerabilities against systems that could not be protected. They have also said that they would not violate that non-disclosure rule unless there was found to be exploit code available in the public domain or in use in the wild.

Even with people like Ralph and Symantec describing the attack code in Stuxnet, ICS-CERT could use this internal non-disclosure policy to justify not talking about those vulnerabilities beyond the generalities that it has posted on their web site. Again, they would be concentrating on working with venders like Siemens to figure out a way to defend against the vulnerabilities. Once those advanced mitigation/prevention strategies were developed, we would expect full disclosure of the vulnerability as well as the fix.

The CERT non-disclosure policy is not the same as the information being classified though the practical effect may be the same, at least initially. It is no where near as bureaucratic as the security classification procedures. The managers at CERT can, under this policy, change the disclosure status of a particular vulnerability with a simple verbal order. A bureaucratic declassification procedure is not required.

Non-disclosure or Classified?

So which is it? Is a nondisclosure policy directive or security classification preventing the ICS-CERT lab from disclosing the results of its investigation into the Stuxnet malware. Or is it simply a matter of a less than competent investigation not revealing anything worth discussing (as some writers have suggested).

Personally, I seriously doubt the latter; I have no data to support that, it is just my opinion. Similarly I have no data available to weigh in definitively on either of the other two alternatives. I would like to think that it is simply the non-disclosure issue controlling the current situation. There are too many problems with Stuxnet as a weapon for me to want to suspect that the ICS-CERT people had anything to do with cooking it up.

Of course I have been forced to use too much poorly designed military equipment to say that we couldn’t have designed and deployed Stuxnet. I would just like to think that a research organization that we have to rely on helping us to protect our control systems would do a better job of designing a stealthy attack program. It’s not necessarily a rational desire on my part, but it is there.

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.

SCADA Exploit Vulnerabilities

Readers of this blog will have noted that I have been writing more often about identified vulnerabilities in various industrial control systems and even the existence of published exploits to use those vulnerabilities to attack such control systems. Earlier this week I did a posting about the Stuxnet man-in-the-middle attacks that Ralph Langner has identified. On Wednesday Ralph posted a new entry into his blog that builds on the dangers identified in that attack methodology.

Not Patchable

One important point that Ralph continues to make is that we should not be expecting a ‘patch’ from Siemens to ‘correct’ the vulnerabilities used by Stuxnet. He points out that these vulnerabilities are “regular product features that you find in the majority of these systems, regardless of vendor [emphasis added]”. To eliminate these potential attack points is not going to just require a revision of the Siemens soft ware, but also a complete reworking of the programming for each of the millions of controllers currently in place in manufacturing facilities around the world.

It is not realistic to suppose that the multitude of controllers currently in use will be re-worked to avoid the attack techniques that Stuxnet utilized. I’m not sure about future PLC’s (I’ll leave that discussion to the engineers and security professionals), but it is just not practical to make such radical changes to all of the devices currently in the field. It cannot be done piece meal, it will require a simultaneous reload of all control software and PLC firmware in a facility to minimize the risk of compatibility issues. This would make for a very long turnaround time, with extensive (expensive) pre-installation testing and post-installation trouble shooting. Even then, subsequent process problems will be almost inevitable.

Not Limited to Stuxnet

Ralph makes the point that the two attack modes he describes in his Stuxnet analysis blogs are not limited to being used by Stuxnet (they could be carried by other attack vectors) nor are they limited to being applied to just Siemens controlled systems. Since the attacks actually takes aim at the PLC’s not the Siemens work stations, any industrial control system that utilizes programmable logic controllers could be attacked using these two modes.

One of the things that Ralph doesn’t explicitly state in his blog, yet is clearly implicated by his discussion, is that any vulnerability in control systems that allows an attacker to gain system access to allow code injection to the controllers would allow for a Stuxnet like attack on those systems. Ralph does note that the “development tools to aid in the [code injection technique] development are [available] in the wild”.

The hard work has been done. Now all it takes is a reasonably technically proficient person with the necessary intent to launch the next attack on industrial control systems. An attacker without any process knowledge could launch an attack that could randomly disrupt control system operations to the extent that facility shutdown would be required. An attacker with basic process knowledge (from a disgruntled, or cash strapped insider for instance) could cause worst case process upsets resulting in catastrophic failures of processes and/or equipment that could seriously affect the neighboring community.

Stuxnet Man in the Middle Attack

Ralph Langner has been one of the people that have been providing the most detailed looks at the internal workings of the Stuxnet worm. The Symantec people have provided a great deal of data on the worm, but their expertise has been focused on the Windows side of the worm’s operation. That, after all, reflects the nature of their typical cybersecurity work. Ralph has been providing insights into the operations on the Siemens side of the process.

Ralph’s blog has been active on this topic since August, but he has been posting blog entries daily (sometimes twice a day) since November 11th. His postings have been vocal in their criticism of both Siemens and ICS-CERT in the lack of information that they have shared with Siemens users, suggesting that the reason is that neither organization actually knows much about the workings of Stuxnet.

In addition to these complaints, he has been providing a detailed look at the Stuxnet 315 and 417 attack codes. These are the two separate sections of the Stuxnet code that actually cause changes in PLC programming. These two attack modes are so different in their operation that Ralph suggests that they are actually targeted at two completely separate targets in the Iranian nuclear industry.

Cyber security professionals should be concerned about the method of operation of both of these attack codes, but as a process chemist I am much more concerned with the methodology used in the 417 attack codes. So much so, that I have to admit that this attack mode professionally scares the hell out of me. This is because it compromises the chemical process professional’s trust of, and reliance on, data provided by the process control system.

Description of Stuxnet 417 Operations

Ralph takes a number of blog posts (11-15-10, 11-16-10a, 11-16-10b, and 11-18-10) to properly describe the mode of operation for the man in the middle attack. To truly understand the operation you should read all four of these posts by Ralph. I’ll provide a brief summary here (a summary that Ralph is no way responsible for).

In an automated control system the system takes inputs from various process measurements, compares them to the rules provided by the process professional, and automatically directs process equipment to respond appropriately. For instance, a typical process parameter is temperature. Inputs come from various temperature measurement devices in the process. If the measured temperatures are too low, valves are automatically opened to allow heat (via steam, hot water, etc) to flow into the process; when the process reaches the appropriate temperature range the valves are then automatically closed to stop the application of heat to the process. At the same time, the human machine interface (HMI) visually displays the temperature and the process response for that temperature to the human overseer of the process.

As Ralph describes the Stuxnet 417 operation the worm passively records process measurement inputs and outputs. When it executes the process changes programmed into the attack, it replays the normal process data for display in the HMI, allowing the operator and the process historian to see only that data that is expected in normal operation. This effectively prevents effective human oversight of the process or proper diagnosis of the process upset after the attack is over.

Process Implications

One of the biggest benefits of automated process controls in chemical manufacturing is that product quality is much easier to maintain because process variables are maintained through a narrower range than is possible with active human monitoring of those variables. Destroying that control capability via a man-in-the-middle attack like this could financially ruin many chemical manufacturers; increased raw material costs to remanufacture good product to fulfill orders and waste disposal costs are not easily recovered, especially in today’s economic environment.

From a security perspective the process safety implications are even more important. For many chemical processes there are safety limits for process variables as well as quality limits. One very typical limit is process temperature. There are a large number of processes, that if a critical temperature limit is exceeded, it is no longer possible to control the chemical reaction that takes place. These runaway reactions can, in some instances, result in process temperatures and pressures that will result in an overpressure situation that the press commonly calls an explosion.

While these catastrophic failures of process vessels are not technically explosions, the effect of such a failure would be the equivalent of a very large explosive device, potentially larger than even a VBIED. I have worked with military grade explosives and I have seen the results of a catastrophic process-vessel failure. I am much more concerned about a large vessel failure than I am with a typical terrorist bomb.

Process professionals typically understand the risks of these overpressure events and take appropriate precautions. Process controls are designed to prevent temperatures from approaching the runaway initiation temperature. Separate automated safety controls are designed to shut down the heat producing reactions that typically are the cause for these events. Unfortunately, it is becoming more and more common for these safety systems to utilize the same process input devices, computer systems, and often the same software, as the process control system as a cost control measure. Thus the compromise of process data by the Stuxnet 417 attack code could compromise these safety systems as well as the process control system.

Less than Catastrophic Attacks

Most industrial chemical processes that can result in catastrophic consequences only do so during specific, well defined portions of the manufacturing process. This means that a Stuxnet type attack leading to that catastrophic failure will require quite a bit of insider process knowledge. The attacker will need to know the process conditions that would lead to that event, when those conditions could lead to that event and how to identify that point in the process from information available through the process controller.

Terrorists would be expected to be best served by these high-visibility process failures, but there are other potential attackers that could benefit from less than catastrophic process failures. State actors wanting to disrupt opponents critical industrial processes, criminals wanting to extort money or even other companies trying to obtain a competitive advantages could benefit from a less targeted process upset event. Given recent Al Qaeda propaganda to the effect that they intend to conduct economic warfare in their future attacks, even they could be potential beneficiaries of process control attacks that don’t necessitate insider knowledge.

Langner identifies how this would be done. He notes that all “that needs to be done is to blind the legitimate program along with operators by re-playing normal input signals and manipulate outputs randomly”. Such random process changes are unlikely to cause catastrophic events in any but the most dangerous processes. They would almost certainly cause product quality issues. And Langner points out that it is entirely possible that such an attack “can be packaged into an exploit tool that lets attackers assemble an attack by point-and-click”.

To understand how thoroughly this can disrupt a chemical manufacturer (and to a lesser extent any manufacturer that uses process control software) you have to understand how companies that rely on product quality to market their wares deal with off-spec product. First the off-spec material must be isolated so that it cannot be inadvertently shipped to customers. Next an investigation must determine the cause of the quality issue and identify process changes that will prevent a recurrence of the problem. All of this will have an economic cost associated with the effort.

Since the advent of modern process control one of the key tools that the industrial chemist or engineer uses to diagnose process upsets is the Process Historian. This is a data file that collects information from the control system. If the data in the control system is corrupted, then the data in the Process Historian will be similarly worthless for the diagnosis of the problem.

If the cause of the quality issue cannot be determined by a detailed process data review (and it can’t be if the data is corrupted), most companies will resume production, keeping a closer eye on the process. If subsequent random and undocumented process changes are made, there will be additional quality issues (usually different issues), that will cause the isolate and investigate cycle to be repeated with their associated costs. With the actual cause of those problems equally impossible to identify, the manufacturer will have to shut down the process; continued manufacture will be just too expensive.

Prevention is the Key

So, you can see why I am very concerned about the potential for this man-in-the-middle type of attack being used against chemical manufacturing facilities. Similar types of issues are possible in a wide range of industries utilizing process control software. Prevention of these types of attack are key to preventing the occurrence of these quality or safety issues. That means keeping the malware out of the control system is very important. Unfortunately, it seems that that may be very difficult to achieve. I’ll address that in a future post.

Stuxnet Hearing

The Stuxnet hearing yesterday before the Senate Homeland Security and Governmental Affairs Committee was interesting for a couple of reasons. First it was one of the few informational hearings that I have watched where the congresscritters actually seemed to be interested in hearing what the witnesses had to say. Second the only political posturing came from one of the witnesses, none from the questioning politicians.

The Politics

Senators Lieberman (and Collins opted to have their official opening comments entered into the record without reading them, providing more time for the witnesses to talk and respond to questions. There was none of the typical speechifying questions; they were all short and to the point. The questions were intelligent, informed and actually sought information. If more congressional hearings were conducted in this manner, Congress might actually learn some things.

The witnesses all commended the Committee on their work on S 3480 and expressed their support for the legislation. None of them pointed out that the bill doesn’t specifically address the control system security issues that might have something to do with Stuxnet defense or mitigation.

The only real disappointment in the hearing was the testimony and responses from Mark Gandy, the sole industry representative. While Gandy works for Dow Chemical he was actually representing the American Chemistry Council. He could have provided some valuable insights about control system security issues from the user’s perspective. Instead he spent most of his time spouting the standard ACC chemical security political mantra; voluntary efforts, $8 billion dollars spent on security, support for current CFATS program, we have everything under control, etc. The exact same testimony could have been made at any of a number of hearings. It was a waste of the Committee’s time and contributed nothing to the Stuxnet, control system security discussion.

PET PEEVE RANT WARNING: How many times do we have to hear about the ‘$8 Billion dollars that ACC members have voluntarily spent on upgrading their facility security since 9/11’? First off the figure hasn’t changed in two years; surely the expenditures have continued. Second, your opponents don’t care about what has been done, they are interested in specific things they want to see happen, you need to discuss those issues if you don’t want the measures imposed upon you. Finally, in this instance that figure means little, how about telling the world what you have done about control system security.

Stuxnet Information

Sean McGurk, Acting Director, National Cybersecurity and Communications Integration Center, U.S. Department of Homeland Security provided some interesting political theater at the start of his testimony when he held up a USB drive and told the Committee that it contained Stuxnet. If true, I hope he keeps that drive locked up, it’s one drive we don’t want to see go missing. His opening remarks and printed testimony provided a good overview of the current DHS cyber security program and ICS-CERT as well as a pretty good, if brief, overview of the Stuxnet worm.

For those people who questioned what ICS-CERT was doing during the initial phases of the Stuxnet investigation, McGurk told the Committee about the efforts undertaken at INL to deconstruct Stuxnet in their malware lab. He noted that they set up a control system, complete with PLCs to watch what the worm did. It would be interesting to see a report on those efforts to see if they discovered anything that Symantec and Langner have reported about the worm.

I think the most important information about Stuxnet came from Dean Turner, Director, Global Intelligence Network, Symantec Corporation, in response to a question from Sen. Collins (R, ME). Turner told the Committee that there were 1600 unique Stuxnet infections in the US and that fifty of them were in systems that included Siemens control systems components. That is more than three times the last number that I’ve seen reported by Siemens world wide.

I would understand why Symantec would not publicly release the identity of those fifty systems, but I would hope that they have or (at least) will share that information with ICS-CERT. Given the difficulty in cleaning system of Stuxnet, it would be helpful if an ICS-CERT team would help insure that those fifty systems have actually been cleared of their infections.

Process Information

Sen. Coons (D, DE), the Committee’s newest member, asked a very interesting question. Given the testimony about the ability of Stuxnet to capture and report system information the Senator asked if this capability placed trade secrets at risk. All of the witnesses opined that yes, they thought that intellectual property was at risk. McGurk explained that Stuxnet accessed process history files which would allow an attacker to reverse engineer the development of the process.

I think that this issue might have been a tad bit overblown. The amount of equipment knowledge that an attacker would need to reverse engineer the process development from the computer commands sent to the PLC’s is immense. If the attacker had that sort of insider knowledge they would likely already have access to process development information. Besides, process changes are not based entirely on information obtained from measurement tools that are connected to the control systems. A major source of information driving process development comes from lab testing of in-process and final product samples. Without access to that information, there would be no understanding of the reasons that changes were made.

In his response to this question Turner explained that Stuxnet had the capability to install ‘back-doors’ on infected systems and those would allow the attacker to steal design information. It wasn’t clear if he was talking about the reporting capabilities that have been widely discussed in the reports on Stuxnet or a specific feature that could provide a new entrance to future access. If the later is the case, the close inspection of all Stuxnet infected machines (not just control systems) seems to be indicated.

Response to Stuxnet

Michael J. Assante, President and Chief Executive Officer National Board of Information Security Examiners, in his written testimony, provided the committee with a number of important recommendations to help protect critical infrastructure from Stuxnet-like attacks. His testimony should be required reading for every security manager with responsibilities for an industrial control system and for Congressional staffers preparing cyber security legislation for the next session of Congress.

One point that I think demands special attention (particularly when looking at recent SCADA vulnerability disclosures) is the need for a reporting requirement. In his testimony (pg 10) he notes that there should be a requirement for “critical infrastructure asset owners and control system vendors to report industrial control system specific security incidents and the U.S. government must provide up-to-date information to asset owners and operators on observed adversary tactics and techniques, especially when investigations reveal attacker capabilities to side-step or exploit relied upon security technologies.”

Sen. Lieberman asked each of the witnesses if they thought that the response to Stuxnet required voluntary or government mandated programs. Assante was the only one who unequivocally stated that DHS would benefit from additional authority, including a mandate for reporting of incidents. McGert’s reply was a particularly disappointing bureaucratic reply that he didn’t make policy, he just did what he was told. Turner recommended that Congress take measures to shore up the “existing voluntary communications channels”.

The best argument for increased DHS authority came from the representative from the industrial user community, Mark Gandy. He reported that industry was doing just fine thank you with their voluntary efforts, though he did note that the CFATS program would help counter this threat. This head in the sand point of view, if held by any significant portion of the user community (and I’m afraid that it does), provides the best argument of adding vigorous control system security requirements to any comprehensive cyber security legislation. If industry does not now recognize the potential threat to their control systems, and their completely inadequate preparations to prevent such an attack, then voluntary programs will no longer suffice.

S 3480 Status

On a final note, Sen. Lieberman did provide a brief, undetailed (I know that word is not in the dictionary, but I’m sure you know what it means) explanation of why S 3480 has not been (nor won’t be this session) brought to the floor of the Senate even though it has been ordered reported by his Committee. He noted that there were on-going negotiations with other committees with legitimate interests in the cyber security arena. He did promise that the bill would be re-introduced early in the 112th Congress.

When they hold hearings on that bill next year I hope that they bring Mike Assante back to testify. He has the necessary technical background, regulatory experience and the passion for control system security that will help Congress formulate the necessary legal framework for the regulation of industrial control system security in critical infrastructure applications.

Vulnerability Disclosure

Andrew Ginter has an interesting posting on his Control System Security Blog (also posted on the Findings From the Field blog) talking about public disclosure policies for discovered cyber vulnerabilities. This is a recurring topic in the cyber security community, but Andrew adds a new dimension to the discussion after looking at the latest discoveries made by Symantec about the Stuxnet worm. Those discoveries seem to point even more firmly towards Stuxnet being a cyber weapon targeted at Iranian nuclear processing capabilities.

Control System Vulnerability Disclosure

Andrew does a very good job of describing the standard debate between security researchers (those who discover vulnerabilities) venders (those who create and must fix vulnerabilities) and system owners (who might get attacked via the vulnerabilities). I’ll summarize briefly here (and the summary is my fault not Andrew’s):

● Researchers – want their discovery released so that they get full and open credit for their prowess in detecting vulnerabilities.
● Venders – want to keep vulnerabilities quiet as they make them look bad and they have to take people away from new product development to fix something that they have already sold.
● Users – want to know about the vulnerabilities, want them fixed, but don’t want anyone telling potential attackers how to get inside their systems.

Weapon System Disclosure

When a cyber weapon (like maybe Stuxnet) is involved, as Andrew points out, the problem becomes even more clouded. First off we, presumably, add a government or two to the mix of players. The first is the target government and the second is the targeting government. Their motivations in the disclosure debate are even more complex.

When a cyber weapon is covert the government wielding the weapons does not even want its existence disclosed as that would decrease the potential effectiveness. They certainly don’t want the detailed mechanisms of the weapons disclosed as this would make it easier to defend against. And they probably don’t want their identity as the weapon wielder disclosed; it could expose them to retaliatory attacks (and not necessarily cyber attacks either).

There are potential reasons that the targeted government would not want it disclosed that they were the target of a cyber attack. The disclosure of an attack almost requires a knee-jerk requirement for a retaliation; the more effective the attack the stronger the required response. If a government does not think that it has the where-with-all to mount an effective response, it might not want the attack exposed. Or it may want to use a period of non-disclosure for planning and mounting an appropriate counter attack. If it didn’t look like they knew they were being attacked, perhaps the attacker would be less diligent in looking for the counter-attack.

The innocent bystanders, in this case other control system owners not involved in either the attack from either side, also have a complex outlook about disclosure. At first it would seem obvious that they would want disclosure about the attack vector/method so that they could consider deploying defenses to defend their system from similar attacks. The argument against disclosure from this view point is a bit more convoluted, but still potentially very real.

Stuxnet is a large and convoluted piece of software. According to most commentors it required a lot of assets and knowledge to put together and deploy. The list of countries with the in-house expertise to construct this cyber weapon is fairly limited, by some estimates no more than a half-dozen countries; most of whom the United States considers friendly to our interests. That keeps us relatively safe against a similar attack, or at least common wisdom would seem to hold that point of view.

The problem is that ‘weapons’ like Stuxnet, once they are understood, are relatively easy to duplicate and modify; the hard work has been done. The key word there is, of course, ‘understood’. So, full disclosure here would almost certainly increase the number of countries (and potentially groups) that could file off the serial numbers and re-direct Stuxnet type weapons at whom ever they desired.

Pandora’s Box is Open

Unfortunately, Andrew’s valuable discussion is about two months too late. The details about Stuxnet that have been released by Langner and Symantec are almost certainly enough to increase the number of Stuxnet capable countries by a factor of at least two. The cyber weapon arms race has almost certainly begun and there is no non-proliferation agreement.

To make matters worse there is already an international arms market in existence for the ‘small arms’ in this weapons race. There is also a growing ‘small arms’ independent research establishment in existence supporting that arms market. Both will almost certainly realize that scaling up their research and weapons development to the industrial scale is not only possible, but certainly profitable.

We better start building better defenses quick. The offense always has the benefit in the arms race between offense and defense. We better not get too far behind.

Stuxnet and Congress

It is interesting to see that the hearing listings are already starting to appear on Congressional Committee web pages; kind of early coming back from a long recess, especially for a lame duck session. Stuxnet will be one of the first subjects that the Senate Homeland Security and Governmental Affairs Committee will be looking at, with a hearing next Wednesday at 10:30 am EST.

The witness list provides an interesting mix of folks. It includes:

• Sean McGurk, Acting Director, National Cybersecurity and Communications Integration Center, U.S. Department of Homeland Security
• Michael J. Assante, President and Chief Executive Officer, National Board of Information Security Examiners
• Dean Turner, Director, Global Intelligence Network, Symantec Corporation
• Mark W. Gandy, Global Manager, IT Security and Information Asset Management, Dow Corning Corporation

Obviously this will be a high-level policy-review type hearing not an actual look at the nuts and bolts of Stuxnet. This is the first hearing that I have seen that will specifically address ICS security issues, certainly there has not been much in the way of legislation looking at ICS security. Its disappointing not to see someone from Siemens, but at least Symantec will be at the table.

BTW: We are still waiting to see this Committee’s report on S 3480, the Lieberman-Collins-Carper cyber security bill. This report was ordered by the Committee back in June. Nothing in the original version of the bill that specifically addressed ICS security, but we won’t know for sure about the final version until this report is issued. This bill is not likely to be passed in the lame duck session.

Symantec Stuxnet Update

Yesterday, Symantec published the 1.2 version of their Stuxnet Dossier. According to a blog on their site, they have still not been able to identify the actual target for Stuxnet, but they have done some additional work on the “high level the behavior of the PLC code” and have updated their Stuxnet document to include that information.

The updated information is a bit over my head (I was an ICS user not programmer), but it would certainly be of interest to control systems engineers and security experts.

The blogger, Eric Chen, notes that they would have provided some more information on the remaining zero-day vulnerability, but Microsoft has still not provided a patch/update to resolve that vulnerability (a “Task Scheduler privilege escalation vulnerability”) so Symantec will hold off until some future revision of the Dossier to explain that issue.

Another Detailed View of Stuxnet

Thanks to Bob Radvanovsky at the SCADASEC List for pointing me at a new source of detailed information about Stuxnet. He recently posted a link to a blog at ESET.com that is covering Stuxnet in some detail, in fact they recently revised a major paper on the malware.

In many ways this paper is similar to the Symantec paper I recently discussed; it is a very technical discussion about the Stuxnet operation on MS Windows® systems. It does take a little bit different tack on the discussion so it complements that paper. More importantly it includes information on the recently patched escalation of privilege (EOP) vulnerability that previous papers had to dance around. It also has a brief and deliberately vague discussion about the second EOP that has yet to be patched. If for no other reason, this paper is worth downloading for the technically minded just for the discussion of the EOP vulnerability.

I was hoping that I would be able to give the SCADA users in the audience a reasonable explanation of the Key Board EOP that was patched this week by Microsoft (MS10-073). I read the portion of the paper dealing with that vulnerability and quickly got bogged down in the details. Fortunately, Randy Abrams had a really good explanation in his post on the ESET.com blog:

“A flaw in the software that translates what you type on the keyboard to letting the computer know what that was allowed Stuxnet to have more control over the infected computer than it was supposed to be allowed.”

In fact, he does even better in discussing the two latest Microsoft patches for vulnerabilities used by Stuxnet:

“For a normal user, all of the pictures of computer code don’t really matter. What is critical for you to understand is that if you do not apply the recent Microsoft security patches, anyone can hijack your computer using the print spooler attack and the privilege escalation attacks.”

That’s good advice, even if you have to shut down a process to get the patch installed. Of course there is still one other EOP vulnerability that Stuxnet used that is not patched, so many will want to wait for that patch before shutting stuff down to be all of the holes patched at one time. Of course, there will be other ‘zero day’ vulnerabilities coming down the road too with their associated patches.

That’s one of the problems with using standard IT type security measures on SCADA systems, they can be a lot more time-consuming, expensive and painful to implement.

Fake Stuxnet Cleaner

As if Stuxnet were not enough of a problem by itself, now Symantec is reporting that they have found a Trojan ‘in the wild’ that is claimed to clean the Stuxnet infection from a computer. They report that this ‘free software program’ is being offered under the bogus name of “Microsoft Stuxnet Cleaner”. Symantec has tested the program and it wipes out the content of the C Drive and changes file extensions for .exe, .mp3, .jpg, .bmp and .gif so that the files cannot be opened using standard software. Symantec has labeled this as “Trojan.Fadeluxnet”.

That this is apparently being offered as a ‘free software tool’ should be a major warning. Secondly, a legitimate free Microsoft anything would only be available from a Microsoft web site. Finally, a “Microsoft Stuxnet Cleaner” would most likely be included as part of a standard Windows update package, not a stand alone product.

Non-Iranian Stuxnet Targets

Much has been made of the targeting of the Stuxnet worm. The way the worm was constructed it appears by all accounts to target a specific installation with specific Siemens software and a particular hardware configuration. If you are not operating an Iranian uranium processing facility, the popular wisdom is that Stuxnet is nothing more than a minor inconvenience.

There are problems with that assessment. If this was a cyber attack by a nation-state on the weapons program of another nation-state it really seems to be a very poorly directed attack. A covert cyber attack needs to remain covert. If it is discovered, the process upsets can easily be corrected, the computer systems purged of the weaponized worm and the weapons program will proceed with tighter attention to cyber security issues. A publicly identified cyber weapon will delay, but not stop the weapons program; too much time and effort for such a minor effect.

The prolific propagation of Stuxnet is a result of a deliberate design process. The weapon was designed to move through computer systems and networks through a wide variety mechanisms ranging from human intervention (USB drive) to a unique peer-to-peer network updating system. More than anything else it seems to search for computers running either of two Siemens’ software systems used to control a wide variety of industrial control systems.

Everyone has noticed that there appears to be only one specific active target for the worm. If the weapon does not detect a specific programmable logic controller (PLC) configuration, it sits idle; almost as if it is waiting for further instructions. And we know that when ever it contacts (or is contacted) by another infected computer, the one with the older version of Stuxnet gets updated with the newer version’s software instructions.

What if this isn’t a cyber weapon being used by a nation-state to destroy a weapons program? What if this isn’t an incredibly sophisticated yet inept weapon? What if it is something entirely different?

Criminal Tool not Cyber Weapon

Let’s suppose that the most effective portion of the construction of this malware was actually the intended purpose; spread the infection through as many Siemens’ based ICS systems as possible. The attack payload, the instructions ‘targeted’ at Iranian processing facilities, would just be a red herring thrown across the trail. It successfully makes everyone jump to the conclusion that either (or perhaps both) the Israelis or the Americans were behind the ‘sophisticated’ attack so no one is actually looking for the real perpetrators. Even the Americans and the Israelis disbelieve the other’s protestations of innocence. No one seems to be seriously interested in tracking down the perpetrators.

After the initial furor dies down, and the Stuxnet is dissected and analyzed until no one is really interested any more, then a series of new versions could be released at various locations around the world. The new versions would have a slightly different payload and a new C&C address to report to. The new payload would be a set of ‘document and report’ instructions that would collect detailed information about the PLCs connected to the system.

The Stuxnet control organization would then have the necessary information to target attacks against each of the reporting control systems. The programmers would once again modify the payload, this time modifying the instructions for a number of different PLCs at the facility. One of the controllers would be programmed to visibly ‘misbehave’ at a particular time. Shortly there after the facility management would receive a message threatening to disrupt other manufacturing operations unless a fee were paid. The remaining controllers programs would initiate at separate times unless a special stop signal were received. If Stuxnet were ‘cleaned’ from the system then the process upsets would be set to trigger on specific, yet normal, control system commands to the PLC.

How many facilities would pay the protection fee? How many could afford not to? To properly clean this type system, each PLC would have to be taken off-line, erased and re-programmed from a clean system. For most systems this could not be done piece meal, the entire facility would have to be shut down. The reprogramming would also require re-tuning many of the processes a time and resource consuming process.

If the fee were low enough it would certainly look to be a preferable alternative to many managers. After a few facilities inadequately cleaned their control system and had even worse problems after the shutdown, that news would encourage other managers to up their definition of a reasonable fee.

Which is it?

I am certainly not stating that this is the true nature of the Stuxnet worm. I am neither proficient nor connected enough to be able to make that determination. It does seem to me from reading the reports from Symantec and Langner that the obvious answer is just a little off from what we would really expect to see if this were a cyber-warfare tool. I may be expecting too much from a weapon design team, but there are too many unexplained inconsistencies to suit me.

It is time that we considered alternative explanations and tried to determine the consequences of those alternatives. And someone needs to be thinking now about how to deal with those potential consequences. Stuxnet may have been designed as a cyber weapon. If so it was sloppy and left lying around for anyone to pick-up and use.

Anyone that thinks that we won’t be seeing Stuxnet variants targeted at non-Iranian processing facilities is living in a dream world; they need to get ready for the nightmare. The new targets will either be the real targets or just targets of opportunity. It won’t make much difference to the target.

Stuxnet Dossier from Symantec

Thanks to the folks at SCADESEC List for pointing me at today’s Symantec Blog about their release of the W32 Stuxnet Dossier. Symantec has compiled a 49 page document that lists what they know or have been able to learn about the Stuxnet … thing (virus, Trojan, worm, malware; none of these really fits. We may need a new term.). It is a pretty document (good production values) but it is more importantly an important learning tool for anyone concerned with protecting (or unfortunately attacking) industrial control systems.

Perhaps the scariest part of the document comes just before the Introduction:

“While the bulk of the analysis is complete, Stuxnet is an incredibly large and complex threat. The authors expect to make revisions to this document shortly after release as new information is uncovered or may be publicly disclosed.”

Part of this is driven by the need to get this together for delivery at the Virus Bulletin 2010 conference. Part of this is apparently still being driven by the complexity of Stuxnet, and I assume the very real possibility that the unknown design team may have new variants on the way.

At a glance, much of this document is over my head technically. If you are a control system engineer at a high-risk chemical facility (or a power plant, or a food processor, or…..) you probably need to download and read this document; soon. I’ll wade through the technical stuff, I recommend that the rest of the chemical security community does the same.

New DHS ICS-CERT Stuxnet Advisory

This afternoon the DHS ICS-CERT has published a new Stuxnet Advisory on their web site. The new advisory provides three lists of file names that are indications of Stuxnet infection. They can be found in computers with the Siemens software installed, while some can also be found in infected computers without Siemens SIMATIC WinCC or SIMATIC STEP 7 software installed.

Yesterday I mentioned the recently detected transmission route via project files. This alert addresses infection indicators related to these files, noting:

“In infected projects, the malicious *.sav files are stored in the GraCS subdirectory within a project’s root directory. This can occur in compressed or zipped project files. It appears that the malware specifically looks for demo projects commonly installed as part of the WinCC software. If any of these malicious *.sav files are found, it is likely that the malware has injected malicious stored procedures into one or more of the project’s database files. If any of these malicious *.sav files are detected, please contact ICS-CERT for further assistance [emphasis added].”

Stuxnet Transmission

Just a quick note about another Stuxnet transmission technique discovered over at Symantec. Their latest Stuxnet blog describes how infected project files can transmit the malware between computers and even provides a way to re-infect a cleaned computer by running a back-up version of a project file. It certainly seems like the Stuxnet design team wanted to make sure that their toy had staying power. So now Stuxnet can be propagated via:

● USB Stick
● Print Spooler
● Network via P2P
● Project Files

The only thing missing is an email transmission mode via the address book list and the Vulcan Mind Meld. But, research is still on going.

BTW: Symantec has collected all of their Stuxnet blogs at one convenient URL: http://www.symantec.com/connect/stuxnet

Iran and Stuxnet

The Stuxnet malware has finally hit the mainstream media’s radar screen and there is lots of reporting on the Iranian target connection. Many people in the cyber security community are cautioning that the discussion of the Iranian nuclear program being the target of Stuxnet is currently based on circumstantial evidence at best. That makes yesterday’s AP news report about the Iranian reaction even more interesting.

AP notes that “Iranian media reports say the country's nuclear agency is trying to combat a complex computer worm that has affected industrial sites in Iran”. This is a long way from confirming that there have been problems at their nuclear facilities because of the Stuxnet. Of course, since the concept of freedom of the press has never been big in Iran, it would be very surprising if the press, semi-official or otherwise, were to report actual disruptions.

Of course, we already know from Microsoft reports that there have been a significant number of Stuxnet infections in Iran (not the largest number by any stretch, the US still holds that honor). With the recent discussions in the mainstream western press that the Iranian nuclear program was the target, it would be a real head-in-the-sand agency that didn’t worry about what Stuxnet infected computers could do to their nuclear fuel enrichment program.

Iranian Detection of an Attack

If there was an actual cyber attack on Iran’s nuclear program, the government might not have realized that it had possibly been attacked until the Stuxnet discussion hit the mainstream press. The way that Stuxnet apparently works would cause problems that would look like natural process upsets under normal investigations. Process people typically accept that their control systems are doing what they are supposed to do, so it is unlikely that any cyber security experts would have been involved in a process upset investigation.

Since it was just about two weeks ago that the open speculation in the cyber security community in the west started about the Stuxnet target, I doubt that there was wide spread consideration of the attack scenario in Iran. Local cyber security experts wouldn’t have talked much about it because of the black mark it would have left on the appreciation of their capabilities by Iran’s rulers.

With the Stuxnet discussion hitting the mainstream press I think that we can assume that any process problems being experienced in their nuclear program are now going to be re-investigated by cyber security experts. I would bet that the vast majority of those investigations are not going to have any actual cyber component, but the process people will want to be able to explain their process problems on Stuxnet; it would take the pressure off of them.

I don’t expect that Iran has any more cyber security experts than does the United States; probably much fewer. Trying to determine if process problems were caused by Stuxnet, even on systems with an identified Stuxnet infection is going to be very time consuming. It may not actually be possible to make a real determination. If I were designing an attack program, I would include an instruction to erase the offending code from the PLC’s (programmable logic controllers) involved. At this point we don’t know if such a capability was programmed into Stuxnet; we still don’t know that much about all of the capabilities of this malware.

This would not be a good time to be a cyber security expert in Iran. Every process upset over the last year will be blamed on Stuxnet by the process owners (covering one’s butt in a restricted society is a very big thing). The prioritization of investigations is going to be confusing because it will depend so much on the power and influence of process sponsors. Finally, the evidence is probably going to be equivocal at best, so how does the cyber security expert color the final report? Do they admit that they failed the mullahs and allowed an attack to take place? Or do they accept the initial process upset reports as gospel to avoid taking responsibility for the problem?

Iranian Response to an Attack

If and when the rulers of Iran decide that there was an actual attack on their nuclear program, things will start to get interesting. If this were a missile strike on the processing facilities, we would expect navel efforts to close the Straits of Hormuz, Hezbollah terror attacks in Israel and perhaps the United States, and disruptive attacks against US forces in Iraq. Whether a cyber attack would garner the same response is unknown; but it is entirely possible.

There is also the possibility of a more cyber related response to the attack. I doubt that Iran has the current capability to effect a Stuxnet type attack on American or Israeli infrastructure (though you can bet that they are now starting work on such capability). There have been reports, however, of a more conventional cyber attack capability in shadowy jihadist organizations. One should certainly expect that Iran would have that capability in house or in terror organizations that they sponsor.

We could expect to see more denial-of-service attacks against government and private computer systems in the United States and Israel. There would also be more persistent penetration type attacks on IT systems to try to get inside of such systems to damage or disrupt their operations.

We might also see other adversaries of the United States or Israel loan more advanced cyber attack capabilities to Iran. This would allow them to actively test and practice their cyber warfare capabilities with minimal possibilities of direct retaliatory strikes. Whether these capabilities could include attacks on industrial control systems (ICS) is not known; remember Stuxnet was the first such attack, that doesn’t mean it is the only ICS attack vector in existence.

Game Changer

Those of us in the cyber security community (well I’m loosely associated with that community as should be everyone in the chemical security community because of our dependence on computer control systems) has been aware of the potential vulnerabilities of industrial control systems. Because of the lack of apparent attacks on those systems, it has been hard to get the attention of management and regulators. With the public perception of Stuxnet rising, that will no longer be the case. More people are becoming involved in the industrial cyber security debate. It is just a matter of time, for instance, before there is a Stuxnet hearing in Congress.

If we get a response from Iran to an actual, documented attack on their nuclear facilities, then the situation will change once again. There will be a very real, loud, and expensive push to force the industrial control community to secure our cyber boundaries.

Stuxnet and the Future

Late yesterday Dale Peterson at DigitalBond.com posted “[o]ne more Stuxnet post before we move on.” As typical, Dale’s blog post provides us with some valuable in-sight into Stuxnet. I certainly hope, though, that he isn’t implying that this will be the last post on the matter. He has been a good source of updated information about Stuxnet, explaining things that he and others have found out about the operation of Stuxnet.

Stuxnet Response

In this post Dale isn’t really looking at the details of Stuxnet; rather he is looking at how the industrial control system network responded to one of the most creative and complex assaults on system security. In his analysis ICS-CERT and Siemens come off looking bad while Langner Communications and Symantec received some well deserved praise.

Dale’s complaints about ICS-CERT are particularly important. This DHS office is the one charged with supporting cyber security activities in the industrial control sector. Since most companies using these control systems do not have the resources to watch out for, investigate, and formulate a response to sophisticated attacks like Stuxnet we turn to the Government for this type of support.

Dale points at possible political issues hampering a more aggressive public ICS-CERT response to Stuxnet. Unfortunately he doesn’t explain what stopped them from being able to “clear the bureaucratic hurdles required to release more information”. If Stuxnet was actually an Israeli attack on Iranian nuclear fuel processing as Dale and others have suggested as being a plausible explanation for the sophistication of the attack (and I agree that it does sound extremely plausible), then the intelligence community would have been reluctant to see that information released.

That would have been a piss poor (though entirely predictable) reason to restrict the spread of information about Stuxnet. Once Iran was identified as having an unusually large number of Stuxnet infections it didn’t require a great deal of ‘jumping to conclusions’ to start to think that Israel might have discovered a new means to execute offensive operations against a target that they have publicly warned that they intend to attack before Iran could produce a nuclear weapon.

Actually I suspect that the ICS-CERT failure in this situation was more based upon resources and a lack of imagination than the lack of political will. While DHS is a large organization their manpower is spread thin. Their lack of depth is further aggravated by the political necessity of having a huge amount of manpower involved in the symbolic protection of commercial air traffic. We continue to see understaffed agencies ‘protecting’ high-risk chemical facilities, Hazmat pipelines, and toxic freight rail targets. Until those targets are actually hit, the politicians will continue to only provide token monies to support those programs.

Cyber Weapons

As we continue to hear discussions about cyber warfare and governmental cyber attacks, this Stuxnet incident points out a unique problem with cyber weapons, once they are employed in the wild, they become public property. While Langner Communications and Symantec have done some valuable work explaining what Stuxnet does and how it works, we must not forget that every government in the world with a modicum cyber expertise has been hard at work doing the same thing.

Dale touches briefly on this in his posting, but I think that this deserves more attention. The developers of Stuxnet (Mosad, the Russian Mob, a bored pimply-faced kid, who ever) has done the hard work. They developed the tools to attack Siemens-based control systems. Those installed systems will now be forever suspect of being vulnerable to attack. And any government, any large criminal organization, will have access to the tools necessary to execute those attacks.

We are now at the cyber equivalent of August 1945, with the Stuxnet shaped cloud rising on the horizon, proclaiming that the world will never be the same again. If this was an attack on the Iranian nuclear program, the irony is totally appropriate. With the potential ability to conduct anonymous attacks on civilian and military infrastructure at will we are heading into a dangerous new era of international politics.

Unfortunately, it will be the private sector in the United States that will bear the brunt of the damage and cost of this new type of warfare. The targets will largely be owned by private companies and they will bear the brunt of both defending against and responding to the results of those attacks.

The world has become an even more dangerous place and there’s not much we can do about.