Worm Allegedly Bypasses System Rollback Software

I just noticed this thread now. AppGuard version 1.2 indirectly stops a killdisk attack by suppressing unknown software launches from user-space. However, to directly stop the RAW I/O or direct access based attack on the master boot record, we have a feature called MBRguard.

I announced a pre-release version available download last month. Another version may be released soon, with some refinements. MBRguard will be folded into AppGuard version 1.3 as part of normal software updates. I do not have a release date for 1.3 because we had an unplanned development sprint for EdgeGuard to satisfy requirements from some new, large customers.

MBRguard should stop any KillDisk variant. We would appreciate feedback.

Cheers,

Eirik

 

This worm bypasses Eaz-Fix as well.

 

For those who are interested,

I can personally confirm that DefenseWall v2.56 successfully blocks the malware sample in question under Vista 32 SP2.


Peace & Gratitude,

CogitoErgoSum

 

Thanks. Can u elborate how the test?
Did you test alongwith returnil?

 

Hello aigle,

FYI, I tested DefenseWall along with Shadow Defender. As long as DW was active my system was not compromised.


Peace & Gratitude,

CogitoErgoSum

 

Thanks.
By the way, does this worm works in vista? Any ideas?

 

Yes.


Peace & Gratitude,

CogitoErgoSum

 

A puzzle called SafeSys

 

Thanks for the article. Now that the cat has been let out of the bag by someone at Prevx with technical expertise and reputation, it might be in order for everyone to review her/his security philosophy. I will speak with reference to Deep Freeze (DF), which I use on one system.

I came across DF many years ago while teaching in a local college. I thought the idea of reboot-to-restore was quite unique. This was especially effective in computer labs and classes where Administrative privileges allow the user to work on assignments that make system changes in networking, the registry, etc. Upon rebooting, the computer is restored to its original state.

For the home user, there are issues to consider. In the education environment, the computers have just one partition which is frozen. No user data is ever written that needs to be retained. The home user, however, needs at least one partition that is not frozen, or 2nd internal or external hard drive that is not frozen. Now, how do you protect the unfrozen areas should malware intrude?

A good example is a file infector which searches across all partitions/drives for .exe files to infect. The current DDOS exploit is even more sinister:

DDOS Madness Continued...
http://blog.fireeye.com/research/2009/07/ddos-madness-climax.html

I eventually moved away from using DF as a security product. Rather, my use turned out to be for keeping the system partition free from the normal build up of clutter and temporary junk, etc. No maintenance like defragmentation is required.

Somehow the idea that malware could intrude w/o any care or concern because it would be discarded on reboot, went against my own philosophy of preventing intrusion in the first place, since my attention was focused on secure preventative measures that would be useful for home users. This is what got me interested in looking at exploits to see how they can be blocked from running.

For Deep Freeze, another weakness was exposed last year with Chinese malware used mainly in Internet cafes, requiring physical access to the computer. This malware attached a driver near DF's low level filter driver, intercepting the read/write calls. I don't know if DF's next version addressed that problem or not.

Now we have the current safesys which, if permitted to install moves down the chain of drivers, bypassing DF's filter driver, to write directly to disk.

And so we come to one's security philosophy. One fallacy is exposed by this statement in the Prevx article,

This sentiment is often expressed in posts stating something to the effect, "let the nasties come while I'm surfing: they will be gone on reboot."

Well, maybe not.

Not all reboot-to-restore products are affected by this particular exploit, but who is to say that new exploits won't target other products later?

Another point of philosophy addressed in the article:

An illustration I've used before is addressing the problem of rats underneath my house. If the air vents around the house are not secured by wire mesh, rats and other rodents can get in.

With no wire mesh, permitting the critters easy access, setting traps underneath the house may eventually catch them, at which point they can be removed/discarded. Meanwhile, before being caught they may do other damage, such as chewing on wiring.

From my point of view: As with the rat trap, roll-back or reboot-to-restore systems should not be the primary focus of malware prevention in one's security philosophy

----
rich.

 

It's also probably worth noting that this is not the first infection to bypass various disk protection products - the last few variants of the MBR rootkit also bypass their protection and can infect the system directly beneath it.

