Slashdot Mirror
Rutkowska Faces 'Blue Pill' Rootkit Challenge
Controll3r writes "Three high-profile security researchers — Thomas Ptacek of Matasano Security, Nate Lawson of Root Labs and Symantec's Peter Ferrie — have issued a challenge to Joanna Rutkowska to prove that her 'Blue Pill' technology can create "100 percent undetectable" malware. The Black Hat 2007 challenge will feature two untouched laptops of the make/model of Rutkowska's choosing for her to plant Blue Pill on one. From the article: 'She picks one in secret, installs her kit, sets them up however she wants,' Lawson explained in an interview. 'We get to install our software on both and run it, [and] we point out which machine [Blue Pill] is on. If we're wrong, she keeps the laptop.' No word on whether Rutkowska will accept the challenge."
Don't install root-kit on either one! ;)
No seriously now, if all she was allowed to do was touch one of them.. and both laptops had the same exact everything else, then it should be simple to find ANYTHING that was added to either one. But maybe I'm being naive.
_Vishal www.squad9.com
this is clearly not a fair test, no one installs rootkits on virgin installs, also giving a small set of laptops means they have a much larger chance of just guessing which one even if they're wrong from their analysis, and if the rootkit is the only thing that is on it besides an OS how hard would that be to find? look at the file access dates? with no other software installed this should be trivially easy to find.
.. which already comes pre-loaded with malware to wehre they'd have to actually look for blue pill code.. that might be a little more balanced and realistic since virtually all consumer pc's have some form of virus or malware as people have no clue what it is or what it does and they like their animated mouse icon even if it's stealing their CC#'s for african nationals.
now if they wanted to test on an E-machine
I think this calls for a double-blind experiment with a larger sample size, say 20 laptops. 10 laptops are held out and left untouched; the other ten will either be infected with Blue Pill or not based on a random coin flip. Then it would not just be a question of detecting it, but detecting it to a sufficient degree to put it beyond chance. A 50-50 shot is just too high to be regarded as accurate.
GetOuttaMySpace - The Anti-Social Network
then the same technology could be used for DRM.
The Kruger Dunning explains most post on
It's straightforward to detect *any* malware in this setup. If the hosts of the challenge can't find it, they deserve to lose more than just a laptop.
Step one: Pull the BIOS chips or stick a reader on them. Compare the images between the two laptops. Obviously flash them to the same revision beforehand.
Step two: Pull the hard disks and diff them in another system.
Step three: If the BIOS images are the same on the first two computers, put the drives in new computers of the same model and ask the rootkit to be demonstrated there. This step may be heating, since the contest was apparently only about two computers.
Step one covers BIOS rootkits, step two covers hard disk rootkits, and step three covers the (slightly) less likely case that the contestant will pick a model of laptop or hard disk with some other easily flashable device that can be used to store the rootkit. If the hard disk controller or hard disk itself can be flashed, it would be trivial to make it return a sector from some kernel driver with a rootkit installed only when a certain sequence of other reads have occurred since poweron. Just hash each read request, and only return the rootkit sector if the hash matches a certain value when the sector is read, and then don't return the rootkit version any more. It would just require one boot (with modified firmware) to discover the hash of sectors read by the BIOS and operating system as it boots, and then set the hash in the firmware and leave it. To discover such a hack, the people running the challenge would have to do basically the same thing, patch some firmware or load their own boot sector hack that recorded the exact sequence of reads from a boot, and then hotplug the rootkitted disk to trigger a poweron event and then play the sequence of reads (and any writes) back to the disk, possibly with the same timing, in order to discover the actual rootkit. They could also just read the firmware off the disk and try to debug it, or at least compare it to the firmware of a good drive, but both approaches require a pretty deep knowledge of the hardware and software being used, which gives the contestant an advantage.
There are almost certainly other random flashable devices laying around, especially on laptops, and any of these could be used in combination with a driver bug or some other "feature" to take over the computer. Since the contestant can pick the hardware, this is a distinct possibility. The only way to detect such a rootkit would be to load a higher level rootkit which can be prevented if the original rootkit virtualizes the entire system, but in that case it's probably quite vulerable to timing attacks to detect its presence. I think the hosts of the challenge can ultimately win, but they may spend quite a few hours on it. If they're sneaky, they'll just put their own rootkit on the laptops to begin with and record all the challenger's actions.
Well, this is all about real-world feasability.
-"bluepill.exe and bluepill.sys" wil be installed on ALL machines. Okay, I guess they don't want them to just check the drive's free space to see if extra files were added?
-ALL machines will have the driver loaded, but not necessarily be "infected". Is that a reasonable condition for a rootkit "in the wild"? If the rootkit is doing it's job you shouldn't be able to detect the driver being loaded in the first place.
In the real world, you won't have an uninfected control against which you might compare your machine to see if it's infected. A detector based on free disk space or free memory is useless, because in the real world you won't know what those values "should" be (nor have a basis for comparison). A detector based on a file name or process image name is also useless, because a real rootkit won't call itself by a name you know. I'd say her requirements are reasonable counter-balances to the presence of an identical "control" in the experiment.
-Detector.exe must be completely autonomous and return only a single flag value to indicate infection. This sounds like a completely unreasonable requirement, since even rudamentary human review of the results is a realistic real-world scenario.
-The detector can not cause system crash or halt the machine. I fail to see why this would be a requirement, unless you argue that whatever system that might be tested is mission critical and can't afford ANY unplanned downtime... unexpected crashes are bad, but shouldn't be an instant-lose condition.
-The detector can not consume significant amount of CPU time. Why not? If the user is scanning for a rootkit, they probably understand it's a fairly serious issue and should be willing to devote resources to it. Inconvenient? Sure, but again not a condition of failure
Again, these restrictions are about making this a "real-world" detection test. As in, I'm at home surfing the web, at any point I might visit a page that delivers malware, so I have software periodically scanning my system.
Your average home user won't (and probably isn't qualified to) do manual inspection of results. Not even once in a while, certainly not on a routine basis as would be required to protect a real system.
Similarly, taking up resources or crashing the machine once doesn't sound so bad, but doing it on every scan (or even on 1% of all scan attempts) is not reasonable.
Fundamentally, the point is in the real world you wouldn't know when your system might have been infected, so you'd have to be scanning regularly -- in essence, all the time.
So all of the technical requirements look reasonable and valid to me. Asking to be paid... especially asking to be paid an amount that overshadows the challenge prize... well, I can understand it, but I can't agree with it. Not to say that it's easy trying to get research funded, but asking those who think you're wrong to fund your effort to prove you're right is too much.
I was under the impression that a rootkit was only supposed to be undetectable from _within_ the system. i.e. Overwriting ls with your version that hides your secret malicious files. Pulling out hard drives and placing them inside of other systems would not be a reasonable method of rootkit detection.
A complicated error is indistinguishable from a feature.
Well, it's undetectable for software not knowing what to search for. It's of course detectable by the author of the root kit, and I'm sure a requirement will be to demonstrate that the computer really is infected, otherwise she could simply infect none, and then simply decide which ones are "infected" after the fact.
:-)
If there's no such requirement of proof, I'll happily offer a test of my completely undetectable root kit. And I'll not even demand the source of the detector program (I'll also not offer mine).
The Tao of math: The numbers you can count are not the real numbers.
I think everything is fairly obvious once you think about it hard enough ...
I don't disagree with her theory, but in practice it is difficult enough to achieve that it will probably never happen.
How do you figure that monopolizing the CPU for several seconds is unreasonable in the real-world? While you certainly wouldn't do that 'on-access' ie, all the time, you could certainly do this on a scheduled basis. After all, you may not be aware of the malware all the time, but being aware once in a while certainly has a high degree of value to an anti-malware solution.
It's either 100% undetectable or not. You can't start limiting the methods they are using for detection.