Windows Rootkit Wars Escalate
An anonymous reader writes "The rootkit wars have started to escalate with a rootkit named Rustock which is able to remain hidden from all the popular anti-rootkit tools. It uses some new techniques including not only putting itself in a ADS (NTFS alternate data stream) which isn't seen by normal file system enumeration tools, but even blocks ADS aware tools from seeing the stream. Works in Vista, too! Analysis in both Symantec and F-Secure blogs."
If that's not functionality that should require Windows binaries to be signed, I don't know what is.
tasks(723) drafts(105) languages(484) examples(29106)
Long ago, in the days of MS-DOS, there was a program that was excellent at detecting unknown MS-DOS viruses. Called Integrity Master, for maximum security one ran it from a bootable floppy, scanned files on the hard disk, and stored the file with the scanned signatures on a floppy. It wasn't SHA or MD5 hashes, but at the time it was solid security.
Then, one periodically (once or twice a week, as paranoia sees fit) ran the utility on their machine. If stuff in the MS-DOS directory was changed, it was immediately apparant. Integrity Master also was able to scan for some known viruses as well in addition to keeping a log of changed files.
We need a utility like that for Windows XP and Vista. A bootable CD or DVD that not just can understand NTFS (and NTFS's file compression), but has the necessary software to mount hard disks which are encrypted with BitLocker, PGP, SafeBoot, PointSec, WinMagic, DriveCrypt Plus Pack. The utility should also allow for username/password entry so EFS-protected files can be checked too.
This utility should use a CD or DVD to boot from, mount hard drive volumes, run checks for alternate data streams, system and nonsystem files, and finally the registry, perhaps including the encrypted parts like the SAM. It should not just save hashes of files, but perhaps have some ability to check file signatures as well (like sfc.exe and sigverif.exe do), so an update to Windows via a legitimate way doesn't set off a lot of false positives. Of course, the "manifest" file storing the file hashes on the file system would be stored on a removable USB drive, so the OS on the hard drive never has the ability to touch it.
Because this checking is done offline, a rootkit would be a lot harder to hide (unless it uses a method that the integrity scanner wasn't programmed to detect, like perhaps pointing to unallocated disk space for executable code, or hiding in an EFS-protected file.)
Of course, offline checking isn't perfect, because the machine being scanned has to be totally downed for a good amount of time which can't be done in a 24/7 environment.
There are some hurdles though. Trying to reduce the amount of false positives is one, for example. A novice user presented with a notice that a lot of files were changed likely wouldn't know what was a bad change, and what was normal for system functioning. After that, its decoding files and registry keys. Finally, if a known rootkit database was used, keeping track of how rootkits encrypt their payload, and delivering timely program updates.
Before any of the hundreds of security holes in Windows XP were published, they were still there! If you have paid any attention to security, you would be very confident that there are many remote root, arbitrary code, no-interaction-required holes in Windows RIGHT NOW.
They are no doubt being used. I can think of many ways to build a bot that connects home indetectably to all but the most paranoid and brilliant sysadmin.
A slashdotter who didn't build his own computer is like a Jedi who didn't build his own lightsaber.
There is no 100% solution except to cease using the technology. That's a given. But that would be like saying we should stop using cars because accidents happen.
What you advocated, however, was users not running software or opening data they don't trust. For most users, that cuts the functionality of their machine in half. Trust is a sliding scale. And given the relatively mild punishment for trusting too much, most users will chose functionality over security. The job of the OS should be to make sure they never have to make that choice.
There is no technical solution to everything, though. You cannot "fool proof" everything. Would you go around fool-proofing cars or guns? I'd rather expect someone using either to have proper training and knows how to use it, so he is neither harm to himself nor others.
Well, if I can get a gun or car to do exactly what I want without any risk or decrease in functionality, I'm all for it. As for training, the point is that the usability and functionality of the system has to be up to snuff before it can be effective. To bring cars to the equivalent level of functionality as a Windows machine you'd have to have no windshield and the user would have to just be guessing where they are going. Right now users are given basically no information about what is happening. Is that a program or data? What is it doing when I'm running it? Is it sending spam, or running a game? Is it reading my tax returns? No idea.
The analogy of guns is an interesting one. Anyone who has had a traditional education concerning guns has heard that they should always treat the gun as if it is loaded and point it away from anything they don't want to shoot. Why? Why not only point it in a safe direction when it is loaded? There is no danger if the action is open and it is obviously empty. The answer is "conditioning." Nobody can concentrate on one thing all the time. By always treating the gun as loaded users condition themselves through repetition. That way, when they're thinking about something else (like is that a bear in those trees) they unconsciously point their gun in a safe direction and don't accidentally shoot their hunting buddy when they stumble.
The reason this is such an appropriate comparison is because Windows uses conditioning as well. Every time it brings up the same cryptic dialogue box with (OK/Cancel) it conditions users to click "OK" to get their computer to work again. It also conditions them to click "OK" when being warned of a potential threat. It is one of the worst UI choices, ever and a classic example of what not to do. In many cases even reading the dialogue you don't know what each of the buttons will do since "OK" and "Cancel" are not appropriate responses and are not actions. It is the result of programmers ignoring the human component of computer/human interactions when it comes to security.
First and foremost, you are responsible for what comes out of your computer.
I'll accept that I am responsible, but that does not mean no one else is as well. Picture this, the computer sales guy talks a grandmother into buying a computer. She knows nothing about them, but he tells her it is as easy to use as a TV and will let her send e-mail to her grandkids. They install it and hook it up for her. She never patches it and it is not set to do so automatically. It is compromised. It sends spam. Is it her fault she was lied to? Is it her fault she assumed it would behave reasonably instead of doing things all on its own? Yes, but even more than that it is the fault of the salesman and the system designers.
If someone is unfit to use a car, we don't let him use it.
If more than 70% of people are unfit to use most cars on the road, but do just fine with an Audi, maybe we need to rethink our car designs rather than sending everyone back to driver's education.
Likewise, if someone is unfit to use a computer because he cannot follow the most basic rules of common sense, he should not be on t