The Malware of Ultimate Destruction

The Malware of Ultimate Destruction

  • Comments 6

The other day Peter was talking about the ActiveX Control of Ultimate Destruction -- a hostile control which, the moment it is loaded immediately formats your hard disk.  The aim of the ACoUD is to do "as much damage as possible in a short amount of time".

 

Well, Peter's not the only one who's kept up at night worrying about this stuff.  Last night I couldn't sleep because I was thinking about how that characterization of the ACoUD really isn't bad enough.  If this is going to be the ULTIMATE in destruction, let's think about just how evil we can get.

 

For the purposes of this discussion, let's not care about how the evil code gets on your machine.  Perhaps you download and trust a malicious ActiveX control.  Perhaps a worm takes advantage of a buffer overrun in the operating system.  Perhaps you got an email virus, or ran a bad macro, or whatever.  Let's just call all those things malware.  Furthermore, let's assume that all attempts to stop the malware from running -- like never logging in as administrator, etc, -- have failed and that the malware has elevated its privilege to administrator.  Let's assume that the malware author is brilliant and has unlimited time to craft something incredibly devious.  Remember, we're going for the ultimate here.

 

Here's the worst I could come up with:

 

* when the malware is run, first it waits until some point when no one is using the machine.

* When the coast is clear, it compresses and backs up the entire hard disk.

* It then installs a minimal linux kernel on the box along with a cleverly written Windows emulator.

* The state of the emulator is set up to exactly mimic the state of the machine as it was before the attack.

* The linux boot sequence is rewritten to exactly resemble the Windows boot sequence, except that of course what is really happening is that linux is loading a windows emulator during the boot.

 

The net result: you are not even running Windows anymore so nothing is trustworthy.  The emulator could be logging every keystroke, sending your files to Brazil , whatever the emulator writer wants.  The emulator could be reporting that no, there is no linux boot partition on this disk!  You don't own that box anymore.  The chain of trust has been broken.

 

How could you detect this attack?  Since you're not running Windows, you can't assume that the operating system will report anything about the machine correctly.  You'd have to boot off of trustworthy media and run utility programs to examine the real state of the disk.

 

How could you prevent this ultimate attack?  Remember, we're assuming that all the usual good stuff has failed, like keeping up-to-date with patches, not running as administrator, maintaining firewalls, not opening suspicious email attachments, and so on.  What is the final line of defense against this sort of ultimate malware?  Really the only line of defense that remains is the hardware.  To solve this problem the chain of trust needs to be rooted in the hardware, so that when the machine boots it can tell you whether you are loading code that has been signed by a trusted authority or not.  The possibility of constructing such chips has met with considerable controversy over the last few years, and it remains to be seen whether they are technically and economically feasible. 

 

Regardless, the point is that though this is in many ways a ridiculous "overkill" attack, it is in principle possible. This is why trustworthy computing is so incredibly important.  At the very least, you need to have confidence that when you boot up your machine, you are actually running the operating system that you installed!

 

 

I was thinking about all of this last night because of the recent successful attack against Valve, a local software company that made the popular video game "Half Life".  I don't know the exact details -- and probably no one does except for the attackers who perpetrated the attack -- but what seems likely is that attackers exploited a known vulnerability in Outlook, and a high-ranking Valve employee was vulnerable to the attack.  The malware installed a key press logger, and from that point, it was pretty much game over, so to speak.  By monitoring key presses they'd quickly learn all kinds of details such as the administrator passwords to other machines, compromise them, and eventually manage to "own" as much of the network as possible.  The attackers didn't have to emulate all of Windows, they just had to tweak it a tiny bit by installing a key logger.

 

The fact that this underscores the importance of keeping up to date on patches is not particularly relevant, and I do not ever want to blame the victim for failing to patch a machine.  The important point which this illustrates is that there is a spectrum of malware out there.  Consider the Blaster worm, which simply tries to cause as much havoc as possible and spread as fast as possible -- that thing wasn't targeted against anyone in particular, and though it was very costly, it was akin to a hurricane that blows through and wrecks a lot of stuff.  But it certainly announces itself.  I mean, it might as well put up a big dialog box that says YOU ARE OWNZORD BY BLASTER -- Blaster was about as subtle as a brick through a window.

 

The Valve attackers were far cleverer and subtler. Their attack was focused on a particular individual at a particular company and depended on slowly and carefully gathering the information needed to launch further attacks, avoiding detection until the job was finished.  You can rapidly write and disseminate a virus checker for "broad distribution" worms, viruses and Trojans, but it is very hard to write a "virus checker" for custom built malware that only attacks a single person!

 

This second kind of attack I suspect is far, far more common than the first and ultimately costlier.  But since the first kind is by its nature highly visible, and the second is by its nature as invisible as possible, the former gets a lot more press. 

 

We need to solve this problem and produce a more trustworthy digital infrastructure.  It will not happen overnight, but I am very confident that we are on the right track.

  • Nice entry, Eric. Whilst Microsoft software is often the target of mass-infection, let's-get-as-many-zombie-machines-and-generate-as-much-network-traffic-as-possible attacks, it really is the hand crafted, precision attacks against high profile targets (like Valve or the FSF) or the "inside" attacks against corporate systems that are more interesting (and more costly) in the long run. And they happen no matter who your software vendor of choice is, or how well your machines are patched, or whether you have the source code or not.
  • Also many inside attacks or targeted attacks aren't reported as corporations worry that it might cause a lost of confidence and hurt business if they're made public. Another interesting post Eric! Thank you.
  • A few years ago, I had a server hacked. It took me a while to figure it out (I guess the new admin account, hax, didn't catch my eye right away). What made me notice was that when I logged off, the screen would blink and then not log off. The second attempt would work. That's when I checked the running tasks and saw a process I didn't recognize. After looking for it, I found it in the system32 folder. It was an executable disguised with the standard folder icon. I found an entry in the registry named passwords. After a bit more debugging, I found that this sucker registered itself as the handler for text files (not just .txt extensions). What it did was make sure it was "installed" correctly and then ran a second copy of Explorer and then opened the original text file with notepad. I ended up having to wipe the entire domain since it was possible that the domain was no longer under my control. The machines were patched and up to date as much as possible (within a week of any releases). It was also running anti-virus software. I've always wondered if my machine was a test run for some other attack.
  • Ouch! But that's the right approach to take -- http://www.cert.org/tech_tips/root_compromise.html
  • Yeah. Now I hide behind a firewall, keep as many ports closed as possible (now why in the heck don't my servers sync up with the time servers... oh, yeah), use different passwords for every machine, and moved other services off the domain controller (now that I can actually afford to build and run more than one server).
Page 1 of 1 (6 items)