Threats move beyond Linux to Windows: Insight

To print: Select File and then Print from your browser's menu

--------------------------------------------------------------
This story was printed from ZDNet Australia.
--------------------------------------------------------------

Threats move beyond Linux to Windows

By Scott Lowe, 0
December 10, 2002
URL: http://www.zdnet.com.au/insight/soa/Threats-move-beyond-Linux-to-Windows/0,139023731,120270561,00.htm

UNIX admins have been dealing with rootkits since the early 1990s, when the first ones to be discovered were exploiting SunOS 4 machines. Now, Windows admins must get up to speed, because rootkits are also being used to attack Windows NT and 2000 systems.

Hackers can obtain user-level security privileges and install a rootkit, which is basically a collection of tools, to compromise a system or network. The rootkit will exploit a known system vulnerability or crack a password for a user with administrator-level privileges and will then cover the hacker's tracks, making them difficult to detect. The best way to protect your network against rootkits is to know how they work and what type of damage they can do.

What rootkits do and how they do it
One of the primary purposes of a rootkit is to allow an attacker unfettered and undetected access to a compromised system at some point in the future. One way that a rootkit can do this is by installing a backdoor process or by replacing one or more of the files that run the normal connection processes, such as telnet or ssh. Within the Linux platforms, most rootkits also replace some system commands such as ls, ps, netstat, and who.

In addition to replacing core system utilities, a rootkit may install key logging software and network sniffers. Although having a system compromised and a rootkit installed is a major problem, the damage that can be done by an attacker making use of one of these two utilities is potentially disastrous. Using the keylogging software, an attacker can basically watch an administrator as he or she attempts to log in to the system as a privileged user. In some cases, the attacker can watch as the admin logs in to remote machines, gaining access to those as well.

If an attacker uses a rootkit that includes a network sniffer, other problems might arise, depending on how the attacked network is configured. For example, if the attacker enables the sniffer on the compromised system and that system is connected to a shared-type networking environment, such as a hub, the compromised system may not be able to handle the ensuing onslaught of network traffic. When a sniffer is used, the network adapter is placed into promiscuous mode, which means the system the adapter is connected to has to process all of the traffic that hits it, even if it is not destined for that particular system.

In addition to the potential for network problems, the sniffer can be used to create a pretty accurate map of a network, which gives the attacker further information about the infrastructure that he or she has gained access to. A sniffer will also enable an attacker to build a list of usernames and passwords for any telnet or ftp sessions that are opened on the network, since these passwords are sent in clear text. The hacker can launch more attacks against other systems with this information.

Rootkits include a plethora of other utilities that serve the needs of almost any attacker, including:

Modified versions of core system files.
Utilities to modify or clear system logs, which further erase the traceable information left behind by an attacker.
Loadable Kernel Module Trojans. Loadable modules are used to avoid recompiling the kernel, but in the form of a Trojan, they can be used to subvert system security at the same time. Basically, utilities that rely on the system kernel are compromised since the information coming from the kernel cannot be trusted.

What do rootkits exploit?
A rootkit can't be installed unless there is some way to compromise the security of the system. The compromise can be accomplished through social engineering, brute force attacks, or known vulnerabilities in system processes.

Installing rootkits via known exploits is the most popular method. Essentially, a hole (or weakness) in a given application/daemon/process will allow a hacker to slip the kit under the radar. Attackers have exploited processes such as WUFTP, BIND, and Xlib. Many of these exploits are buffer overflow problems and are patched soon after they're discovered. Your best defense is to keep apprised of such vulnerabilities and upgrade as soon as the patched version is released.

Sample rootkits
Many rootkits can be installed on various operating systems. I’ll describe a proof-of-concept rootkit that is available for Windows and one of the most popular Linux rootkits, Rootkit IV.

The NT RootKit
A proof-of-concept rootkit named NT RootKit has emerged. It can:

Hide processes to keep them from being listed.
Hide files and registry entries.
Log keystrokes.
Redirect executable files.
Issue commands that result in a Blue Screen of Death.

Even at the proof-of concept stage, this rootkit is dangerous; it can hide a backdoor process that will allow continued access to the system. This rootkit also contains its own TCP/IP stack, so Windows NT and 2000 netstat will not show any of its processes. In addition, this stack uses raw sockets that enable it to do much more than the built-in Windows TCP/IP stack would normally allow. Raw sockets allow the developer of a rootkit to code an application that makes use of TCP/IP sockets in unexpected ways, such as writing an application that takes instructions over a port that would be more secure if it was being used with the Windows built-in TCP/IP stack. Raw sockets are not necessarily a bad thing, but when used for hacking purposes, they can be very dangerous.

If you’re still unsure of how a rootkit can work its magic, take a look at Listing A to see an excerpt from one of the information pages about the NT RootKit's ability to redirect executable files.

You can see how dangerous this set of utilities might be for a Windows machine. Unauthorised access to a system is always bad, but the instructions in Listing A explain how an attacker might be able to install Trojan versions of system utilities on the server and get back in later. On top of this, the notes go on to describe how the CRC and file hashes still match the original, which means that the changes to the files may go unnoticed. You can find more information about the NT RootKit on the MegaSecurity site.

Linux Rootkit IV
Below is a listing of programs and processes that Linux Rootkit IV modifies. They are indicative of the modifications made by most Linux rootkits:

ls & find—In this rootkit, the ls and find utilities have been modified so they will not display the intruder’s files.
tcpd & syslogd—The rootkit versions of these utilities will not show or log any connections that are listed in the rootkit configuration file. (These are configured by the intruder.)
ifconfig—This version of ifconfig prevents the administrator from being told that the network adapter has changed modes and is now running in promiscuous mode.
ps, top, killall—These work normally except that the intruder’s processes are not shown or affected in any way.
inetd & rshd—These processes are modified to not show the rootkit processes and to allow the intruder to gain root access.

Utilities installed:

FIX—This modifies the timestamps and checksums on the modified files to hide the changes from the administrator.
bindshell—This utility provides the attacker with a rootshell on a specific TCP port.
linsniffer & sniffchk—This installs a packet sniffer and a utility to ensure that the packet sniffer is running.

This is not a complete listing of everything that is installed and/or modified by this particular rootkit, but you can see that significant, serious changes are made to the system that will compromise its integrity.

Be afraid, but not too afraid
Rootkits are bad news for administrators. They pose significant threats to the security and stability of the systems that users and customers rely on.

Scared yet? Don’t be too afraid. UNIX administrators have been dealing with these little monsters for years, and Windows administrators can learn a lot from the steps they have taken to protect their systems from rootkits.

Editorial disclaimer: The authors and editors have taken care in preparation of the content contained herein but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.

TechRepublic is the online community and information resource for all IT professionals, from support staff to executives. We offer in-depth technical articles written for IT professionals by IT professionals. In addition to articles on everything from Windows to e-mail to fire walls, we offer IT industry analysis, downloads, management tips, discussion forums, and e-newsletters.

©2001 TechRepublic, Inc.