Vulnerability in Windows Shell Could Allow Remote Code Execution

At last, another interesting vulnerability to talk about! Here is the official Microsoft documentation on it:
http://www.microsoft.com/technet/security/advisory/2286198.mspx

Microsoft is investigating reports of limited, targeted attacks exploiting a vulnerability in Windows Shell, a component of Microsoft Windows. This advisory contains information about which versions of Windows are vulnerable as well as workarounds and mitigations for this issue.

The vulnerability exists because Windows incorrectly parses shortcuts in such a way that malicious code may be executed when the user clicks the displayed icon of a specially crafted shortcut. This vulnerability is most likely to be exploited through removable drives. For systems that have AutoPlay disabled, customers would need to manually browse to the root folder of the removable disk in order for the vulnerability to be exploited. For Windows 7 systems, AutoPlay functionality for removable disks is automatically disabled.

And here's a POC of it (LNK vulnerability):
POC

Here's Didier Stevens' take on it ("Mitigating .LNK Exploitation With Ariad"):
http://blog.didierstevens.com/2010/07/18/mitigating-lnk-exploitation-with-ariad/

I'm going to be doing some testing of this POC against various anti-malware mechanisms. I'll put the results in the next post. Feel free to post your own testings, make comments or make requests. Cheers.

POC exploit on Administrator account, Windows XP, SP3, 32-bit:
A: "explorer.exe" method (browsing the files)
B: "rundll32.exe" method (manually executing the shortcut)

