Jan 08 2008
First off, someone's created a trojan horse program that affects unlocked Apple iPhones. By definition, you can't install anything on an iPhone unless you crack it, so the impact of this is potentially smaller than it could be. At any rate, it pretends to be a patch for v1.1.3 of the iPhone firmware. It doesn't do anything until you try to uninstall it (because it doesn't look like it does anything), at which time it will take any copies of OpenSSH and Erica's Utilities with it when it goes. While the original website that offered this utility is now gone, you just know that a couple of someones out there got hold of copies and are hard at work making it do different (and probably nastier) things.
On the other end of the spectrum, researchers from eEye Security have developed a new rootkit for machines running Windows. Rather than hiding and injecting new drivers or replacing binaries with modified versions, their rootkit works by replacing the master boot record of the OS disk so that the rootkit's code runs even before the Windows kernel starts up, sliding beneath the OS like a bedsheet underneath a brick. So far as the kernel is concerned everything's hunky-dory, but it's been compromised in ways that are undetectable from inside the Windows environment itself. The rootkit's binaries can be hidden in sectors of the disk outside of the file system that aren't in use (no file system uses all available blocks of a partition - there are always some left empty) and nothing inside of the Windows install itself is changed, so standard disk watchers like Tripwire won't pick up on them.
Rootkits, if you're not conversant in matters malware-related, are pieces of software that subvert certain functions of the operating system they're installed into. Someone that has acquired compromised a machine and broken administrative access can keep it for longer periods of time because basic functions of the OS cannot detect their modifications - files hidden in certain places or have certain names don't show up in directory listings. Software written to search disks for unauthorized files can't find them, either, because they all rely upon those hooked functions in the OS. Network connections from certain addresses or to certain ports are also cloaked because the OS routines that could display them are wrapped or replaced with code that specifically ignores them. The closest metaphor I have for a rootkit is blinding a security camera by taping a picture of the room it's watching over the lens to hide the people walking around inside of it.
Technical discussion after the cut. The rootkit's installation utility drops the code at the very end of the disk, using the last 244k that it can get hold of. It then alters the master boot record (sector 0), the kernel portion of the Windows boot loader at sector 61, and puts a backup copy of the MBR at sector 62 (at the very end of the set of reserved sectors at the beginning of every disk, or at least those that run operating systems from Microsoft). Sector 0 gets a custom MBR from the rootkit that is used at boot-time. The rootkit's loader grabs INT 0x13 (the BIOS service that reads or writes sectors on the physical disk) so that it can silently patch the data pulled from the disk by NTLDR. In this way it patches the Windows function nt!IoInitSystem and the final page of the kernel itself to load another of the rootkit's drivers from the disk sectors on the far side of the OS drive, as well as to hook the Windows kernel system calls that read and write data from disk in such a way that the altered MBR can't be noticed by antivirus or file system monitoring software. Finally, a malicious OS-level device driver is loaded into memory which contains code to conceal the altered disk sectors as well as set up hidden network communications from the outside. As the rootkit stands now it could be detected by physically comparing sectors 0 and 62 on the disk (very possible if you know what you're doing).
Removing it is easy: Replace the Master Boot Record with the fixmbr command. The rootkit's code will still be hidden at the far end of the drive but there won't be any way for it to execute.