Countdown to Zero Day: Stuxnet and the Launch of the World's First Digital Weapon (42 page)

Raiu believed that when it came time to build Stuxnet, the attackers used Flame to jumpstart the digital weapon, then later switched to the Duqu platform for subsequent versions of the attack. He based this in part on the fact that Resource 207 found in the 2009 version of Stuxnet—which contained the Autorun code and the wallpaper exploit—looked a lot like an early version of Flame’s main module. Flame would have already existed as a basic espionage tool by 2007, and when it came time to write the missile portion of Stuxnet in 2009, it appeared that the team behind Flame shared source code for Resource 207 with the Stuxnet crew, essentially kick-starting the creation of the missile code. The payload was already created by then, and the attackers just needed something to deliver it. “Probably there was some kind of urgency to get [Stuxnet] out the door, so that’s why they took this already mature plug-in from Flame and used it in Stuxnet,” Raiu says.

After this, however, Stuxnet and Flame diverged. The programmers
behind Flame continued to build their platform into a massive espionage tool, and in 2010 when the attackers behind Stuxnet prepared the next version of their code for a subsequent assault, they switched to the Tilde-d platform—which had already been used to create Duqu—to recraft the missile for launching their attack. The switch to the Duqu platform likely occurred because the missile portion of the variant Stuxnet 2010, with all of its zero-day exploits and additional spreading mechanisms, was much more complicated and required more code. And the Tilde-d platform was a much simpler and more compact tool to use.

The sequence of events determined by Raiu and his team seemed to match the scenario depicted by
New York Times
reporter David Sanger, who reported in his book
Confront and Conceal
, citing current and former government officials, that the earliest version of Stuxnet was developed by the United States, while later versions were developed by the United States and Israel. Raiu believed that Flame and the Flame platform were created by the United States, while Israel created Duqu and the Tilde-d platform. Both then used their respective platforms to build their portions of Stuxnet.

Whatever Flame’s role in Stuxnet, the whole spy operation around it came crashing down on May 28, 2012, when Kaspersky and Symantec went public with news of its discovery in near-simultaneous announcements.
⁹
Once news of the spy tool was out, the response of Flame’s operators was swift. Within an hour of the first news stories being published, command servers used for the spy tool went dark as the attackers shuttered their operation, thus ending a massively successful five-year espionage
campaign in a matter of minutes. It was almost as if they had been waiting for the news to break.

Flame’s reign was now over, but its effects would live on. Days after the servers went dark, Microsoft announced that it had found an even more disturbing discovery about the Flame attack that the Kaspersky and Symantec researchers had missed.

IT WAS THE
Memorial Day holiday in the United States when news of Flame broke, and not many people at Microsoft headquarters in Redmond, Washington, were working. But when engineers in the company’s Security Response Center learned that a new attack campaign, attributed to the same team behind Stuxnet and Duqu, had been uncovered, they immediately grabbed samples of the Flame files made available by researchers. They wanted to see if the new attack used any zero-day vulnerabilities in Windows, as Stuxnet and Duqu had done. But as they examined one of the files they received, they realized they were looking at something much worse than a zero day—Flame was performing a sophisticated attack against part of Microsoft’s Windows Update system to spread itself between machines on a local network.

Windows Update is the automated system Microsoft uses to distribute software updates and security patches to millions of customers. To obtain the updates, a client-side tool sits on each customer machine and contacts the Microsoft servers to download patches whenever they’re available.

For years, the security community had warned of the security nightmare that would occur if hackers ever hijacked the Windows Update system to deliver malicious code, threatening the security of millions of Windows customers. This attack didn’t rise to that level exactly, but it was just as dangerous. Instead of subverting the actual Microsoft servers that delivered Windows software updates to millions of customers, it subverted the Windows Update tool that sat on customer machines. The distinction was subtle but important. If the attackers had subverted Microsoft’s servers, they could have compromised machines on a global scale. But the way
they performed the attack meant they could compromise machines only on specific networks that they targeted, leaving anyone else unaffected.

Like the Windows software, the update tool itself gets periodically updated by Microsoft. Each time the tool launches on a customer’s machine, it sends out a kind of beacon to Microsoft servers to see if a new version of itself is available. Microsoft distributes the updates through a series of so-called .CAB files, signed with a Microsoft certificate to verify their legitimacy.

The attackers subverted this process by first infecting one machine on a victim’s network with Flame. Then when the update client on any other machine on that victim’s network sent out a beacon to Microsoft servers to check for updates to the Windows Update tool, the infected machine intercepted the beacon and sent a malicious Flame file, masquerading as a legitimate Microsoft .CAB file, to the new machine instead, thus infecting it with the spy tool. This wasn’t the most sophisticated part of the attack, however. To pull off the hijack, the attackers had signed their malicious .CAB file with a legitimate Microsoft certificate—except in this case the certificate indicated that the company it belonged to was “MS,” not Microsoft Corporation, as it should have said. When Microsoft’s research team saw this, they immediately suspected something was wrong. The certificate appeared to have been issued and signed by Microsoft’s Terminal Services Licensing Certificate Authority in February 2010, but it was clearly a rogue certificate, which the CA should not have generated and signed. Had Microsoft’s server been compromised or its cert-signing key stolen? The engineers had to quickly figure out how the attackers obtained the cert before anyone else could repeat the feat. They put out a call for any colleagues available to work on the holiday and quickly assembled a team.

