Stuxnet, part 2

Hello, and welcome to Malicious Life – I’m Ran Levi.

As I told you at the beginning of the previous episode, my third book was called “Battle of Minds: A History of Computer Viruses.” Writing a book is never easy, but this time I ran into a new problem, one that I never encountered when writing before—paranoia.

You see, while doing research for the book, I visited countless websites that can only be described as “dubious”: hacker forums, virus-spreading websites and so on. I’m a cautious person, so I took all measures I could to protect my computer from getting infected from any scary viruses. But despite my efforts, I was always worried that I missed something and would get infected by some malware. Every time my computer acted slightly weird, I immediately wondered whether it had to do with a virus. Slow Internet? It might be a virus! Some software stopped working? A trojan! The hard-disk is over active? It’s malware for sure! You get the picture. I was a digital hypochondriac.

But why am I telling you this? Because I believe that right now, a few thousand miles away, perhaps inside an underground bunker somewhere, there are programmers and technicians who are sitting in front of their computers and experiencing the same paranoia.

The Right Person At The Right Time

But first, a mini-recap.
In the first part of this episode, I introduced you to Stuxnet, a malicious software that flipped the IT security world upside down when it was exposed in 2010. Stuxnet wasn’t your typical run-of-the-mill computer virus, but an entirely new threat called an Advanced Persistent Threat, or APT for short. Unlike typical viruses, an APT is a targeted threat, sort of like a guided missile aimed at a specific target. We learned how Stuxnet was accidentally exposed by a small Belarus IT company, and of the industrial control world’s terrified reaction when its executives realized the real potential of APTs. We also learned that Stuxnet exploited an unknown vulnerability in the Windows operating system and a secret password in Siemens’ software in order to penetrate control systems in industrial facilities.

One question, however, was not addressed in the previous episode, and it is the topic of this episode. It’s a question that kept many CEOs awake at night: What, or Who, was Stuxnet’s target?

The technological analysis published after Stuxnet was exposed made it clear that Stuxnet was a sophisticated and malicious software—but experts couldn’t figure out who it was targeting. There were literally thousands of industrial facilities using Siemens’ industrial control equipment around the world. Were they all targets, or just a few of them?

Ralph Langner is an IT security expert and the owner of a tiny three-man IT security company. He also specializes in industrial control systems, so when Stuxnet became known to the public, it struck Langner’s interest. He immediately obtained a copy of the malware and started analyzing it.

It turned out that Ralph Langner was the right person in the right place at the right time. He had years of knowledge and experience working with Siemens’ control systems. In fact, Siemens sometimes sent its employees to him for professional seminars on using their equipment. Langner and his two colleagues spent weeks decoding the secrets of Stuxnet and were able to paint a clear picture of how it operated.

The Payload

Now’s a good time for a quick reminder of how Stuxnet works, since we’re going to go into more detail.

Stuxnet’s infiltration process began when an infected USB was connected to a PC by one of the industrial facility’s employees. It then took over the computer and traveled inside the network, skipping from computer to computer, until it found one that belonged to the facility’s industrial control system—for example, a computer that controls an assembly line. Stuxnet checked whether software called Step7, made by Siemens, was installed on the PC. If Step7 was on the PC, Stuxnet hacked it using a secret password that was built into the software. Next, Stuxnet looked for a specific type of control equipment called a PLC, which is a smaller computer used to “translate” commands to and from the PC to the actual machinery. If Stuxnet found a PLC, it took over it as well.

Now, up until this point in the process, Stuxnet hasn’t caused any damage. It hasn’t erased any files, nor has it stolen any data. Going back to the guided-missile analogy, now that the thruster has brought the missile to its target, it’s time for the payload to cause the real damage.

Once Stuxnet took over the PLC, it checked to see which electrical components were attached to it. Specifically, it was looking for two microchips that control the rotation speed of engines, made by two specific companies: Vacon from Finland, and Fararo Paya from Iran. If Stuxnet didn’t find these two microchips—or if the microchips were made by some other company—then Stuxnet terminated its operation and erased itself from the computer. If Stuxnet found the two microchips it continued to look for an even more specific condition—the rotation speed of the engines connected to the microchips, specifically, between 807 and 1210 Hertz. Once again, if it didn’t find the engines, or if the rotation speed was not within the right range, Stuxnet terminated its operation and erased itself from the computer.