We've tested a handful of products and none of them are impervious to these types of attacks simply because there are limitations to how low a driver can sit in the stack and still intercept data/allow data to pass through.

Using a limited user account as well as rollback software helps to prevent these infections because it prevents userland applications from accessing the disk for any form of read or write access at a raw level. However, it still isn't perfect and there have been a number of userland elevation exploits which work under limited user accounts and can grant access to write to the disk. Alternatively, you can use a virtual machine (VirtualPC or VMWare) which is far less likely to be exploited (although still technically possible) for any browsing/software downloading/etc. However, the need to use a conventional detection-based security product is still very prominent because of the ability to infect a system without administrative rights (i.e. a usermode keylogger).

This new worm uses a far more interesting technique than others but there are many, many more ways to get past than this one and I suspect it will continue to be a cat and mouse game to see who can protect against what.

 

OK, fine, Virtualizers can't protect against everything. How many of these "SafeSys" nasties are out there? 5-10-15? They can be counted. How many nasties can be missed by top notch AVs? 1000, 2000? these figures produce percentages around 99.7% 99.8% which are considered excellent.

If I had to choose to run ONLY with ONE security application, I would certainly choose a virtualizer/ISR over an AV. I still have to read about a Wilder's member who only uses one security application though (there is maybe one that I know of).

 

Totally agree.

 

Hi, I am curious about one thing above.

Can you explain (or cross reference) how the various "userland elevation exploits which work under limited user accounts and can grant access to write to the disk" have managed to do this? Specifically, did any of them achieve this without user knowledge, ie without giving the limited user the UAC option to deny / block?

Peter

 

pbw3

That's what i was wondering too, i think i've find the answer which i felt deserved it's own thread.

https://www.wilderssecurity.com/showthread.php?t=248767

S

 

StevieO,

I may be simply confused, in which case apologies, but your new thread seems to refer to the same link as in thread 63 above by "Developers", ie a Prevx blog?

You suggest this may provide the answer, but I am not sure I can see any reference to that in the blog referred to, ie how elevation exploits under limited user accounts can grant write access to the disk - unless in reality it is because the user actually allowed the UAC prompt..??

Peter

 

Sounds to me like he (PrevxHelp) was simply referring to privilege escalation vulnerabilities and exploits against them. http://en.wikipedia.org/wiki/Privilege_escalation Such vulnerabilities may be exploited without any user knowledge. For example, your antivirus scans a malicious RAR file, which is designed to exploit a vulnerability in the AV's scanner that runs as SYSTEM, and thus can execute code as SYSTEM when scanned by the AV, effectively elevating privileges to highest possible without the user ever noticing anything at all (well, the AV may crash, for example) or having any option to stop it. UAC does nothing. Any code that has gained admin or SYSTEM level privileges can write directly to disc, if it wants to, since such code has freedom to load drivers to do such jobs.

However, privilege escalation exploits are something rarely seen in the Windows world. Such exploits are rarely used even in targeted attacks against high profile and value targets like businesses, and widespread in-the-wild malware practically never attempts anything even remotely like a proper privilege escalation exploit. Tricking the user to execute the file with admin privileges does not count - that is social engineering, and very easy to defend against (if you bother to, that is). Can anyone here show an example of any malware that was at some point ITW and actually exploited a privilege escalation vulnerability? Those aren't exactly common.

Where I'm going with this is that I feel PrevxHelp was being a little sensationalist with his statement. Which is really to be expected, considering that vendors have a product to sell and wouldn't be wise to make statements that make their own products seem less than necessary. Actually, PrevX should be applauded for going so far as stating in public that using limited user accounts can mitigate this problem or that - there are lots of people in the world with stuff to sell you that tend to often forget to mention such things. The following quote shows you that we're still in marketing mode, though: "However, the need to use a conventional detection-based security product is still very prominent because of the ability to infect a system without administrative rights (i.e. a usermode keylogger)."
The problem with conventional detection-based security products is that they're very quick with the false positives and very slow with detecting the real threats - especially the new ones. Sometimes, for some people, they can save the day. But don't ever, ever count on it. Much more effective is a whitelist mode of protection, where anything new is denied by default - don't need no signature updates. And then, the quoted statement is actually somewhat misleading technically, as well. An usermode keylogger, if only infecting a limited user account, isn't really infecting the system. It's infecting one user profile that has limited privileges. The infection is at a user level, not at the system level: one user is infected, but the system is not, and other users can go about their business and they are not infected.

