Analysis: Stuxnet dissected

The first clue something had gone horribly wrong would have been the noise.

Engineers working on Iran's nuclear enrichment program would have grown accustomed to the usual hum of the many hundreds of motors running its centrifuges, which spin at high speeds to enrich uranium gas.

Without warning, at some time in the middle of last year, those centrifuges were likely to have spun uncharacteristically faster for 15 minutes. The change in frequency would have been noticeable to the layman - to the engineers, it would have been deafening.

They no doubt would have stared at their screens and at each other - had someone made a mistake? There would be a scramble to upload new instructions to the system - to correct whatever error they thought they made earlier - only to find that the code running on the machine didn't match what they could see.

No matter what code they would upload, the machines wouldn't respond to their new commands.

It is highly likely the centrifuges - spinning well beyond their usual limits - would have shredded, with shards of metal piercing the soft aluminium sheaths that surround the cascades.

Engineers may have panicked and flicked a kill switch to dump the uranium before worse damage could be done.

The extent of the damage will probably never be known to those outside the enrichment program. The Iranian Government has admitted to its nuclear enrichment program being set back by the Stuxnet virus  - but has not gone into a great amount of detail.

Thankfully, there is a great deal we do know - based on an excruciatingly detailed analysis of the Stuxnet worm by the Symantec Security Response team.

Stuxnet was - for a number of reasons - one of the most fascinating and sophisticated computer hacks in history.

Kevin Hogan, senior director at Symantec Security Response, devoted some of his best resources over the latter part of 2010 and early 2011 to reverse-engineering the threat to understand what precisely happened.

Read on to part 2 to discover the genesis of Stuxnet.

Realising the threat

Speaking to iTnews.com.au in Tokyo, Hogan pointed out that the IT security community had taken note of some of the vulnerabilities exploited by Stuxnet as far back as late 2008, but could not have been certain how the threats could combine to such dramatic effect. Stuxnet used four zero-day exploits to achieve its authors' goals.

The IT security community had recognised the first few attempts Stuxnet's authors had made to infect its target but it took time to understand the ramifications.

The first wave variant - compiled on June 22, 2009, attempted to use the Autorun vulnerability and removable drives - but for whatever reason, the worm wasn't viral enough to meet all of the authors' goals. Another attempt was made with a second wave last March.

The rest of the world only discovered something was going on when Stuxnet's authors changed tactics.

Last July 12, VirusBlokAda discovered malware using the LNK vulnerability. Unlike the Autorun vulnerability, LNK had the capability to be extremely promiscuous. IT security vendors had to sit up and take notice - VBA had found a vulnerability that could have big ramifications for customers if left unpatched.

Seeking a sample of the code VBA had caught, researchers at Symantec's Security Response Team noted "some odd strings in Stuxnet," Hogan said.

"There were little snippets of text that referred to Siemens Step 7 [software used for industrial control systems]. There were also sections of the file that contained something that didn't look like normal compiled windows code."

That odd-looking code had the quantum leap Stuxnet's authors achieved - a capacity to cause change to physical systems by infecting the target's industrial control systems.

The security response team then 'sink-holed' or traced the two command-and-control servers for Stuxnet by gaining permission to redirect these domains to IP addresses in its Dublin response centre to log the information coming back from infected machines.

"We now had the opportunity to understand Stuxnet in the field," Hogan said.

The team noted that most victims of the new worm were on PCs in countries that wouldn't otherwise make up the lion's share of activity - places like India, Pakistan and Iran.

This was a strange attack.

It became very obvious that the threat was directed at Iran, at users of a specific Siemens industrial control system. The data showed that 58.31 percent of infections were in Iran, but once that number was adjusted to only include such Siemens users the worm appeared to target, that rose to 67.60 percent.

The data presented a peculiar challenge for Hogan - already he could see that the malware was more complex and targeted than most of the exploits his organisation was paid to shield users from - but it was very new and very fascinating.

"I had to approve putting senior resources into this - and there was that fear, maybe we are spending time and attention on nothing," he said.

But as the code was pulled apart, these fears were put to rest.

It became apparent that Stuxnet had not just been designed to attack systems using Siemens' S7-315 and S7-417 PLCs (programmable logic controllers), but specifically users of this technology that had a precise number of machines set up in a combination of which only Iran's nuclear enrichment program could be a match.

The data suggested to Symantec that there were five primary targets or root nodes that were Iranian commercial entities, working in engineering control systems and many infections elsewhere in the world (40,000) that Hogan believes were collateral damage.

The five facilities were attacked over three attack waves, Hogan said. Some targets in Iran had been hit in the first few waves and one was hit by all three.

Click to the final page to discover the five steps Stuxnet took to pwn Iran's nuclear program.

