definition of rootkit

Windows malware can write to anywhere on disk. And if it can do that, it can own the system - it can become a rootkit.

Xnews/CLIXchange 014,002 - 'Rootkits Roam the World'

[0] Rootkits Roam the World
[1] Ring 0
[2] Protection on Mac OS X
[3] Across the Tracks
[4] The Sony DRM Rootkit
[5] Privilege Escalation
[6] Smile!
[7] Who's the Rootkit?
[8] Attacking the Enemy
[9] But There's More
[A] Epilogue

[0] Rootkits Roam the World

No one can have missed the commotion caused by Microsoft Windows of late. It began with the announcement by Google that they'd been hacked by China. Then the revelation that way too many Google computers were running Windows and way too many of them were running the intergalactically shunned IE6 web browser, bane of web designers and security consultants everywhere.
Then Microsoft went into Damage Control Mode. Their reps around the world tried to contain the media and spin the disaster away from Redmond, all the while HQ worked on a patch to temporarily tighten the leaky ship up.
And so now Microsoft sent out a patch - and that's where the fun started. For a great many of these systems, once patched, became unusable, showing only that all too familiar Windows screen known as the BSOD - the Blue Screen of Death .
The Windows Blue Screen of Death is a text mode screen that's the result of some low level driver screwing up. This screen became more prevalent on the NT side of things once Cutler's NT tribe in 1996 moved the Win32 subsystem out of user land where it belongs and into the kernel space where even Cutler knew it didn't belong.
Cutler made this move - despite his belief in microkernel systems - because the 'nonsense' that was the Windows 9x GUI threatened to slow his system down too much. Flawed driver code started crashing as a result. The BSOD came back in vogue.
Here's what's important to understand: if a Windows system bottoms out in a BSOD, then there's something very wrong at kernel level.

[1] Ring 0

Windows programmers like to talk about processor ring levels. Intel processors have different so-called rings. The Intel processors run code at different levels and keep track of where they are at all times. Apple computers of today use Intel processors too, so the concept is applicable on Mac OS X as well.
Another more generic way to describe this is to just say the processor runs code in either user mode or privileged mode.
The essence of a multiuser multitasking system is that users have no access to the computer hardware. Users - and their applications - cannot access the computer screen directly, access the keyboard directly, access peripherals directly, or any of that. Their requests go through their application code to the system APIs which in turn send them to the kernel, which in turn talks to the drivers.
No one in user land can write directly to the computer screen - imagine what it'd be like if they could. How come your text editor always stops at the right margin and doesn't run off into the next program window on screen? Their requests are sent through all those layers and even wayward code is nipped in the bud and all operations 'clipped' to be contained in the allotted content area.
The same applies to the operating system per se. The operating system must protect itself. Nothing from user land can be allowed to alter the operating system.
Think for a minute back to the late 1960s / early 1970s at Bell Labs in Murray Hill, New Jersey. Ken Thompson and Dennis Ritchie were working on what would become Unix. They'd both had considerable experience working on mainframe systems. And their colleagues on Mountain Avenue were programmers too.
Programmers do a lot of testing. Program code rarely works right the first time around. And Unix was going to run on a single computer that all those programmers were going to share from their own individual terminals.
What'd happen if any one programmer could write a routine that would mess with the operating system? What'd happen to that programmer when twenty four other extremely furious programmers came around looking for blood?
The operating system obviously has to protect itself. Unix does this through a symbiosis between the kernel and the file system. And with privilege levels and (imaginary) users. Everything in the system pertaining to the hardware and the system itself is owned by the root account or a close friend of root. Ordinary users and their applications can't touch this stuff.

[2] Protection on Mac OS X

Mac OS X is a variation on a vanilla Unix theme. All the important system files are locked away and out of bounds to ordinary users. Take a look yourself.

* /bin. The original repository for Unix programs or binaries. Note the protection on these files and on their directory.

