Puzzle box: The quest to crack the world’s most mysterious malware warhead
State-sponsored Gauss contains secret warhead eluding global cracking experts.
When Stuxnet was found infecting hundreds of thousands of computers worldwide, it was only a matter of time until researchers unraveled its complex code to determine its true intent. Today, analysts are up against a similar challenge. But they're finding considerably less success taking apart the Stuxnet cousin known as Gauss. A novel scheme encrypting one of its main engines has so far defied attempts to crack it, generating intrigue and raising speculation that it may deliver a warhead that's more destructive than anything the world has seen before.
Gauss generated headlines almost immediately after its discovery was documented last year by researchers from Russia-based antivirus provider Kaspersky Lab. State-of-the-art coding techniques that surreptitiously extracted sensitive data from thousands of Middle Eastern computers were worthy of a James Bond or Mission Impossible movie. Adding to the intrigue, code signatures showed Gauss was spawned from the same developers responsible for Stuxnet, the powerful computer worm reportedly unleashed by the US and Israeli governments to disrupt Iran's nuclear program. Gauss also had links to the highly advanced Flame and Duqu espionage trojans.
Gauss contains module names paying homage to the German mathematicians and scientists Johann Carl Friedrich Gauss, Kurt Friedrich Gödel, and Joseph-Louis Lagrange. Its noteworthy features only start there. Gauss has the ability to steal funds and monitor data from clients of several Lebanese banks, making it the first publicly known nation-state sponsored banking trojan. It's also programmed to collect a dizzying array of information about the computers it infects—including its network connections, processes and folders, BIOS, CMOS, RAM, and both local and removable drives.
But the most intriguing characteristic of Gauss is an encrypted payload that has so far remained undeciphered, despite the best efforts of cryptographers who have already tried millions of possible keys. Tucked deep inside the Gödel module, the secret warhead is loaded onto USB sticks and removable drives when they're connected to Gauss-infected machines. When the drives are plugged into an uninfected computer later, the mysterious code is executed—but only if it encounters the specific machine or machines targeted by the Gauss developers. On every other computer, the module remains cloaked in an impenetrable envelope that prevents researchers and would-be copycats from reverse engineering the code. The extreme stealth has stoked speculation that the payload may contain a potent exploit that could rival the Stuxnet attack that was bent on destroying uranium centrifuges inside Iran's high-security Natanz enrichment facility. Certainly not your everyday malware.
"Considering the link with Flame and Stuxnet, the payload of Gauss
must be of similar magnitude," Costin Raiu, director of Kaspersky Lab's
global research and analysis team, told Ars. "Given how careful the
attackers were to make sure the Gauss payload doesn't fall into the
'wrong' hands, we can assume it is very special."
Enlarge / The Gauss architecture.
Built to last
Gauss is by no means the first malware with a payload that was programmed to remain dormant unless it was installed on computers meeting a narrow set of criteria. Stuxnet also contained code instructing it to destroy uranium-enrichment centrifuges only when they were physically located at Natanz. Researchers have theorized that the trigger was implemented to reduce the chances of collateral damage that might result if Stuxnet took hold in other facilities. (The precaution proved wise, since Stuxnet infected more than 100,000 computers scattered all over the globe.)But as cryptographer Nate Lawson observed more than two years ago, the mechanism Stuxnet used to protect unintended targets from destruction was surprisingly crude for an otherwise advanced cyberweapon developed by countries with almost unlimited budgets. The coding techniques were largely limited to conditional "if/then" range checks that identified computers running German conglomerate Siemens's Simatic Step7 software inside Natanz. If an infected computer met the criteria, the sabotage payload was activated. If not, the exploit sat dormant.
Noticeably absent from Stuxnet was any kind of mechanism preventing researchers, enemies, or potential copycat programmers from peering inside the malware to see what the highly selective payload did. That's precisely what security experts such as Ralph Langner did following the Stuxnet discovery. Within a few weeks, the world had its answer: Stuxnet was a powerful cyberweapon unleashed by a well-resourced government bent on sabotaging Iran's nuclear program. While the developers may have taken care to prevent the worm from attacking other countries, they did little to conceal the true aim and methods of their malware, which attacked programmable logic controllers at the heart of the enrichment process.
"Encrypting your payload so that only the intended target can decrypt it hides both the identity of the victim and the worm's purpose," Lawson recently told Ars. "If Gauss came after Stuxnet, it's clear the authors disliked the publicity its PLC [programmable logic controller] payload received and made an effort to hide it properly the second time."
The notion of software containing a "secure trigger" isn't new either. Scientists such as Fritz Hohl theorized about it as early as 1998 in a paper titled "Time Limited Blackbox Security: Protecting Mobile Agents From Malicious Hosts." Researchers from security firm Core Security expanded on the idea eight years later in a paper titled "Foundations and applications for secure triggers." The idea was to use strong cryptography to ensure a piece of code or content remained secret until a particular event occurred. Once the preselected condition was met—and only if it was met—the concealed payload was automatically disclosed or executed. Otherwise it remained locked inside an impenetrable vault.
Gauss developers implemented this advanced concept using a
surprisingly unsophisticated set of tools. That set includes the
relatively archaic RC4 cipher to encrypt three sections of the Gödel module and the cryptographically weak MD5 algorithm
to generate the key. Gauss developers likely chose the outdated design
because it worked reliably across a broad range of Windows computers
thanks to the Microsoft CryptoAPI.
Keys unlocking the Gödel payload are generated dynamically based on the
settings of one or more computers that were specifically targeted by
the attackers. Only the machine or machines containing a specific set of
programs and directories will generate the key. To confound people
trying to crack the code—and to considerably slow the speed at which
they work—Gauss MD5 hashes the configuration data 10,000 times and uses
the final output as the key that unlocks the encrypted code.
Gödel's mysterious encrypted data is stored in three sections.
If a hash value passes the verification check, Gauss has located the mysterious PATH and program file that the Gödel module was programmed to find. It then takes that string, appends a new salt value to it, and hashes it 10,000 times. The resulting hash is the RC4 key used to decrypt one of the three encrypted Gödel sections. If the decrypted block passes an additional verification check, Gauss takes the same path and program files string, then appends a different hard-coded salt to decrypt sections two and three.
Enlarge / A simplified flow-chart showing Gödel's decryption routine.
Example of the string pair, second string starting from “~dir” and first salt.
Literally take forever
The use of real Windows configuration variables poses some unusual challenges for cryptographers trying to crack the payload. While the number of possible inputs, for instance, could theoretically be 21000 or higher, the actual number is almost certainly far lower since real-world path strings are almost always in human-readable form. (While a password may randomly be generated, path strings typically follow conventions such as "C:\Program Files\Common Files\Microsoft Shared\Windows Live.") Then again, the strings still have the ability to incorporate unique names or even randomly generated values few eyes have ever seen before. The likelihood that the sought-after Program Files folder contains characters from a different language could pose its own obstacles and benefits. While it narrows the possible choices, it may also require crackers to incorporate alphabets bigger than those that include standard English characters."Password cracking becomes more difficult as the input space grows," Karsten Nohl, a cryptographer with Security Research Labs, told Ars. "The input space for the Gauss unlock password is all names of Windows programs in certain languages, which should be a relatively small space compared to the billions of combinations a password cracker typically tries. However, nobody has a complete list of Windows programs."
He continued: "To find the Gauss unlock password, good heuristics are needed that guess Windows program names. Simply brute-forcing the space from 'אאא...' to 'תתת...' is not an option as it would literally take forever."
So far, Kaspersky researchers have tried millions of combinations to no avail. In December, they redoubled their efforts by recruiting the creator of the Hashcat password recovery program. That resulted in ocl-GaussCrack, an open-source application that streamlines the cracking of the Gödel module and harnesses the speed of graphics cards to accelerate the process. Typically, GPU crackers can try billions of guesses per second against MD5-derived hashes, but thanks to the design of the encryption routine, GaussCrack can achieve just 489,000 candidate passcodes each second. Posing yet another burden on crackers, the Gauss architects were able to hinder crackers by iterating the hash 10,000 times, a technique often referred to as key stretching.
Just as the amassing of hundreds of millions of real-world passwords has fueled recent advances in password cracking, a comprehensive corpus of likely Windows configurations targeted by Gauss is the most likely way to solve the Gödel mystery. Jens Steube, the Hashcat and GaussCrack developer better known as Atom, said he still hasn't settled on the best method for compiling the data. One possibility is to tap into databases already assembled by antivirus companies or other vendors of software that collect the names of programs installed on hundreds of millions of computers. Another possibility, Kaspersky's Raiu said, is to seek help from the National Institute of Standards and Technology or a similar organization.
The encrypted payload in the Gödel module is by no means the only mystery surrounding Gauss. Researchers still don't know how the malware takes hold of target computers in the first place or how it spreads from one machine to another. They're also at a loss to explain why Gauss installs a custom font known as "Palida Narrow" and corresponding registry values on infected machines. Analysts have speculated that the font may be used to steganographically fingerprint the author of certain printed materials. Under alternate theories, Palida Narrow, which appears to contain valid Western, Baltic, and Turkish symbols, may provide a simple means for websites to identify infected machines, or even open a font-based vulnerability to exploit.
Still, the biggest mystery connected to Gauss undoubtedly remains the encrypted payload tucked inside its Gödel module. Given the destruction malware creators brought about with Stuxnet, it wouldn't be a stretch if Gauss targeted additional enemy-operated PLCs or an entirely unseen class of equipment in the fledgling annuls of computer warfare. The choice that Gödel be transmitted using USB drives suggests it was targeting "air-gapped" systems so sensitive they weren't connected to the Internet.
"It's one of the biggest mysteries of our times and this is a very cool challenge for any security researcher out there who cares about security," Raiu told Ars. "What could we find inside the Gauss payload? PLC code? Zero-days? Code to target unknown systems? Nobody knows for sure and it is probably the incertitude which makes it the most captivating mystery."
Thanks to Jeremy Gosney of Stricture Consulting Group, Hashcat developer Jens Steube, and Johns Hopkins University professor Matt Green for their assistance in reporting this story. Story updated to add "reportedly" in first paragraph.
No comments:
Post a Comment