Follow Slashdot blog updates by subscribing to our blog RSS feed

 



Forgot your password?
typodupeerror
×
Security

Windows Rootkits 344

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!"
This discussion has been archived. No new comments can be posted.

Windows Rootkits

Comments Filter:
  • Rootkits in brief (Score:5, Informative)

    by Anonymous Coward on Friday March 07, 2003 @05:20PM (#5462455)
    Published on The O'Reilly Network (http://www.oreillynet.com/)
    http://www.oreillynet.com/pub/a/linux/2001/12/14/r ootkit.html
    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 /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."

    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 ... 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.

    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.
  • by BagOBones ( 574735 ) on Friday March 07, 2003 @05:27PM (#5462559)
    Its called Run As.. It should be in every NT version of windows and its in the Right Click menu.. (I think you have to hold Shift or Ctrl some times) Lets you try and run an app as any user you know the login too.
  • by glenebob ( 414078 ) on Friday March 07, 2003 @05:28PM (#5462569)
    There's no need to run as Administrator. Pretty much any user account can mess up a Windows system pretty bad, even the Guest account.

    But what you say is also true. I too run an account that's a member of Administrators because it's too much trouble to become all-powerful when needed.

    It's kinda funny now that I'm thinking of it. You have to be an admin to install a printer, but any old account can delete the printer driver files. Nice.
  • by mrkitty ( 584915 ) on Friday March 07, 2003 @05:30PM (#5462606) Homepage

    http://www.chkrootkit.org [chkrootkit.org]
  • by Malc ( 1751 ) on Friday March 07, 2003 @05:41PM (#5462759)
    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.

    C:\>runas /?
    RUNAS USAGE:

    RUNAS [/profile] [/env] [/netonly] /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
    program command line for EXE. See below for examples

    Examples:
    > runas /profile /user:mymachine\administrator cmd
    > runas /profile /env /user:mydomain\admin "mmc %windir%\system32\dsa.msc"
    > runas /env /user:user@domain.microsoft.com "notepad \"my file.txt\""

    NOTE: Enter user's password only when prompted.
    NOTE: USER@DOMAIN is not compatible with /netonly.
  • by djkitsch ( 576853 ) on Friday March 07, 2003 @05:44PM (#5462785)
    My point was not that it's easier to do on Windows than on Linux (it's not), but that the average Linux user is a lot more likely to already have 'locked down' their system than the average Windows user, not to mention is more likely to hve the skills to remove it.

    Also, since Linux is a file based config OS, it's gonna be a damn sight easier to remove a rootkit than it would be with Win32. Having had experience (trying to) remove undesirable VXDs and so forth from Windows systems, if the driver in question is resident Windows itself tries very hard not to let you remove it, and there's no easy way to edit the registry without booting fully into the OS.
  • by muletool ( 234921 ) on Friday March 07, 2003 @05:45PM (#5462801)
    Heres some info for Win2k

    http://lists.isb.sdnpk.org/pipermail/comp-list/2 00 1-December/000558.html
  • by Anonymous Coward on Friday March 07, 2003 @05:46PM (#5462814)
    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..
  • by Anonymous Coward on Friday March 07, 2003 @05:50PM (#5462851)
    I've even read about stealthy ddos type applications that take their targeting and control info from remote hosts via specially encoded ICMP packets. Unless you expect them, the firewall may just think someone is doing a ping or traceroute.
  • by jd142 ( 129673 ) on Friday March 07, 2003 @05:51PM (#5462868) Homepage
    Boot from a Linux floppy/cdrom or Windows cd. Boot to console, mount your drives as ro and scan them. Then if you find something, boot into safe mode and remove the offending files.

    Pretty simple.
  • by alanjstr ( 131045 ) on Friday March 07, 2003 @05:54PM (#5462907) Homepage
    Safe Mode is used to avoid the rootkit.
  • by BroccoliGod ( 462180 ) on Friday March 07, 2003 @05:58PM (#5462950)
    Its called Run As.. It should be in every NT version of windows and its in the Right Click menu.. (I think you have to hold Shift or Ctrl some times) Lets you try and run an app as any user you know the login too.

    Just to clear up a few things: "Run as" is not in Windows NT 4.0 (or below I would assume). In Windows 2000, you Shift-right_click to get "Run As" as an option. You cannot run another copy of Explorer.exe with it (and so you cannot access the control panel as administrator using this trick). Windows XP's fast user switching is better in this regard- no need to close programs to do something as administrator, but still not as nice as nix. Windows NT Resource kit has a command line SU utility, but I've never used it.

  • by jetmarc ( 592741 ) on Friday March 07, 2003 @06:00PM (#5462979)
    I hate to reply to myself, but even more I hate to not check links :(

    The link is in german and requires a lot of click-though until you hit the download. An easier location to get KNOPPIX is the ftp server, eg this one:

    ftp://ftp.tu-chemnitz.de/pub/linux/knoppix/

    You find KNOPPIX on many big linux distro mirrors, so go to your favourite one..

    Marc
  • by Anonymous Coward on Friday March 07, 2003 @06:07PM (#5463064)
    won't always work under ntfs. users have massively obfuscated mappings, and changes of ownership trying to overcome this problem can, in my experience, lead to gross file corruption.
  • by zbuffered ( 125292 ) on Friday March 07, 2003 @06:24PM (#5463221)
    if it is a Win2k box, you can enable the terminal service

    Point of clarification: W2K Professional does not have terminal services available to it, although Server and Advanced Server both do. WXP has it tho, and it's nice and easy to use.
  • by Hork_Monkey ( 580728 ) on Friday March 07, 2003 @06:24PM (#5463225)
    Change the port number in this registry key:
    HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Contro l\Terminal Server\winstations\RDP-TCP

    In the client, just append a ":" to the hostname/ip.
  • by hughk ( 248126 ) on Friday March 07, 2003 @06:34PM (#5463322) Journal
    These guys do root kits that can hide in protocol eror messages so unless you have an air-gap, all a firewall will do is to stop it being installed in the first place. Standard messages often have unused places in which a covert channel can be established. The message can go out from the rooted system looking like anything. The trick is to ensure that the firewall is open for the technique used.

    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.

  • by Jouster ( 144775 ) <slashdot@angel[ ].com ['faq' in gap]> on Friday March 07, 2003 @07:11PM (#5463667) Homepage Journal
    ...(and so you cannot access the control panel as administrator using this trick)
    Au contraire--the control panel is easy!
    RunAs /user:Administrator MMC
    Then, File->Open, navigate to %WINROOT%\SYSTEM32, and there are your control panels. Choose your poison.

    Jouster
  • by Anonymous Coward on Friday March 07, 2003 @09:55PM (#5464692)
    If you'd post a binary dump, I might have see it before. Sounds similar to my style... I do know mine bluescreened on win2k sp3 on an older version.

    Most of the true windows rootkits have no names. It's just a patch/repack. We prefer NOT to put names/sigs/gr33ts on software we make. One less identifier is one less way we can be 'found out'.
  • by KJKHyperion ( 593204 ) on Friday March 07, 2003 @10:08PM (#5464775)
    You cannot run another copy of Explorer.exe with it (and so you cannot access the control panel as administrator using this trick).

    wrong, and wrong

    First, you can. Kill explorer.exe from the task manager, and then rerun it as Administrator: you'll get the Administrator's taskbar, desktop, etc.

    Second, you don't need to. You can run the command prompt as Administrator, and launch all the commands you need from there, including control panel applets and MMC snap-ins (you learn soon which has what filename). Or you can start Internet Explorer (iexplore.exe) as Administrator, instead - when browsing local folders, it will turn into an Explorer workalike, with just some UI problems (it won't be able to receive update notifications, not even from itself, so you'll need to refresh directory listings manually with F5)

  • by spectecjr ( 31235 ) on Friday March 07, 2003 @10:10PM (#5464784) Homepage
    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.

"Gravitation cannot be held responsible for people falling in love." -- Albert Einstein

Working...