.LNK Exploits – Shortcuts to Insecurity
The vulnerability in Windows Shell’s parsing of .LNK (shortcut) files presents some interesting and novel features in terms of its media lifecycle as well as its evolution from zero-day to patched vulnerability. For most of us, the vulnerability first came to light in the context of Win32/Stuxnet, malware that in itself presents some notable quirks.
For a short time, at least, you could have said that the .LNK exploit itself was a more effective attack than the Autorun/Autoplay attack that malware has (all too efficiently) used for some years. And I do mean efficient. Generic detection for Autorun-exploiting malware has consistently ranked number one or number two in our monthly prevalence statistics for as long as I’ve been involved in analyzing those statistics. However, because of the very different ways in which different companies implement detection, other vendor statistics may show dramatic differences. This isn’t an indicator of relative performance, by the way. It’s about how malware is named and the details of implementation, not overall detection performance.
Microsoft’s reluctance to disable Autorun/Autoplay as a default – at least in versions of Windows prior to version 7 – has not done the user population any favors. At least it can be disabled fairly easily. But until Microsoft released their patch, avoiding the .LNK problem was more difficult. The issue is actually a problem in the way that the Windows Shell parses shortcut files, enabling a specially crafted icon to allow remote code to be executed, a classic entry point for malware and other attacks. Disabling Autorun didn’t help, and the nature of the vulnerability meant that on an unpatched, unprotected system, there was no need for social engineering tricks to persuade the victim to click on something. Just the presence of a malicious icon on a USB device (or indeed a network or webDAV share) was enough to launch the attack when the drive or share was first mounted.
And that brings us back to Win32/Stuxnet. Its author(s) found – or maybe bought, as Kurt Wismer has suggested – a zero-day threat that gave a new lease of life to an attack that, according to Symantec, may have been around for over a year, although how active and effective it was in its previous incarnations has not, to date, been determined. Buying information on the vulnerability would be consistent with the suspicion that the authors may also have bought the certificates used for digitally signing two of the drivers installed by the malware. For instance, they could have bought from the gang behind the Zeus botnet, which is known to steal certificates. However, as those certificates belonged to companies (Realtek and JMicron) at the same geographical location, it’s not impossible that this was the result of a physical attack.
What most people found fascinating about Stuxnet, though, was the fact that it specifically targeted SCADA (Supervisory Control And Data Acquisition) systems designed by Siemens. And indeed, when our lab first analysed it, we were struck by the unusual geographical dispersion of reports. While the political interest of SCADA installations in the U.S. and/or Iran is obvious, we certainly learned something about power generation in the Faroe Islands. But the exact nature and source of the attacks also remains speculative. We do think that the source is probably not one of the gangs we’re accustomed to dealing with. In part, that comes from analysis of the code. However, we’re also going by the quirky use of self-replicating malware to deliver a payload suggesting industrial or military espionage. (Given that many of the components of a critical national infrastructure are often installed, maintained and even owned by the private sector – banks. for example – the borderline between industrial and military spying and sabotage is often fuzzier than you might think.)
Think about that for a moment. A few years ago, in the heyday of the virus and worm, malware authors were mostly driven by dreams of personal glory (or notoriety), and malware that spread fast and/or far enough grabbed lots of attention. Some more modern malware also benefits from wide exposure. While banking Trojans, for example, forgo the joys of self-replication for dissemination by a spammed link, such links are spammed far and wide by phishing emails. Fake security programs are promulgated using blackhat SEO (Search Engine Optimization), maximizing the exposure of potential victims to malicious sites. But these are all untargeted attacks, taking a scattergun approach to hitting as many mailboxes as possible in the hope of getting enough responses to make a healthy profit.
Espionage is, you might think, a Trojan horse of a different color. You would expect malware designed to monitor industrial processes to be highly targeted. That not only reduces the likelihood of early detection by security vendors, but also increases the likelihood that the social engineering hook will work, because it’s tailored to the circumstances of the recipient and potential victim. We already know that the combination of a zero-day exploit and targeted social engineering works effectively. Gangs like NCPH (a group of Chinese hackers for hire with strong ties to the Chinese military) were using unpatched Microsoft Office vulnerabilities to install malicious code in 2006 and earlier. Ken Dunham and Jim Melnick describe in the AVIEN Malware Defense Guide how one individual in an energy sector company in the U.S. was targeted for emails using PowerPoint and Word files to deliver a payload. “In this case, only one individual within the company was targeted, and with just two messages socially engineered for maximum success.”
Win32/Stuxnet is no Conficker, creating botnets with millions of nodes. The number of systems it’s infected is tiny, by comparison. But its impact goes far beyond the four engineering systems that Siemens claims it has affected, and even beyond the other systems it has infected in passing. By bringing the CVE-2010-2568 vulnerability to the world’s attention, it not only ensured detection for the immediate threats, but more generic detections for the vulnerability. I don’t expect much media acknowledgement of the fact, but this was an instance of the AV industry filling a gap while Microsoft worked on a fix that didn’t entail banishing shortcuts and/or webDAV, registry hacking and so on. That’s just as well, too, because the publicity for the vulnerability also ensured that other malware, old and new, also tried to make use of it, notably Win32/Chymine, Win32/Vobfus, Win32/Sality, and a number of others.
So, all’s well that ends well, then? Well, if your system has been patched, your exposure to any further attempts to use the exploit has been much reduced. (The patch won’t stop malware using other vectors, of course). Spooky SCADA intruders will have to look for other exploits to carry out targeted attacks on fully-patched sites. And the Department of Homeland Security has, it seems, resolved to expand its specialized forensic resources to address attacks on critical control systems. Still, one has to wonder how many horses were left the stable before this particular stable door was bolted.
