Subscribe / Unsubscribe Enewsletters | Login | Register

Pencil Banner

Stuxnet explained: How code can destroy machinery and stop (or start) a war

Josh Fruhlinger | Aug. 23, 2017
We now live in a world where computer malware causes destruction at a physical level.

Stuxnet was never intended to spread beyond the Iranian nuclear facility at Natanz. The facility was air-gapped and not connected to the internet. That meant that it had to be infected via USB sticks transported inside by intelligence agents or unwilling dupes, but also meant the infection should have been easy to contain. However, the malware did end up on internet-connected computers and began to spread in the wild due to its extremely sophisticated and aggressive nature, though as noted it did little damage to outside computers it infected. Many in the U.S. believed the spread was the result of code modifications made by the Israelis; then-Vice President Biden was said to be particularly upset about this.

 

Stuxnet source code

Liam O'Murchu, who's the director of the Security Technology and Response group at Symantec and was on the team there that first unraveled Stuxnet, says that Stuxnet was "by far the most complex piece of code that we've looked at — in a completely different league from anything we’d ever seen before." And while you can find lots of websites that claim to have the Stuxnet code available to download, O'Murchu says you shouldn't believe them: he emphasized to CSO that the original source code for the worm, as written by coders working for U.S. and Israeli intelligence, hasn't been released or leaked and can't be extracted from the binaries that are loose in the wild. (The code for one driver, a very small part of the overall package, has been reconstructed via reverse engineering, but that's not the same as having the original code.)

However, he explained that a lot about code could be understood from examining the binary in action and reverse-engineering it. For instance, he says, "it was pretty obvious from the first time we analyzed this app that it was looking for some Siemens equipment." Eventually, after three to six months of reverse engineering, "we were able to determine, I would say, 99 percent of everything that happens in the code," O'Murchu said.

And it was a thorough analysis of the code that eventually revealed the purpose of the malware. "We could see in the code that it was looking for eight or ten arrays of 168 frequency converters each," says O'Murchu. "You can read the International Atomic Energy Association’s documentation online about how to inspect a uranium enrichment facility, and in that documentation they specify exactly what you would see in the uranium facility — how many frequency converters there will be, how many centrifuges there would be. They would be arranged in eight arrays and that there would be 168 centrifuges in each array. That’s exactly what we were seeing in the code."

 

Previous Page  1  2  3  Next Page 

Sign up for CIO Asia eNewsletters.