I n T h i s C h a p t e r
♦ Root kits
♦ Brute force entry attacks and intrusion detection systems
♦ Intrusion prevention systems
♦ Buffer overflow attacks
Chapter 5: Gaining and Keeping Root Access
C05 Page 109 Tuesday, March 8, 2005 1:57 PM
110 Chapter 5: Gaining and Keeping Root Access
5 . 0 I n t r o d u c t i o n
The goal of a system cracker often is to gain access to a system, not only once, but repeatedly. If at all possible, the cracker wants to secure root (or administrator) access so that he or she can do just about anything with the system. Perhaps the cracker wants to read or copy files; per-haps the hacker wants to install software that will cause the compro-mised system to take part in a distributed attack on another computer.
Whatever the reason, the cracker wants to establish root access, leave behind whatever is necessary to gain access again, and then exit with-out being detected.
The software a cracker leaves behind is known as a root kit, a collection of programs that allow the cracker to access the system at any desired time and gain root or administrator privileges. In this chapter we will be-gin by looking at root kits—what they are, where they come from, and how you can detect them—and then consider how root kits might be in-stalled on your system in the first place and what you can do to thwart such attacks.
5 . 1 R o o t K i t s
Root kits have been around since at least the early 1990s. Commonly they let a hacker
♦ Enter a system at any time.
♦ Open ports on the computer.
♦ Install software on the system.
♦ Run any software installed on the system, including software that can be used in a denial of service attack. (See Chapter 6 for in-depth coverage of denial of service attacks.)
♦ Become a super/administrative user, and therefore perform any actions associated with that high-level access (especial-ly creating new accounts).
♦ Use the system as a platform for cracking other computers on the same local network.
C05 Page 110 Tuesday, March 8, 2005 1:57 PM
5.1 Root Kits 111
♦ Capture user names and passwords.
♦ Change log files—which are discussed later in this chapter—
to erase any record of a cracker’s actions.
One of the most insidious things about a root kit is that if it works as in-tended, you won’t know that it is on your computer. A root kit hides it-self, as well as the actions of the cracker who installed it. How can you detect the presence of a root kit? It’s not easy, but you can look for
♦ Unexplained decreases in available disk space.
♦ Disk activity when no one is using the system (and no back-ground processes should be running).
♦ Changes to system files.
♦ Unusual system crashes.
Then you’ll need to look for files that don’t belong, not an easy task with today’s operating systems that are made up of tens of thousands of files.
In addition, on a Windows system, root kit files are invisible, although some may appear if you boot in safe mode.
Some help is available in the form of automated file change monitoring tools, such as Tripwire (http://www.tripwire.com). If the installation of a root kit replaces system files, change monitoring software can detect the replacement (see Figure 5.1). Software like Tripwire works by establish-ing a baseline of clean software and can therefore make it much easier to recover when a root kit is detected.
The only reliable way to recover from a root kit infection is to reformat the hard drive, restore the OS from original installation media, reinstall all applications from original installation media, and copy data files back to the hard drive. Don’t simply restore from a backup copy: You could restore the root kit as well!
5 . 1 . 1 R o o t K i t T h r e a t L e v e l
Until 2003, UNIX systems were the primary target of root kits; there weren’t any Windows root kits. (Finally, something Windows users didn’t have to worry about!) At this time, however, there are several Win-dows root kits, including Slanret, null.sys, HE4Hk (a Russian effort),
C05 Page 111 Tuesday, March 8, 2005 1:57 PM
112 Chapter 5: Gaining and Keeping Root Access
Hacker Defender, and FU. There are a large number of UNIX root kits, in-cluding t0rn, Knark, Are, and Rkit.
Note: You can learn a great deal about Windows root kits at http://www.rootkit.com. You can download root kit code and even take a course in developing a root kit.
A root kit is made up of files left behind after a system cracker gains ac-cess to a system through some other means. The easiest way to prevent a root kit from being installed on your computers is to prevent crackers from getting in in the first place!
Figure 5.1 A Tripwire report screen
C05 Page 112 Tuesday, March 8, 2005 1:57 PM
5.1 Root Kits 113
So, how vulnerable are your systems to a root kit? It depends on how easily your systems can be penetrated. Stop unauthorized access and you’ll impede root kits as well.
5 . 1 . 2 H o w R o o t K i t s W o r k
Most root kits hide themselves by placing themselves between calls to system routines made by program APIs and lower layers of the operat-ing system. Whenever an application (or a portion of the OS, for that matter) makes a system call, the root kit intercepts the call and deter-mines whether to pass the call through to the OS, handle the call itself (thus changing OS behavior), or drop the call.
The root kit handles system calls that might reveal its presence. For ex-ample, if a user were to request a listing of a directory containing root kit files, the root kit would perform the listing, but leave out any of its own files so they wouldn’t be seen by the user. This also means that nor-mal virus-detection software won’t find a root kit.
UNIX root kits take advantage of the modular nature of UNIX: Most UNIX variations can be extended by Loadable Kernel Modules (LKMs), com-piled OS modules that can be loaded into RAM while the OS is running.
Current UNIX root kits—many of which load as device drivers—are LKMs that intercept system calls in the manner just described.
Reality Check: The basic technique used by root kits isn’t particularly new. In the mid-1980s it was possible to set up a dumb terminal connected to a mainframe or su-permini to collect user names and passwords. The system cracker wrote a script that captured input from the terminal’s keyboard and wrote it to a text file. Then it passed the input on to the computer. The script passed all output directly back to the termi-nal screen. The user interface looked just like the normal command line; a user would have no idea that all his or her keystrokes were being logged. The cracker would start the script and walk away from the terminal. Then, some time later, the cracker would return, shut down the script, and analyze the contents of the script’s log file. User names and passwords would be there, in plain text.
C05 Page 113 Tuesday, March 8, 2005 1:57 PM
114 Chapter 5: Gaining and Keeping Root Access
5 . 2 B r u t e F o r c e E n t r y A t t a c k s a n d I n t r u s i o n D e t e c t i o n
Before there were sophisticated tools for attempting to penetrate com-puter networks based on known system vulnerabilities, hackers would use brute force attacks in attempts to gain entry to systems. Such an at-tack involves repeatedly trying dial-up numbers, user names, and pass-words in the hopes that something will work.
The hacker could write a simple BASIC program to dial a sequence of telephone numbers and record those numbers that reached a computer.
Known as war dialing, this technique has changed with the predomi-nance of the Internet, but not disappeared. Today, script kiddies use pro-grams that run through a set of IP addresses, attempting to find resources such as file sharing servers (for example, Kazaa), Web serv-ers, or Trojan horses that have been left behind by other hackers. The ranges of IP addresses used by major IPSs such as AL and Earthlink are well known. All a script kiddie needs to do is run the program, fill in the starting and ending IP addresses, and sit back and let the program run.
The program reports what it finds; then the script kiddies can use other software to exploit the system he or she has found.
Crackers can use a similar technique to search for user names and pass-words. Assuming that user names are not publicly available, a cracker can make educated guesses as to what administrative accounts exist on a system. Knowing employee names, the cracker can also make some reasonable guesses as to what account names might be. He or she can then try likely possibilities or, using a file containing common account names, can use software that tries every entry.
Once a cracker knows an account name, the remaining step in a brute force attack is to try to guess the password. Crackers might use clues given when users register for accounts, such as knowing that a pass-word must be 6 to 16 characters long and must contain at least one letter and one number. Then he or she can use software that either tries ran-dom combination of letters and numbers or uses a file of possible pass-words. Sometimes, the cracker gets lucky and the software stumbles upon a password that works.
You can’t prevent someone from mounting a brute force attack against your network, but you can detect that such an attack is occurring and
C05 Page 114 Tuesday, March 8, 2005 1:57 PM
5.2 Brute Force Entry Attacks and Intrusion Detection 115
ensure that the perpetrator doesn’t succeed. There are two basic tech-niques for detecting a brute force attack:
♦ Look through your network logs for patterns of repeated ac-cess attempts. Logs are usually kept by multiuser operating systems (in particular, severs) as well as firewalls. (If logging isn’t turned on, turn it on!)
♦ Disable an account after a small number of unsuccessful log-in attempts. In most cases, software will lock access to an ac-count after three failed connection attempts. The user will then need to contact a help desk to get the account released.
♦ Use intrusion detection system (IDS) software.
An experienced security person can see patterns in system logs, but scanning the logs can take a lot of time. IDS software runs by itself and sends alerts when it detects a potential problem. However, in many sit-uations IDS software isn’t as good as an experienced eye.
5 . 2 . 1 E x a m i n i n g S y s t e m L o g s
Operating systems and firewalls keep logs of the events that happen in their environments. Exactly what you see, and what you should look for, depends on the specific OS or the specific firewall.
When you set up a procedure for examining system logs, you will need to answer the following questions:
♦ If the OS or firewall allows customization of what appears in the log file, what events should be logged? At the very least, you will want to keep track of unsuccessful login attempts. A pattern of attempts to access the same account may indicate a brute force attack.
♦ How long should log files be retained? This depends on the size and activity level of your network (the larger and more ac-tive, the larger the log files), the amount of storage media available (the more storage media available, the more log files you can store), and judgements about the persistence of cracking attempts (the more persistent the crackers, the less time you need to store the log files). Keep the log files however
C05 Page 115 Tuesday, March 8, 2005 1:57 PM
116 Chapter 5: Gaining and Keeping Root Access
long you feel is necessary to show patterns of unauthorized access.
♦ Where should archival log files be stored? One of the ways in which a system cracker hides his or her tracks is by altering log files. Changes for achived log files can mask a pattern of repeated access attempts. Therefore, such files should not be stored on media that are accessible to a network. The saf-est way to store them is on removable media, such as a CD or DVD, that can be stored away from a computer that can read the data.
♦ Which hardware should keep logs? Should each workstation keep its own logs, or is it enough that servers and firewalls keep logs? If all Internet and WAN access is through an edge router, then you may feel it is sufficient to keep logs only on those machines that are exposed to an external network along with the firewall logs. However, if you are concerned with system cracking attempts by employees, then you will also probably want to keep logs on workstations that contain sensitive information.
♦ How often will logs be examined? Is once a day enough, or should it be done several times during the day? How often you examine logs depends on the volatility of your network.
The higher the traffic level, the more often you’ll need to look at the logs.
You should begin monitoring system logs even before you suspect there might be a problem. Why? To see what normal activity looks like. Then, when something out of the ordinary occurs, you will be able to detect it.
For example, if you see your organization’s CEO logging in at 2 in the morning, you should be very suspicious (unless you know that he or she actually works at such an hour).
W i n d o w s E v e n t L o g s
Windows can keep logs of a wide variety of events. In most cases, you want to look for failed logon attempts, repetitions of which from the same source are a good indication of a brute force attack in progress. To make your life easier, Windows allows you to set up an audit policy, which can filter the events that are being recorded.
C05 Page 116 Tuesday, March 8, 2005 1:57 PM
5.2 Brute Force Entry Attacks and Intrusion Detection 117
Note: In the long run, you may also want to look for things such as failed attempts to delete files of change security settings, but those occur after the miscreant has already gained access to your system.
The typical Windows system actually keeps three logs: an application log, a security log, and a system log. A Windows computer running as a domain controller also keeps a directory service log and a file replica-tion service log. You can see a porreplica-tion of a system log in Figure 5.2. Each event header contains the information in Table 5.1. (For details on ac-cess and configuring Windows system logs, see the Hands On section at the end of this chapter, beginning on page 126.)
U N I X S y s t e m L o g s
What you see in UNIX system logs will depend on the version of UNIX you are using. For example, in Figure 5.3 you can find a portion of the system log for the startup of a Macintosh OS X system, which is a variant of BSD UNIX. The system log keeps a record of just about everything the OS does. There are also logs for each user, a panic log (entries about kernel Figure 5.2 A portion of a Windows system log
C05 Page 117 Tuesday, March 8, 2005 1:57 PM
118 Chapter 5: Gaining and Keeping Root Access
panics), crash logs (entries about software crashes), and so on. In addi-tion, many applications, such as Web servers and database severs, keep their own log files.
Log in and log out information is usually kept in /var/log/wtmp. A UNIX administrator will therefore probably monitor this particular log file closely. Most services write entries to /var/log/syslog and messages about system connection attempts can be found in /var/log/messages. These files are also important sources of data about what who is at-tempting to enter the system.
Because UNIX log files are text files, a user with the appropriate access rights can view them with any text editor of UNIX utility (for example, more). However, the content of the logs can be confusing to view as plain, unformatted text. Help comes in the form of a log analyzer, soft-ware that can extract relevant information from a log and format it for easier viewing.
Field Contents
Date The date when the event occurred.
Time The time when the event occurred.
User The user performing the event.
Computer The computer on which the event occurred.
Source The software that generated the event.
Event An event type ID and a description of the event.
Type The severity of the event. System and application events can be Error (a serious problem that will affect system functioning), Infor-mation (successful software action), or Warning (inforInfor-mation about a potential problem). Security events can be Success Audit (a secu-rity event that is being logged that succeeds) or Failure Audit (a security event that is being logged that fails).
Category A category into which the event falls, determined by the event’s source.
Table 5.1 The fields in a Windows event log header
C05 Page 118 Tuesday, March 8, 2005 1:57 PM
5.2 Brute Force Entry Attacks and Intrusion Detection 119
Tip: You can find a collection of links to free and GNU li-censed Linux log analyzers at http://www.linux.org/
apps/all/Administration/Log_Analyzers.html.Intrusion-Prevention.
Jul 8 07:17:40 localhost syslgd: restart
Jul 8 07:17:40 localhost syslgd: kernel bt file is /mach_kernel
Jul 8 07:17:40 localhost kernel: standard timeslicing quantum is 10000 us Jul 8 07:17:40 localhost kernel: vm_page_btstrap: 124988 free pages Jul 8 07:17:40 localhost kernel: mig_table_max_displ = 68
Jul 8 07:17:40 localhost kernel: IKit Component Version 7.4:
Jul 8 07:17:40 localhost kernel: Wed May 12 16:54:39 PDT 2004;
root(rcbuilder):RELEASE_PPC/ikit/RELEASE
Jul 8 07:17:40 localhost kernel: 69 prelinked modules
Jul 8 07:17:40 localhost kernel: Copyright (c) 1982, 1986, 1989, 1991, 1993 Jul 8 07:17:40 localhost kernel: The Regents of the University of California.
All rights reserved.
Jul 8 07:17:40 localhost kernel:
Jul 8 07:17:40 localhost kernel: using 1310 buffer headers and 1310 cluster I buffer headers
Jul 8 07:17:40 localhost kernel: Local FireWire GUID = 0x3065ff:0xfee18eee Jul 8 07:17:40 localhost kernel: Security auditing service present
Jul 8 07:17:40 localhost kernel: BSM auditing present
Jul 8 07:17:40 localhost kernel: From path: "/pci@f2000000/mac-i@17/ata-4@1f000/
@0:5,\mach_kernel", Waiting on <dict ID="0"><key>IPathMatch</key><string ID="1">IDeviceTree:/pci@f2000000/mac-i@17/ata-4@1f000/@0:5</string></dict>
Jul 8 07:17:40 localhost kernel: Gt bt device = IService:/MacRISC2PE/
pci@f2000000/AppleMacRiscPCI/mac-i@17/AppleKeyLarg/ata-4@1f000/KeyLargATA/
ATADeviceNub@0/IATABlockStorageDriver/IATABlockStorageDevice/
IBlockStorageDriver/Maxtr 5T060H6 Media/IApplePartitionScheme/MacS@5 Jul 8 07:17:41 localhost kernel: BSD root: disk0s5, major 14, minor 5 Jul 8 07:17:41 localhost kernel: Jettisoning kernel linker.
Jul 8 07:17:41 localhost kernel: Resetting ICatalogue.
Jul 8 07:17:41 localhost kextd[88]: registering service
"com.apple.KernelExtensionServer"
Jul 8 07:17:44 localhost kernel: Matching service count = 2
Jul 8 07:17:44 localhost kernel: NVDANV10HAL loaded and registered.
Jul 8 07:17:44 localhost kernel: RM ndrv for NVDA,NVMac is to ld (0xb690c0f5) Jul 8 07:17:44 localhost kernel: AppleRS232Serial: 0 0
AppleRS232Serial::start - returning false early, Connector of machine incorrect Jul 8 07:17:44 localhost SystemStarter: Welcome to Macintosh.
Figure 5.3 A portion of a Mac OS X system log
C05 Page 119 Tuesday, March 8, 2005 1:57 PM
120 Chapter 5: Gaining and Keeping Root Access
5 . 2 . 2 I n t r u s i o n D e t e c t i o n S o f t w a r e
An Intrusion Detection System (IDS) is software that attempts to detect a brute force or other attack that is in progress. It can then alert you to the attack or perform actions that you have specified to stop the attack.
IDSs work in one of three ways:
♦ Examining system logs (host based)
♦ Examining network traffic (network based)
♦ A combination of the two
Which is better? There is no simple answer because host-based and
Which is better? There is no simple answer because host-based and