drwxr-xr-x 39 root wheel 1326 Nov 10 11:20
drwxrwxr-t 31 root admin 1122 Feb 13 14:09
-r-xr-xr-x 2 root wheel 63184 May 18 2009 [
-rwxr-xr-x 1 root wheel 1346576 May 4 2009 bash
-r-xr-xr-x 1 root wheel 44272 May 18 2009 cat
-r-xr-xr-x 1 root wheel 62656 Jul 14 2009 chmod
-r-xr-xr-x 1 root wheel 57632 Jul 14 2009 cp
-rwxr-xr-x 2 root wheel 767200 May 18 2009 csh
-r-xr-xr-x 1 root wheel 80848 May 18 2009 date

The directory /bin itself is owned by root and the group wheel (0:0). The parent directory / (the root directory) is owned by root and the group admin (which administrators can belong to). But that directory also has the sticky bit which means only the owners can remove things at that level.
So users can put things in the root directory if they want but they can't remove things that don't belong to them.
Now note the file permissions on the files in /bin. Only the root account can write to them (if that). They can be read and run by group members (or by anyone for that matter) but no one can mess with them - no one but the root account can alter their contents.
And you can't remove a file in /bin you don't like and replace it with another you like better. Note the permissions on the directory /bin.

drwxr-xr-x 39 root wheel 1326 Nov 10 11:20 .

The root account can write to the directory but no one else can. Only the root account can add or remove files from the directory. And only the root account can modify the actual files in the directory.

/bin is secure.

* /sbin, /usr/bin, /usr/sbin. There are more Unix programs here and they're protected the same way as /bin.

All of /usr is actually a sensitive area, with critical header files for application development, shared libraries used by applications at runtime, further repositories for program code, and so forth. It's all protected the same way - only the root account can directly modify files or the contents of the directories.

It's all secure.

* /System/Library. This is where Apple's system code resides. But it's still the same story here. /System can't be messed with because it's owned by root and because the same parent directory rules apply - only owners can remove things.

And /System/Library is owned by root and is protected by /System so that entire directory is secure too.

[3] Across the Tracks

So take the time now to pay a visit to the other side of town. See how the poor unfortunate live. The recent issues with Windows BSODs have to do with a rootkit that seems to have spread to a lot of computers. What's a rootkit?
A rootkit is malware that sneaks onto a system and hides away and is capable of doing anything to the system. A rootkit by definition has to be able to 'get root'. Getting root involves getting access to the root account so one can do anything. Getting root on a secure system can be difficult - the method used is going to have to be adapted to the specific target. Unless there's a gaping hole in the system architecture itself, no one method will work on all systems.
Real good rootkits excel at 'hiding': they can subvert all attempts to detect their presence. They pervert low level code so administrators only see what the rootkit wants them to see. And so forth.
Mac OS X has had its share of ways to 'get root' if you accept single digit numbers as a 'share'. The Opener hole was a paved superhighway to root (with no toll booths either). The exploits - such as Opener itself - weren't 'rootkits' in the strict sense of the word: they didn't attempt to disguise their presence. But still and all.
But those were the result of design flaws introduced by Apple and not a part of (or party to) any endemic system weakness. And they're (finally, hopefully) fixed today - and not by rewriting the operating system from the ground up but by removing those 'user friendly features'.
Hackers can still poke into 'secure' systems if they find system configuration errors. But again: those attacks are often used to target individual systems. They don't become part of a worldwide outbreak.
Yet something happened in the world of Windows - there was a worldwide outbreak. How can a rootkit which would seem to need to be targeted to a specific system propagate and spread to computers everywhere?
To understand that, it's necessary to understand how Microsoft Windows security does not work.

[4] The Sony DRM Rootkit

The most powerful file attribute in MS-DOS is the 'read-only' attribute. With this attribute set, applications can't write to files. But because MS-DOS is a single user system, anyone - any process - can remove this attribute on a whim.
Nobody owns anything on an MS-DOS system. There's no concept of ownership. Anyone can do anything they like to MS-DOS.
IBM used PCs as 3270 gateways to their mainframes. IBM didn't need security on the PC - the security was on the mainframe. The mainframe took care of authentication and permissions and protecting itself. The PC couldn't get at the mainframe itself.
DEC's VMS was built the same way. And the author of VMS built Windows NTx (NT/2K/XP/Vista/7) the same way. Those 16-bit Windows PCs weren't to have anything important on them - all the important stuff would be on the server beyond their control.
Even Microsoft's (Dave Cutler's) file system NTFS has no concept of ownership - to get that, admins have to implement access control lists which aren't particularly functional anyway. And there's still a larger and much more important problem.