1. SRP (setup as described here: http://www.mechbgon.com/srp/ ):
A: BLOCKED
B: BLOCKED
Essentially SRP allows the LNK file to spontaneously execute but I suppose the DLL file fails to load. Of course, if SRP was not configured to block DLL files, it would be bypassed. What's interesting is that SRP doesn't seem to block this LNK file from running, even if the LNK file type is included in the policy. Anyway, good to know that 10 year old technology (that I use) blocks this exploit haha.

2. Faronics Anti-Executable 2:
A: BLOCKED
B: BLOCKED
Note that if left in default configuration, it is bypassed, simply because it is not configured to block DLL files.

3. COMODO Internet Security 4.1.150349.920 (default configuration):
A: BYPASSED
B: BYPASSED
No pop-ups whatsoever. There probably is a way to configure CIS to block this (like with any Classical HIPS), but I'm just testing it in default configuration for now. If anyone would like to instruct how they would configure CIS to pass the test, please post.

4. Online Armor Premium Personal Firewall v4.0.0.45 (default configuration):
A: BYPASSED
B: BLOCKED
No pop-ups whatsoever with A. Again, probably a way to configure OA to block this too. B is blocked successfully with this pop-up (which is rather odd...it says "explorer.exe" is the process used - this is different to what GeSWall says below). Only one pop-up is issued:


5. Malware Defender 2.7.1 (default configuration):
A: BYPASSED
B: BLOCKED
No pop-ups whatsoever with A. Like with OA, B is blocked successfully, except the pop-up gives different information (or more information?). We see that "explorer.exe" is indeed the process used, and that it is being used to target the "rundll32.exe" process. Like with OA, only one pop-up is issued:


6. Sandboxie 3.46:
A: CONTAINED
B: CONTAINED
According to tzuk himself:
http://www.sandboxie.com/phpbb/viewtopic.php?p=55989#55989

We already discussed this in the context of buffer overflows. It's the same principle. A program unintentionally starts executing what was supposed to be just some bytes of data. But the program is still executing that "data" in the sandbox.

7. DefenseWall 3.04:
A: BLOCKED
B: BYPASSED
To be honest, DefenseWall gave some very weird results and I'm unsure how to interpret them fully. On running the exploit (everything "Untrusted") as described, nothing comes up on the Debugger (suggesting that DefenseWall blocks it). However, a new folder called "DefenseWallVC" is spontaneously created in the directory, and within is a sub-folder called "HarddiskVolume1". Within this sub-folder is a shortcut file called "suckme". Furthermore, the original shortcut file that loads the DLL has now become "Trusted" (on checking via DefenseWall "File properties")! This is obviously concerning in itself, even though it's not really a direct bypass. However, the direct bypass comes when manually executing (by right clicking and selecting "Run as untrusted") this file as "Untrusted" - the Debugger shows that the exploit loaded successfully. Not sure if Ilya would like to check this out?

8. GeSWall 2.9 Professional:
A: BLOCKED
B: BLOCKED
I must say, I am impressed by GeSWall here. Not only does it successfully block the DLL from loading, but it gives an alert showing exactly what it has blocked:

This also gives a big clue as to how to configure the programs with classical HIPS (CIS, OA, MD) to block this exploit.
Furthermore, this is what happens when double clicking the shortcut file (instead of just browsing to it):

As you can see, a different process is used to load the DLL file - "rundll32.exe" instead of "explorer.exe". And with this piece of information, we now know a bit more about how DefenseWall was bypassed with this exploit. Remember, DefenseWall appeared to block the original exploit (although it did give some strange results as described above) but it failed to block the exploit when "rundll32.exe" is used instead (that is, double clicking the shortcut file).

9. Returnil System Safe 2011 RC:
A: BLOCKED
B: BLOCKED
Obviously I am only testing the anti-executable component of Returnil here, and again I am impressed (shows same alert for both A and B):


10. AppGuard 1.4.7:
A: BYPASSED
B: BYPASSED
Appears to go right through it.

11. PE GUARD 2.1:
A: BYPASSED
B: BYPASSED
Appears to go right through it.

12. Prevx 3.0.5.179
A: BYPASSED
B: BYPASSED
Appears to go right through it. I've been told that Prevx can be classified as a "behaviour blocker" product (and not just a black-lister), hence the reason for the test.

13. Mamutu 2.0.0.22:
A: BYPASSED
B: BYPASSED

14. BluePoint Security 2010 1.0.28.99:
A: BYPASSED
B: BYPASSED

15. ProcessGuard 3.500
A: BYPASSED
B: BLOCKED

Here's Ilya's reply on the apparent DefenseWall bypass (described above):
http://gladiator-antivirus.com/forum/index.php?showtopic=107368&st=0&p=260294&#entry260294

Negative. DefenseWall invulnerable to it. The point is just how DW displaying file status of shortcut files. If it's untrusted, but points to a trusted process, right now the status to be shown is "Trusted". It just comes from the old versions of DW.

It's quite complicated staff how to display shortcut file's status. Because it can be untrusted, but point to a trusted app. It can be trusted, but point to untrusted app. Looks like I need to make a separate file status for .lnk's.

I don't quite understand this. I think what he's trying to say is that DefenseWall doesn't display shortcut file status accurately? Anyway, it sounds like he's at least going to modify how shortcut files display their DefenseWall status.

Unfortunately, as I already stated, I don't quite understand what he means by DefenseWall being invulnerable. What does displaying shortcut file status have to do with it? As I've shown (see under "GeSWall 2.9 Professional"), the exploit can use 2 different processes to load the DLL: "explorer.exe" and "rundll32.exe". From my testing, DefenseWall appears to block the original exploit (which uses "explorer.exe"), although for some reason, extra folders and a file are produced spontaneously. However, DefenseWall fails to block the exploit when "rundll32.exe" is used instead.

As you can see, I don't understand how DefenseWall is invulnerable to it like Ilya says? Each time I tested or executed the exploit, I checked to make sure that both the "shortcut" AND the "DLL" file are labelled "Untrusted" by DefenseWall. In fact, it's not necessary to make the "shortcut" file "Untrusted", as you can clearly right click the file and "Run as untrusted", guaranteeing that the file will run untrusted.

Furthermore, I extracted the files to C:\ using an "Untrusted" WinRAR (and therefore guaranteed that the files produced are also "Untrusted").

Or have I missed something here? Thanks.

EDIT: also keep in mind that GeSWall (which is in some ways conceptually similar to DefenseWall) passes the test easily in default configuration - there's no problem with how the status of shortcut files are displayed etc. I think what Ilya could mean is that manually changing the name of the shortcut file resulted in this file having a status of "Trusted". However, despite this, DefenseWall appears to block the original exploit anyway (which uses "explorer.exe"), presumably because the DLL file is still "Untrusted". However, when manually running the shortcut file as "untrusted" (and with the DLL file remaining "untrusted"), the exploit is successful (using "rundll32.exe"). I think I need to do this test twice for each program I tested and state which method is bypassed or blocked.

Here's a step by step guide and explanation of how I do the POC test - hope it helps those who are asking:

1. Download the POC here:
http://ivanlef0u.nibbles.fr/repo/suckme.rar (reference is in the original post).

2. Note that the POC consists of 2 files in an archive file. They are called:
dll.dll
suckme.lnk_

3. Notice that "suckme.lnk_" is not a real file, and therefore is harmless as it is - it has the extension ".lnk_". This is why to activate the exploit, you have to delete "_", and therefore the extension becomes ".lnk", which is a real file type. And no, I'm not making faces here haha.

4. As far as I understand it, this POC uses "suckme.lnk" to load/run "dll.dll" (and this exploit is triggered by simply browsing the files with explorer.exe).

5. Download the Debugger here (this program is not part of the POC - it's only used to check whether the exploit has run successfully or not):
http://live.sysinternals.com/Dbgview.exe

6. Run the Debugger program and keep its window open where you can see it at all times.

7. Extract the POC files that are in the archive you downloaded earlier. Make sure you extract them into the C:\ directory. If you extracted them elsewhere, you can simply copy the 2 extracted files into the C:\ directory.

8. Browse to your C:\ directory and check that those 2 files are there.

9. Rename "suckme.lnk_" to "suckme.lnk" (that is, delete "_") and notice the Debugger program showing this spontaneously (meaning the exploit has executed successfully). This is basically how I do test A (described in above post):


10. To do test B, I simply manually double click "suckme.lnk" and look for the same message in the Debugger program. Note that with this method, only one line of text appears (instead of 3).

Thanks for you good work.

Here's a bit more information about DefenseWall and the exploit. As I described above, DefenseWall appears to block method A, but not method B. This is true in default configuration, and the fact that I can configure DefenseWall to block method B pretty much proves that it is bypassed (when not configured).

It's actually pretty simple configuring DefenseWall to block method B. To do this, add "rundll32.exe" to the Untrusted Applications list (it is NOT in the list by default):


And when I test the exploit with method B, DefenseWall gives the following pop-up:


However, adding "rundll32.exe" as Untrusted will most likely break many normal and safe operations - that, or you'll get a lot more pop-ups from DefenseWall (essentially making it more like a Classical HIPS).

When "rundll32.exe" is removed from the Untrusted Applications list, the exploit is successful with method B:


Regardless, this is the most interesting reaction against the exploit of any of the tested applications. I will be testing future versions of DefenseWall to see if any changes are implemented to block method B (and perhaps to block method A more cleanly, without the seemingly random creation of new folders and a file).

POC exploit on Administrator account, Windows XP, SP3, 32-bit:
A: "explorer.exe" method
B: "rundll32.exe" method

ssj100, would you mind clarifying the two methods. I'm guessing A: is browsing and B: is direct launch?

Edit: Just caught the bottom of your post, just confirming A= Browse B = Direct Shortcut Launch

Yes that's right - I'll edit the post to display that. Welcome to the forums by the way.

Thanks, we've silently followed anyway, may as well make it official!

1.0.34.99 is publicly available. This release isn't a definitive solution to the problem, but it should help mitigate the vulnerability itself. We're still working on the issue, the next patch Tuesday is a long way away, hopefully we'll be able to close up it completely shortly.

Still working on this one, working on a clean solution that doesn't involve blocking and prompting for every loadlibrary call. It would be trivial to intercept LoadLibraryW and prompt the user as the others are doing, however that results in too many prompts for our user base (average joe). Method A is taken care in the lab at the moment, working specifically on the on browse method.

I'm betting MSFT releases an out of band patch for this one, it's nasty. They'll be patching shell32.dll most likely.

Thanks for the updates Zero_One. Just downloaded 1.0.34.99 and will test it soon.

How do you mean "an out of band patch"? And yes, it certainly appears quite a nasty exploit. I'm surprised it's only just surfaced now.

EDIT: sorry, just checked the file version I downloaded from the BluePoint Security site and it says version 1.0.28.99. Where can I get 1.0.34.99? Thanks.

It'll most likely still fail the test above, the next release (hoping for later this evening) should fix it permanently.

Second Tuesday of every month is the normal MSFT release cycle for patches, the most recent one was July 13th, which means there is plenty of time for in the wild exploits of this one. We'll be seeing more of them soon I'm sure.

They've had a bad month, the Help Center vulnerability was nasty too.

Click update in the main interface, should update it.

This is what SRP's advanced log ( https://ssj100.forumotion.com/windows-hardening-f5/how-to-enable-advanced-logging-for-software-restriction-policies-t201.htm ) shows when the POC is executed:

Test A:
explorer.exe (PID = 1512) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
explorer.exe (PID = 1512) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}
explorer.exe (PID = 1512) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}