Let’s review the long chain of specific conditions vital for Stuxnet’s operation. A computer on which a specific software made by Siemens was installed, connected to Siemens PLC, itself connected to two microchips made by two specific companies that controlled rotating engines at a very specific speed range. The convergence of such a precise set of conditions is comparable to searching the phonebook for a Mr. Butterworth who lives in Michigan, in the city of Livonia, and on 19323 Shadyside Street. If you found Joe, he is most likely the person you were looking for, since the chances of there being two people with the same name at the same address are slim. In other words, Stuxnet was looking for a very specific target.

This level of preciseness, atypical for computer viruses, astonished Ralph Langner. Who would invest that much effort in order to harm one specific facility? The answer was almost obvious: It could only be a country that wanted to attack a military facility of some other country. Langner contacted several of his colleagues and clients and asked whether they knew of an industrial facility whose characteristics matched the specific pattern Stuxnet was after. Soon after he found a match—a gas centrifuge for a uranium enrichment facility in Nantanz, Iran.
For those of you who aren’t familiar with the ins and outs of a uranium enrichment process, here’s a quick explanation.

Uranium Enrichment

Uranium is the vital material for nuclear fission, the process that takes place in nuclear power plants and nuclear bombs. There are several naturally occurring isotopes of uranium—think of them as different “flavors” of the same element. Only one particular flavor, known as uranium 235, can support the process of nuclear fission. Luckily, uranium 235 is rare and makes up less than one percent of the uranium found in nature, which is why uranium deposits are not spontaneously exploding on their own. In order to use uranium in a nuclear power plant or to make a nuclear bomb, it must be enriched. That is, the percentage of uranium 235 in the original material needs to be increased. It’s kind of like assembling a basketball team—the more Stephen Currys you have playing on your team, the better the chances you’ll make it to the playoffs.

The most common method for enriching uranium is by using a gas centrifuge. An enrichment centrifuge is a rapidly rotating tube, into which hot uranium gas is injected. The centrifugal forces acting on the gas separates the different isotopes or “flavors” of uranium so that the gas leaving the centrifuge is enriched with uranium 235. In other words, the percent of uranium 235 is higher than it was before the gas was injected to the machine. If five to 10 percent of the Uranium atoms are uranium 235, then it can be used as fuel in a nuclear power plant. If the concentration goes up to 20 percent, it can be used in a nuclear bomb.
That’s the whole secret. Now only you, I and Wikipedia know it.

These centrifuges, or more precisely—the engines that run them—were Stuxnet’s targets. If all the conditions we talked about were fulfilled (the specific microchips attached to engines rotating at a specific speed) then Stuxnet would interfere and force the engines to change their speed. Initially it would speed them up, then slow them down so that they almost stopped, before returning them to their original rotation speed. Stuxnet initiated these weird speed changes in the centrifuges once every 27 days.

Why, then, is Stuxnet messing with the centrifuges’ rotation speed? Well, to understand that, we have to appreciate how sensitive these machines are. A typical centrifuge rotates at tens of thousands of revolutions per minute—the edge of the tube travels almost half a mile each second. The tremendous speed at which they rotate, combined with the high temperature of the radioactive gas inside them, makes the centrifuges extremely sensitive to any sort of rattling and turbulence. Think of a centrifuge as a motorcycle on a highway running into a rock. If the motorcycle is fast enough, even a small stone could cause great damage.

If a spinning centrifuge experiences uncontrolled rattling, the shaking and extra friction can be disastrous. The best-case scenario is that the centrifuge will be worn out sooner than expected and need to be replaced at huge cost. In the worst-case scenario, the centrifuge will disintegrate and break into pieces. By increasing and decreasing the centrifuges’ rotation speed, Stuxnet induced turbulences that did exactly that.

Sabotage

