Windows zero-day exploit?: USB storage + .lnk files + file explorer = FAIL

Update 07-17-2010 – 6:45 PM (CST) I’ve added a couple more late-breaking details added to the bottom of the post

The best summary brief on the issue I’ve seen comes from F-Secure Weblog: Espionage Attack Uses LNK Shortcut Files. Quoting…

There's a possible new zero day in the wild which is being used in targeted espionage attacks. Belorussian antivirus company, VirusBlokAda, recently published news about two new rootkit samples, and quite interestingly, the infection vector is a USB storage device and Windows shortcut [.LNK] files.

The rootkit uses a LNK file that infects the operating system when viewed by an icon rendering file explorer such as Windows Explorer or Total Commander.

According to Krebs on Security, the method is capable of infecting a fully patched Windows 7 computer.

From Krebs: Jerry Bryant, of Microsoft, stated that "Microsoft is investigating new public claims of malware propagating via USB storage devices. When we have completed our investigations we will take appropriate action to protect users and the Internet ecosystem."

Our initial analysis of the samples appears to indicate that the shortcuts somehow take advantage of the way in which Windows handles Control Panel shortcut files.

Got the gist?

According to Microsoft, it appears all versions of Windows from XP through Windows 7 are vulnerable to this attack method.  Oh bother!

OK, more reading now:

• Experts Warn of New Windows Shortcut Flaw - Krebs on Security
• Windows zero-day attack works on all Windows systems - Chester Wisniewski’s Blog
• Windows zero-day vulnerability uses shortcut files on USB - Chester Wisniewski’s Blog
• Espionage Attack Uses LNK Shortcut Files - F-Secure Weblog : News from the Lab
• More Analysis of Case LNK Exploit - F-Secure Weblog : News from the Lab
• Malware Targets Shortcut Flaw In Windows, SCADA – Slashdot Comments
• Microsoft Security Advisory (2286198): Vulnerability in Windows Shell Could Allow Remote Code Execution – MS TechNet.
• The Stuxnet Sting - Microsoft Malware Protection Center

Finally initial deep analysis for the hard-core set:

• Trojan-Spy.0485 and Malware-Cryptor.Win32.Inject.gen.2 Review (PDF) by Kupreev Oleg and Ulasen Sergey of VirusBlokAda as linked to and hosted by F-Secure Weblog.

The current thinking is that an expired but still valid Realtek Semiconductor Corp driver signing certificate is being used to load/install the root-kit malware files “mrxnet.sys” and “mrxcls.sys”. 

Microsoft also reported they have worked with VeriSign and Realtek and now have had the particular driver-signing certificate used in this initial attack revoked.

From the Microsoft Malware Protection Center Post:

Threat details

What is unique about Stuxnet is that it utilizes a new method of propagation. Specifically, it takes advantage of specially-crafted shortcut files (also known as .lnk files) placed on USB drives to automatically execute malware as soon as the .lnk file is read by the operating system. In other words, simply browsing to the removable media drive using an application that displays shortcut icons (like Windows Explorer) runs the malware without any additional user interaction. We anticipate other malware authors taking advantage of this technique. Stuxnet will infect any usb drive that is attached to the system, and for this reason we’ve classified the malware as a worm.  This classification for the malware should not be confused with another vector used by this worm, the newly disclosed vulnerability (CVE-2010-2568) covered in today’s advisory.  The vulnerability itself is not wormable.

Stuxnet uses the aforementioned .lnk technique to install additional malware components.  It first injects a backdoor (Worm:Win32/Stuxnet.A) onto the compromised system, and then drops two drivers:

• Trojan:WinNT/Stuxnet.A - hides the presence of the .lnk files
• Trojan:WinNT/Stuxnet.B - injects (formerly) encrypted data blobs (.tmp files) into memory, each of which appear to serve different purposes as the Stuxnet deployment system infrastructure (drivers, .lnk files, propagation, etc.).