Test B:
rundll32.exe (PID = 1072) identified \??\C:\dll.dll as Disallowed using default rule, Guid = {11015445-d282-4f86-96a2-9e485f593302}

The log results here are consistent with what GeSWall shows and confirms that different processes are calling "dll.dll" with each test. With Test A, it is "explorer.exe". With Test B, it is "rundll32.exe". It also confirms that SRP successfully blocks the exploit on both accounts.

Hi,

Can someone please test the actual malware? In these links below it is said this malware doesn't call LoadLibrary in a "normal" manner, I don't understand what does that mean but I'm interested to know how does SRP fare against the actual malware.

Thanks.

http://www.symantec.com/connect/blogs/w32stuxnet-installation-details

http://www.symantec.com/connect/blogs/distilling-w32stuxnet-components

Hi, Sadeghi85, if you can help me get hold of a real malware sample, I'd be most happy to test it against SRP (and other anti-malware mechanisms) and post my results.

However, I am fairly sure SRP will block the real malware itself. I'm not sure if you know who Didier Stevens is, but he really knows his stuff - he's basically said that SRP blocks this malware (as well as the POC exploit). Have a read here:
http://blog.didierstevens.com/2010/07/20/mitigating-lnk-exploitation-with-srp/

The juicy bits are actually in the comments section. A poster called "Anonymous" writes the following:

OUCH!

0. SRP does NOT help against this type of exploit at all, since there is no
code “executed” via ShellExec(), WinExec() etc.

1. SRP would not help against the original exploit, which uses a *.TMP file.
*.TMP is not in the list of executables for SRP, to be found here:

[HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers]
“ExecutableTypes”=multi:…

2. With SRPs standard level set to DENY no shortcut within the start menue
will function!

The fact that he made point number 1. shows that he doesn't understand how SRP blocks execution - it doesn't just look at file type. Windchild explains it well here (AppLocker uses the same mechanism as SRP):
http://www.wilderssecurity.com/showpost.php?p=1605844&postcount=34

Anyway, Didier Stevens replies:

@Anonymous You’ll have to redo your homework, you’re wrong on all 3 accounts.

0. Yes it does also work for LoadLibrary, I did configure SRP to INCLUDE libraries. Pay close attention to the screenshots and test it yourself.

1. Yes it does, SRP blocks LoadLibrary when it sees the file is on the D drive. I tested this with dll.tmp.

2. No it won’t. Shortcuts in the start menu are in the users directories (like all users). On a non-domain member machine, these are also on the C drive which I excluded. Test it yourself.

Further down in the comments section, Anonymous persists in saying that me and Didier are wrong etc. I've hopefully explained to him that he's been testing the POC wrongly and mis-interpreting the SRP logs.

Well, I don't have it but Meriadoc @wilders uploaded two of the malware's components maybe he has the lnk file too.

Anyway, here's your answer:
http://www.sophos.com/blogs/chetw/g/2010/07/16/windows-day-attack-works-windows-systems/

Today, a colleague suggested the best mitigation I have heard so far: deploying a GPO disallowing the use of executable files that are not on the C: drive. This will work for most environments, and you really shouldn't be running executables from USB drives and network shares anyway. We tested this solution against the vulnerability and it does in fact provide protection.