It turned out the attackers had pulled this off using something called an MD5 hash collision. An MD5 hash is a cryptographic representation of data—in this case the data on the certificate—generated by a cryptographic algorithm known as MD5. Hashes are supposed to function like a fingerprint, so that every data set run through the algorithm produced a unique hash. If the data changed, the algorithm would produce a different
hash. The MD5 algorithm, however, had been found years earlier to have a weakness that would allow someone to create the same hash from different data sets.
¹⁰
This was called a hash collision. Many companies had stopped using the MD5 algorithm for this reason. But Microsoft hadn’t changed the algorithm used for its Terminal Services (TS) Licensing service since 1999, when the system was architected.

TS Licensing is a system used by Microsoft corporate customers when setting up a server with Microsoft software running on it so that multiple employees or machines can use the software. The customer purchases licenses from Microsoft—say 100 licenses for 100 employees or machines—then submits a request for a certificate to Microsoft’s Terminal Services Licensing Certificate Authority. Microsoft’s CA generates a certificate with the customer’s name on it, as well as a timestamp indicating when the certificate was issued and a serial number for the digital document.

When Microsoft issues the certificate, it runs all of the data on the certificate, including the timestamp and serial number, through the MD5 algorithm to create a hash, then signs the hash and sends the cert to the customer. The customer then uses the signed certificate to ensure that only authorized machines or people issued the certificate use the software licensed from Microsoft. But in this case, the attackers used the hash from Microsoft to sign their rogue certificate and then to sign their malicious .CAB files.

Before the attackers submitted their certificate request to Microsoft, they created a rogue certificate that contained information that they anticipated the real Microsoft certificate would contain, as well as some minor alterations—alterations that they had to be sure would produce a hash that was identical to the one Microsoft would issue. This was no easy task. Among other challenges, it required running thousands and thousands of different variations of the data on their rogue certificate through the MD5 algorithm to get one that produced an identical bit-for-bit hash as the legitimate Microsoft certificate that contained different data, a feat
that required a lot of computational power. It also required anticipating the serial number that Microsoft would give the certificate and the exact time when Microsoft’s licensing server would sign the legitimate certificate, since the timestamp and serial number were part of the hash that Microsoft generates and signs.
¹¹
If they estimated the wrong time by even a millisecond, the signed hash would not be transferable to their rogue certificate, since the two hashes would no longer match.
¹²
The attackers would have needed to research the Microsoft system extensively and test multiple certificates—possibly hundreds—before they got the timing and serial number right.
¹³

The attackers then used the signed hash with their rogue certificate to sign their malicious .CAB files. It appeared to be a legitimate certificate, since it had the signed hash generated by Microsoft.

The Windows Update hijack was a brilliant feat that pushed the boundaries of mathematics and could only have been achieved by world-class cryptographers.
¹⁴
When the Kaspersky researchers learned of it, they
dubbed it the “God-mode exploit,” since it was so technically astute and so much more potent than spreading malware via a zero-day exploit.
¹⁵
The only thing that would have made it more powerful and dangerous was if the attackers had actually subverted the Windows Update patch servers themselves.

Microsoft’s engineers initially estimated it would take just twelve days for other well-resourced attackers to learn everything they needed to know about Microsoft’s certificate and update system to pull off a copycat attack to spread their own malware. But when they did a test run, walking through all the steps someone would need to take to copy the Windows Update hijack, and timed themselves while doing it, they realized that someone could actually pull off a less-sophisticated version of the attack—one that didn’t require an MD5 hash collision—in just three days.
¹⁶

Working against the clock, Microsoft rushed out an emergency out-of-band patch to fix the vulnerabilities that allowed the attack to occur. The company had released only one out-of-band patch in all of 2011, the previous year, and reserved such releases for only the most significant vulnerabilities, so it was an indication of just how seriously Microsoft viewed the Flame exploit that it took this step.

The attackers behind Duqu and Stuxnet had already struck at the underpinnings of the validation system that made the internet possible—first by stealing individual security certificates from the companies in Taiwan to sign the Stuxnet drivers, then by sending Duqu to steal data from a
certificate authority itself. But this exploit went even further than that by subverting the trust between the world’s biggest software maker and its customers. Assuming that the perpetrators behind it were American, they likely justified the operation and even got legal approval for it by arguing that they weren’t subverting the Microsoft Windows servers themselves—thereby putting all of Microsoft’s customers at risk—but simply subverting the Windows client on individual customer machines. In this way, they could focus the attack on victims and machines that weren’t in the States.
¹⁷

But ultimately it mattered little that they hadn’t subverted Microsoft’s servers. Subverting the update client tool was enough to create customer mistrust in the integrity of the update service itself—which could lead users to disable the tool and prevent them from receiving the security updates that were critical for the safety of their systems.

Who
was
responsible for threatening this trust between Microsoft and its customers? About three weeks after the news of Flame broke, former US government officials claimed ownership, telling the
Washington Post
that Flame had been a joint operation between the NSA, the CIA, and Israel’s military.
¹⁸

The unnamed sources said Flame had been developed sometime around 2007—confirming the general timeframe Raiu and his team had established for it—to collect intelligence about Iranian officials and to map computer systems that were part of Iran’s nuclear program. But the officials also suggested that Flame had been an early-generation tool that had since been surpassed by others.

“This is about preparing the battlefield for another type of covert action,”
a former US intelligence official told the paper, adding that cyber collection against the Iranian program was “way further down the road than this.” He may have been referring to things like the implants the NSA uses that can transmit stolen data via radio waves from infected machines. (See
this page
.)

Notably, the
Post
’s sources also cleared up a mystery about the Wiper attack that had struck Iran earlier that year. They told the paper that the attack, which had erased hard drives on machines at Iran’s oil ministry and had led to the discovery of Flame, was also a nation-state construct. But unlike Flame and Stuxnet, which had been joint operations of Israel and the United States, Wiper, one source said, had been launched against Iran by Israel alone. An official told the
Post
, in fact, that the United States had been caught off guard by the destructive attack.