These drivers are signed with a digital certificate belonging to a well-known hardware manufacturer called Realtek Semiconductor Corp., which is unusual because it would imply that the malware authors somehow had access to Realtek’s private key.  Microsoft MMPC has been working with Verisign to revoke this certificate, and did so at 08:05:42 PM UTC with the agreement and support of Realtek.

Also the fact that currently some evidence exists that Siemens WinCC SCADA systems seem to be the target could be based on the fact they seem to require use of a standard id/password set to correctly operate.  However that is sure to change as other attackers build upon the now disclosed vulnerability.

A workaround (temporary fix) offered by Microsoft in the Microsoft Security Advisory (2286198) is to disable the display of icons for shortcuts as follows:

1. Click Start, click Run, type Regedit in the Open box, and then click OK

2. Locate and then click the following registry key:
HKEY_CLASSES_ROOT\lnkfile\shellex\IconHandler

3. Click the File menu and select Export

4.In the Export Registry File dialog box, enter LNK_Icon_Backup.reg and click Save
Note This will create a backup of this registry key in the My Documents folder by default

5.Select the value (Default) on the right hand window in the Registy Editor. Press Enter to edit the value of the key. Remove the value, so that the value is blank, and press Enter.

6. Restart explorer.exe or restart the computer.

Impact of workaround.Disabling icons from being displayed for shortcuts prevents the issue from being exploited on affected systems. When this workaround is implemented, shortcut files and Internet Explorer shortcuts will no longer have an icon displayed.

It seems that most all GUI-based Windows file explorer tools, including those not from Microsoft, could trip the vulnerability when used to view an infected USB storage device. One such text-based Windows file explorer tool that does not is reported to be Far Manager so you probably would do well to keep a version of this one on your systems when doing examinations of USB devices.

Of course, it might be even better to use a lab-system, and one running a LiveCD distro of a Linux-based OS to do your suspect USB storage device examinations….just saying…

Finally, incident responders might also be well to know that Windows Incident Response bloggest Harlan Carvey has also weighed in on this, as well as the issues it illustrates for responders:

• Windows Incident Response: Exploit Artifacts redux – WindowsIR blog

Whew!

This is still a breaking event so I’m sure more information will be coming in the days ahead as everyone devotes more resources to research and analysis (and hopefully Microsoft with a vulnerability patch…unless it turns to be a “feature”).

Update 07-17-2010 – 6:45 PM (CST)

The H Security team in their Trojan spreads via new Windows hole post adds this observation:

Microsoft has been informed about the vulnerability, but appears to have problems with reproducing it. Andreas Marx of AV-Test says that every .lnk file is linked to the ID of the newly infected USB Flash drive. This means that the sample trojans found so far can't simply be started on an arbitrary Windows system – the malware will only start in the OllyDbg debugger after some modifications to the code.

And the SANS-ISC Storm Center Handler’s Diary has this post Vulnerability in Windows "LNK" files? with findings from the handler’s work on malcode they got their hands on.  Quoting from Bojan’s update to the article notice,

I've tested the exploit and can confirm that it works in Windows XP, Vista and Windows 7. The exploit uses a specially crafted LNK file. This file allows the attacker to execute an arbitrary file by carefully specifying its location – the LNK file in itself does not exploit any vulnerability such as buffer overflows, for example, so it is a legitimate LNK file. The LNK file used in targeted attacks was manually crafted as some fields that are normally present, such as CreationTime, AccessTime or WriteTime are all set to 0.

I will not be posting details about how the exploit works, but here are some things that you should be aware of:

• If autorun is disabled, when a USB device with malicious LNK files is inserted, the exploit will not be triggered automatically.
• The exploit is triggered every time a folder containing a malicious LNK files is opened (for example, with Windows Explorer). It does not matter where this folder is – it does not have to be on a USB device, but in order to execute to malicious binary, the attacker has to specify its location correctly.

What makes this vulnerability extremely serious is the fact that it can be opened from any place, including remote shares, for example. The victim just has to browse to the remote share in order to trigger the vulnerability. So double check permissions on any remote shares you use in your companies (you shouldn't allow users to write in root folders, for example).

Seems like it’s a security-focused posting weekend here at GSD!

Cheers!

--Claus V.