He's basically talking about using SRP or AppLocker to block execution on external drives, and according to their research, this blocks the malware.

Yeah, it does seem to block it, thanks.

I'm actually new to SRP/AppLocker and got some questions to ask later.

It's a normal Loadlibrary call. Right click -> properties on a malformed .lnk will load the dll as well.

Double click call looks like shell32.dll -> explorer.exe -> rundll32.exe -> LoadLibraryW -> bad.dll

Browse looks like shell32.dll -> explorer.exe -> LoadLibraryW -> bad.dll

It's definitely not an issue with loadlibrary, it's an issue that shell32.dll ends up calling loadlibrary loading an arbitrary piece of code/library when a .lnk or .pif is simply browsed.

Thanks for the explanation Zero_One. That makes good sense.

By the way, CloneRanger from the Wilders forum writes:

Yes blocking “rundll32.exe” from running with ProcessGuard definately works. For most people it might not be practical ? What i can say is that, it hasn’t broken Anything for me, and i have NOT had ANY rundll32.exe alerts for Anything else. So it’s fine for me.

And I reply:

“rundll32.exe” is indeed required for many normal and safe operations – you just haven’t got round to issuing them just yet haha. Here are a few such normal operations that many people will use frequently:
1. Using “Open With” menu to choose the program you want to open a file with
2. Using “Safely Remove Hardware” so you can safely unplug a device from your computer
3. Opening “Date and Time Properties” (eg. so you can view the calender, adjust time/date)
4. Opening “System Properties” (eg. so you can change Performance options, enable/disable DEP)
5. Opening “Display Properties” (eg. so you can change desktop wallpaper, screensaver)
6. Opening “Add or Remove Programs” (eg. so you can uninstall programs)
7. Opening “Mouse Properties” (eg. so you can adjust the scrolling speed of your mouse)
8. Opening “Keyboard Properties” (eg. so you can adjust the cursor blink rate)
9. Opening “Sound and Audio Devices Properties” (eg. so you can change Windows Sound scheme)
10. Opening “Phone and Modem Options” (so you can add a phone/modem device)

Keep in mind that the above list applies only for Windows processes itself. I’m fairly sure many third party applications would also call “rundll32.exe”.

So yes, blocking “rundll32.exe” isn’t exactly very good advice for most people.

You can see a more complete (and more technical) list of what "rundll32.exe" is used for here:
http://www.faultwire.com/file_report/rundll32.exe.html

EDIT: and regardless, blocking "rundll32.exe" wouldn't stop the original exploit anyway (Test A).

Oh and by the way, I tested the above "rundll32.exe" operations after adding it to DefenseWall's "Untrusted Applications" list:



From the above quoted list, I tested as below with corresponding observations:
3. "Date and Time Properties" window opens but I am unable to change the date or time. Not a single pop-up is issued.
4. "System Properties" window opens but I am unable to eg. change any "Performance Options". Not a single pop-up is issued.
5. "Display Properties" window opens but I am unable to eg. change the screensaver or desktop wallpaper. Not a single pop-up is issued.
6. “Add or Remove Programs” window opens but I am unable to eg. uninstall a program (WinRAR archiver). Not a single pop-up is issued.
7. “Mouse Properties” window opens but I am unable to eg. change the Scheme. Not a single pop-up is issued.
8. “Keyboard Properties” window opens and I am able to change eg. the cursor blink rate!
9. “Sound and Audio Devices Properties” window opens but I am unable to eg. change the Sound scheme. Not a single pop-up is issued.

As you can see, adding "rundll32.exe" as untrusted by DefenseWall is practically not a good idea. Therefore, with DefenseWall, there doesn't appear to be a practical way to block the exploit when it is executed via "rundll32.exe" (Test B).

Worse yet, blocking rundll only blocks the manual shortcut double click method. The browse method calls the loadlibrary api directly, so blocking rundll32.exe wouldn't do any good of course. Unfotunately the browse by method is the most likely infection vector as well.

Intercepting and notifying the user of loadlibrary calls would do it as a few of the vendors are doing. We're going to eliminate the vulnerabilty itself, a smoother solution for non tech users. .35 takes care of it, should be out tomorrow, it's in QA now.