According to past media reports, The United States and Israel have previously tried to sabotage the Iranian nuclear program by replacing sensitive components with false or failed ones. Robert Langner suspected that Stuxnet was another such sabotage attempt. But he needed to learn more about the Iranian nuclear program. Ironically enough, one of his main resources in doing so was the Iranian Public Relations Office. Over the years the Iranians have published images and videos of the former Iranian President Ahmadinejad visiting nuclear facilities—Ahmadinejad walking near the gas centrifuges, Ahmadinejad leaning over a technician’s shoulder and looking at a control screen…you get the picture. Langner analyzed every image and frame he could get a hold of in order to figure out what equipment the Iranians were using, and was convinced that Iran was the target. His conclusion was bolstered by the fact that about 60 percent of the infected computers were located in Iran.

Langner published his theory in a series of posts on his company’s blog. He doubted that anyone would take his ideas seriously, but he was wrong. The IT security world was enthusiastic about the news—and it was only then that the mainstream media realized what was happening.
Blake Sobczak is a reporter who covers IT & Security matters for the magazine EnergyWire.

“You know, the initial stories about Stuxnet were kind of glossed over. The impact of it was immediately clear, and part of that had to do with just the technical aspects of it. Those who were dissecting it, this took time. It’s an enormous piece of code, multiple versions of it. They were trying to find where it came from, what it was trying to do, what the malicious payload was. And then for a while, it didn’t have that added element of Iran’s nuclear program, which of course pushed it over the edge to be international news [when] all of a sudden when you realize what this was going after and how significant it really was.”

Nowadays, the consensus among experts is that Stuxnet was indeed developed in order to damage the uranium enrichment centrifuges in the nuclear facility in Nantanz. What damage did it cause? It’s hard to tell. According to media reports, the Iranian nuclear program was often delayed in 2010, and more than 1,000 centrifuges were replaced due to severe defects. Leaked documents referred to a possible nuclear accident that took place in the first half of 2010. The Iranian President, Mahmud Ahmadinejad, admitted that a malware caused “limited damage” to the centrifuges, although it’s safe to assume that the damage was worse than the Iranians wanted the world to know.

Now you may be asking: How is it possible that no one in the Iranian facility noticed the changes in the rotation speed caused by Stuxnet? Such dramatic changes of speed should have caused the alarms in the facility’s control room to go off and alert the technicians monitoring the machines.

Nefariously Brilliant

This brings us to what is probably the most brilliant – or perhaps nefariously brilliant – aspect of Stuxnet. When Stuxnet takes over the control computer and it’s PLC, it also replaces the sensor data sent to the technician’s monitor with a pre-recording. That way, when Stuxnet drives the centrifuges crazy—the monitors are still showing the appropriate speed, temperature and more. Downstairs, among thousands of centrifuges, a single centrifuge starts doing the tango and making noises like your grandfather’s broken Chevy. But upstairs in the control room, all systems are go.

Eventually, of course, someone will notice that something’s wrong. If a hundred centrifuges usually need replacing in a typical month, and all of the sudden 500 go out of order almost simultaneously—someone will start asking questions. The executives will inquire and the technicians will report that no alarm went off. It’s safe to assume at this point that Iranian nuclear program executives will start demanding explanations…

Here is where the brilliance of Stuxnet comes into play. When Stuxnet replaces the existing software in the PLC, it does not erase the original software, instead, it actually “saves” it somewhere in the memory. When a programmer tries to examine the currently running control software in the PLC—Stuxnet pulls out the original software from where it was stored and presents it to the programmer as if nothing’s wrong.

Now, put yourselves in the shoes of that Iranian programmer.
Expensive centrifuges are being destroyed daily, and upper management is going nuts. The pressure on you, the programmer, is tremendous. Your boss is constantly looking over your shoulder. You retrieve the software from the PLC and it’s perfect. Nothing seems to be wrong; after all, it’s the same software you wrote a week ago and tested countless times. So how is it possible that centrifuges can disintegrate without any warning? As an engineer, I can empathize with those poor programmers, and feel their hair-pulling & monitor-kicking frustration…

