Microsoft warns of critical unpatched Windows Shell vulnerability

Microsoft issued a security bulletin on Friday to warn customers of a 0-day exploit involving the Windows Shell.

The vulnerability is caused due to an error in Windows Shell when parsing shortcuts (.lnk). The flaw can be exploited automatically by executing a program via a specially crafted shortcut. Certain parameters of the .lnk are not properly validated on load, resulting in the vulnerability. Microsoft says it has "seen only limited, targeted attacks on this vulnerability."

For the exploit to be successful it requires that users insert removable media (when AutoPlay is enabled) or browse to the removable media (when AutoPlay is disabled). According to Microsoft's advisory, exploitation may also be possible via network shares and WebDAV shares. Microsoft states that the exploit affects all Windows versions since Windows XP, including Windows 7. However, Security Researcher Chester Wisniewski of Sophos, reports that Windows 2000 and Windows XP SP2 (both unsupported by Microsoft) are affected by the flaw.

Sophos explain that the flaw bypasses all Windows 7 security mechanisms, including UAC, and doesn't require administrative privilege to run. In a blog posting, Sophos researchers demonstrate the flaw (see below) on Windows 7, which becomes infected with a rootkit as a result.

Microsoft says users could halt attacks by disabling icons for shortcuts and switching off the WebClient service. Unfortunately the suggestion is far from ideal for most corporate customers, disabling icon shortcuts will likely result in mass confusion for users and turning off the WebClient service will render Microsoft SharePoint useless. Microsoft has not confirmed when a patch will be made available for the issue. The company's next patch Tuesday is scheduled on August 10.


Demonstration of vulnerability on Windows 7
Report a problem with article
Previous Story

Microsoft creates a terapixel map of the night sky

Next Story

Zune Pass now available in the UK

50 Comments

Commenting is disabled on this article.

i was a victim i plugged my usb into my sisters netbook and all the folder in that usb turned into shortcuts which then just gave a bunch of useless errors. all the files were lost

I feel like buying a Sophos AV now... nah, not really. First I don't stick USB drives into my computer that I don't know, and I don't go looking for files I don't trust either.

In user mode with user privileges, there's very little damage code can do, it can't even hack into the keyboard interrupts to log my input keys, it can't do anything at the Kernel level either. I don't keep any important files in my standard user account, so like usual, the greatest threat is the user.

Congratulations Sophos, you're stopped one root kit based virus and were kind hearted enough to show us at the end of a product pitch video.

Now then, where were your detection methods when Nachi was around? Hmm?

What i would like to know is will Sophos be sending the MD5 Checksum of this Malware to all the other Anti-Virus companies (not likely)?
If not why not?
They know how much harm this could/can do but they are unwilling to pass it on for the greater good, wonder why!

Who`d have thought a poxxy shortcut could be used to install a rootkit, just shows that AV`s are yesterdays technology because if there was no sig and heuristics didn`t catch it, bam your infected...

Riggers said,
What i would like to know is will Sophos be sending the MD5 Checksum of this Malware to all the other Anti-Virus companies (not likely)?
If not why not?
They know how much harm this could/can do but they are unwilling to pass it on for the greater good, wonder why!

Who`d have thought a poxxy shortcut could be used to install a rootkit, just shows that AV`s are yesterdays technology because if there was no sig and heuristics didn`t catch it, bam your infected...

Even if Sophos doesn't release their signature, other AV companies will be looking into this as well since its public knowledge and updates that fix it will probably be released soon

There is no doubt that this type of issue is serious for a lot of users running pre-Vista, however I don't think this researcher understands the point of UAC by saying it's not a security feature. UAC was not designed to prevent users from running rogue code under their user credentials, it was designed to:

a. Prevent code from automatically elevating itself to “true” administrator while an administrator user account is directly logged in.

b. Allow a restricted user a method to authenticate as Administrator without logging out so they could install new software or elevate specific applications to Admin.

c. Black out the screen in such a way to prevent malware from tricking you into thinking you were receiving a UAC prompt.

