Governance & Risk Management , IT Risk Management , Patch Management

A Flaw Used by Stuxnet Wasn't Fully Fixed

Black Hat Conference Research Spots Windows Print Spooler Problems
A Flaw Used by Stuxnet Wasn't Fully Fixed
Illustration: Brother UK via Flickr/CC

Peleg Hadar, a senior security researcher with SafeBreach, went hunting for bugs in Windows. He wasn't sure just what he would find, but he knew where he wanted to look: the print spooler service.

See Also: Maintain a Clear Bill of (Third-Party Risk) Health

Peleg Hadar

The print spooler is an executable file that acts as a conductor when someone is trying to print. It finds and loads the right driver and schedules the print job. It's been around for decades, and its codebase has grown as it has grown long in the tooth.

"I was just looking at different [Windows] mechanisms, and I've seen that once you send the print job, a lot of things happen," says Hadar, who works in Israel. "So I started to go even deeper and - I don't know - I just love to look at something and understand how it [the print spooler] works. It just looked interesting."

Link to Stuxnet

Hadar sought to determine if there were unknown vulnerabilities still lurking in the print spooler service. Sure enough, there were. And the vulnerabilities uncannily relate to issues uncovered in the investigation into one of the most clever and sophisticated pieces of malware ever created: Stuxnet.

Hadar and his colleague, Tomer Bar, a research team manager at SafeBreach, will present their research Thursday at the Black Hat security conference, which is a virtual event this year due to the pandemic.

Tomer Bar

Stuxnet represented an unheralded effort by the U.S. and Israel to delay Iran's development of a nuclear weapon. Stuxnet's ultimate goal was to sneak into air-gapped Siemens refinement equipment and meddle with programmable logic controllers. The malicious code then caused centrifuges to spin out of control despite reporting that nothing was awry.

But Stuxnet had to reach the programmable logic controllers first, an infiltration act that ended up using four zero-day vulnerabilities in Windows, including one involving the print spool service.

That print spool vulnerability, MS10-061, was eventually fixed by Microsoft. The remote code execution vulnerability allowed a remote, unauthenticated attacker to execute arbitrary code on Windows and take complete control of the system.

Microsoft Patches

But 10 years later, Hadar and Bar found the patch still had problems. They found a new vulnerability that could allow an attacker to create a denial-of-service condition that would crash the print spool service. The attacker, however, would have to be on the same machine.

Digging deeper, they found a second issue that would enable an attacker to exploit the print spool mechanism to gain privilege escalation with just a few lines of C code or PowerShell code. That could allow an attacker to install new programs or create accounts.

"It's very easy to exploit," Hadar says. "It makes it more risky."

SafeBreach alerted Microsoft, and it quickly patched the issue (CVE-2020-1048) in May, Hadar says.

At Black Hat, Hadar and Tomer plan to show two proof-of-concept attacks written in Python, one for the denial-of-service issue and another for the CVE-2020-1048 issue patched by Microsoft.

"People can test their own machines and understand if they are vulnerable or not," Hadar says.

There's also another surprise in their presentation, Hadar says, but he can't say more now.

Addressing Another Issue

Hadar says SafeBreach will also release a kernel mode driver that demonstrates how it may be possible to mitigate a common type of bug class: arbitrary file right vulnerabilities that allow attackers to gain privilege escalation. The driver will also be released on SafeBreach's GitHub page.

Hadar cautions that it's not production code, but he hopes that it may stimulate researchers as well as Microsoft as to ideas on how to stop an entire class of bugs.

"I don't want to say it will kill all of the vulnerabilities but we do think it will multiple ones," Hadar says.


About the Author

Jeremy Kirk

Jeremy Kirk

Managing Editor, Security and Technology, ISMG

Kirk is a veteran journalist who has reported from more than a dozen countries. Based in Sydney, he is Managing Editor for Security and Technology for Information Security Media Group. Prior to ISMG, he worked from London and Sydney covering computer security and privacy for International Data Group. Further back, he covered military affairs from Seoul, South Korea, and general assignment news for his hometown paper in Illinois.




Around the Network

Our website uses cookies. Cookies enable us to provide the best experience possible and help us understand how visitors use our website. By browsing bankinfosecurity.co.uk, you agree to our use of cookies.