[5] Privilege Escalation

No secure system can remain secure for long, no matter the level of sophistication in the fundamental architecture, if users romp around with the root account. This was (still is actually) the problem with the iPhone. It's been the problem with single user systems all along. To maintain effective security, a system's users must use the root account sparingly and with extreme caution.
Unix systems have several ways to achieve this, such as su ('substitute user') and the even more effective sudo ('substitute user and do'). Users need not log in to Unix systems with the root account but can temporarily escalate to root status provided they are able to supply the proper credentials.
This reduces the risk of being the victim of a 'piggyback attack' - malware rides on the login account to do its dirty work.
Windows doesn't have a good way to do this. Windows doesn't have a secure way to do this. Windows doesn't have a viable counterpart at all.
Windows admins (members of the user group 'Administrators') can assume ownership of resources (Registry keys, files, directories) owned by the system, but there's no easy way to give ownership back. Windows theoretically has the equivalent of the root account ('SYSTEM') but it's not used the same way at all.
The Windows 'system' wasn't designed to be used the same way - the way it's being used today, the way any connected computer has to be used today. This is what Bill Joy meant when he shook his head at Microsoft.
A Windows installation, whether already there thanks to the OEM or performed by the user with an external medium, will set various access control entries to provide a modicum of protection, but this doesn't yield any flexibility for the user and it's not particularly effective either.
Windows malware can write to anywhere on disk. And if it can do that, it can own the system - it can become a rootkit.
The reason so many Windows users were hit with a BSOD after applying the Microsoft patch was they were already infected by a rootkit. And they didn't know it.
The rootkit could have come through a 'drive by attack' (by merely visiting a website) or by previewing a message in Microsoft Outlook. Nothing more is needed on Windows. Microsoft's 'LUA' is of little help - it attempts to isolate applications rather than protect the system. And malware bots get around LUA anyway.
And the hackers will always get around these panicky ad hoc fixes - the system itself can't be secured.

[6] Smile!

Watching those Windows fools panic everytime there's a catastrophe can be infuriating or frustrating or enervating. But sitting on a secure system where none of this ever applies has to elicit a smile. Slashdot had a huge thread on the topic the other day. Some of the quotes there are precious. Precious few contain any helpful insights. But they're all extraordinarily amusing.
Windows fanbois remind me of battered women, explaining to others how they walked into a door or fell down some stairs. No you didn't, you let somebody beat the shit out of you and then covered it up. - spun

On a SANE OS, rootkits can't be installed by regular users who are viewing a banner ad, or plugging in a storage device like a memory stick or USB picture frame. - Sleepy
FOAD

Several weeks ago, I worked on a PC that was probably infected after doing a few Google Image Searches or browsing DeviantArt or something of that nature. I tried multiple virus/malware programs (AVG, Avast, Adaware, MalwareBytes, Spybot). I thought I got rid of the infection...then a Windows Update caused her computer to blue screen on boot. - Anonymous Coward

My solution? http://www.ubuntu.com/getubuntu/download - DeadcatX2

Please don't joke about this. I have been affected, and at the worst possible time, too. I have to submit my PhD dissertation tomorrow, and I don't know what the fuck I'm supposed to do now. I can't boot up, and I have one of those HP computers that has everything built into the screen, so I can't even take the hard drive out.

I CAN'T GET MY FUCKING PHD DISSERTATION. I AM SO FUCKED. - Anonymous Coward