So how did Stuxnet do the damage?

Hogan believes the team has a fairly accurate idea of how Stuxnet succeeded.

1. Getting inside

Even the most sophisticated virus in the world would have trouble infecting machines that aren't connected to the internet.

The computers connected to the enrichment program's industrial control systems are air-gapped - that is, not connected to the internet or other insecure networks.

Hogan can only guess that a degree of social engineering would have been required to convince an operator or engineer that worked at the plant to introduce data from external media (such as USB key) that was infected with the virus.

"In our experience in cases like this, the target organisation is usually being attacked through an intermediary like an outsourced partner," Hogan said.

These intermediaries might have offered skilled labour, technology outsourcing, and any number of services to the program.

Engineers often used ruggedised laptops, he said, that are taken off-site for new instruction sets to be programmed and taken into the facility to upload these new commands to the system.

Hogan suspected that the worker that infected the machines made a genuine mistake rather than a deliberate attempt at spying.

The attacker may have deliberately left memory sticks lying around at the offices of the outsourced provider. As long as one machine was infected, any network it connected to was at risk - and the worm was programmed to use these connections to seek out those devices that could do the damage.

2. Creating a backdoor

Once a USB stick or other external media is plugged in, the worm used the LNK automatic file execution vulnerability to infect the machine. The code would be executed simply by the user looking at what contents might be on that USB stick using internet explorer - they would not have to click on anything.

The Stuxnet worm then used compromised security certificates from two Taiwanese device manufacturers - JMicron and Realtek - to allow Stuxnet to run more deeply inside the target computer.

"Someone got access to private keys of those two organisations - which curiously are based within a few kilometres of each other," Hogan said.

Stuxnet would then log-in, create an internet connection and connect to two command and control servers to download instructions.

3.  Looking around the network

The worm also used vulnerability in Microsoft's Windows print spooler to spread to other devices connected to the local area network for infection, copying itself and executing on network shares.

Stuxnet then created a peer-to-peer network between infected machines to efficiently download the latest version of the virus from the command-and-control servers.

The virus also performs a check to see whether a Siemens Step 7 SCADA software is running on any devices connected to the infected machine.

If any computers with this software are found on the network, Stuxnet copies itself and executes on these machines, too.

4.  Doing the damage

Once the virus finds machines running the Siemens software, it infects the Step7 project files as another way to spread around the target installation.

Ultimately, Stuxnet attempts to upload its own code to the Siemen's controllers or programmable logic controllers that act as a hardware-software interface. In the case of the Iranian nuclear enrichment facility, the controllers were connected to frequency modulators that ran high-speed motors to spin the centrifuges used for nuclear enrichment.

So Stuxnet was able to download a fresh set of commands to the controllers that would override instruction sets.

This code instructed frequency converters on how fast the 164 motors in the centrifuges should spin and for how long.

Stuxnet was programmed to first watch the frequency modulation for 13 days to calculate what instructions could cause the most physical damage. Symantec believes Stuxnet would have inserted a set of instructions to spin up the frequency converters at 1410Hz for 15 minutes, well above the usual limit of 1064Hz.

"We assume it was spinning it up quickly to malfunction," Hogan said. "It was an attempt to create sympathetic vibrations that would cause problems," he said, potentially even breaking the rotors or centrifuges themselves.

Next, Stuxnet's instruction set aimed to set the frequency converters back to nominal speed for at least 27 days, then set the speed way back down to 2Hz for some 50 minutes, before spinning back to normal speed, screaming back up to 1410Hz, and so on and so forth.

5.  Masking its tracks

In order to inflict maximum damage, Stuxnet would intercept any attempt by operators to upload new code onto the controller chips. As new instructions are uploaded, Stuxnet would shunt the code aside and keep its own instructions running, but present a picture back to the operators that suggested all was running as it should be.

"If you went in and looked at the .DLL file, you would see your original code," Hogan remarked. "Stuxnet is hiding what it is doing."

Best in class, and hopefully the last.

After months of pulling Stuxnet apart and documenting its ability, Hogan is convinced it is the "first publicly known malware to intend real-world damage".

He believes the development of such a sophisticated threat "required resources characteristic of a nation state".

Symantec has noted that the attacker would have required access to the design schematics of the plant, to the private keys of the two Taiwanese manufacturers, and a team of "five to 10 core developers" taking about six months to develop the exploit.

With the LNK vulnerability now known, and Stuxnet analysed in every corner, Hogan is confident it will be a relatively isolated attack.

"I don't believe there will be a Stuxnet II," he said.

"But the whole area of industrial controls systems security is now an open to a lot more eyes and brains than it was before - for both good and bad."

The writer attended Symantec's research labs in Japan as a guest of the anti-virus vendor.