Discussion on:

Forged memory fools antimalware: A new development in rootkits

It seems the rule is whatever gets in the lowest starting position wins. That is, if malware gets into a low level before the OS/App can get a hold it wins and if the OS/App gets there first it wins.

I will pass it along to Mr. Mathur.

Or is this something that any OS could fall victim to?

I do not have all the details of the exploit. So, I am passing this question on to Mr. Mathur as well. Thanks, SinisterSlay

I would think the dropper or injection part of the package either exploits a vulnerability for remote code execution (probably doesn't matter so much which exact vuln) or simply uses social engineering - especially effective where users are already running the admin account for normal use.

What exact vulnerability is currently being exploited would be interesting to know. It would also be interesting to find out what vulnerabilities the payload(s) are using - the virus, worm, or whatever - or indeed what the payloads are. I understand that this was outside the scope of the research and discussion on the rootkit part of the malware package.

is vulnerable to rootkits.
specially the unix and unix-likes.*
The privilege escalation nature of administration for the unix and unix-like operating systems is exactly what rootkits were originally designed to exploit, get the root user login info. [ root being system admin account ]


*the BSD variants, GNU/Linux, HPUX, AIX, Irix, MACOS(n) for a quick listing of unix and unix-likes

Not being remotely a Linux expert, I was hoping you might comment about Linux distros being vulnerable or not.

the mac fanbois would lie and say it can't impact all operating systems, when the truth is rookits are something that can get any os and everyone needs to defend against.

lucky there are rootkit detection tools for all the unix and unix-like operating systems. rkhunter being the current promoted version.
http://www.rootkit.nl/projects/rootkit_hunter.html

Ignorant *Nix fans, I'd guess. If so, become a better *Nix user/admin and learn a little. Guess where rootkits are first described, and why some do not consider Windows rootkits to be true rootkits at all.

On windows the lower hanging fruit is higher up in the stack, not as much need to get a low level compromise. Maybe malware writers are being lazy, or kind (no sport shooting fish in a barrel) not making "true" windows rootkits more popular.

Reminds me of Bart Simpson bored in the library pulling "find waldo yet again" off the shelf and declaring "oh man, he's not even trying anymore!?

http://www.youtube.com/watch?v=dZ9kcB1xfXk&feature=related

You just about have to use a rootkit to compromise a *nix system, with windows, why bother?

And yeah, I can watch that clip in my head without referring to YouTube. I agree with the sentiment. Why bother hiding something that is unlikely to be removed anyway, never mind the usually unnecessary privilege escalation? Many users are the best sort of rootkit a malware writer could hope for.

But as to the Windows rootkit thing, I've read plenty of text from people that think the definition of rootkit simply does not apply to Windows, and would rather call Windows rootkits something else. I thinks it is an old-school Unix-y definition thing.

Especially in light of this : Mac OS X runs on UNIX. The underlying code base is inherently more secure. Its more difficult to hack. Thats not to say it cant be done; it can. But cracking UNIX security is more difficult than some other operating systems. - Eric Eckel
From here
Amazing synchronicities, eh?

Eric actually has that wrong you know.
Macos(n) [ all versions of it from the first onwards ] ARE a unix.
they don't run on unix, they are unix.

Can you let us know when there is a software that implements the new detection routine? The only blip about this is "updating anti-rootkit features take time" so I imagine that there is currently no automated detection available?

I wonder how long it will take before we see malware inserting into the hypervisors.
Let's just hope there are few vulnerabilities to allow it...

I tend to ponder two things. How researchers find this stuff, and what stuff isn't being found.

A) Testing the wild stuff... like Mr. Mathur did.
B) Asking "What would I do, were I bad?"

I don't know how much they do the third option, the detailed forensic study of already perpetrated crimes to find the reasons - I would assume that the needs for recovery takes precedence over forensics most of the time - hard drives are simply wiped and images restored. And then, it's hard work.

How do they harvest their samples? There could be blind angles.

The cat versus mouse game will be going strong for a long time I fear.

http://www.techrepublic.com/blog/security/code-for-ultimate-rootkit-to-be-released-on-19-march-2009/1130
http://www.techrepublic.com/blog/10things/10-things-you-should-know-about-rootkits/416
http://www.securityfocus.com/columnists/402
http://theinvisiblethings.blogspot.com/
http://www.invisiblethingslab.com/itl/Resources.html

Thanks to Rachit Mathur, Joris Evers, Ian Bain, and Michael, et al.

As users, how do we avoid memory-forging malware?

Excellent question. Conficker, you know, still owns millions of computers.

Also, thank you for adding your insight in your earlier comments. I am hopeful that Mr. Mathur will get back to me with his thoughts.

whats to keep this memory at restart...say place in memory at shut down write to hd then on restart write to memory and delete hd files

The key to this new malware is that it takes over the operating system at a very low-level (likely right above the kernel). This would give it control over what other applications can see; if the malware is below the level of the anti-malware, it can send fake information to it since it has "more control." So, it does not need to delete "hd files." Instead, it just spoofs them with the location Y data when querying for location X data as stated in the article.

From what I was able to glean from Mr. Machur, the rootkit has low-level control.

Pre-boot scans, provided the AV has the rootkit's signature, are not fooled by this exploit simply because scan is performed before operating system is loaded. I know Avast provides such scan.

But there is another thought that's bugging me; even if AVs have the right signatures, still rootkits can get around pre-boot scans by encrypting themselves and storing the encrypted copy with the encryption key on the disk in a, say, jpg file. At boot time, instead of the rootkit, a simple "loader" can be loaded to load and decrypt the rootkit, re-encrypt it with another random key, and save it to the disk. Even a simple scrambling technique, such as XORing the code with a randomly generated pattern, can ensure the rootkit is not detected in a pre-boot scan. The loader itself is not detected because it is not a malware itself and AV's don't look for it. Even if they do, it's much easier to create different variants of a simple loader than the rootkit itself.

