Jump to content

New Windows .LNK vulnerability


Guest wsxedcrfv

Recommended Posts

Guest wsxedcrfv

http://www.microsoft.com/technet/security/advisory/2286198.mspx

See also:

http://www.computerworld.com/s/article/9179299/Microsoft_confirms_nasty_Windows_zero_day_bug?taxonomyId=17&pageNumber=1

--------------

Computerworld - Microsoft on Friday warned that attackers are exploiting a critical unpatched Windows vulnerability using infected USB flash drives.

The bug admission is the first that affects Windows XP Service Pack 2 (SP2) since Microsoft retired the edition from support, researchers said. When Microsoft does fix the flaw, it will not be providing a patch for machines still running XP SP2.

In a security advisory, Microsoft confirmed what other researchers had been saying for almost a month: Hackers have been exploiting a bug in Windows "shortcut" files, the placeholders typically dropped on the desktop or into the Start menu to represent links to actual files or programs.

--------------

And

--------------

According to Microsoft, Windows fails to correctly parse shortcut files, identified by the ".lnk" extension. The flaw has been exploited most frequently using USB flash drives. By crafting a malicious .lnk file, hackers can hijack a Windows PC with little user interaction: All that's necessary is that the user views the contents of the USB drive with a file manager like Windows Explorer.

--------------

Anyone know if Windows 9x/ME is vulnerable to this?

Anyone know if there is any proof-of-concept code that can be tested?

--------

Ok, here is POC code:

http://blog.zoller.lu/2010/07/cve-2010-2568-lnk-code-execution-proof.html

The link file (suckme.lnk_) nor it's target (dll.dll) are not identified as a threat by ANY AV programs at virustotal.com. When I rename "suckme.lnk_" to "suckme.lnk", the icon turns into a shortcut, but nothing else seems to happen. The properties for the .lnk file doesn't show a target, and when I "find target", the control panel opens. Double-clicking on the shortcut also opens the control panel.

Edited by wsxedcrfv
Link to comment
Share on other sites


I do love MS way of presenting things:

Mitigating Factors

Mitigation refers to a setting, common configuration, or general best-practice, existing in a default state, that could reduce the severity of this issue. The following mitigating factors may be helpful in your situation:

  • An attacker who successfully exploited this vulnerability could gain the same user rights as the local user. Users whose accounts are configured to have fewer user rights on the system could be less impacted than users who operate with administrative user rights.
  • When AutoPlay is disabled, the user would manually have to launch Windows Explorer or a similar application and browse to the root folder of the removable disk.
  • Blocking outbound SMB connections on the perimeter firewall will reduce the risk of remote exploitation using file shares.

They manage to make it sound like it's your fault because you "browsed the root folder of a removable disk", like it was NOT the main thing one has the removable disk for in first instance, and like Windows Explorer was NOT their own crappy program. :whistle:

jaclaz

Link to comment
Share on other sites

