It took 10 hours to find what had eluded others for close to five years.
German computer science student Michael Heerklotz spent the Christmas holiday reading Countdown to Zero Day, a narrative on the discovery and impact of Stuxnet, the computer worm considered one of the first cyberweapons, and which is accused of putting a serious dent in Iran’s development of nuclear weaponry.
The book inspired the University of Augsburg student to examine Stuxnet, specifically the .LNK vulnerability in the Windows shell that was exploited during the hack of the Natanz uranium enrichment facility.
Microsoft had patched the flaw in August 2010, and in the four-plus years since, no public reports of problems with the patch or residual effects from the vulnerability were ever heard. It was assumed that Windows machines that were patched against CVE-2010-2568 were in the clear.
“I wanted to take a closer look at the .LNK vulnerability by testing it on an old Windows XP installation, and then trying to figure out what Mircosoft did to fix it,” Heerklotz said in an email to Threatpost. “Amazingly, after about 10 hours, I found a way to bypass the fix, by abusing other parts of the .LNK code which Microsoft most likely did not check too carefully when they created the patch.”
Heerklotz reported in January what he’d found to HP’s Zero Day Initiative, a vulnerability disclosure program originally started by TippingPoint before it was acquired by HP. The program vets vulnerabilities, creates proof-of-concept code, and eventually shares its findings with the affected vendor while paying out a bounty to the researcher and giving its customers first dibs on a fix.
Yesterday, HP disclosed intimate details of what Heerklotz had discovered, hours after Microsoft produced a patch that took care of the Stuxnet bug—again.
“It was a bit tricky, but not too complicated, and it puzzles me that nobody discovered (and published) it earlier,” Heerklotz said. “Other researchers have looked at the patch, too, but I guess nobody invested too much time, because everything seemed to be OK.”
The .LNK vulnerability was part of Stuxnet’s arsenal as it went after Iran’s nuclear program with a barrage of zero-day exploits targeting Windows vulnerabilities, as well as shortcomings with Siemens programmable logic controllers (PLCs) in charge of centrifuge operations inside Natanz.
“That patch didn’t completely address the .LNK issue in the Windows shell, and there were weaknesses left behind that have been resolved in this patch,” said Brian Gorenc, manager of vulnerability research with ZDI. Gorenc said the vulnerability works on Windows machines going back to Windows XP through Windows 8.1, and the proof of concept exploit developed by Heerklotz and tweaked by ZDI evades the validation checks put in place by the original Microsoft security bulletin.
From a high level, Stuxnet was launched after a USB drive was inserted into an air-gapped machine at the facility that was loaded with an exploit for a Windows vulnerability that would execute when a user browsed a directory or folder containing the .LNK exploit, HP said.
“Windows allowed for .LNK files, which define shortcuts to other files or directories, to use custom icons from .CPL (Control Panel) files. The problem is that in Windows, icons are loaded from modules (either executables or dynamic link-libraries). In fact, .CPL files are actually DLLs,” HP said in its advisory. “Because an attacker could define which executable module would be loaded, an attacker could use the .LNK file to execute arbitrary code inside of the Windows shell and do anything the current user could.”
Microsoft’s answer in the August 2010 patch was to whitelist which .CPL files could load non-standard icons for links.
HP explains the bypass in detail in its advisory, adding that for all of its necessary investments in memory corruption attack mitigations, Microsoft paid in this instance for a 10-year-old decision to load such shortcut icons by loading executable modules into the process.
“The Windows operating system itself will handle resolving ASLR and loading the attack into executable memory. And because of that, the attack is stable, reliable, and works cleanly across Windows versions. Microsoft has gone to a great deal of effort to make exploitation of memory corruption bugs more difficult,” HP said. “This is a classic example of the Defender’s Dilemma — the defender must be strong everywhere, while the attacker needs to find only one mistake.”
