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

1
Another clue uncovered from the ravaged system also seemed to point to the attackers behind Stuxnet and Duqu. The clue indicated that the first thing Wiper did when it landed on a system was hunt down and obliterate any file that had a .PNF extension. Raiu recalled that the payload file in Stuxnet as well as some of its other files all had .PNF extensions. Duqu also had files with a .PNF extension, an extension that was rarely used in malicious tools.

2
The log also contained the internal computer names of systems in Iran that had been infected.

3
Microsoft patched it on June 9, about two weeks before the June version of Stuxnet was released on June 22, 2009.

4
With regard to whether Flame was connected to Wiper, there was some confusion between the two attacks after the Kaspersky researchers uncovered a Flame module that was named
Viper.
But the job of this module was to transmit stolen data to a command server, not to wipe the hard drive of infected machines. Its existence, though, raised questions initially about whether the Wiper malware the Iranians found was actually a component of Flame. It didn’t help that some Iranian reports identified Wiper as Viper, due to a transliteration error from Persian to English. But in the end, Kaspersky found no direct connection between Wiper and Flame.

5
Most of the machines that were infected had the 6 MB version installed on them. But they also found a smaller starter kit that was about 900 KB with no extra modules included with it and that may have been used to infect machines over slow network connections, since the 6 MB module would take forever to install remotely in countries with slow and unreliable internet connections.

6
The malware’s configuration file contained a list of five static domains—among them traffic-spot.biz, dailynewsupdater.com, and bannezone.in—as well as another list that could be altered at random whenever the attackers added new command servers.

7
The attackers were more careful with Flame to alter timestamps in files to prevent researchers from dating the work. Although some of the timestamps appeared to be accurate, others that indicated files had been compiled in 1994 and 1995 were clearly incorrect because the files contained code from libraries that hadn’t been created until 2010.

8
The server code actually had a liner note the programmers had inserted to identify the authors and date of creation. The note read: “@author OCTOPUS in 12/3/2006; @author DeMO (modifications).” The names were likely code names for the individuals or teams that set up the servers.

9
While Kaspersky had been examining the Flame files it obtained, Symantec had been examining the one it received from Bencsáth as well as other modules they obtained from the machines of infected customers after adding detection to their antivirus tools. Neither of the teams communicated with each other about their work, though each secretly learned that the other was researching the code. When the Symantec researchers discovered that the Kaspersky researchers planned to publish their results on Memorial Day, they rushed to complete their analysis to publish the same day. The author was contacted by both companies separately—first by Kaspersky and then by Symantec—in advance of the announcements. See Kim Zetter, “Meet Flame, the Massive Spy Malware Infiltrating Iranian Computers,”
Wired.com
, May 28, 2012, available at
wired.com/threatlevel/2012/05/flame
.

10
Its weakness has been known since at least 2004.

11
Generally a certificate is generated and signed within seconds after a request is submitted to Microsoft’s servers. The attackers could have been able to gauge how long it took Microsoft to issue signed certificates by submitting a number of certificate requests to the company to detect a pattern. But one former Microsoft employee suggested to me that the attackers could also have been sitting on Microsoft’s internal network watching the requests come in to see exactly how long it took for requests to arrive from outside and be processed. There’s no evidence this is the case, however.

12
In addition to all of this work, they also had to modify the certificate to use it to install their malware on Windows Vista machines, since in its original form it would not have been accepted by any system using Vista or a later version of the Windows operating system. The modification involved getting rid of an extension on the certificate. They didn’t remove the extension, which might have caused it to fail the computer’s code-signing check; instead, they “commented out” a bit on the certificate—surrounded it with markers to make the machine simply ignore the extension. This allowed it to work on Vista machines. Only 5 percent of the machines that Kaspersky saw infected with Flame had Windows Vista installed, however. Most of the machines were using Windows 7 or Windows XP.

13
According to sources, Microsoft tried to investigate who had submitted the requests and how many requests for a certificate came in from this entity, but too much time had passed between when the certificate was issued—in February 2010—and when Flame was discovered in 2012. Microsoft’s logs get rewritten over time, and the logs for that time period were no longer available.

