New MBR rootkit goes undetected

what about drweb and superantispyware?
im sure other vendors will be able to detect it when active soon.
last time drweb was first followed by KLand later on f-secure.

 

I know Dr. Web is working on it, but AFAICT they don't yet. We've been sharing information with a number of other AV companies so I suspect others will be adding detection for it soon

 

Is an update needed for detection? If so, which version detects it?

 

The current beta version detects it and we will be releasing it officially to all users by tomorrow morning. v3.0.1.47+ detect and clean the infection (released first on April 8th).

 

Wouldn't AVG Identity Protection (based on SANA's product) be able to spot it? I believe it works different from "normal" HIPS?

 

Its a completely different threat - the behavior which it has is built to just hide itself as thoroughly as possible within the system.

No current HIPS product can see what its doing once the system is infected because the changes it makes are hidden via a new spin on old rootkit techniques.

However a HIPS which intercepts raw disk writes "may" be able to see the initial infection, but it highly depends on the HIPS.

 

I wish I could test it with DriveSentry.

 

Samples have been distributed on many research lists and to antivirus vendors. We're quite busy but I'll see if we can do any testing with DriveSentry

 

PrevX support.Are you working on a complete solution to prevent this type of threat (and similar) rather than individual variants? If so how's it going?

 

Yes, we have "Realtime MBR Rootkit Detection" which detects it generically in realtime and our detection/cleanup is not dependent on this variant at all.

Our previous detection routine for the older MBR rootkit also never changed since we released it > 1 year ago across the few hundred variants released for the MBR rootkit.

 

Thank You

 

All known exploits are by remote code execution (drive-by download) triggered by code on web sites that exploit known vulnerabilities in IE and various applications, such as Adobe (PDF), Flash (SWF).

Mebroot - Advanced and Stealthy MBR based Rootkit
http://msmvps.com/blogs/harrywaldron/archive/2009/02/19/mebroot-advanced-and-stealthy-mbr-based-rootkit.aspx

1) Configure Software Restriction Policies

2) Get any program that has execution prevention (blocks unauthorized executables from running)

Those sites I've found in Malware Lists have already been taken down, but here is a Mebroot exploit from 2008 using MS06-014 (MDAC) where the downloaded executable is copied to %User% as svchost.exe
and attempts to execute and is blocked:

​

If I find a current live site, I'll test and post a screenshot.

----​

rich

 

For technical users this could work, but if a threat like Conficker was able to spread to millions of users via simplistic exploits and USB drives, its very possible that another threat can spread similarly (as they have many many times in the past). Using an anti-executable program like this isn't really a fair way to say you're blocking a threat - its as effective as turning a computer off as nothing should technically be able to get through but you'll get a popup everytime a new program runs

However, a less "draconian" approach from a complete anti-executable solution would be to use a limited user account, which should be equally effective without the overly suspicious prompting.

 

That's good to see Will these detection routines be incorporated into CSI?

 

With all due respect, your comments show a lack of understanding about execution prevention (White Listing)

I would argue that it is the most effective way of blocking this type of threat (remote code execution).

There is no requirement that the user have technical knowledge. I've installed such protection in many home systems with no problems. Popups (alerts) come only when an executable attempts to run without permission. To install a program (executable) you grant permission, as in the case where the user grants Administrative privileges.

Conficker is a wonderful example. Anyone with execution prevention would have been protected from both of the two attack vectors,

1) RPC via Ports 139,445 to set up a shell to call out to the malicious server to download the DLL (unauthorized executable).

2) Autorun.inf which triggers run32dll.exe to load the DLL.


----
rich

 

I agree that blocking all new executable code is very effective from a technical perspective, however, if a user receives a prompt every time they install a new piece of software, that requires user education to discern between a legitimate program and a malicious program and, with all due respect to users everywhere, whenever a user has to make a decision, they tend to decide wrong.

Ideally, security should be silent and not require any prompting but an anti-executable approach is the opposite, prompting on every new program.

