Rootkit.TmpHider

Originally Posted by MrBrian

I was just trying to make everyone, especially those of the "I always run as admin, with UAC disabled, without SRP/AppLocker or similar, with AutoPlay disabled, and with a sandboxed browser, and I'm fairly knowledgeable and careful" variety, consider what would have happened in your own setup before this issue became widely known.

Right, and it seems UAC enabled at least on default (preferably maximum) provides more protection within an administrator account than it gets credit for, because of the Standard user access token (besides also the administrator access token) causing all applications to launch with only standard user priviledges unless the user okays for administrator consent. The parent process explorer.exe is launched with only Standard user priviledges. It doesn't mean this equals running under a standard account but it's far better than running administrator with UAC disabled.

This MS Technet article explains it nicely in more detail without overwhelming technical language.

[MrBrian]

Originally Posted by wat0114

Right, and it seems UAC enabled at least on default (preferably maximum) provides more protection within an administrator account than it gets credit for, because of the Standard user access token (besides also the administrator access token) causing all applications to launch with only standard user priviledges unless the user okays for administrator consent. The parent process explorer.exe is launched with only Standard user priviledges. It doesn't mean this equals running under a standard account but it's far better than running administrator with UAC disabled.

I agree . I use a standard account normally, but I also have UAC on max. About UAC in an admin account, one of the UAC developers said,

As for the security messaging around UAC. The point where our messaging switched from security to reliability was when the product team engaged the support of our Secure Windows Initiative (SWI) team to PenTest UAC. They clearly demonstrated because of the shared state, HKCU, user profile, etc., between the “little Abby” and “big Abby” tokens (as we referred to them) that UAC elevations could never be a security feature – this was also right around when MarkRuss came to MSFT.

Source:http://www.wilderssecurity.com/showthread.php?t=273860

I actually do think of UAC as being a security feature, among other things, just not a security boundary. UAC probably prompts with this particular malware, but testing is needed to be sure.

[Windchild]

Originally Posted by Rmus

I don't have the .lnk files. I would like to get them to really test the entire exploit.

Anti-Executable v.2 parses the files in a directory and flags an alert if an executable is not on the white list. Here is firehole.exe, an old leak test I keep around. It's not on the white list, so when I go to the directory, AE pops up an alert

Ah, okay, so AE is basically just scanning for executable files and popping up alerts for any found executables that have not been previously whitelisted, identifying executable files based on the typical signs like magic numbers and such, so it doesn't have to care about the file extensions. That would explain the alert coming up even though nothing is trying to execute those .tmp files. One wonders, though.... What if an AE user enters a directory that contains, say, 900 executable files that haven't been previously whitelisted? Do they get 900 popups in a row? Well, most users probably wouldn't meet such situations, but the thought occurred to me as I was just going through one of my many little archives, containing about 8000 unique executable files...

Originally Posted by MrBrian

I was just trying to make everyone, especially those of the "I always run as admin, with UAC disabled, without SRP/AppLocker or similar, with AutoPlay disabled, and with a sandboxed browser, and I'm fairly knowledgeable and careful" variety, consider what would have happened in your own setup before this issue became widely known.

That's a good point.

[Rmus]

Originally Posted by Windchild

What if an AE user enters a directory that contains, say, 900 executable files that haven't been previously whitelisted? Do they get 900 popups in a row?

I've not tried that scenario, but I've tested AE2's delete prevention with a large group of files. You get one visible alert for the first file, but all the rest are denied anyway. Here, I attempted to delete all .exe files in the Windows directory:

Well, most users probably wouldn't meet such situations, but the thought occurred to me as I was just going through one of my many little archives, containing about 8000 unique executable files...

I don't have that many, but I keep mine in zip files.

In my example above of firehole.exe, I unzipped the file to another directory.

BTW, with AE2's Copy protection, a child or other non-principal user of the family computer without the AE password, can't extract a non-whitelisted executable, preventing any mistakes with email attachments, for example.

----
rich

[CloneRanger]

@ggbb

I work for a SCADA

I am very interested in the malware itself (as well the exploit, but mostly on the malware) as it is a potential target to some of our clients and we would like to analyze it.

I'm sure someone reading this might be able to assist you by PM, if you can prove who you say you are

