Download here

We have developed this tool to detect all kinds of viruses exploiting .lnk vulnerability. Computer users can download and scan with the tool to check if their computers are infected with the viruses.

Detect .lnk shortcut file virus tool

Our monitoring system has detected some virus samples taking advantage of this vulnerability. Microsoft Windows .lnk vulnerability is a critical flaw. Many different kind of viruses would exploit the flaw to infect users’ computers. Meanwhile, no patch or workaround for the flaw has been released by Microsoft.

Thus, we would like to provide the tool to help users check if their computers are infected with viruses exploiting the .lnk vulnerability.

You can download “Detect .lnk shortcut file virus tool” here.

Bkis

.lnk file is the format of the Windows’ shortcuts. The vulnerability recently found in this format actually lies in the way Windows processes the Control Panel shortcuts. Normally, these shortcuts are processed as below:

Control Panel

Each Control Panel shortcut is linked to an executable file. For example, shortcut “Automatic Update” is linked to Windows’ update utility. Windows, specifically Windows Shell, will load a PE file with .cpl extension to get icon from its resource to display this shortcut’s icon. In this case, the PE file loaded is “C:\Windows\System32\wuaucpl.cpl”.

Taking advantage of Windows Shell’s loading PE file to display the shortcut’s icon, hacker is able to create a Control Panel shortcut file with a path to a  malicious file. When Windows Shell performs the abovementioned steps to display shortcut’s icon, the malicious file will be loaded. The figure below describes the parsing process of crafted Control Panel shortcut to load malicious file:

The parsing process of crafted Control Panel shortcut

Below is the description of the Control Panel shortcut format which is used to exploit the vulnerability:

Crafted shortcut file format

So, to execute an arbitrary malicious file (in this case, it is DLL file), which may be located in a USB drive just like Autorun feature, hacker only needs to create the lnk format with the path in “fake cpl path file” linking to the malicious file.

Bui Quang Minh
Senior Security Researcher
Bkis Global Taskforce

In previous blog entry, I commented that the latest patch of Adobe still cannot fix PDF launch vulnerability. Adobe has confirmed this issue on their blog. Accordingly, Brad Arkin, Director of Product Security and Privacy for Adobe Systems, said that the solution in the latest patch for /Launch flaw is “not a perfect solution”.

The flaw still remains and the risk for users remains large. Adobe should release the next patch as soon as possible.

According to Adobe blog, blacklist has been used to fix the flaw. Brad says that blacklist bypassed by using quotes makes the mistake. However, I think that Adobe can still resolve the problem by using blacklist mechanism.

My advice is: standardize the parameter string passed to /Launch before comparing with blacklist, a basic principle in secure coding. Thus, fixing the flaw is easy.

I have emailed Adobe. I hope that they would soon release a complete patch.

Le Manh Tung
Senior Security Researcher

On June 29, 2010, Adobe has published its security updates for Adobe Reader and Adobe Acrobat (APSB10-15). Among many vulnerabilities fixed this time, the noticeable one is /Launch vulnerability (CVE-2010-1240), which is said to be found by Didier Stevens. However, it is pity that the patch is not working properly.

/Launch vulnerability was released by Didier on March 29, 2010. Since then, many viruses in the wild have taken advantage of the flaw:

• Virus using /Launch exploit code in MSF
• Virus exploiting the true nature of PDF /Launch vulnerability

It takes Adobe three months to release the patch. I think it is delayed for too long.
On the blog entry, Didier confirms that Adobe has completely fixed the flaw. Thus, I decide to check the patch carefully, and the patch turns out to be incomplete.

Firstly, I check the exploited PDF file with the latest version of Adobe Reader.

Before version 9.3.3

Version 9.3.3:

The patch seems to be working. Now, what would happen if I modify the exploit code a bit?

Specifically, I add the quotes to the parameters passed to /F.

Eg: /F(cmd.exe) becomes  /F(“cmd.exe”)

With the quotes added, Adobe Reader will not block the execution and the warning becomes as follow:

After pressing Open, cmd.exe will be executed!!!

So, Adobe Reader version 9.3.3 has fixed the fake warning massage, but the threat of exploit code execution still remains.

Le Manh Tung
Senior Security Researcher