Fixed it is. Didn't have to delete the old Windows partitions. The data is still there. And it does everything it did before - stream videos through the S-Video output to the TV, view the TV tuner card, browse the Internet, play Flash games, read email/facebook, etc.
Sure, if it breaks she probably won't be able to fix it. But it hasn't broke yet, and after all I did have to come fix Windows, too. The computer can install security updates and it doesn't need to reboot. No more virus scanner. No more malware, trojans, or rootkits. - DeadcatX2

I have just repaired TWO computers with this rootkit infection. Both are XP Pro machines made by DELL - madhatter256

At what point will it be decided that common rooting of a box that people are using for banking, health, etc in their house is Not Okay? - lotho brandybuck

is that Microsoft's best solution was to boot into the recovery console and uninstall the patches. This put the rootkit back in business. Where is 'trustworthy computing'? - Anonymous Coward

12 years of software development and tech support with windows, what have you got under your belt??? I know the vb.net community I am in, regards what I have to say with a little more respect, but then again, they might just all be tools too. - hesaigo999ca

We have seen this occur on a few machines at the FAA so I wrote a vbscript to loop through an .xls of machines and record the MD5 Checksum. Thought it may come in handy for yourself and some of your readers.. - n0tWorthy

Rootkit? I don't see it. Maybe it's because this damn blue screen is blocking my view. - thatskinnyguy

BSOD: Bull Shit On Demand - Anonymous Coward

I run a small computer repair shop, and we first started seeing this ATAPI.SYS virus a few weeks ago. When I would submit it to VirusTotal, it would always come back as clean on every single virus scanning engine - but I could tell it was infected. I even had a computer in here just yesterday which had the infected ATAPI.SYS file, yet it was not detected as such - even when the hard drive was mounted as a secondary drive in another system and scanned with several up-to-date antivirus programs.
The virus itself is actually quite a clever little beast. After infecting the file, it sets the file modification time back to the original date & time, which makes it hard to tell that it's been modified. Also, I've noticed that the byte counts between infected and non-infected versions of the file are almost always identical. But to do that, it appears to be injecting its code into the area normally used to store the file version information. The upshot is, if you check the file properties and there's no file version information (the Version tab under XP or the Details tab under Vista/Win7), there's a good chance the file is infected.

I have not had any computers come in to the shop with the BSOD mentioned in the articles yet, but I'm expecting them at any time... - nlewis

The TDSS rootkit (not sure how many variants do this...) installs itself as a Non-Plug-and-Play device driver. You can often remove the head of the rootkit by going to System Properties => Device Manager => View menu => Show hidden devices Then, click the + sign next to Non-Plug-and-Play devices. If there is a 'TDSS*' device, you can delete it. I was able to recover a machine by doing this, then scanning for viruses. Obviously it's best to scan the hard disk externally or wipe the whole machine, but that might help someone in a pinch. - Kremit

A total fresh install is the best option - unless you happen to have an identical clean machine nearby..... - karnal

If you arent a programmer or some shit, dont offer your opinion, because right now its terribly stupid. - Rockoon

It seems you don't really grasp the concept of a rootkit. - Anonymous Coward

They were using Windows after all. Case closed. - Anonymous Coward

[7] Who's the Rootkit?

And then there's the even bigger issue: what can Microsoft do to a Windows user without said user's express permission? Aren't stealth installs the same or worse than supposedly malicious rootkits? Isn't Windows in such case the biggest virus of all time? Complaints about how Microsoft effectively exercise remote control over user systems aren't new.
The main reason Microsoft have taken this stance - and ignored the protests of security and privacy advocates - is their spin doctors demand it. Windows is such a sorry mess that a single malplaced byte can cause a worldwide epidemic. And then the media will go nuts and Microsoft will get a lot of bad publicity. And they can't have that. So they run programmes like WGA and WAT instead - they force updates on their users (and simultaneously perform amateurish consistency checks to make sure you haven't stolen your precious Windows system).

Microsoft updates Windows without users' consent
Top story 13 September 2007 by Scott Dunn
Many companies require testing of patches before they are widely installed, and businesses in this situation are objecting to the stealth patching. It's surprising that these files can be changed without the user's knowledge.

