Windows Shell vulnerability confirmed as concern grows

by Steve Ragan - Jul 19 2010, 12:20

Security author and analyst Brian Krebs broke a story on Thursday about a new flaw in Windows that is being used to spread Malware. Since then, the Malware itself has sparked concern in certain SCADA circles and Microsoft has confirmed the Zero-Day attack.

Microsoft has confirmed the existence of a new vulnerability that is targeting Windows Shell, due to the fact that the Windows operating system incorrectly parses shortcuts. The *.LNK vulnerability, as it has been dubbed, is a clever find according to many experts. It was discovered after a Belarus-based anti-Virus company inspected a new piece of Malware.

The security firm, VirusBlokAda, reported its findings in June [link], but it wasn’t until it went to Krebs that the discovery gained mass attention. Testing has confirmed that the vulnerability will work on Windows XP, Windows Vista, Windows Server 2003/2008, and Windows 7.

How the *.LNK vulnerability works hasn’t been fully disclosed to the public, but enough research has been done that the basics of the attack are known. The flaw itself resides in how the icon for the shortcut is loaded by the Windows Shell. When the icon is loaded, Windows will not validate some of the parameters in a specially crafted shortcut file. Instead, Windows will blindly load whatever target the shortcut tells it to.

Microsoft has advised organizations and users to Disable AutoRun (AutoPlay) as one of the mitigation steps against this attack. However, AutoRun isn’t the only attack vector. Simply having the malicious shortcuts in a network share or folder on a system can lead to exploitation and infection as well. A victim needs only to browse to an infected location on the system for the attack to succeed.
 
In addition to AutoRun being disabled, Microsoft has encouraged IT administrators to disable the IconHandler key in the Windows Registry. Moreover, disabling the Web Distributed Authoring and Versioning (WebDAV) registry key is an option that will limit remote attacks. Information on these mitigations can be found in Microsoft Security Advisory 2286198.

The Malware itself, dubbed Stuxnet, has been flagged by several security vendors including Symantec, Sophos, ESET, Panda, Kaspersky, F-Secure, and Microsoft.

Stuxnet is the other side to this story. While the vulnerability in Windows Shell is serious enough, the additional concern stems from the fact that Stuxnet appears to have been created with a single purpose in mind. Namely, it was written to target SCADA systems. This conclusion comes from research performed by Frank Boldewin, a noted and respected Malware analyst.

Boldewin’s research discovered code strings in the Malware that targeted the WinCC SCADA system by Siemens. When targeting WinCC, Stuxnet will attempt to use default passwords to gain access. If that fails, then it does nothing.

In addition to targeting Siemens, Stuxnet uses a digital signature from Realtek Semiconductor Corp. The digital signature has since been revoked, but most SCADA environments will require that software be signed before it is allowed to run.

The assumption is that Realtek’s key was compromised, allowing it to be used maliciously. We’ve reached out to VeriSign for more information on this, as well as confirmation that it was in fact revoked.

Siemens issued a warning to customers and encouraged them to check their systems. In addition, Siemens also advised them to update security and system software and to stick to IT best practices when focusing on security.

“This Malware was written by real professionals to spy on SCADA systems. From what I’ve seen so far, they must have been very skilled to achieve such a piece of code. Next to the SCADA code they used a very smart way to exploit [a Zero-Day] vulnerability in all Windows systems to install the Malware,” Boldewin said in an email to The Tech Herald over the weekend.

We’d initially reached out to Boldewin to get his opinion on the Stuxnet and SCADA issue. We wanted to hear his thoughts for the potential for it to explode into something as overhyped as Conficker - if it wasn’t already.

He disagreed with our line of thought, adding that since the story about his research broke, many governments and companies had been in contact with him, each expressing fear over his discovery.

“Imagine [if Stuxnet] manages to steal important secrets, like manufacturing information from the car or aircraft industry or [worse], the code [that] controls a power plant or a missile system. That’s what SCADA systems are made for and governments and industries are aware and afraid of this,” Boldewin said.

“The code is very large (about 5000 functions) and it will still take some time until we have clarified all open questions, but from what I’ve analyzed so far, the results are anything but overhyped,” he added.

Boldewin also noted that it was likely a system such as the one targeted by Stuxnet was already hit, given it is widely known that SCADA systems are often unpatched, missing security software, and using default passwords.

Given that governments and organizations are worried, combined with the fact that SCADA systems are already insecure, should the fault land on their shoulders should they be infected?

“To a certain extent this might be correct. I think, as always, there are lots of reasons why systems might not be patched and hardened as they should,” outlined Boldewin. “Too less human resources, too less time, people who administer those systems are often not very well educated on how to harden systems. Sometimes even it’s not possible to easily install, let’s say, OS patches, because of side effects, which could harm the functionality of a SCADA system.”

The old adage, "if it ain't broke, don’t fix it," is a mainstay for many administrators. As long as nothing bad happens, then it isn’t worth the risk that you may break something by touching a working system. This, Boldewin says, should change.

“In my opinion, [the] time has come to reassess such phrases, because of the latest threats. A good test environment is needed to check if new patches or special security software like HIPS, Firewalls, [anti-Virus scanners] or just hardening configurations affect the correct functioning of a SCADA system. And after intensive tests, the security measures should be applied immediately. This strategy applies for other environments like as well of course.”

More Information:

Microsoft Malware Protection Center

Kaspersky Research Part 1, 2, and 3

US CERT - VU940193

Around the Web