Rootkit.TmpHider

rundll32.exe only gets involved when you double click the shortcut, what do you do about explorer.exe?

-http://ssj100.fullsubject.com/security-f7/vulnerability-in-windows-shell-could-allow-remote-code-execution-t187-15.htm#1391

 

@Sadeghi85

Just recently seen the newer replies in that thread, and will be responding

 

The .lnk POC provided by - http://www.ivanlef0u.tuxfamily.org/?p=411 - ONLY works if you copy dll.dll into c:\ first.

As Rmus has said

I must admit i overlooked that aspect when testing, and so did a lot of other people

Yes it goes to prove how .lnk works so but how would ANY associated nasty get into c:\ etc without a system/app being set up to allow the transfer ?

Maybe i'm missing something, if so please elaborate

Edit

I deleted dll.dll from C:\ and tried the POC again from both my USB stick and a folder on my desktop. This time just cruising and double clicking showed NO entry in DbgView ! = Fail

 

Yes, it is a reactive solution, rather than a proactive one.

A better solution is to White List the executables on the system. Then, you don't care what rundll32.exe does as long as it doesn't attempt to load a non-white listed DLL.

This is easy to test White Listing security.

Here, I use rundll32.exe in an autorun.inf file to load the hmmapi.dll which starts IE with Windows Hotmail:

Code:

shellexecute=rundll32.exe hmmapi.dll,MailToProtocolHandler %1

​

Rundll32.exe can happily do its task since the hmmapi.dll is an authorized executable.

Now, I use a different version of the hmmapi.dll - not white listed on my system - and rundll32.exe is not permitted to load the DLL:

​

The problems with setting rundll32.exe to prompt are

1) where do you stop in trying to figure out how an exploit is going to use a system file? You can end up prompting many Windows systems files and effectively cripple the system.

2) you get many false positives. Check the ProcessGuard archives here at Wilders and search for rundll32.exe. You will find many unhappy PG users who complained about this very thing: how to you deal with these system executables?

----
rich

 

Yes, the exact exploit in the wild had everything on USB stick. This exploit cannot be tested unless you get the USB stick itself, since the .lnk files are hardcoded to point to a specific device.

A better test is to put a non-white listed executable on a USB device and create a shortcut to that executable. Now, the .lnk file will not execute automatically, but you can simulate the exploit by manually clicking on the .lnk file.

The same result occurs: the executable file is launched.

Or, maybe not, if you have proper protection in place.

Here, I use an old leaktest file, firehole.exe, not white listed on my system. I create a shortcut to it and attempt to run it. It goes nowhere. End of exploit.

​

----
rich

 

The real exploit doesn't execute an executable, it loads a DLL - which might be pretty different (protection-wise).

 

Yes, they are spoofed with the .tmp file extension:

W32.Stuxnet Installation Details
http://www.symantec.com/connect/blogs/w32stuxnet-installation-details

I showed in Post #179 blocking the loading of a DLL. Without having the complete exploit on a USB device, people can only simulate the attack.

Any attempt to access those files flags an alert here:

​

----
rich

 

Very nice post by Peter Silberman on M-unition the MANDIANT blog, I hadn't read it until the link was posted here so

 

Some more info etc

*

*

Glad you liked it

 

SophosLabs Released Free Tool to Validate Microsoft Shortcut

 

Myrtus and Guava, Episode 4

Myrtus and Guava, Episode 5

 

W32.Stuxnet – Network Operations

 

guys, i have some noobish questions, hope no one bothered by answering them
anyone tried comodo aganist this rootkit? i mean D+ aganist shortcut vul?
if i can get a sample of this rootkit? is it safe to run it in shadow mode?
i read Mandiant blog about this malware, it's using // instead of / in directory for process, is this called "hook" or "inject"?
@Ramus ....whats this environment you were using to test the malware if you dont mind my question?
Thanks in advance

 

G Data fights back Windows security flaw
http://www.gdatasoftware.co.uk/about-g-data/press-centre/news/news-details/article/1723-g-data-fights-back-windows-sec.html

 

Here is the direct link :-

http://www.sophos.com/pressoffice/news/articles/2010/07/shortcut.html

 

@MrBrian

Thanks for the SophosLabs Free Tool link

More info and videos from the direct link AvinashR gave

Installed it and it worked to stop the POC from both my USB stick and desktop, as viewed in DbgView. But i didn't get an alert box as seen in the video ?

@Ford Prefect

Nice find

G Data LNK-Check

Anyway kudos to Sophos and G Data for releasing these, they should help a lot of people till a permanent fix arrives, if the word is spread about them, and used correctly The Sophos one does appear less risky though.

Wonder if these tools are using the LinkIconShim trick in some way in Post 184 ?

@Sadeghi85

Thanks, W32.Stuxnet Network Information already in Post #175

 

As per LinkIconShim :-

The Sophos Windows Shortcut Exploit Protection Tool doesn't handle all malicious link files due to mishandling of the .lnk internal data..

Now how can we test this thing?

 

Some more article on .LNK Exploit

"Read It Here"

 

Version 3.05 of DefenseWall blocks the .lnk exploit. http://www.softsphere.com/cgi-bin/redirect.pl?Name=DEFENSEWALL_PF.EXE

 

This is not a free tool, whereas GData .LNK Tool and Sophos Labs Blocking tools are absolutely free.

 

This one is Network Operations.

+ that Sophos tool doesn't seem to work if the dll/lnk files are on the hard drive.

-http://ssj100.fullsubject.com/security-f7/vulnerability-in-windows-shell-could-allow-remote-code-execution-t187-60.htm

 

This behavior was expected. Due to the nature of the flaw (design flaw) it is pretty difficult to develop a fully working patch. You can't exactly understand which LNK is malicious and which one is not. While waiting for Microsoft patch, solutions are two:

1) heuristically try to detect the malicious file (i.e. the linked file is loaded from removable device and/or network), but this will leave some vulnerability if the LNK is located on hard drive;

2) totally filtering the vulnerable function, this will prevent every LNK from exploiting it, but this filter will cut off some legitimate LNK icons too (it is still far better than having all LNK shortcuts with blank icon)

I've developed my own patch SafeLink and choosed the 2nd way currently I've uploaded a sample video on Youtube http://www.youtube.com/watch?v=e422t-cLAm0

 

Please share this technique with us...

 

Well spotted sorry, thanks

I've seen reports of both the Sophos a Gdata tools failing

*

 

You might be surprised how many people will actually do that