by Kim Zetter
47 Author interview, 2012.
CHAPTER 13
DIGITAL WARHEADS
Liam O’Murchu was growing tired and bored. He’d been sitting at his desk for two hours diligently plugging virtual hardware components, piece after piece, into a Step 7 emulator, making a last-ditch effort to identify what Stuxnet was attacking, but he was having no luck.
It was early October, weeks after Ralph Langner had identified Stuxnet as a precision weapon aimed at a single target, and both teams—in Hamburg and California—were now working independently, without the other knowing it, to identify the digital weapon’s target.
One of the things the Symantec researchers discovered was that right before Stuxnet unleashed its destructive payload on a 315 PLC, it searched the PLC for three “magic values”—combinations of numbers and letters embedded in the data blocks of the PLC itself. When Stuxnet encountered a 315 PLC, it rifled through these blocks in search of the magic values 2C CB 00 01, 7050h, and 9500h—and knew it had reached its target when it found all three.
Eric Chien had done a Google search on the values but found nothing that made sense in the context of Stuxnet. The researchers suspected the first one was some kind of part or serial number for a hardware component that got plugged into the PLC, so O’Murchu had set up a simulated Step 7 PLC environment to try to determine its identity. The Step 7 system included an emulator feature for building a virtual PLC network to test different hardware configurations before building the real network in a plant. The emulator featured a long list of hardware components that engineers could virtually plug into the configuration one at a time simply by clicking on a name from the menu. Each time an engineer selected an item from the list, an ID number for the component popped up on the screen. O’Murchu was hoping the mysterious 2C CB 00 01 was among them. But for two hours he’d been systematically plugging in one device after another and still hadn’t found a match after trying more than a hundred components. It was beginning to feel like an exercise in futility, until, that is, he reached a cluster of Profibus and Profinet cards on the list—devices that transmitted data between PLCs and the components they controlled. O’Murchu clicked on a Profibus CP 342-5 card and, just like that, the value popped up.
The Profibus card was just one half of the puzzle, however. He still didn’t know what devices the PLC controlled. Encouraged by this bit of success, however, he quickly plugged in the rest of the components on the list, but neither of the other magic values appeared. It didn’t matter. They’d made a big leap with this new finding anyway. They now knew that Stuxnet was looking for a system with six of these network cards attached, and they knew it was only a matter of time before they solved the rest of the configuration mystery.
THREE MONTHS INTO the discovery of Stuxnet, the rest of the world now knew about the mysterious code that had evidently targeted Iran. Yet speculation that it had specifically targeted the uranium enrichment program at Natanz remained just that—speculation. Symantec’s engineers were about to find the proof they needed in the code. But first, they needed a crash course in PLCs.
Discovering that Stuxnet was sabotaging the Siemens PLCs had certainly been a big breakthrough for Falliere and his colleagues. But Langner had been right that they had hit a wall in their research and were stymied by the PLCs. “We quickly knew that we knew nothing,” Chien says.1
If that weren’t enough, in discovering that Stuxnet was injecting malicious code into the PLCs, Falliere had also discovered that Stuxnet didn’t have just one payload, but two. Stuxnet sent out dual warheads to attack the PLCs, like special ops commandos. One targeted the Siemens S7-315 PLC; the other homed in on the S7-417.
Just a few kilobytes of malicious code got injected into each PLC, but cracking that code was the key to solving Stuxnet’s biggest puzzle. There was just one problem. The code was written in a format and language that Falliere didn’t understand. Stuxnet’s missile portion was written in C and C++ and compiled into Intel x86 assembly—the most common and widely known computer assembly language. But the digital warheads used an obscure programming language, unique to the Siemens PLCs, called STL.2 To program Siemens PLCs, engineers wrote their commands in STL, then converted them into MC7, an assembly language, before compiling that into binary that the PLCs could read. All of this meant that even if Falliere succeeded in reversing the ones and zeros of the binary back to STL, he still would have no idea what it said. It was a bit like unscrambling the coded message of the CIA’s famous Kryptos sculpture only to find that the unencrypted message was written in Greek. In Symantec’s August 17 announcement, they had put out a call for anyone with knowledge of PLCs and STL to contact them, but they got no response.
They wouldn’t have needed to seek help from the public if Siemens had been able to assist them, but unfortunately that turned out not to be the case. Chien contacted the company early in their analysis and throughout the months that they worked on Stuxnet. But whenever he sent the German firm questions about how the Step 7 system worked, Siemens took days or weeks to respond. Usually by then the Symantec researchers had discovered the answer on their own and had prepared a new set of questions for Siemens to answer.3
There was also another group of people who could have helped them out. Langner and his team excelled in the very areas that confounded Symantec. It would have been the perfect marriage of skills—Symantec with its expertise in Windows systems and reverse-engineering malicious code, and Langner’s team with their extensive knowledge of the Siemens software and PLCs. But any hopes of collaboration were quickly dashed after a brief e-mail exchange between the two groups, followed by a couple of blog posts, led to misunderstandings and bad feelings on both sides. It was a communication lapse that might have been easily resolved with a quick phone call, but neither side was motivated to make it.
In the absence of any help, the Symantec researchers did the only thing they could do—they bought a handful of books about STL online and proceeded to teach themselves how the code worked. The best way to reverse-engineer STL code, they reasoned, was to learn how to write it.
Each day on the Métro during his morning and evening commutes, Falliere pored over the books trying to make sense of the code. He made little progress for days until he discovered an open-source tool online that someone had created to program Siemens PLCs as a freeware alternative to the Step 7 software. Falliere studied the tool to see how STL code looked when it was compiled into MC7 and then used this as a road map to take Stuxnet’s MC7 code in reverse.
It took weeks of picking through the code to get it all reversed, and, when he finally did, the few kilobytes of binary that Stuxnet injected into the PLCs had ballooned into more than 4,000 lines of instructions for the 315 attack and more than 13,000 lines for the 417 attack. It was too large and unwieldy for Falliere to read in this format, not to mention too complicated for him to follow. So he decided to translate it into something resembling C code to give himself fewer and simpler commands to read. All of this only provided him with a static reading of the code, however; without a PLC, he still couldn’t see the attack in action. So he wrote a small program to simulate a PLC on his Windows machine and unleashed the code on that. Between this and a static reading of the reversed code, he was finally able to piece the attack together.
One of the first things that struck him about the attack was that it unfolded in six stages that repeated over weeks and months. Once the attack was done, it recycled itself and began again. This meant that rather than launching a single blow that caused catastrophic failure, as the researchers originally believed Stuxnet was designed to do, the attackers were going for subtle sabotage that extended over time. This, combined with the man-in-the-middle attack that concealed the sabotage from operators as it occurred, would have made it hard for anyone to detect and pinpoint the source of problems. The attackers, Falliere realized, had expected to go undetected for months, and indeed they had.
The first part of the attack, a reconnaissance stage, laste
d about thirteen days, during which Stuxnet sat silently on the PLC recording normal operations in order to loop that data back to operators when the sabotage began. Stuxnet recorded data at least once a minute and only progressed to the next stage after recording data at least 1.1 million times.
Once enough data was recorded, a two-hour countdown commenced. Then when the count reached zero, the sabotage began. It lasted just fifteen minutes, however, and once it was done, normal operations on the PLC and the devices it controlled resumed. Then, after a five-hour interval passed, the entire sequence began again, with Stuxnet this time waiting about twenty-six days to strike, and recording twice the amount of data it recorded the first time. And when the sabotage kicked in this time, it lasted fifty minutes instead of fifteen. As before, once the sabotage was done, operations returned to normal for another twenty-six days, and the whole cycle repeated again. Each time the sabotage occurred thereafter, it alternated between fifteen minutes and fifty minutes in length, though the reconnaissance stage remained twenty-six days.
Falliere had no idea why the length of the sabotage changed or what the difference was between the two sequences. Without knowing what devices were being attacked, he had no way of knowing the nature of the assault. It was a bit like watching tracer bullets fly through the night sky without having any idea what they would hit.
THE FINAL BREAK in the Stuxnet puzzle came in early November when a Dutch programmer named Rob Hulsebos, an expert on the Profibus protocol, sent Chien an e-mail. He was responding—albeit belatedly—to a second call for help the Symantec researchers had posted on their blog, asking anyone with knowledge of Profibus cards and critical infrastructure to contact them. Hulsebos’s e-mail contained just two paragraphs, most of it information about Profibus that Chien already knew, but one sentence stood out. Hulsebos wrote that every peripheral device connected to a Profibus network card had a unique ID assigned to it by Profibus. Each ID was about 2 bytes in size, or 16 bits, Hulsebos wrote.
Chien recalled that the two mystery values they were trying to crack—7050h and 9500h—were exactly 16 bits each.
He walked over to O’Murchu’s cubicle and showed him the e-mail on his BlackBerry. As Chien watched anxiously over his shoulder, O’Murchu did a Google search on Profibus device IDs and got a series of links for product brochures. Chien pointed to one, a PDF listing devices commonly used with Profibus network cards. O’Murchu opened the file, and alongside the name of each device on the list was the unique Profibus ID the e-mail had described. O’Murchu scrolled down the list until he reached the bottom, and there it was—one of the magic values that they (and Stuxnet) were seeking—9500h. According to the manual, the ID corresponded to a brand of frequency converter made by a company in Finland. Chien dug around on the site for information about the other ID but couldn’t find anything. So he wrote an e-mail to Profibus asking the company to identify the 7050h. He didn’t expect a response and was surprised when he got a reply indicating it was a frequency converter made by a company in Iran.
Frequency converters are power supplies that control the electric current fed to motors and rotors to modulate their speed. Increase the frequency of the drive and the speed of the motor increases. The 9500h ID was for a frequency converter made by a company named Vacon in Finland; the 7050h ID was an unspecified model of converter made by a company named Fararo Paya in Iran. O’Murchu suspected the Fararo Paya converters were an Iranian knock-off of the Finnish one.4 If this was the case, there was likely no other facility outside of Iran that used the converters from Fararo Paya.
They downloaded everything they could find about frequency converters, including a dozen manuals for various brands. None of them were manuals for the Vacon and Fararo Paya converters, but some of them listed commands for controlling the converters that were identical across different brands of devices. One of the STL commands Falliere had pulled from the Stuxnet code was “47F and 1,” and sure enough, when they looked in one of the manuals they found these words: “To start the frequency converter, send down the word 47F and set the value to 1.” O’Murchu’s fingers hovered above the keyboard as he read the line aloud. He couldn’t believe it. For four months they’d been struggling to solve the mystery of what Stuxnet was attacking, working nights and weekends to understand what it was doing, and now with a couple of simple Google searches they had found their answer. It was as exhilarating and gratifying as it was anticlimactic.
It was the end of the day and the two of them were exhausted, so they sent a quick e-mail to Falliere letting him know what they’d found, along with a few of the PDF manuals showing the commands. “Take a look at these and see if you find anything in here that works,” Chien told Falliere.
When Falliere awoke that morning and saw the e-mail, he raced to the office. He pulled out a list of all the configuration data and commands he’d extracted from Stuxnet and sifted through them side-by-side with the manuals. It didn’t take long before he found matches for all of them. He’d already suspected that Stuxnet might be changing the frequency of something on the other end of the PLC—the attack code contained numbers like 10640, which he suspected was 1,064 Hz expressed in deciHertz. Now the new information confirmed it.
He used the manuals to translate all of Stuxnet’s commands and within an hour or two had a complete blueprint of the attack, which he sent to O’Murchu and Chien.
Before Stuxnet began its assault on the S7-315 PLC, it made sure the system was using frequency converters made by Vacon and Fararo Paya, and that the converters were operating at a frequency somewhere between 807 Hz and 1,210 Hz. Stuxnet was looking for a plant that had up to 186 of the converters installed, all of them operating above 800 Hz. Frequency converters were used in a number of varied applications, but converters that operated at 600 Hz or higher had limited use—so limited, in fact, that when Chien did a search online he discovered they were regulated for export in the United States by the Nuclear Regulatory Commission. There could be no doubt about it now. Stuxnet was targeting a nuclear facility. Langner had gone out on a limb asserting that Stuxnet was targeting Iran’s nuclear program, but now they had evidence in the code to back it up.
Chien was stunned by how beautifully everything now fell into place.
They had struggled for months to decipher the code, achieving their progress in increments of inches rather than miles, worried that they would never reach the end of the road. Now in hindsight, it all seemed so elegant and complete. With the final details resolved, Falliere laid out a step-by-step description of the attack from start to finish.
Once Stuxnet found a Step 7 machine, it unpacked its Step 7 .DLL doppelgänger and kidnapped the Siemens .DLL to take its place. Then it waited patiently for a programmer to launch the Step 7 program to read or create code blocks for an S7-315 PLC. Stuxnet then injected its malicious code into the blocks and waited until the programmer connected his laptop to a PLC or copied the commands to a USB flash drive to transfer them to a PLC. It could take days or weeks for the malicious commands to land on a PLC, but once they did, the attack unfolded without resistance.
After the initial reconnaissance stage recording data for thirteen days, Stuxnet first increased the frequency of the converters to 1,410 Hz for fifteen minutes, then reduced it to 1,064 Hz, presumably the normal operating frequency, for about twenty-six days. Once Stuxnet recorded all of the data it needed to record during these three weeks, it dropped the frequency drastically to 2 Hz for fifty minutes, before restoring it to 1,064 Hz again. After another twenty-six days, the attack began again. Each time the sabotage commenced, the man-in-the-middle attack fed false frequency readings back to the operators and safety system to keep them blind to what was happening.
SYMANTEC AT LAST knew exactly what Stuxnet was doing to the S7-315 PLC. But the attack targeting the S7-417 PLC remained a mystery. The two digital weapons arrived with the same missile but operated completely independent of each other.
The S7-417 was Siemens’s high-end PLC, which came
with 30 megabytes of RAM and a price tag of more than $10,000 compared to about $500 for the S7-315. As if to match its higher status, the attack targeting this PLC was also much larger, with many more blocks of code—40 blocks of code compared to 15 blocks for the 315 attack—some of which got generated on the fly based on conditions Stuxnet found on the system it was attacking.
The 417 attack code was also far more complex, both in terms of the steps that got executed and the conditions under which the attack was unleashed. In addition, it had bizarre constructs that made it a huge pain to reverse-engineer. There were pointers leading to pointers leading to pointers, which made it difficult to follow the sequence of events in the code. The difference in structure between the two attacks made it appear as if the codes had been created by completely different teams using different tools.
The attackers had obviously put a lot of thought and effort into the 417 code, so Falliere was perplexed when he discovered that it didn’t work—that in fact the attackers had intentionally disabled it. In part of the code responsible for fingerprinting the 417 PLC to see if its configuration matched the target configuration Stuxnet was seeking, the attackers had inserted an exception—a programming trick that involved introducing an intentional error into the code to abort a mission before it began. What’s more, there was no sign the attack had ever been active. Stuxnet needed to generate a crucial block of code on the fly to make the attack work, but the code that was supposed to create that block was incomplete.
It wasn’t clear if the attackers had disabled the code because it was still a work in progress or if it had been completed at one point and later disabled for a different reason. Falliere recalled the recent news story quoting an Iranian official saying that five versions of Stuxnet were found in Iran.5 Symantec and other researchers had seen only three versions of Stuxnet so far. But was there, perhaps, another version of Stuxnet in the wild that contained a complete version of the 417 attack?