d. Block key loggers running in your user context from grabbing key presses as you type in a password at the UAC prompt, as any program launched via “Run as Administrator” or “Run As Different User” cannot see key presses from a program in focus that is running with different user credentials. (UAC prompts cannot prevent key loggers running at the System level from recording keystrokes though).

Basically that researcher was saying UAC = AppLocker or the older SRP (Software Restriction Policies), when they resolve completely different issues.

Nothing in Microsoft's SA or the Sophos alert indicate this bug on its own results in privilege escalation, which bypassing UAC would be considered. It's also seems to me from his update that AppLocker, SRP, Deny execution ACLS, and other tools which prevent rogue code execution prevent this vulnerability from executing.

Actually, just to rephrase the way I opened that. It's a bad bug for all levels of Windows (especially for non-IT people), but it's worse for people running pre-Vista because UAC doesn't exist to stop the rogue execution from automatically becoming full admin… Not that UAC helps for people who automatically answer Yes or authenticate to every UAC prompt because they don't realize they didn't do anything that should have generated it.

Also, AppLocker makes this kind of bug much easier to avoid than SRP just because of the better method of rule generation.

Also, a clarification from "d.". Key presses when done at the blackout UAC prompt cannot be captured by malware running as your user context, but it can be captured by malware running as the System itself.

I believe key presses done at the "Run As Different User" prompt can be captured by malware running as both the logged in desktop user that is calling on it, as well as system level malware. However malware running at the user level cannot see key presses made to the program launched in this method, and the reverse is true (malware run via Run As Different User shouldn't be able to see key presses done when that Window is not in focus). So far as I know, non-system level malware is trapped by the user level window focus barrier. (I could be incorrect here, but I believe that's how it works.)

If I have anything wrong, let me know! Now I'm done talking to myself.

Kaedrin said,
Also, a clarification from "d.". Key presses when done at the blackout UAC prompt cannot be captured by malware running as your user context, but it can be captured by malware running as the System itself.

if a malware is already running as "system" (which is the highest privilege on windows), why would it be monitoring for keystrokes on the UAC prompt to obtain privileges it already has? ^^



I believe key presses done at the "Run As Different User" prompt can be captured by malware running as both the logged in desktop user that is calling on it, as well as system level malware.

the key presses on the UAC prompt CAN'T be captured by malware running on the limited user desktop.

but a malware could spoof the elevation window (uac prompt on windows, or whatever else on linux/osx) and ask the user for the adminstrator/root password...
and if this malware is well designed, it will monitor what the user is doing to display this window only when he is about to execute something that would legitimately display an elevation prompt.

so, usermode malwares can easily be elevated even by an advanced user...
but even without being elevated, an usermode malware can already do much harm (steal passwords, credit card numbers and send them to a malicious server, send spam, ...)

It's not that it would be monitoring specifically for UAC passwords, it's that it would already be capturing all keystrokes from the machine no matter what they are made into. If a keylogger is running as system, it should be capturing everything no matter what Windows security feature would stop it.

As for key presses on the "Run As Different User", I actually am not sure what type of prompt that is. I am not positive that is actually a UAC prompt at all, but the Windows XP "Run As" prompt restored to Windows 7. I'll have to check... it should be easy to verify which way this prompt works.

I'd say it would be nearly impossible for malware to spoof the "Run As Different User" window to anyone that knows what it is and be successful. Anyone that actually knows how to use and call on it should be aware it will only appear when called. Having said that, the security Window for this barely looks different than other Windows authentication prompts when your credentials aren't good enough to access a remote resource.

"Run As Different User" is not a UAC prompt, and it turns out nothing run this way will protect from a keylogger in either direction. If a keylogger runs as a restricted user either with the logged on desktop user, or through “Run As Different User”, it will capture all keystrokes made to any window *EXCEPT* those elevated by UAC.

I was mistaken when I thought/said that Run As Different User could do anything to protect against keyloggers. It will only prevent malware from either account from causing damage to the other users data (going by default ACLS on %userprofile% anyway, changes there and your mileage will vary). Keyloggers are still fully functional no matter what non-UAC window is in focus.