Protect yourself from silent Windows updates
Top story 20 September 2007 by Scott Dunn
Microsoft have confirmed Windows Secrets' Sept. 13 story that Windows Update periodically installs certain files even if you've selected a 'do not install' option.

Bug in automatic updates forces install, reboot for Windows users
15 October 2007 by Jeremy Reimer
Automatic Updates have been rebooting people's Windows boxes for a while now, but only if the user has set the updates to automatically install. However, an apparent bug in a new update for Windows Vista has left many users confused when they awoke to a login screen recently, despite setting updates to install manually.

Microsoft apologise for Windows Update snafus
28 October 2007 by Jeremy Reimer
The explanation of the WSUS issue is a tad confusing, but it revolves around a WDS update from February that was an optional update that only applied to people who already had WDS installed. So far, so good. Then last Tuesday, Microsoft revised that same update package to be applicable (but still optional) for all XP SP2 and Windows Server 2003 SP1+ systems. Unfortunately, WSUS users who did not have WDS installed found that they got this 'optional' update automatically, because WSUS is set by default to automatically approve update revisions. Confused yet? I sure am.

Microsoft Investigating Forced Silent Windows Updates
29 June 2009 by Marius Oiaga
'There have been some recent questions about how users are notified about updates and comments that sometimes customers aren't being notified that updates are available when they shut down their computer. We are investigating the reports and trying to clarify with the community exactly what people are experiencing.'

More Computers Hacked in China than any other Country!

[8] Attacking the Enemy

And then the crowning achievement: attacking Firefox installations.

Silent Install Firefox Plugin Backfires on Microsoft
17 October 2009 by Kroc Camen

Whilst it's not okay in Microsoft's eyes for Google to install a plugin into Internet Explorer, increasing the potential surface area of attack, when Microsoft do it to Firefox, it's a different matter. Now a security hole has been found in a plugin that Microsoft have been silently installing into Firefox. The exploit is a drive-by, meaning that the victim needs only to be lured onto a web page for the attack to be effective.

[9] But There's More

But there's more, as any Mac OS X or Unix user knows. Their systems are protected, meaning even the OS vendors can't install updates onto their system areas without their express permission.
Mac OS X users are familiar with the 'authorisation panel' that precedes such updates. Users have to authenticate by providing their pass phrase so the update process can run as root. Without that authentication, the update can't access the 'system areas' and can't even schedule the update to continue on reboot - those areas are closed off.
All Unix systems 'boot' in single user mode, which is equivalent to the root account but even more powerful. Yet configuring the boot process is only possible if the account doing the configuring is root itself.

The overreaching issue with Microsoft Windows updates isn't the fact Microsoft decide to force updates on people without their knowledge or permission; that's bad enough. The overreaching issue is these updates take place without privilege escalation.

Mack Diesel reports.
'In past jobs I left my workstation on 24/7 and would always find it at the login screen after a set of updates along with the stupid balloon about how Windows happily restarted itself for me once I was logged in. My user account was centrally managed with limited privileges of course. And since the company had no IT person pushing out updates, MS was doing all of the work.'
'So yes EVEN IF you're only logged in as a LUA, Windows will still perform the updates and reboot itself. If you decide to shut down, Windows will apply the updates without any privilege escalation, even as a limited user (and you'll get the 'do not turn off or unplug your computer' warnings).'

Be it a Microsoft update or a rootkit outbreak, the overreaching issue is the same: Windows can't be secured.

Be glad you're where you are. The Windows calamities will continue until Windows vanishes from the Internets forever (and someday it will, make no mistake about it). But until then? Nothing to do but smile.

[A] Epilogue

Roel Schouwenberg of Kaspersky Labs reported today that most likely *all* versions of Windows are vulnerable to the rootkit attack that caused the BSODs.

'(almost) all Windows versions vulnerable to TDSS +/- MS0-015 BSOD. Confirmed on XP, 2k3 and 7. No time to test others but they are safe bet.'
Kaspersky may have an advisory soon.

Malware can be hidden in English language text, say US scientists
Breakthrough paper shows hackers could evade anti-virus protection by hiding malicious code in sentences that read like English language spam