I don't see any answers in that thread to pwb3's question.

 

@ Windchild

Great explanation - thanks... I'm reading that as possible due to unpatched OS design flaws / other exploits (per wiki et al), but in reality pretty rare re actual malware, if at all - at least currently as known..

and completely agree re whitelisting etc - in practical terms one of the most valuable security concepts I have gained from reading these forums...

Peter

 

Yeah, unpatched vulnerabilities in the OS or other installed software. Microsoft is doing a good job plugging the privilege escalation holes in the OS itself thanks to their secure code initiative (the name of which always escapes me), but some third party software isn't doing so well. But that doesn't matter as much as it would elsewhere: privilege escalation vulnerabilities aren't of great interest to Windows malware authors, since such a large number of Windows users run as admin all of the time - even the ones who think of themselves as security-minded. It's much more interesting for them to look for more flaws in browsers and commonly used programs like Adobe Reader of Flash that enabled drive-by attacks. Taking advantage of privilege escalation vulnerabilities isn't so easy, when compared to just your everyday social engineering attacks or using some premade exploit & rootkit kit to spread crapware with. In the Unix world privilege escalation is a much bigger thing, since almost everyone run as a regular user, not root.

 

Yes - they are indeed rare but they are possible. I wasn't trying to be sensationalistic or trying to pitch anything/market anything - just trying to put everything into perspective: users who depend on certain technologies should be aware of the limitations/issues, just as there are limitations with our solution and every other solution.

Regardless of who it is affecting, a keylogger is a keylogger - if you are using a limited user account and are hoping for the increased level of security and end up coming across a keylogger it will be just as effective as if it had administrative rights. A limited user account would indeed prevent it from affecting other users but at that point I would suspect the keylogger doesn't care about affecting other users because it already has access to you.

The best security still is leaving your computer off with the battery out, but what many people forget is that they need to unplug their ethernet cable also to prevent Wake-on-Lan

 

Certainly true - being aware of the limitations of any technology or policy is essential to security. Accurate assessment of risk is impossible otherwise.

I wouldn't say it's as effective as a keylogger that has administrative rights. Although it's certainly true that both could do the job and steal sensitive information from an unwary user. But, limiting the infection into a limited user account makes detection a lot easier than if you were dealing with a system-wide infection, and protects the other user accounts as well. That's difference enough for me to say that keyloggers are a lot more effective when they get admin rights. Obviously a keylogger wouldn't want the victim to detect it, and hiding would be easier with admin rights. In any case, it would be wrong to think that one cannot be infected by malware in a limited user account, and believing that would result in a false sense of security (see people who use OS X, here). But one might say that limiting privileges is the essential basis to build on: if you don't do it, what security do you really have (see Windows 9x here)?

Well, I understand that was a joke that I often use myself. Certainly all the news and discussion in the web on security can make it feel like the only way to achieve security is to take a hammer into the computer and smash it good. But then, security requires availability, and a smashed computer isn't very available for use. Or a computer that's unplugged.

 

Hi, all. The way i read it seemed to provide an insight into what was happening and how. If the info is not related in any way then i'm sorry for posting it and potentially misleading anyone.

S

 

I agree - although it is possible to have a usermode rootkit installed under a limited user account (affecting the view of the current user), a much larger can of worms is opened if run under an administrator account. A keylogger is trivial to detect when it is running as a limited user account but my point still holds true that you will need some means of detecting it, i.e. a conventional antivirus program or other form of detection. My guess is that the average user doesn't open WinDbg and walk through the LDR_MODULE structs and follow the InLoad/Memory/InitializationOrderModuleList linked lists to see if there are any hidden or untrusted modules injected into the processes

I agree here as well, and I think Microsoft should have gone further with their definition of a limited user account to prevent access to specific APIs that can log keystrokes. The loss in usability is marginal and they can always just force the user to use an administrator account if they need keystroke monitoring capabilities.

IMO, most computers can be used effectively as expensive paperweights.