14
Dutch cryptographer and academic Marc Stevens, who with colleague Benne de Weger developed one of the first practical MD5 hash collision attacks for research purposes in 2007, described the Flame attack as “world-class cryptoanalysis” that broke new ground and went beyond the work they and others had done with collisions. Stevens and de Weger were part of a group of researchers, including Alexander Sotirov, who demonstrated a similar, though technically different, collision attack in 2008 at the Chaos Computer Club Congress—a hacker conference held annually in Germany. They used a cluster of two hundred Playstation 3s to do their computational work to generate an identical hash for a certificate. Their certificate masqueraded as a different company, not as Microsoft. When they conducted their experiment, however, they kept guessing the wrong timestamp and had to generate a hash four times before they got it right. When the Flame attack was discovered in 2012, Sotirov estimated that it was ten to a hundred times more difficult to pull off than the attack he and his colleagues had done. Slides for the presentation by Sotirov and his colleagues can be found at
events.ccc.de/congress/2008/Fahrplan/attachments/1251_md5-collisions-1.0.pdf
.

15
It should be noted that after going through all of this trouble to obtain their rogue certificate, the attackers should not have been able to use it to sign their malicious code. But they were able to do so because Microsoft had failed to implement certain restrictions so that the certificates it issued for TS Licensing would be designated for “software licensing” purposes only.

16
This low-rent certificate would allow the malware to at least slip past Windows XP machines, though not Windows Vista machines, which had stronger security.

17
Some would say, however, that this attack was even worse than subverting the Microsoft Windows Update servers to deliver malicious software, because in subverting those servers, although the attackers would be able to send malicious software to customers from Microsoft’s servers, customer machines would reject the code if it wasn’t also signed by Microsoft. But by undermining Microsoft’s certificate process to sign their malicious code, the attackers didn’t need Microsoft’s Update servers. They could deliver their malware to machines from any server and pass it off as legitimate Microsoft code.

18
Ellen Nakashima, “U.S., Israel Developed Flame Computer Virus to Slow Iranian Nuclear Efforts, Officials Say,”
Washington Post
, June 19, 2012.

19
With Duqu, the attackers had launched their cleanup operation
after
news of the malware broke, but the fact that the team behind Flame launched their cleanup about ten days before news of Flame broke, suggested they had known in advance that their cover was about to be blown. The Kaspersky researchers had likely tipped them off inadvertently when they connected a test machine infected with Flame to the internet. As soon as the machine went online, the malware reached out to one of Flame’s command servers. The attackers must have realized the machine wasn’t on their list of targets and may even have identified it as a Kaspersky machine and concluded that Flame’s days were numbered. In a panic, they wiped the command servers and sent out a kill module, called Browse32, to infected machines to erase any trace of the malware so victims would never know they had been infected.

The cleanup campaign was successful for the most part. But Browse32 had a fatal flaw; it left behind one telltale file, ~DEB93D.tmp, that gave it away. This was a temporary file that got created whenever Flame performed a number of different operations on an infected machine. Once the operation was done, Flame was supposed to delete the temp file automatically. Because of this, the attackers hadn’t put it on the list of files that Browse32 was supposed to delete, since they weren’t expecting it to be on machines. In a twist of fate, however, if the Browse32 kill module arrived to a machine while Flame was still performing one of the operations that had created the temp file, the kill module erased Flame before it could delete the temporary file. Kaspersky found the orphan temp file abandoned on hundreds of systems that had been infected with Flame. It was this file, in fact, left behind on a machine in Iran, that led the Kaspersky researchers to stumble across Flame in the first place.