However, I was still accurate about “Run As Administrator”/UAC and keyloggers. If a keylogger is not fully elevated, it cannot capture keystrokes made to any window in focus which was launched or sublaunched by something covered by UAC.

When a UAC window is in focus, a keylogger running without UAC will see nothing.

Sorry for any confusion. Going by memory with a bit of conjecture is bad for accuracy.

Kaedrin said,
a. Prevent code from automatically elevating itself to “true” administrator while an administrator user account is directly logged in.
It's a convenience feature, because too many people complained about how annoying it was to use a system designed to be secure.

It's impossible to make an informed decision based on the information on the UAC prompt. You don't even know whether the file name it shows is actually the file you wanted to run. Malware could already have substituted it with something else, nor do you know what external code it could be bringing with it.

Another problem is what happens when you elevate something. Both elevated and normal programs end up running in the same session, and normal programs can manipulate elevated ones. This is again by design for the sake of usability, but it's a vulnerability.

For something to qualify as a security boundary it must be completely impossible for anything to move past it without authorization. This is not true for UAC, which means it's not a security boundary, which again means that any bugs or weaknesses in it are not considered security bugs.

In this context, the only security boundary Windows has are sessions. They have to be completely isolated from each other.

Kaedrin said,

c. Black out the screen in such a way to prevent malware from tricking you into thinking you were receiving a UAC prompt.
This only applies to administrator approval mode (AAM). Other UAC prompts are vulnerable.

Kaedrin said,

d. Block key loggers running in your user context from grabbing key presses as you type in a password at the UAC prompt, as any program launched via “Run as Administrator” or “Run As Different User” cannot see key presses from a program in focus that is running with different user credentials. (UAC prompts cannot prevent key loggers running at the System level from recording keystrokes though).
Yes and no. The UAC prompts are shown on the secure desktop, but the credential prompts are still somewhat vulnerable.

The reason is that unlike AAM, they actually make you enter a username and password. AAM only makes you click a button, which is of no value to malware.

The result of this is that malware can spoof the prompt. Most people will have no clue whether the prompt they're looking at actually came from UAC. All the visual indicators can be spoofed.

Now, this particular attack will involve making the user enter his password twice, but many would. They'd simply think the prompt popped up twice because they wrote the wrong password.

Of course the most important issue here is that you can still make plenty of malware that does not need administrator rights.

hdood said,
It's impossible to make an informed decision based on the information on the UAC prompt. You don't even know whether the file name it shows is actually the file you wanted to run. Malware could already have substituted it with something else, nor do you know what external code it could be bringing with it.

Can't argue, you're completely correct. However it does display publisher data from valid code signing trusts when they exist (completely depends on the company releasing that product). Besides, UAC prompts don't just magically appear at random. If you're not actually doing something specific that requires elevation, you shouldn't elevate. I have never gotten a UAC elevation prompt I didn't expect; they have either always come when installing software, or when launching software when the icon basically states it requires elevation.

While I can't argue that it needs work (though frankly, AppLocker needs more focus so it can actually become usable to home users). Having said that, if the new malware Sophos was playing with is the following it is now very interesting:

http://krebsonsecurity.com/201...-new-windows-shortcut-flaw/

If so, that malware was signed and was briefly and successfully able to masquerade as Realtek Semiconductor before VeriSign revoked the certificate. That means it could briefly bypass AppLocker/SRP if you were trusting Realtek. I think this is the first piece of malware that has been successful in this attempt, and it would have broken whitelisting

hdood said,
For something to qualify as a security boundary it must be completely impossible for anything to move past it without authorization. This is not true for UAC, which means it's not a security boundary, which again means that any bugs or weaknesses in it are not considered security bugs.


I don't exactly consider UAC a security boundary if you're logged directly in as Administrator, however, I would say it helps keep a restricted users boundaries very clear when you need to exceed them. So in those regards it works as a security feature, but your restricted user account is actually the security boundary.

The way I use it always requires authentication to a different user account, as I never login as Administrator.

AAM is really the only UAC prompt I really consider to be a UAC prompt really. I never see the other ones, because if I'm logged in as the built-in Administrator UAC doesn't matter because I'm already trying to resolve a major problem (or configure a brand new server). I really consider AppLocker/SRP as the only real protection available when logged in directly as Administrator.