It looks like to test you'd put the shortcut and dll file in your C: drive's root folder, then browse to said folder. I haven't scrutinized dll.dll so don't know what it is (and I didn't test it).

I tried copying calc.exe to C:\ and renaming it dll.dll and then using the shortcut, but on my 98SE machine, this didn't lead to code execution. I'll try on XP and Win7 later. From what I recall when I was messing with the shortcut file format a few months ago, the shortcut file looks like it might be a newer format than 9x uses, as in, the exploit may rely upon features added to shortcut parsing after 9x.

Queue

Link to comment
Share on other sites

It's using a rootkit to hide the files after the .LNK exploit has already been used to install the rootkit. The rootkit is just the payload and has no bearing on if the .LNK exploit works.

So far, I haven't gotten the .LNK exploit to work on 98SE, so I'm thinking either 98SE isn't vulnerable, or the malformed .LNK file has to be made differently to affect 98SE.

Edit - I did further testing and can confirm with certainty that the example exploit does not affect 98SE. That's not to say some other malformed .LNK file couldn't affect 98SE, but the flaw that's out there isn't a risk for 9x. I built my own DLL file to test with as the one included with the proof-of-concept won't function on Windows versions below 5 (9x is version 4) regardless.

Edit - It's also worth noting that the exploit has to reference a DLL. A renamed executable won't work.

Queue

Edited by Queue
Link to comment
Share on other sites

This can't seriously be "new" can it? Conficker used this vulnerability in version 2... :rolleyes:

Different vulnerability, but it's not "new" per-se. This new one would have to be modified to affect the way Win9x handles .lnk files for the control panel (specifically control panel .lnk files), because on 2000+ the .lnk must load a .dll and use a specific control panel path which is a bit different in Win9x, it seems. It *could* be done easily, but I doubt with the 9x userbase this would be a useful expenditure of time for a virus writer.

Link to comment
Share on other sites

It *could* be done easily, but I doubt with the 9x userbase this would be a useful expenditure of time for a virus writer.

Conversely, if all it takes is to throw an extra LNK file in and it expands your targets to include a group that will never have the vulnerability patched, the ROI might be acceptable. The most successful malware campaigns don't rely on a single exploit, but leverage as many as possible, including many that have been patched to try and catch unpatched systems.

Queue

Edited by Queue
Link to comment
Share on other sites

to include a group that will never have the vulnerability patched, the ROI might be acceptable

Do you seriously think a malware writer will keep a Win9x box handy (physical or not), just to write a separate version of his malware, to target a still very rapidly declining OS with a market share that's pretty much already non-existent (below 0.1%)? The target is so small, you might as well try to attack OS X, Linux, the iPhone/iPad/iPod, BlackBerry, Windows Mobile/Embedded/CE, all of which have FAR more users. Attacking something so tiny *and* still decreasing so quickly is just a total waste of time.

There is just much more to be gained from concentrating on the other 99.9% or so of Windows users, making it stealth (rootkit indeed) and a real pain to remove/clean too. There's already countless millions of n00bs who won't notice anything, who don't keep updated, run everything as an admin, wouldn't know how to remove it, etc.

Link to comment
Share on other sites

First off, all you need is a VM. Keeping a separate computer just for 9x would be a waste. A VirtualPC 2007 98SE VM (in saved state) opens in 5 to 10 seconds. Secondly, you wouldn't need to write a separate version of the malware if you just follow reasonable programming practices when you write it in the first place. I'm not talking about something tied to the inner-workings of the OS like a rootkit to hide the malware, but the part of the malware that harvests info, etc. Alternatively, if you've been a bad guy for a while, you'd have old 9x malware that you wrote long ago that you can just bundle in.

So, I've recreated the exploit LNK myself (the proof-of-concept had been made on a French install of Windows and the file path was unicode). After recreating the LNK file with an ANSI file path, I was able to get the exploit to work on 98SE, so 98SE is vulnerable as well. Demented fun-fact: on XP, the DLL is automatically executed 3 times when the exploit is triggered; only 2 times on 98SE.

Queue

Link to comment
Share on other sites

Guest wsxedcrfv

Does the execution of this vulnerability require a specially-crafted .lnk file, or a specially-crafted .dll file, or both?

And is a .DLL file required, or could it be engineered as a shortcut to an .exe file, or any file?

Why is the windows shell trying to access (or load, or open) the target that the shortcut is pointing to? To get the target's icon bitmap?

Link to comment
Share on other sites

Does the execution of this vulnerability require a specially-crafted .lnk file, or a specially-crafted .dll file, or both?

And is a .DLL file required, or could it be engineered as a shortcut to an .exe file, or any file?

Why is the windows shell trying to access (or load, or open) the target that the shortcut is pointing to? To get the target's icon bitmap?

The exploit itself is a barely modified LNK file. It's not malformed or anything and not taking advantage of buffer overflows, errors in parsing, etc. It's simply a a poor design that is being exploited.

It has to be a DLL, but it doesn't have to be specially crafted. The LNK file calls the DLL's main entry procedure (often called DllMain, but the name isn't relevant). For my test, my DLL file simply makes an API call to MessageBox in its DllMain procedure to spit out a message box to show it's been triggered. Also, it doesn't have to be named .DLL, it can have any extension, it just must be a normal DLL file.

As to the third question, no clue why it's so stupid of a mechanism.

-

Something interesting, if you've seen any info about the original news of this exploit, the example showed 4 LNK files; my best guess is you can't use relative paths to access your DLL file so there are 4 LNK files targeting the 4 most common drive letters for a flash drive. If you start the file location with a backslash (\filename.dll) instead of a drive letter, it accesses the root of C drive (presumably your Windows drive) regardless of where the LNK file is. If I figure out a way to use a relative path for this exploit, I'll let you guys know. Currently, short of putting 20+ LNK files on the root of the flash drive, I'm not sure if there's a simple way to deal with variable drive letters.

Queue

Link to comment
Share on other sites

Let us know how it goes. In response to a previous question, the caveat of the .lnk/.dll exploit is that it has to go through control panel .lnk handling code - the regular OS .lnk handler doesn't appear to have the vulnerability, but whatever is happening specifically with the control panel does (I haven't really debugged it much further than has already been done, because I don't really care much more than that).

Link to comment
Share on other sites

So, I've gotten one ''relative path'' setup working, but I've only tested it on XP (SP3, not that it matters) and 98SE so far, and it only works on XP. I specify the file path as \\?\STORAGE#RemovableMedia-etc. (it's a long identifying string).

It has a device ID number embedded in the path, so it's specific to a given USB drive, definitely doesn't work on 9x, and I'm not positive the format doesn't change for newer versions of Windows (I'll get around to testing that Wednesday). It isn't machine specific though; I've tested it on multiple XP machines. One problem is the \\?\ path is used as the working path for any execution calls, so child processes (spawned by the executed DLL) have issues if they can't cope with that sort of path format.

If I can come up with a simple way of converting the long \\?\ path to a normal drive letter in the DLL, then it'll be a more useful mechanism.

Edit - A shortcut that references the exploit shortcut will also trigger the DLL to be executed, but a folder with its icon set as the exploit shortcut (via desktop.ini) won't trigger it nor will a drive's icon set to the exploit shortcut (via autorun.inf). So far I haven't found any real danger from this (shortcut pointing at shortcut), it's just interesting.

Queue

Edited by Queue
Link to comment
Share on other sites

Guest wsxedcrfv

After recreating the LNK file with an ANSI file path, I was able to get the exploit to work on 98SE, so 98SE is vulnerable as well.

http://msdn.microsoft.com/en-us/library/bb774950.aspx

The IShellLink interface has an ANSI version (IShellLinkA) and a Unicode version (IShellLinkW). The version that will be used depends on whether you compile for ANSI or Unicode. However, Windows 95 and Windows 98 only support IShellLinkA.

Link to comment
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Recently Browsing   0 members

    • No registered users viewing this page.
×
×
  • Create New...