Be very interesting to hear you analysis of this malware after you get hold of a copy. I would have thought approaching one or more of the AV companies should prove fruitfull

[CloneRanger]

About TmpHider/Stuxnet #1

Some info on this new malware spreading in these days under the name of TmpHider/Stuxnet

Let’s start with the propagation method which is the only novel aspect about this malware. As already discussed and reported on multiple forums online, this particular piece of malware exploits some unidentified bug in the lnk file format to autostart itself when a usb key is opened.

Once infected you’ll find in the usb pen two lnk files and a two tmp files, opening one of the lnk files we can see inside the UNC path to the tmp file, which is actually a DLL.

-

As you can see it’s trying to load the the tmp file from the system32 directory, something is not going how expected right ? my guess is that’s because the UNC path inside the lnk file is specific to the usb pen, so if you copy the link and tmp files on a different usb pen they wont work.

Let’s start from the lnk file since it’s clear that it is triggering the loading of the dll in some way, and since there is no sign of shellcode must some kind of logic bug or “feature”.

-

The path is expressed as a PIDL, and is composed by three components (two of which represented through their CLSID)

-

more details coming in the weekend on how that path leads to execution.

http://www.inreverse.net/?p=1246

My emphasis. Other interesting stuff on there you might like

Addendum

Another thing that I forgot to mention...we see in the MMPC post that the files are referred to, but nothing about the persistence mechanism. Do we assume that these files just sit there, or do we assume that they're listed as device drivers under the Services key? What about the directory that they're installed in? Do they get loaded into a "Program Files\RealTek" directory, or to system32, or to Temp?

http://windowsir.blogspot.com/2010/0...cts-redux.html

[stonerhash]

According to that http://www.kb.cert.org/vuls/id/940193 a mitigation technique is to disable the IconHandler. Maybe the bug is in the IconIndex attribute in the lnk struct or icon related

I tried to corrupt various struct length values in an lnk file but no crash at all.

[ScadaGuy]

Originally Posted by frank_boldewin

this points me to the Siemens WinCC SCADA system.
looks like this malware was made for espionage.