Which brings us back to the notion of paranoia… Once Stuxnet was exposed in the media we can assume that the Iranians understood what was really going on in their facility. Given the sophisticated level of programming they were dealing with—they would have to become extremely suspicious and paranoid. Every computer failure, every small malfunction, could potentially indicate the existence of a new and advanced malware. According to one report, the Iranians were so suspicious of their equipment that at a certain point they sat people in front of the centrifuges in order to manually monitor the rotation speed of the machines.

Ralph Langner thinks this paranoia—this digital psychological torment—might have been the real intention of whoever was behind Stuxnet. It’s obvious that Stuxnet’s creators could have caused catastrophic damage to all the centrifuges simultaneously, which might have caused the entire facility to shut down; yet they chose a kind of gradual “strangling” in order to sabotage not only the machines but also the confidence the engineers had in them.

“If catastrophic damage was caused by Stuxnet, that would have been by accident rather than by purpose. The attackers were in a position where they could have broken the victim’s neck, but they chose continuous periodical choking instead. Stuxnet is a low-yield weapon with the overall intention to reduce the lifetime of Iran’s centrifuges and make their fancy control systems appear beyond their understanding.”

Stuxnet’s Bug

So Stuxnet was a unique piece of malware. It could not only bypass anti-virus software from multiple vendors without batting an eye, but it also knew how to disguise its activity so that neither the equipment operator, nor the system’s programmer could find it. Here’s Andrew Ginter, the industrial system security expert whom we met in the previous episode.

“This class of attack had been described as possible years early in security conferences – but has never been seen in the wild until Stuxnet. Stuxnet in a sense did not invent any kind of new attack. Stuxnet took the most powerful, the most effective and the most advanced of any technique that anyone had ever described—and put them all together, and made them work really well in one package, and this had never been seen before. This was the big thing.”

According to Ginter, Stuxnet must have been the result of a huge investment in time, money and expert IT programmers.

“I developed SW for 25 years. I wrote software, I managed teams that wrote software—I know how much it costs to produce software. This worm installed cleanly on every machine I tried it on. Everything from Windows NT up to the Windows OS of the day, all of the different variants—it installed clean and it ran clean on all of them. I know how hard it is to produce a legitimate product that works on that wide a variety of equipment. My estimation is that there were at least millions of dollars spent on the worm. It might have been tens of millions.”

This last point raises another interesting question. If Stuxnet was so sophisticated and polished, why was it ever exposed? That’s not a trivial question. According to the media, earlier versions of Stuxnet successfully meddled with the Iranian facility for five whole years before it was ever discovered. Something must have gone wrong…

It turns out that Stuxnet might have successfully remained “underground” for a long time, had it remained within the confines of the Iranian facility. The makers of Stuxnet had reliable intelligence regarding the computers at the facility, so Stuxnet operated without any problems. But at a certain point, Stuxnet began spreading to other places and other computers…a lot of other computers.

“You know, you might ask—if the worm was that sophisticated, how did it ever get discovered? The people analyzing the worm have concluded they have discovered what they think is a bug. [LONG PAUSE] … And so this bug caused the worm to propagate. Instead of there being tens or hundreds of copies of the worm in the world, there grow to be at one point over a 100,000 copies.”

A small bug—an error in one code line—caused the mechanism controlling the malware’s propagation to malfunction. As a result, instead of only infecting three new computers at a time – it ended up infecting exponentially more. It’s possible that among the infected computers were some that exhibited the “blue screen of death” that VirusBlokAda, the small Belarus IT security firm, was called to look into, which initiated the chain reaction that led to the discovery of the worm.

“This very sophisticated artifact was discovered because of a bug. To produce that much code that is that reliable is extremely costly. And to have that investment vanish because of one line of code—that’s really annoying.”

You know, I have a reason to believe that some of the listeners of this podcast—both in the US and in Israel—might have had something to do with the creation of Stuxnet. If I am correct, and you are listening—then hold on tight for the next—and final—installment of this episode, since we will be talking about… you.

Who the anonymous creators of Stuxnet, and what clues did they leave for us within the software’s code? Could it be that exposing Stuxnet was part of a bigger plan, and not so coincidental? And who are Duqu and Flame, Stuxnet’s sisters? All that and more, next week, on Stuxnet, Part III.