For the insightful comments. Just can's seem to get away from those signatures, can we.

Image files are becoming popular repositories. I recently wrote about how Evercookies are stored in them.

Signature based detection seems to be the only way that does with it's supposed to effectively. Unfortunately with inherent inadequacy of signature-based detection, our best bet is an effective real-time behavior analyzer, and I yet to see one.

Your article about Evercookies was very interesting. It just shows how securing our computers, and information, become increasingly more difficult vis-a-vis ingenious new techniques used by cyber-crooks.

Please let me know. I have been researching what is needed to pull it off and the requirements are steep. Still, I have no doubt that it will happen.

Glad you liked the article. The cleverness we humans exhibit never ceases to amaze me.

if you promise to do the same! But I have a feeling that by then the bad guys will have already found a way around it.

made my Emisoft, the makers of A-squared and Online Armor, called Namutu. It is kind of like using the free version of WinPatrol, but seemingly more powerful. It is strictly behavior based, uses very little resources, or RAM that I can tell. It took it just a few seconds to find my DRM spies on my PC. I had to exclude them from "protection" just so I could use my cable and blu ray.

It seems lightning fast at what it does. So far it seems awesome!! I can't use Online Armor on Vista x64 so I'm pretty excited about testing this. So far so good!

I think the giveaway ended this Sunday.

I searched for Namutu and didn't find anything on CNET (including download.com)

I think JC just mistyped the name.
http://www.emsisoft.com/en/software/mamutu/
http://download.cnet.com/Mamutu/3000-2239_4-10777324.html?tag=mncol;1

I downloaded it for trial and waiting to see how it deals with the little buggers!

I may have to try it myself, but probably not in the near future.

because when it identifies OpenVPN client as behaving like a backdoor that tries to bypass LAN or another program that tries to "invisibly" send out information, it doesn't provide any clue (such as the destination IP address) so I can tell if the program has been compromised or it's just performing its legitimate function.

With my ear pressed to the door, I learn more than I probably am entitled to learn.

Thank you.

behavior analyzer would be a self aware AI, imo. Its the only way I can see that software is going to be able to thwart, to use Mr. Kassner's words, our "human cleverness". But that's just me. A self-aware AI seems like overkill to me, just to take care of malware, seeing as what else an AI of that magnitude would be able to do - if you believe the Kurzweil's of the cyber world

All OS files should be digitally signed with strong cryptography (e.g. 2048-bit or longer RSA). Then all the scanner has to do is check that all OS and boot files are properly signed. If they are, there's no rootkit; if they aren't, it's time to replace them with backup copies.

For OS files that cannot be digitally signed (mostly configuration files), the scanner can still compare them against the defaults and report the differences. Once the user confirms those versions of the files are okay, the scanner compiles a list of checksums for the confirmed versions and digitally signs the checksum list before saving it in a file on the drive. When dealing with Windows, the scanner should also generate separate checksums for each section of the registry, because that file contains a mess of configuration for just about everything.

Since the rootkit is able to change any file on the computer it's on, the backups should be stored on CD/DVD and the scanner should be a live CD (user-made with its own 4096-bit RSA key for digitally signing the checksum list files it makes). With both scanner and backups on read-only discs, I think the only level left for rootkits to infect without being detected would be at the motherboard, which I'm clueless about protecting.

But, the point of this rootkit is that it uses mis-direction. Couldn't that same technology be used to mislead the scanners you mention.

It's my understanding a lot of these things wipe their own executable from the hard drive once they are resident in memory, then re-write it for the next boot on shut down.

A scanner wouldn't have a chance if it's OS dependent, and scanning system files on the boot media, it would seem.

And can you make the registry read only at any point? Maybe when written to disk at shutdown, so during boot it's read only and any rootkit would not be able to erase it's track. But I'm spitting in the wind on this one, I have no idea if such a thing could be done. (some way of preventing the rootkit from erasing it's executable on boot)

from the hard disk when they were running in memory; I could just boot the system, wait a while to make sure rootkit(s) are running, then unplug the computer and all the rootkits would be gone!

after a clean install, you have all your programs installed, data, etc, and when you're done, you flip a switch to make the OS read only; any activity by a user (browsing, creating/saving documents, music video etc) can be retrieved, read/written to a separate partition or drive, leaving the OS totally isolated, no? I'm sure this idea isn't new, and I'm not thinking of virtualization because doesn't certain operations, (like network calls) have to go through the VM sandbox? I'm thinking of totally rerouting everything (misdirection, for use of a better word) but what do I know....

I've always wondered why there can't be some form of randomization of memory locations that would thwart any attempt at an exploit because the malware writer would have no way of targeting a given function, seeing as it'll be a different address at every boot. Sort of like a benign root kit.

I know windows does a modicum of randomization of memory allocation, but that's way up the food chain at the application level. Maybe there's just too much overhead for such a thing to work. But maybe a modular approach could work, have the three basic files that load the OS bump their base up or down a block or two and translate all calls, the math should be simple, but I bet the hardware simply won't allow enough randomization.

I know nothing about low level coding, I suppose I shouldn't speculate about such things. I've also often wondered if there isn't a physical, non code-based way to detect a root kit, say an anomaly in the radiation field emitted by the processor. Have a micron sized starship Enterprise hovering over the CPU checking it's surface for anomalies with the sensors...