I am a new poster on this site, so first a little back ground. I have been a SCADA and process control engineer for the past 25 years and VERY actively involved in SCADASEC since 2000. I have also worked on the Siemens systems in the past (actually I was a Siemens rep in the 1990's) and have been involved in many of the major ICS systems.

My question is this - I am trying to determine is if this is really just a Siemens focused attack or if there may be other variations. Frank Boldewin's excellent decode and analysis is the only one I have seen and it appears that everyone is using this as the golden reference. I have been trying to locate other variants and see if they go after other systems such as ABB, Rockwell, WonderWare, Areva, etc. Has anyone seen variants and attempted to analzye them?

Mind you according to MMPC, the activity of this worm is heavily weighted to the US, Indonesia, India, and Iran. If you forget the US, we are talking big-time Siemens markets. If I was going after SCADA targets in those three countries, I would also pick Siemens. (Courious that Europe is quiet as it is the heartland of Siemens WinCC installations).

However if we see attacks against other SCADA systems, we may be able to determine the geographic and sector targets of this malware. For example, seeing attacks against Rockwell would make me believe this is widespread globaly and focused on Manufacturing IP theft rather than attacks against utilities.

[MrBrian]

Originally Posted by stonerhash

Maybe the bug is in the IconIndex attribute in the lnk struct or icon related

I tried to corrupt various struct length values in an lnk file but no crash at all.

From http://isc.sans.edu/diary.html?storyid=9181:

I've tested the exploit and can confirm that it works in Windows XP, Vista and Windows 7. The exploit uses a specially crafted LNK file. This file allows the attacker to execute an arbitrary file by carefully specifying its location – the LNK file in itself does not exploit any vulnerability such as buffer overflows, for example, so it is a legitimate LNK file. The LNK file used in targeted attacks was manually crafted as some fields that are normally present, such as CreationTime, AccessTime or WriteTime are all set to 0.

I will not be posting details about how the exploit works, but here are some things that you should be aware of:

* If autorun is disabled, when a USB device with malicious LNK files is inserted, the exploit will not be triggered automatically.
* The exploit is triggered every time a folder containing a malicious LNK files is opened (for example, with Windows Explorer). It does not matter where this folder is – it does not have to be on a USB device, but in order to execute to malicious binary, the attacker has to specify its location correctly.

What makes this vulnerability extremely serious is the fact that it can be opened from any place, including remote shares, for example. The victim just has to browse to the remote share in order to trigger the vulnerability.

From http://secunia.com/advisories/40647/:

The vulnerability is caused due to an error in Windows Shell when parsing shortcuts (.lnk) as certain parameters are not properly validated when attempting to load the icon. This can be exploited to automatically execute a program via a specially crafted shortcut.

Successful exploitation requires that a user is e.g. tricked into inserting a removable media (when AutoPlay is enabled) or browse to the root folder of the removable media (when AutoPlay is disabled) using Windows Explorer or a similar file manager. Exploitation may also be possible via network shares and WebDAV shares.

[Rmus]

MrBrian.

Is it your conclusion that any .lnk file should run when viewed in Windows Explorer?

----
rich

[MrBrian]

Originally Posted by Rmus

Is it your conclusion that any .lnk file should run when viewed in Windows Explorer?

Not in general, or else my system would be opening a lot of programs when I browse a start menu folder, which contains many .lnk files. However with a specially crafted .lnk file, it appears to be possible to automatically execute a given executable when Windows Explorer processes the .lnk to attempt to display an icon.

[Rmus]

That makes sense; I've tested with WinXP SP3 and regular .lnk files don't do anything automatically.

Have you figured out how the malicious .lnk file is different so as to invoke an auto execution? I've asked Bojan (sans.edu) and hopefully he'll give me an answer.

Note in his Diary:

If autorun is disabled, when a USB device with malicious LNK files is inserted, the exploit will not be triggered automatically.

This seems to contradict other reports that Autorun isn't involved, unless I misinterpreted something.

----
rich

[MrBrian]

Originally Posted by Rmus

Have you figured out how the malicious .lnk file is different so as to invoke an auto execution? I've asked Bojan (sans.edu) and hopefully he'll give me an answer.

No, but then again I don't have any samples and I haven't looked into it.

Originally Posted by Rmus

This seems to contradict other reports that Autorun isn't involved, unless I misinterpreted something.

Microsoft in its security advisory stated,

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.

I'm not sure how much consolation that is though, because wouldn't most users with AutoPlay off eventually browse a USB stick to view its contents?

[Rmus]

Originally Posted by MrBrian

wouldn't most users with AutoPlay off eventually browse a USB stick to view its contents?

Yes, and things become confusing.

In an autorun/autoplay exploit, depending on how those are disabled, the exploit will trigger automatically if the USB drive letter is clicked-to-open in My Computer (Windows Explorer single pane view)

[autorun]

open=calc.exe

but not if the USB drive letter is clicked from the left pane in Windows Explorer 2-pane view.

----
rich

[MrBrian]

Originally Posted by Rmus

Yes, and things become confusing.

AutoPlay can automatically browse a folder upon insertion of a USB stick.

[stonerhash]

I was wondering maybe this thing is not an exploit.

For example I have a malicious dll and in its resources I have an Icon.
So I create a shortcut with an icon pointing to that dll.

If the shell32 uses LoadLibrary to load the dll and sequentially the icon resource then we would have an execution. Keep in mind that maybe LoadLibrary is not used at all in case that shell32 just reads raw data from the shortcut.

Unfortunately I havent managed to make it work yet, maybe I'm doing something wrong, it's just a theory

[Windchild]

Well, it seems now that Sophos is reporting this malware works just fine in spite of UAC or limited privileges. Apparently there's a user mode rootkit involved to hide the malicious files on the USB drive - Sophos didn't say anything about privilege escalation occurring and there are no UAC prompts. The .lnk file exploit itself surely works with any privileges, since it's just a shell vulnerability, and apparently when the exploit (or more accurately explorer.exe) starts the Styxnet/TmpHider malware, the malware detects it's running without admin privileges and falls back to a user mode rootkit in order to hide its files and does not ask for higher privileges so as not to spook the user with a sudden and unexpected UAC prompt. The malware wouldn't run at all, though, if there's a SRP or AppLocker policy in effect that denies executing stuff from random USB drives. Similarly, any HIPS and such that would warn you whenever explorer.exe or anything else for that matter tries to execute some new file should prevent the infection.

Originally Posted by Rmus

I've not tried that scenario, but I've tested AE2's delete prevention with a large group of files. You get one visible alert for the first file, but all the rest are denied anyway.

Ok, that makes sense. I figured (well, hoped) there would be something like that to avoid a popup storm...

[CloneRanger]

@Windchild

Is Sophos now calling it Styxnet/TmpHider or should that be Stuxnet/TmpHider ?

Whoever coded up this certainly know what they are doing, very clever.

[MrBrian]

Originally Posted by Windchild

Well, it seems now that Sophos is reporting this malware works just fine in spite of UAC or limited privileges.

Thank you Windchild for the information . The link is http://www.sophos.com/blogs/chetw/g/...ndows-systems/.

[MrBrian]

Some information about user-mode rootkits from Prevx blog entry Is Limited User Account enough? Not really...:

We can then go on to talk about rootkits. I've already written above that under a limited user account, a kernel mode rootkit can't run; but don't forget about user mode rootkits.

Running under a limited user account will still give attackers a nice chance to play their game. If a user runs a piece of software under his limited user account, the software will get the user's privileges. What does this mean? Basically, every piece of software run by the same user will get the same privileges. More exactly, with a bit of work, every piece of software can write into the process memory zone of other processes owned by the same user.

So, if user "mike" is running under a limited account and he runs notepad.exe and then it runs a piece of malware, this last one could modify the notepad process in memory, for example injecting code into it. More interesting is that, as you can check for yourself looking at process owners under task manager, explorer.exe is obviously run with mike's privileges.

In other words, Windows Explorer, which manages Windows graphical shell, can be modified by a piece of malware even under a limited user account.

This is really enough for a user mode rootkit to hide an infection (maybe a trojan keylogger, as said before). The goal of a rootkit is to hide an infection into a system, not to deeply subvert Windows kernel.

Then, it can simply inject code into other processes, modify IAT/EAT, or hooking SSDT, using DKOM techniques and so on. This is not important at all, the goal is to hide something from the user's eyes.

I'm sure someone is already thinking: "Sure, it is possible, but these rootkits can be easily detected and removed. It's enough that an antimalware software is running under Administrator or SYSTEM account so that it can't be corrupted by the rootkit, because a limited user account can't access to other processes he owns".

Bingo, we've got to the goal of this blog post.

Yes, they can be defeated in an easier way, but we need a security product to do it. And the people who usually think that a standard limited user account is enough to avoid getting infected, won't care to check if they're infected.

The truth is that, even under a standard limited user account, there are still several ways a piece of malware can infect a pc. I have only talked about some ways malware can work, but there are still other ones I won't talk about.

[s23]

In the Sophos video, UAC is at Default settings. In maximum will make difference?

[MrBrian]

Originally Posted by s23

In the Sophos video, UAC is at Default settings. In maximum will make difference?

The Sophos blog post states that admin privileges aren't needed for this malware, so a UAC prompt needn't be triggered. What's left unsaid is whether the malware does even worse things if it gets admin privileges, and whether a UAC prompt is triggered (at various settings) when an admin account is used.

[Rmus]

I asked Bojan at sans.edu for an explanation of the specifics of how the .lnk file actually works - the Diary was referenced in a previous post.

He said in essence that the .lnk files contain a number of structures that point to the destination they are linking to. and that Windows Explorer will parse these structures to display the resulting icon. This is where the vulnerability is -- they carefully craft these structures so they point to Control Panel and then link back to the removable drive. While parsing this there is a vulnerability in Shell32.dll which, when trying to open the icon of the malware gets it executed.

This is why just making a regular shortcut to the malware doesn't automatically trigger the exploit.

Nonetheless, I created a regular shortcut and manually clicked on it to reconfirm that with proper protection in place, the exploit is stopped dead in its tracks:

Windchild mentions other protection:

The malware wouldn't run at all, though, if there's a SRP or AppLocker policy in effect that denies executing stuff from random USB drives. Similarly, any HIPS and such that would warn you whenever explorer.exe or anything else for that matter tries to execute some new file should prevent the infection.

----
rich

[Rmus]

Originally Posted by MrBrian

AutoPlay can automatically browse a folder upon insertion of a USB stick.

Agreed, but if AutoPlay is disabled, there is still danger if the user goes to the folder, as you have pointed out earlier.

----
rich

[erikloman]

Proof of concept exploit code here.