Slashdot Mirror
Windows Rootkits
GuidoJ writes "The Register is running an article by Kevin Poulsen of SecurityFocus Online about rootkits in Windows NT. While rootkits are a well-known issue in Unix and Linux systems, they have rarely been found on compromised Windows machines. According to the article, Windows NT backdoors have always been 'trivial', and they have caused enough havoc already. Imagine what a stealthy rootkit could do!"
I thought Windows WAS a rootkit.
..There's a-dooin's a-transpirin'
What I mean, is that what are you going to do from a windows remote terminal? I mean honestly, it's not that cool to have a windows terminal server session open (presuming that service is even set up), and even though you can telnet into windows, hacking in DOS just isn't 1337 enough. :P
Watch as I type edit and the screen goes blank!
Karma: Chameleon (mostly due to the fact that you come and go).
Published on The O'Reilly Network (http://www.oreillynet.com/)r ootkit.html
/proc (procfs). A kernel rootkit may subvert the kernel to hide specific processes from procfs so ps or even a known good copy from vendor media will report false information."
... not exactly. Even if you make the maximum effort possible to secure your system, given enough exposure, it is still very likely that someone will break into your system and install a rootkit or two.
http://www.oreillynet.com/pub/a/linux/2001/12/14/
See this if you're having trouble printing code examples
Understanding Rootkits
by Oktay Altunergil
12/14/2001
A rootkit is a collection of tools an intruder brings along to a victim computer after gaining initial access. A rootkit generally contains network sniffers, log-cleaning scripts, and trojaned replacements of core system utilities such as ps, netstat, ifconfig, and killall. Although the intruders still need to break into a victim system before they can install their rootkits, the ease-of-use and the amount of destruction they cause make rootkits a big threat for system administrators.
The main purpose of a rootkit is to allow intruders to come back to the compromised system later and access it without being detected. A rootkit makes this very easy by installing a backdoor remote-access daemon, such as a modified version of telnetd or sshd. These will often run on a different port than the one that these daemons listen on by default.
Most rootkits also come with modified system binaries that replace the existing ones on the target system. At a minimum, core binaries such as ps, w, who, netstat, ls, find, and other binaries that can be used in monitoring server activity, are replaced so intruders and the processes they run are invisible to an unsuspecting system administrator.
Because most rootkits will mimic the creation dates and file sizes of the original system binaries while replacing them with infected versions, keeping records of these file statistics is not sufficient. Thus, the best way to make an inventory of system file information that can be used to identify suspicious activities on the server is to calculate the cryptographic checksums of these files and store this information in a safe location, such as on a CD.
Third-party tools such as Tripwire or AIDE make this process much easier and more robust by automating the calculation of these file signatures.
Here's a quick explanation of Tripwire from the organization's web site:
"Tripwire is a tool that checks to see what has changed on your system. The program monitors key attributes of files that should not change, including binary signature, size, expected change of size, etc."
Obviously this process has to be repeated as you introduce more software and other files into your system. You can also use the RPM signatures on RPM-based systems such as Red Hat and SuSE to compare the current MD5 signatures of your files to those in the RPM installation database. Unfortunately, the RPM application itself and the local RPM database cannot be trusted to provide accurate information because intruders can potentially infect them too.
Some rootkits may also contain sniffer or keylogger applications that are used to gather passwords for other systems and listen to traffic for sensitive information. To do this, the rootkits set the PROMISCIOUS mode on the target machine's network interface card (NIC). In normal operation, a network interface card only listens to traffic that is specifically addressed to itself and traffic that is coming through the broadcast address that everyone listens to.
On a "non-promiscuous" network adapter, the packets that are addressed to other network interfaces are silently discarded without even looking at the actual data in them. However, when using directly connected computers or a network that uses basic, non-switching HUBs, your interface actually can listen to all traffic if it's in PROMISCIOUS mode.
If an intruder listens to this traffic on a relatively large network, the results may be catastrophic. To protect the whole network even when one of the machines is broken into, using direct cable connections and basic HUBs should be avoided. Switching-hubs and other more advanced networking equipment do not broadcast traffic to all the machines on the network, but only send it to the machine that is supposed to receive it, effectively protecting all the other machines on the network.
Because the first thing a system administrator does to monitor unusual activity is to check the system log files, it is very common for a rootkit to include a utility to modify the system logs. In some extreme cases, rootkits disable logging all together and discard all existing logs. Usually if the intruders intend to use the server for an extended period of time as a launch base for future intrusion activity, they will only remove those portions of logs that can reveal their presence. Because the absence of log files or stopped logging activity is a sign of suspicious activity itself, only attackers who have adopted the hit-and-run style will choose to blindly discard all logs.
One method administrators can use to maintain logs about an intrusion attempt -- successful or otherwise -- is to devise a system that detects network anomalies and alerts the system administrators by sending them notification email messages and/or log files. Obviously, the network intrusion detection and periodic log-file transfer methods cannot be trusted after the intruder gains access to the machine.
Related Reading
Building Internet Firewalls, 2nd Ed. Building Internet Firewalls, 2nd Ed.
By Elizabeth D. Zwicky, Simon Cooper & D. Brent Chapman
Table of Contents
Index
Sample Chapter
Full Description
Read Online -- Safari
Arguably the most severe threat to system security that can be caused by a rootkit comes from those that deploy LKM (Loadable Kernel Module) trojans. Loadable Kernel Modules are a mechanism for adding functionality to an operating-system kernel on the fly -- without requiring a kernel recompilation. Although the benefits of using LKMs are universally recognized, they are also subject to abuse by intruders who use the kernel module-loading mechanism for malicious purposes. Even if you reboot a system that is infected by an LKM Trojan, the LKM process will reload it during boot-up just like any other kernel module. Loadable Kernel Modules are used by many operating systems including Linux, Solaris, and FreeBSD.
According to SANS, "Kernel [LKM] rootkits do not replace system binaries, they subvert them through the kernel. For example, ps may get process information from
Although it is thought to be possible to cryptographically sign kernel modules, the best mode of prevention against this security threat is to compile all functionality statically into the kernel and disable the LKM functionality -- especially on a server system which is not likely to need additional kernel functionality at a later time.
Knark, Adore, and Rtkit are just a few of many LKM rootkits available today.
The only way to avoid rootkit installations on your system is to stop them before they enter your system. Remember that a rootkit is not designed to help an intruder gain access to a system. A rootkit is designed to make the intruders feel at home and allow them work silently on your system without being disturbed. To install a rootkit, an intruder still must gain unauthorized access to your server using traditional methods, such as exploiting known vulnerabilities or even practicing social engineering to get the password information from a well-meaning person who happens to have it.
To avoid future headaches, you should always install firewalls on your machines that are accessible via some type of a network, apply all published patches to your software, and disable any services that are not absolutely necessary. Coupling these practices with strong passwords and secure protocols, such as SSL and SSh where applicable, you can be sure that your system will never be compromised.
Well
In my next article, I'll discuss some of the tools that are at your disposal in your quest to detect the existence of a rootkit on your system. I will also talk about what you can do to clean up a rootkit after you discover it.
Oktay Altunergil works full time as a Unix Administrator and PHP Programmer.
Return to the Linux DevCenter.
oreillynet.com Copyright © 2003 O'Reilly & Associates, Inc.
Can't a decent firewall counter 90% of rootkits?
I thought this was called "Windows Update"...
Stop by my site where I write about ERP systems & more
...is approaching parity with Linux.
alias uptime="echo '5:33pm up 22342352324 days, 6:28, 2124315623 users, load average: 2432.40, 12312.31, 123123.19'"
Well, as most Windows users run their boxes as Administrator anyway, a rootkit can almost be any program that's run with malicious intent.
I too, in the rarity that it's on, run my Windows box as Administrator because, unlike *nix, there's no easy way to become Admin (root) when you need to. You have to logout and log back in, unless they've changed it in recent releases.
I suspect that too many of the Windoze h4x0rz are too lazy or incompetent to really put in a root-kit. It is possible (imagine if a backdoor installs a .vxd) and this could be devastating (of course driver signing might help).
LedgerSMB: Open source Accounting/ERP
The bit that really concerns me is that it's possible at all, to install a device driver without the user's consent that can directly mediate between the hardware layer and the kernel -
But then I guess that it's possible precisely because MS have made it simple to manage, and thus simple to mis-manage.
Of course, the best way to defeat this kind of trojan is simply to use a firewall and block the ports being used to remotly configure the hidden driver. So then, the worrying part is not the trojan itself, but the competancy of the average user...
sig:- (wit >= sarcasm)
quote:
"The stealth driver in my mind is the scary concept," says Mertens. "You can hide an elephant with it."
So the first thing they do is hide the \winnt folder?
.
Have you read the moderator guidelines? Well, have you, PUNK? (and I want a Karma: Gnarly option)
But seriously, I'm asked to "Imagine what a stealthy rootkit could do!"
Having lived thru Melissa and ILOVEYOU, I can't imagine it would get much worse than that. The way security is(n't) done in Windows pretty much obviates the need for a rootkit, almost by design you could say.
People keep talking about the "next" Melissa, but I don't think there will be one -- for basically the same reason there won't be another 4 planes hijacked and crashed into buildings. Microsoft has learned from past mistakes, and Outlook is far far more secure "out of the box" than it once was.
People have learned, too; for example if you buy a new Dell it comes with McAfee Security Center, which gives you antivirus and (hopefully) some basic firewall protection. It took a few good beatdowns, but Joe User is at least aware of the dangers out there. To a degree I think we can thank the spammers; people are less likely to open suspect attachments nowadays because they prolly think it's spam. I'll take the silver lining and be happy.
I'd be far more worried about a rootkit/attack on the Internet itself (e.g. core routers, DNS) than the Next Big Windows Vulnerability. With the increasing trend towards Internet Everything, were I in the mood to break things, I would be hacking DNS and Cisco -- break the mesh and the nodes are useless. Conversely, clueful people weren't affected by SQL Slammer since why would you let your SQL Server talk to the Internet on port 1433 anyway?
http://www.chkrootkit.org
Believe me, if I started murdering people, there would be none of you left.
Aha! I compromised a process running as root (for example). What shall I do now? I know, I'll insmod IHAX0REDUGOOD.so after dld'ng it from my xoom.com warez page. Oooh, now I can install zombieslaved and use IHAX0REDUGOOD to prevent anyone from seeing it.
So what about this is more difficult than windows? An API must exist for a driver to be loaded, therefore it can be exploited. The tool that interacts with a user installing a driver uses this API, the rootkit bypasses all possible interaction (and uses its priveledged position to hide its existance)
Fuck Beta. Fuck Dice
From trusted ports to trusted ports work for most firewalls. Another way is to control by e-mail. You could even make it look like DNS queries if you wanted. The trick is not getting caught on the way in. Once in, there's not a lot holding you back.
You think that I'm crazy, you should see this guy!
Jon Littman wrote an interesting book about Kevin Mitnick entitled The Fugitive Game. In it he partly addresses the situation of an FBI informant and not-so-l33t hax0r, Kevin Poulsen. 100 to 1 this is the same l33t hax0r. Way back in the day--1990--Poulsen was described as not very l33t:
Now I grant you that 13 years is a lot of time for someone to change and learn to abandon stupid sensational media tactics. But look at the substance of the linked slashdot article : "I wrote a rootkit for Windows, I'm cool, and I ran a script kiddie workshop so lots of people can do it! By the way, I screwed up the old code. But the new ones the evil hax0rs will make will be really bad. .. So hire me as a consultant!"...um, yeah, right.
We recently had heard in the office over one of the Yellow Machine that's made by Anthology Solutions.
It used to be that I would scan someone's system for malware by booting DOS6.22 (or later, Win98 since it could support some newer,bigger filesystem) and run F-Prot. This eventually became less and less practical. The scanner didn't even fit on a floppy anymore, so I was doing thing like clean booting and making a RAM disk, and then unzipping several floppies onto the RAM disk just so I could run a scanner. But eventually people started using NTFS which my DOS/Win98 boot floppies could read anymore.
I guess I didn't keep up, and I didn't know what the orthodox approach to safe scanning was anymore. Eventually we started telling customers to see someone else about their Windows problems; we just wanted to support our apps and that was it.
Eventually I found out what the so-called "experts" we were referring people to were doing: they would boot the unclean, suspected system, and install some Windows-based antivirus program (McAffee, Norton, whatever), and then run it to scan the (possibly) infected system, while it was running in a (possibly) infected state. Holy shit, how stupid can you be? No wonder stuff doesn't get detected.
People were getting huge bills for techs' time too. The amount of waste I saw was staggering, and these were small businesses, not big megacorps.
I guess the only way to reliably scan a Windows system is take the hard disk out and mount it as a secondary drive in a known clean system? Beats me. Just about every other OS can be booted from removable media, but I don't know a way to do that with Windows. Oh well, somebody else's problem.
Except there isn't a "somebody else." The customers call around to try to find someone to help them, and in a city of half a million people, no one can. They ask again a couple of weeks and a few thousand dollars later, more desperate. And I tell 'em the only thing I know will work for sure: Totally wipe the HD and reload your apps.
And given this, I wonder how many windows machines are already compromised?
I read this article a couple of days on bugtraq and they were speculating that with one known kit in existence, there are probably ten more they don't know about. They literally stumbled onto this one by accident.
Imagine these sleeping beauties (well beasts) all just waiting for the signal...
Who are you? The new #2 Who is #1? You are #617565. I am not a number, I am a free man! Muhahaha.
For what the article say, it is more a BSODkit than anything else.
That's not true - I do it all the time using "runas". I use it mostly to launch MMC with the permissions I need to access IIS on a test web server. I also occasionally use it to run Explorer with elevated permissions to save me effort accessing administrative shares. I think it's supposed to be one of the ways to install applications that require administrative permissions, although I'm not sure on that.
/?
/user:<UserName> program
/profile if the user's profile needs to be loaded
/env to use current environment instead of user's.
/netonly use if the credentials specified are for remote access only.
/user <UserName> should be in form USER@DOMAIN or DOMAIN\USER
/profile /user:mymachine\administrator cmd /profile /env /user:mydomain\admin "mmc %windir%\system32\dsa.msc" /env /user:user@domain.microsoft.com "notepad \"my file.txt\""
/netonly.
C:\>runas
RUNAS USAGE:
RUNAS [/profile] [/env] [/netonly]
program command line for EXE. See below for examples
Examples:
> runas
> runas
> runas
NOTE: Enter user's password only when prompted.
NOTE: USER@DOMAIN is not compatible with
I'm a black hat and have had my hand in the creation in them at a few times. You've got to realise that you have to target a default installation of windows given a certain platform. Here's some of my tips of how we go about infecting Windows computers as so they are 'easier' for us to use..
;-)
1: We use packers and unpackers to protect all of our payloads, along with standard de-ICEing as to make casual debuggers simply crash. Look at some of the cracking group trainers as to understand how we hide stuff.
2: Sometimes, we put utilites on the machine (like grep, ps, kill) that normally arent on Windows machines, however the Internix package makes a garbage DOS shell verrry usable
3: We hit many of the files, such as ntoskern, explorer, and others that are ran many times per session. What's better is if you can offload the code to a common library.
4: If you target a Windows 2k or XP platform, make sure to install the payload inside a system file and its backup. If you dont, windows will overwrite your trjaned package with the known good one. With the bad in the cab, you'll be guaranteed a hole. Sometimes, however, the packages cause problems with windows updates. If that kind of thing happens, it usually causes a bluescreen.
5: A smart cracker will program the trojaned executable to check a web page on the net (say geocities) and parse the html for commands to do. This way, you have no direct 'link' to the rooted system, and somebody else takes the rap. Using an anonymizing proxy is highly reccomended.
I've had no experience in writing a kernel-level NT driver, but what I hear from my pals, it's a bitch to do right. I mostly do packages/integration with known software. You'd be amazed how many kid back hats think Netbus, Sub7 or Backoriface is the way you do such things. You just do NOT WANT TO TOUCH THIS CODE, as damn near every anti-virus software will alert the user. That equals a re-Ghost (which that's a good reason to infect the main ghost image...),
I'll hang around a little while if there's any questions.
Ja ne..
yes and no. on win 9X systems (to include ME), yes. however, on NT based systems, not everyone is administrator. for home users, nearly everyone runs as admin, though. for network use, none of my users get much in the way of permissions, and I don't know a lot of windows sys-admins that give their users permissions much higher than bare minimum.
as a side note, don't I know you?
The World's Worst Webcomic!
Field Day!
And here we thought that unstable interfaces for device drivers were a bug, they are a feature! This would be really useful if a BSoD only indicated intrusion, sadly it only indicates that your computer is turned on and what module it ran last. Hint to all you LEET HAXORS, make your names dumb like M$ does, rather than "0wned", "R000TED" or any varient of common four letter words like jerk.
Who says the ierk was responsible for the crash? We know that Windows does that, but we don't know anything about the ierk? Applying the razon, it's best to accept that Windows is still BSoD.
Oh the list of laughs to be had here go on and on. Who actually thought that it was impossible to hide applications and files on a system that's designed for DRM? Ha! those are features. Who would really trust an O$ by a company who's EULA says the company has the right to inspect and delete files at will and without notice? If they can read and delete, you bet they can write. The system is backdoored by design, of course people are going to take advantage of it.
DMCA, Hollings, Palladium. What might have sounded like paranoia is now common sense.
Theres no reason to run Windows as an Administrator except in unique circumstances. I still dont understand why people run as an administrator.
/user:administrator cmd to get a dos prompt with Admin privs.. and then do whatever you want.
; en-us;294676
We're all familiar with sudo for linux. There's an equivalent for Windows. Theres a program called "runas" and its included with Windows 2000 and XP.
You can do runas
You can read the docs on runas by going to http://support.microsoft.com/default.aspx?scid=kb
Since Windows NT isn't a multiuser timesharing system, the power of 'root', in particular remotely, isn't that great. The remote login and remote administration tools for NT are patched on kludges.
You can install Hummingbird Inetd or Interix, or use the built in but anaemic Telnet server that comes with W2K, but since NT's focus is not to be a symmetrical multi-user timesharing system, the default system most people think of as 'NT' isn't that fun to hack into.
Now, I've supported many simultaneous users on an NT box running Interix, but that's the exception. I've wondered for awhile how well Apache would run in an Interix subsystem. But it's not interesting enough that I've tried it.
Why install a rootkit when there are so many other, much easier vulnerabilities to exploit? I mean, come on... What haxx0r has time to write a rootkit, when they have oodles of options at their fingertips? It's the difference between a script kiddie and a real h@xx0r..
If it were me, I would just find a buffer overflow, and have some fun..
Slashdot.. Land of nerds, trolls, and FlameBait..
With closed source code, how do you know that there isn't a root kit included? There are so many "undocumented features", "easter eggs", flight simulators, etc. included free of charge in Windows, what else is in there that we haven't found yet?
Queen B
HDGary secures my bank
The main issue is that although NT has quite good privilege separation and 2K even better (both better than a non-security enhanced Unix), 90% of the apps don't use this. That means once you're in, you have the machine.
See my journal, I write things there
You could always create an NTFS Boot Disk to scan a suspect system. If you want write access, you'll need a boot disk capable of writing data though. Haven't seen a free read/write solution yet...
A simple windows r00tkit can be found here. :)
Karma: pi (Mostly due to circular reasoning in posts).
Since Windows NT isn't a multiuser timesharing system, the power of 'root', in particular remotely, isn't that great. The remote login and remote administration tools for NT are patched on kludges.
You can install Hummingbird Inetd or Interix, or use the built in but anaemic Telnet server that comes with W2K, but since NT's focus is not to be a symmetrical multi-user timesharing system, the default system most people think of as 'NT' isn't that fun to hack into.
Now, I've supported many simultaneous users on an NT box running Interix, but that's the exception. I've wondered for awhile how well Apache would run in an Interix subsystem. But it's not interesting enough that I've tried it.
Look at PSTools on www.sysinternals.com.
They let you do all kinds of wonderful things on a system as long as you have a user account with which to access it, through RPC.
Amongst other things, you can remotely install and run executables. Very handy.
Coming soon - pyrogyra
Well I would have to disagree. Let's peel the onion back one layer - why on earth would anyone have to change the default filesystem permissions?
The reason is that windows has no concept, and never did, of paritioning user data from system data. In any unix, the filesystem is sensibly laid out such that removing write access to huge swathes of it do absolutely nothing to hinder it's usability. Not so in windows, everything's mixed together in one big steaming mess. Instead of simple read access, we have confusing messages from explorer telling users "OH MY GOD! You shouldn't look at the files in this directory, it can cause obesity, nausea, jet-like diarrhea and insanity - but click here if you really really want to see them ..." or some other such nonsense. W2K isn't much better, but at least it's less obnoxious.
Secondly - and this is mroe of a cultural issue which flows naturally from the above situation - this isn't even realistic. I used to do this, locking users out of c:\ and \system32\ etc., but I would find that we had all these boneheaded programs we had to run which needed to write to various parts of the filesystem for no apparent reason other than ignorance. This problem is so rife with windows developers that locking users out of peices of the filesystem is almost useless, because you wind up not being able to do it anyway.
Is that like pouring a bucket of water into the ocean? Or bringing a boxed lunch to an all-you-can-eat buffet?
"I'm absolutely, one hundred percent positive that there's probably ten more that we haven't seen publicly,"
Any sufficiently simple magic can be passed off as mere advanced technology.
You have to have a bleeding PhD in Windows technology to even figure out how to do basic stuff like locking down important files.
Right click on the file/directory, choose properties, go to the Security tab. It's as simple as that. Windows 2000 and above includes an inherit bit that will inherit the permissions of the parent, easing administration (on NT4 you can cascade the setting down, or use a tool like cacls), or if you're really serious you can turn off "Bypass Traverse Checking" and the user will require access up the entire folder chain to access a file (useful if you are REALLY hyper serious and want to ensure that a random file somewhere doesn't have User rights). In any case a default install of Windows 2000 or Windows XP is quite secure, with only read access on system files for non-Admins (despite the FUD on here), however there are a slew of security kits Microsoft distributes that let you choose your configuration (i.e. "Web server on the internet") and it goes through and sets ACLs and user rights system wide.