hdood said,
Yes and no. The UAC prompts are shown on the secure desktop, but the credential prompts are still somewhat vulnerable.

I verified this myself earlier by mucking around with something that could observer keypresses.

If you have one of the non-AAM authentication prompts while logged in as a limited user, then your keystrokes are protected from anything running as a limited user.

However, if you're logged in even as administrator and are entering a user name/password without the full on UAC blackout, malware can see *all* of your keystrokes unless the authentication window in focus was already elevated via UAC AAM.

I'd like to reiterate. I do not really use UAC while logged in to the desktop as Administrator, I only elevate very specific processes to true administrator while logged in as a restricted/limited user.

hdood said,
The reason is that unlike AAM, they actually make you enter a username and password. AAM only makes you click a button, which is of no value to malware.

While logged in as a true administrator, the AAM blackouts that only give yes/no answers still work the same as the limited user. Any program elevated through the AAM blackout cannot be watched by malware running as Adminitsrator if the malware is not also elevated.

But it's semantics. If you're logged in as an Administrator and you have malware watching you at all you've already been conquered. The same is true if you're a limited user who can elevate to Administrator. The fact is, you should only trust signed software that are in directories you don't have access to modify without UAC AAM prompts, and you should barely trust any location inside a user profile to launch software.

My moto is let AppLocker break everything that tries to execute from my user profile (I don't force the hardcore rules on others though, end-users would kill me) if I don't know what it is, and don't let anything launch from any location I have write access to as a limited user. Then allow programs to launch as they require as I need them to function. AppLocker is fairly easy to use and very easy to diagnose problems with its log system. Software Restriction Policies on the other hand are *not* easy to use and sometimes impossible to diagnose when they break “something”. The entire concept of what AppLocker is really needs to be focused on by Microsoft and expanded, because it has some good ideas, but it's still a real pain to use over time if you have a huge quantity of software to trust.

Ugh, I wish I could edit my replies on Neowin to fix slight mistakes I missed while proof reading the first few times. I must correct myself again.

I said,
If you have one of the non-AAM authentication prompts while logged in as a limited user, then your keystrokes are protected from anything running as a limited user.

I made a mistake in how I wrote this sentence. Your *not protected* unless the prompt is a UAC AAM prompt, be you logged in as a limited user or Administrator that has not already been elevated by UAC.

If a window in focus was *not* elevated via UAC AAM, it is *not* protected from any malware running under your limited user.

Sigh.

Kaedrin said,
Can't argue, you're completely correct. However it does display publisher data from valid code signing trusts when they exist (completely depends on the company releasing that product).
True, however it's debatable how many people understand what signing is, or have the enough knowledge to cancel a prompt because they think the program in question should have been signed if it was real.

Kaedrin said,

Besides, UAC prompts don't just magically appear at random. If you're not actually doing something specific that requires elevation, you shouldn't elevate. I have never gotten a UAC elevation prompt I didn't expect; they have either always come when installing software, or when launching software when the icon basically states it requires elevation.
They don't, but the issue here was riding legitimate elevation requests. This can like I said be done by replacing the file with malware before the user has time to run it (say between downloading it and executing it), or in a more complicated scenario take advantage of the fact that the library loader checks the executable dir for .DLLs first (apart for certain system DLLs.) That theoretically means that a trusted signed application could actually unintentionally be loading malware with it.

Kaedrin said,

Having said that, if the new malware Sophos was playing with is the following it is now very interesting
It's interesting, but I think it's too difficult to be a real problem though. Actually getting code signed with a trusted certificate is exceptionally difficult. At least for major publishers, it might be able to be abused on a small scale.

Kaedrin said,

The way I use it always requires authentication to a different user account, as I never login as Administrator.
This is still less ideal though. If something bad is running as that restricted user, it could mess with the executable you are elevating. The most secure setup is to actually log on as an administrator, and from there not access any files the restricted user has write access to. This of course decreases usability further.

The second probably is that once you have elevated the program, it is actually running in the same session as the restricted programs, and it is not completely isolated from them. That means there is a risk of it being manipulated. There is no security boundary separating them, like there would be if you had actually logged on as a separate admin user.

In other words, if you're logged on as a restricted user, then UAC and elevation are features that compromise security, not improve it.

Kaedrin said,

I verified this myself earlier by mucking around with something that could observer keypresses.

If you have one of the non-AAM authentication prompts while logged in as a limited user, then your keystrokes are protected from anything running as a limited user.

I think you misunderstood what I meant. You are too hung up on "keystrokes." I am not talking about manipulating or spying on the real prompt, I am talking about spoofing it. You can spoof the appearance and behavior of the secure desktop (blackout) prompt in a way that would fool most people.

You can also detect that there has been a legitimate elevation request. You then show your prompt, and trick the user into writing his credentials into it. You can't prevent the real prompt from showing, so the user will end up getting two after each other. Since they both look the same, there's a very high probability that he'll think he just typed the wrong password, and enter it again. This is an attack Microsoft has demonstrated several times. It's not theoretical.

This problem exists because the real prompt does not make you press ctrl-alt-del (which can't be intercepted). It did at one point, but people found it annoying, so it was removed in the name of usability.

Kaedrin said,

While logged in as a true administrator, the AAM blackouts that only give yes/no answers still work the same as the limited user.
What I was trying to say was that a click is of no value to malware that wants to spoof the prompt. You can spoof the AAM prompt, but all you can get is a click, which isn't useful. By spoofing the credential prompts, you can steal credentials.

Hmm? I've always disabled webclient before in XP, haven't messed with to many of the services in Windows 7, but disabled it shall be for now!!

I see that in Windows 7 it is set to manual instead of auto, like it was in XP. I'll put it at disabled anyway. Don't have any use for such service anyway. Let's see what happens.

Buendia said,
This is bad

This is catastrophic. All versions of Windows are affected.

BTW this sentence makes no sense: " Microsoft states that the exploit affects all Windows versions since Windows XP, including Windows 7. However, Security Researcher Chester Wisniewski of Sophos, reports that Windows 2000 and Windows XP SP2 (both unsupported by Microsoft) are affected by the flaw."

Buendia said,
This is bad

This is like the the old floppy disk boot sector virus.

(Its not explained in the post, but you do actually have to click on the infected file.)

So the the moral is the same as always, don't go around sticking your floppies anywhere without adequate protection.

Deviate_X said,

This is like the the old floppy disk boot sector virus.

(Its not explained in the post, but you do actually have to click on the infected file.)

So the the moral is the same as always, don't go around sticking your floppies anywhere without adequate protection.


No it is not like that. It affects key components of the WIndows Shell.

Lechio said,

This is catastrophic.

absolutely not.

antiviruses should be able to block this flaw exploitation by searching for malformed .lnk files.
and even without antivirus, it is still not a privilege escalation flaw.

for windows 7 users, it's not worse than what xp users were used to for years when autorun was enabled.
this flaw is probably not going to be patched before next patch tuesday, since it is not a major flaw (it can't be exploited from the network nor by visiting a web page, and antiviruses can block it reliably)

link8506 said,

absolutely not.

antiviruses should be able to block this flaw exploitation by searching for malformed .lnk files.
and even without antivirus, it is still not a privilege escalation flaw.

for windows 7 users, it's not worse than what xp users were used to for years when autorun was enabled.
this flaw is probably not going to be patched before next patch tuesday, since it is not a major flaw (it can't be exploited from the network nor by visiting a web page, and antiviruses can block it reliably)


Cover up much? It is a major bug. It affects Windows 7, using that won't make the user more nor less safer than using a previous version of Windows.

In the article itself it says that can be remotely exploited from the WebClient service.

Lechio said,

Cover up much? It is a major bug. It affects Windows 7, using that won't make the user more nor less safer than using a previous version of Windows.

In the article itself it says that can be remotely exploited from the WebClient service.

Actually as Windows 7 doesn't autorun then it's marginally safer. Additionally, as with Vista, UAC will prevent system level attacks - the hack will only run with the credentials of the locally logged on user.

IMHO this is pretty bad for XP (as there is no UAC and autoplay is on by default), it's bad but limited for Vista (UAC) and very limited for Win7.


Need to remember that this isn't a remote exploit. In fact the attacker will need to use social engineering - as there is no privilage escalation then the social engineering will need to be done on an administrator.

So from an enterprise viewpoint running Vista/Win7 with autoplay off and having users run as limited user this is a very minor "attack".

Lechio said,

In the article itself it says that can be remotely exploited from the WebClient service.

you have to connect manually to a webdav network share (owned by a hacker) from the windows explorer to get infected.

stevehoot said,

Actually as Windows 7 doesn't autorun then it's marginally safer. Additionally, as with Vista, UAC will prevent system level attacks - the hack will only run with the credentials of the locally logged on user.

IMHO this is pretty bad for XP (as there is no UAC and autoplay is on by default), it's bad but limited for Vista (UAC) and very limited for Win7.


Need to remember that this isn't a remote exploit. In fact the attacker will need to use social engineering - as there is no privilage escalation then the social engineering will need to be done on an administrator.

So from an enterprise viewpoint running Vista/Win7 with autoplay off and having users run as limited user this is a very minor "attack".


No really. Look at the video, the exploits runs without autoplay. As for admin rights, those are overrated. If it has access to all of the users data, if doesn't need admin rights.

link8506 said,

you have to connect manually to a webdav network share (owned by a hacker) from the windows explorer to get infected.

Did you not watch the video? Nothing except antivirus software prevented this virus from running. Not even UAC, as the guy doing the video was logged in as a standard user. The only prevention is disabling autorun and WebClient, and running AV software.

SharpGreen said,

Did you not watch the video? Nothing except antivirus software prevented this virus from running. Not even UAC, as the guy doing the video was logged in as a standard user. The only prevention is disabling autorun and WebClient, and running AV software.

you didn't understand what I was saying

I was answering to someone who said that "it could be remotely exploited from the WebClient service". To be exploited through this vector, you have to connect to an infected server using a WebDAV share.

that's another vector for the .lnk flaw. I was not denying the fact that it is exploitable via an usb key by just browsing the folder content.

however, there is no remote code execution in either of these infection vectors. Users has to browse an infected folder manually to get infected (usb key, or network share).

And anyway, the folder has to be infected first by one way or another. And if it has been infected, chances are that even without this flaw, a malware could have placed a readme.exe or photo.exe file on the usb key or network folder, and since file extensions are hidden by default, most users would open these files wondering what there is inside (the exe file would of course have the xp or vista icon for text files or pictures as default icon, so that the user really thinks it is gonna open with notepad or photo viewer).

of course this flaw causes the malicious file to be infected everytime (where as a photo.exe or readme.exe file would be executed "only" by 90% of users).

anyway, since most antivirus will be able to block it (it should be easy to detect malformed lnk files), there is not much risk.
companies should also systematically block EXE files that are run from usb keys or the user profile (there are policies for that since windows 2000), no matter of this flaw.

Edited by link8506, Jul 18 2010, 6:38pm :

Lechio said,

This is catastrophic. All versions of Windows are affected.

BTW this sentence makes no sense: " Microsoft states that the exploit affects all Windows versions since Windows XP, including Windows 7. However, Security Researcher Chester Wisniewski of Sophos, reports that Windows 2000 and Windows XP SP2 (both unsupported by Microsoft) are affected by the flaw."

If you read the FAQ it says that even Service Pack 1 Public Beta 4 Windows 7 is affected!

kevpan815 said,

If you read the FAQ it says that even Service Pack 1 Public Beta 4 Windows 7 is affected!


I've said all Windows versions are affected.
The fact that the sentence says Windows 2000 and XP SP2 are affected too, after saying that all Windows versions are affected, is the part that makes no sense.

kevpan815 said,

If you read the FAQ it says that even Service Pack 1 Public Beta 4 Windows 7 is affected!

P.S. OS's Older than XP SP3 are no longer supported! As a result MSFT will release a fix only 4 XP SP3 and Higher! Vista Gold (no SP's installed) is also no longer supported! Just FYI!