20
This wasn’t the only mistake they made. They also botched the cleanup operation on the servers they could access. They had created a script called LogWiper.sh to erase activity logs on the servers to prevent anyone from seeing the actions they had taken on the systems. Once the script finished its job, it was also supposed to erase itself, like an Ouroboros serpent consuming its own tail. But the attackers bungled the delete command inside the script by identifying the script file by the wrong name. Instead of commanding the script to delete LogWiper.sh, they commanded it to delete logging.sh. As a result, the LogWiper script couldn’t find itself and got left behind on servers for Kaspersky to find. Also left behind by the attackers were the names or nicknames of the programmers who had written the scripts and developed the encryption algorithms and other infrastructure used by Flame. The names appeared in the source code for some of the tools they developed. It was the kind of mistake inexperienced hackers would make, so the researchers were surprised to see it in a nation-state operation. One, named Hikaru, appeared to be the team leader who created a lot of the server code, including sophisticated encryption. Raiu referred to him as a master of encryption. And someone named Ryan had worked on some of the scripts.

21
The attackers seemed to have managed their project like a tightly run military operation, with multiple teams handling carefully compartmentalized tasks. There was a management team that oversaw the operation and chose the victims; there were coders who created the Flame modules and a command-and-control team who set up and managed the servers, delivered the Flame modules to infected machines, and retrieved stolen data from machines; and finally there was an intelligence team responsible for analyzing the stolen information and submitting requests for more files to be purloined from machines that proved to have valuable data. It was exactly the kind of setup that the Snowden documents suggested the NSA had.

The team operating the command servers had limited visibility into the overall operation and may not even have known the true nature of the missions their work facilitated. The process for uploading new modules to infected machines was tightly controlled so that neither they nor any outsiders who might gain access to the servers could alter the modules or create new ones to send to infected machines. The command modules, for example, were delivered to the servers prewritten, where they got automatically parsed by the system and placed in a directory for delivery to victims by the server team, who only had to press a button to send them on their way. Data stolen from victims was also encrypted with a sophisticated algorithm and public key. The private key to decrypt it was nowhere to be found on the server, suggesting that the data was likely passed to a separate team who were the only ones capable of decrypting and examining it.

22
The protocols were identified as Old Protocol, Old E Protocol, SignUp Protocol, and Red Protocol.

23
Two names—Flame and Flamer—appeared in different parts of the code. Kaspersky decided to call the malware Flame, but Symantec opted to call it Flamer in their report about it.

24
It was possible that at one point Gauss might have contained the same Windows font exploit that Duqu had used to install itself on machines, though there was no sign of it. If it had been used, the attackers might have removed it after Microsoft patched the vulnerability it exploited in 2011.

25
The attackers were checking to see whether a very specific program was installed on the machine, a program that was probably unique to the region in which it was located. The target program was unknown, but the Kaspersky researchers say it began with an odd character, and they believed, therefore, that the program might have had an Arabic or Hebrew name.

26
The discovery of SPE left two of the four pieces of malware used with the Flame servers undiscovered—SP and IP. Raiu guessed that SP was likely an early version of SPE that was not encrypted.

27
Gauss’s files were named after elite mathematicians and cryptographers, but SPE adopted a more populist approach, using names such as Fiona, Sonia, Tiffany, Elvis, and Sam.

28
When malicious files are submitted to VirusTotal, the website will send a copy of the file to any of the antivirus companies whose scanner failed to detect the file, though it will also sometimes send files that do get detected as well. The VirusTotal record for the submission of this early Stuxnet file shows that the file was submitted at least twice to the site, on November 15 and 24. Both times, only one out of thirty-six virus scanners on the site flagged the file as suspicious, which would have been good news for the attackers. Oddly, there is information missing in the submission record that generally appears in the records of other files submitted to the site. The category indicating the total number of times the file was submitted to the site is blank, as is the category indicating the source country from where the file was submitted, which might have provided valuable intelligence about the location of the attackers, if they were the ones who submitted the file, or about the first victim, if the file was submitted by someone infected with the file. It’s not clear whether that information was intentionally scrubbed from the record. VirusTotal was founded by a team of engineers in Spain, but Google acquired it in September 2012, just a couple of months before Symantec stumbled across this early Stuxnet version. Google did not respond to queries about why the data was missing from the record.