Also (out of curiosity as I haven't actually used an anti-executable product), do they only focus on ".exe" executables or do they also prompt on every new individual module loaded as well? If the former, that introduces a major vulnerability as a threat doesn't have to enter as an executable itself but can easily enter from a dropped module.

 

My personal effective and non-technical method is to always boot from a frozen snapshot and use a web browser within a software sandbox. Obviously, when buying things online I use a virtual credit card with one-time passwords generated by a key fob. I will "unfreeze" the OS snapshot only when I install softwares once in a long time. Just joking but I do use Prevx Edge and it works pretty well so far.

 

I know Returnil denies access to the MBR when active.

 

According to some poster in the Returnil forum, this MBR Rootkit is able to bypass Returnil when it is active.

 

Thank you Rmus. Theoretically with Sandboxie I should be good to go. If I had a test machine I would give it a go but this is a serious bug. I'd like to see how Sandboxie's Start/Run Access (anti-exec.) and Drop Rights features hold up. Then again, my OS or an app. would have to be vulnerable.

Why do these articles not focus on prevention or methods of infection?

 

At this point the threat is relatively limited. The new MBR rootkit is only being spread from a handful of URLs as a simplistic driveby download but we suspect it will be put inside another infection or placed behind a more powerful exploit.

Luckily it currently looks like the authors spent 95% of their effort on the engineering of the infection itself and 5% thinking about how to infect people which should give vendors a good heads up on detection/cleanup before it becomes a threat to a wider audience.

 

Thanks for your reply. While I can appreciate an articles details of the inner workings of an infection, they are way over my head. What I can understand is how to keep it off my machine but only if I know how it gets installed. If that requires a workaround or an update, that's a simple fix which most can do. Without details as to how it gets installed we are in the dark.

Anyways, good to hear it's a small threat for the time being. Please keep us updated if and when anything changes.

 

i think....no i assume...this way....

the problem.........av's can't detect it....but can something like rollback to clean snapshot save one's day?

 

@PrevX Help & EraserHW:
Apologies to OP; slightly OT here:...

First a question:
That silent all knowing all caring utility will never exist will it.
Even PX's 'in the cloud' db will not have zeroday protection.
Are you saying that PrevX would not have blocked installation of this mal, rather, just detected it after it's installed ??

Still running Px2 here and setup to block anything not approved for 'run' or 'connect' etc.
Does the new PrevX not have this capability easily visible ( think I've asked this before ? )
Am I in fact better off with execution blocking with PX2 rather than handing over all my trust to PX3 ??

Second: an observation (s):

That is a slight hyperbole: as noted the user only gets prompted with a new install.
FWIW, I have not really installed anything "new" for months: (very boring here: aiming for productivity these days, and in fact; stripping out lots of 'tools' I have never really used) ergo -no popups- , and in reality it is not a heavy burden. In fact I am reassured whenever I see the "do you want to or not" or " Blocked this executable" popups and will occasionally do a blind run for testing.

PX by default uses a type of whitelisting at the core, yes?
Fastest db out there, yes?
Easy to see the benefits of that.

 

Without that information, you are right: How do you know what you are protecting against? Ideally, analyses would give the reader that information right up front.

When the digital picture frame exploits began to surface, there was a lot of confusion about how the infection actually took place. Numerous articles made statements that all you had to do was connect the picture frame to your computer and you were automatically infected. I confess that at first I didn't realize that the frame is just a USB device, meaning that the triggering mechanism was the autorun.inf file.

Finally, it became apparent that the autorun.inf file triggered the running of an executable. Many people at that time used autorun, so were potentially vulnerable, unless other preventative measures against such a payload were in place, as was the case with those I helped at that time:

​

You are right: This is the proper way to deal with exploits - how do they install.​

The explanations do not have to be technical. The inner workings of an infection are relevant only to detection/removal. For example, with Mebroot: while the intricacies of infecting the MBR are certainly impressive, nonetheless they are irrelevant to the preventing of Mebroot from installing in the first place. It has to install before it can touch the MBR.

No security-minded people I know wait around for something to detect an exploit. They get the pertinent information about the attack methods and the payload and go from there.

All that is needed is for the analysis to have a brief description of how the exploit gets installed. It doesn't have to be overly technical. Preventative measures will then be discerned.

Let's look at some examples, beginning with the one I just mentioned.

Digital Frame Exploit

The only information that is needed is:

• the attack method uses autorun.inf
• the payload is a trojan executable

Prevention is obvious:

• disable autorun
• have protection against the payload: installation of unauthorized executable

Mebroot

The only information that is needed is:

• remote code execution attacks via web sites, vulnerabilities in IE, various applications.
• the payload is a trojan executable

Prevention is obvious:

• patches for the vulnerable applications you use
• have protection against the payload: installation of unauthorized executable

As has been suggested, another method of exploitation may surface. If that happens, hopefully the security vendors will explain so that other appropriate preventative measures, if necessary, can be put into place.


Conficker

The only information that is needed is:

• The attack method for conficker.A utilizes open Ports 139, 145
• later, conficker.B attacked via USB autorun

Besides the patch for MS08-067, the other preventative measures are obvious. By the way, some articles misled people into thinking that the patch protected against conficker.B via USB.

There is nothing I've listed that is overly technical. There is no reason why analyses of exploits cannot begin with a simple description of how the exploit attacks, followed by preventative measures, before delving into the intricacies of how the infection works once installed.

If it can't install, it can't infect (someone else thought of that line!)


----
rich