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'
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.
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
What I mean, is that what are you going to do from a windows remote terminal you don't necessarily have to set up a shell, you could install port scanners, eggdrop bots and ddos tools. even though its windows you dont want to get hacked for a lot of the same reasons you dont want any computer with internet access to become compromised.
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)
There are ways to get around that. Make the compromised machine initiate all the communications, and you can punch a hole through all but the most determined firewalls. That's why irc bots are so popular.
You think that I'm crazy, you should see this guy!
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.
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!
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.
A windows command prompt is only the beggining of the fun. Once there, you can install a hidden VNC server and get your remote desktop, as outlined in "Hacking Exposed" 2nd and 3rd editions in the section under Windows NT and Windows 2000. Also, if it is a Win2k box, you can enable the terminal service and run something like RT client or in linux Rdesktop to get a remote desktop. There are other things you can do with a command prompt to, such as install any other trojan along the lines of BO, or Sub7 for remote control havoc, not to mention things like run irc bots, zombies, or be really lame and set up crappy things like DDOS nodes. Or if you feel like cheating at SETI, you can set up a remote SETI client, or as some people saw, there was a virus/trojan that ran around and set up a Distributed.net client. Those are just basic examples of what you can do, and if there were a good Root kit for Windows, you could hide those processes. In truth, you could do all the same things you could do with a Windows root kit that can be done with a Unix one, only it just wouldnt be as cool for some reason.
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..
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.
But why would you do that? Delerious you are! That would be so hard to command.Compare that to a simple telnet session.
Depends on how it's configured and is a excellent example of why doing NAT on your router does not equal firewalling.
I have seen may firewalls allowing everything outgoing, even for servers that had no reason to connect to the internet had access to the outside. Sure it might be easier to run that "Windows Update" but still.
my sig
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
Change the port number in this registry key:o l\Terminal
Server\winstations\RDP-TCP
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contr
In the client, just append a ":" to the hostname/ip.
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
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...
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.
"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.