A Primer on Cracking: Part 2

82-03-08

DATA SECURITY MANAGEMENT A PRIMER ON CRACKING: PART 2

Edward Skoudis

INSIDE Stack-based Buffer Overﬂows; The Art and Science of Password Cracking; Backdoors; Trojan Horses and RootKits; Overall Defenses — Intrusion Detection and Incident Response Procedures

INTRODUCTION Part 1 of this article (82-03-07) discussed network mapping and port scanning, vulnerability scanning, wardialing, network exploits, and deni- al-of-service attacks. Part 2 discusses stack-based buffer overﬂows, password cracking, backdoors, Trojan horses and rootkits, and defenses — intrusion detection and incident response procedures.

STACK-BASED BUFFER OVERFLOWS Stack-based buffer overflow attacks are commonly used by an attacker to take over a system remotely across a network. Additionally, buffer overflows can be employed by local malicious users to elevate their privileges and gain superuser access to a system. Stack-based buffer overflow attacks exploit the way many operating systems handle their stack, an internal data structure used by running programs to store data temporarily. When a function call is made, the current state of the executing program and variables to be passed to the function are pushed on the stack. New local variables used by the function are also allocated space on the stack. Additionally, the stack stores the return address of the code calling the function. This return address will be accessed from the stack once the function call is complete. The system uses this address to PAYOFF IDEA With the rise of powerful, easy-to-use, and widely resume execution of the calling pro- distributed hacker tools, many in the security in- gram at the appropriate place. Exhibit dustry have observed that today is the golden age 1 shows how a stack is constructed. of hacking. The purpose of this article is to de- Most UNIX and all Windows sys- scribe the tools in widespread use today for com- promising computer and network security. Addi- tems have a stack that can hold data tionally, for each tool and technique described, and executable code. Because local the article presents practical advice on defending variables are stored on the stack against each type of attack.

DATA SECURITY MANAGEMENT

EXHIBIT 1 — A Normal Stack and a Stack with a Buffer Overﬂow

when a function is called, poor code can be exploited to overrun the boundaries of these variables on the stack. If user input length is not ex- amined by the code, a particular variable on the stack may exceed the memory allocated to it on the stack, overwriting all variables and even the return address for where execution should resume after the function is complete. This operation, called “smashing” the stack, allows an attacker to overflow the local variables to insert executable code and another return address on the stack. Exhibit 1 also shows a stack that has been smashed with a buffer overflow. The attacker will overflow the buffer on the stack with machine-specific bytecodes that consist of executable commands (usually a shell routine), and a return pointer to begin execution of these inserted commands. Therefore, with very carefully constructed binary code, the attacker can actually enter information as a user into a program that con- sists of executable code and a new return address. The buggy program will not analyze the length of this input, but will place it on the stack, and actually begin to execute the attacker’s code. Such vulnerabilities allow an attacker to break out of the application code and access any system components with the permissions of the broken program. If the broken program is running with superuser privileges (e.g., SUID root on a UNIX system), the attacker has taken over the machine with a buffer overflow.

Stack-based Buffer Overﬂow Defenses The most thorough defense against buffer overﬂow attacks is to properly code software so that it cannot be used to smash the stack. All programs should validate all input from users and other programs, ensuring that it

A PRIMER ON CRACKING: PART 2

fits into allocated memory structures. Each variable should be checked (including user input, variables from other functions, input from other programs, and even environment variables) to ensure that allocated buff- ers are adequate to hold the data. Unfortunately, this ultimate solution is only available to individuals who write the programs and those with source code. Additionally, security practitioners and system administrators should carefully control and minimize the number of SUID programs on a system that users can run and have permissions of other users (such as root). Only SUID programs with an explicit business need should be installed on sensitive systems. Finally, many stack-based buffer overflow attacks can be avoided by configuring the systems to not execute code from the stack. Notably, So- laris and Linux offer this option. For example, to secure a Solaris system against stack-based buffer overflows, the following lines should be add- ed to /etc/system:

set noexec_user_stack=1 set noexec_user_stack_log=1

The ﬁrst line will prevent execution on a stack, and the second line will log any attempt to do so. Unfortunately, some programs legitimately try to run code off the stack. Such programs will crash if this option is im- plemented. Generally, if the system is single purpose and needs to be secure (e.g., a Web server), this option should be used to prevent stack- based buffer overﬂow.

THE ART AND SCIENCE OF PASSWORD CRACKING The vast majority of systems today authenticate users with a static password. When a user logs in, the password is transmitted to the system, which checks the password to make the decision whether or not to let the user login. To make this decision, the system must have a mechanism to compare the user’s input with the actual password. Of course, the system could just store all of the passwords locally and compare from this file. Such a file of cleartext passwords, however, would provide a very juicy target for an attacker. To make the target less useful for attackers, most modern operating systems use a one-way hash or encryption mechanism to protect the stored passswords. When a user types in a password, the system hashes the user’s entry and compares it to the stored hash. If the two hashes match, the password is correct and the user can login. Password cracking tools are used to attack this method of password protection. An attacker will use some exploit (often a buffer overflow) to gather the encrypted or hashed password file from a system (on a UNIX system without password shadowing, any user can read the hashed pass-

DATA SECURITY MANAGEMENT word file). After downloading the hashed password file, the attacker uses a password cracking tool to determine users’ passwords. The cracking tool operates using a loop: it guesses a password, hashes or encrypts the password, and compares it to the hashed password from the stolen file. If the hashes match, the attacker has the password. If the hashes do not match, the loop begins again with another password guess. Password cracking tools base their password guesses on a dictionary or a complete brute-force attack, attempting every possible password. Dozens of dictionaries are available online, in a multitude of languages including English, French, German, Klingon, etc. Numerous password cracking tools are available. The most popular and full-functional password crackers include:

• John-the-Ripper, by Solar Designer, focuses on cracking UNIX passwords; available at http://www.openwall.com/john/. • L0phtCrack, used to crack Windows NT passwords, is available at http://www.l0pht.com.

Password Cracking Defenses The first defense against password cracking is to minimize the exposure of the encrypted/hashed password file. On UNIX systems, shadow password files should be used, which allow only the superuser to read the password file. On Windows NT systems, the SYSKEY feature available in NT 4.0 SP 3 and later should be installed and enabled. Furthermore, all backups and system recovery disks should be stored in physically secured locations and possibly even encrypted. A strong password policy is a crucial element in ensuring a secure network. A password policy should require password lengths greater than eight characters and the use of alphanumeric and special characters in every password, and force users to have passwords with mixed-case let- ters. Users must be aware of the issue of weak passwords and be trained in creating memorable, yet difficult-to-guess passwords. To ensure that passwords are secure and to identify weak passwords, security practitioners should check system passwords on a periodic basis using password cracking tools. When weak passwords are discovered, the security group should have a defined procedure for interacting with users whose passwords can be easily guessed. Finally, several software packages are available that prevent users from setting their passwords to easily guessed values. When a user estab- lishes a new password, these filtering programs check the password to make sure that it is sufficiently complex and is not just a variation of the user name or a dictionary word. With this kind of tool, users are simply unable to create passwords that are easily guessed, eliminating a signifi- cant security issue. For filtering software to be effective, it must be installed on all servers where users establish passwords, including UNIX

A PRIMER ON CRACKING: PART 2 servers, Windows NT primary and backup domain controllers, and Nov- ell servers. (Jonathan Held, “Password Security,” Data Security Manage- ment, April 2000, 83-01-11.)

BACKDOORS Backdoors are programs that bypass traditional security checks on a system, allowing an attacker to gain access to a machine without providing a system password and getting logged. Attackers install backdoors on a machine (or dupe a user into installing one for them) to ensure they will be able to gain access to the system at a later time. Once installed, most backdoors listen on special ports for incoming connections from the attacker across the network. When the attacker connects to the backdoor listener, the traditional userID and password or other forms of authenti- cation are bypassed. Instead, the attacker can gain access to the system without providing a password, or by using a special password used only to enter the backdoor. Netcat is an incredibly flexible tool written for UNIX by Hobbit and for Windows NT by Weld Pond (both versions are available at http://www. l0pht.com/~weld/netcat/). Among its numerous other uses, Netcat can be used to create a backdoor listener with a superuser-level shell on any TCP or UDP port. For Windows systems, an enormous number of backdoor applications are available, including Back Orifice 2000 (called BO2K for short, and available at http://www.bo2k.com), and hack-a-tack (available at http://www.hack-a-tack.com). (See also Christopher Klaus, “An Introduction to the Back Orifice 2000 Backdoor Program,” Data Se- curity Management, October 2000, 84-02-02.)

Backdoor Defenses The best defense against backdoor programs is for system and security administrators to know what is running on their machines, particularly sensitive systems storing critical information or processing high-value transactions. If a process suddenly appears running as the superuser lis- tening on a port, the administrator needs to investigate. Backdoors listen- ing on various ports can be discovered using the netstat –na command on UNIX and Windows NT systems. Additionally, many backdoor programs (such as BO2K) can be discovered by an anti-virus program, which should be installed on all user desktops, as well as servers throughout an organization.

TROJAN HORSES AND ROOTKITS Another fundamental element of an attacker’s toolchest is the Trojan horse program. Like the Trojan horse of ancient Greece, these new Tro- jan horses appear to have some useful function, but in reality are just dis- guising some malicious activity. For example, a user might receive an

DATA SECURITY MANAGEMENT executable birthday card program in electronic mail. When the unsus- pecting user activates the birthday card program and watches birthday cakes dance across the screen, the program secretly installs a backdoor or perhaps deletes the users’ hard drive. As illustrated in this example, Trojan horses rely on deception — they trick a user or system administrator into running them for their (apparent) usefulness, but their true purpose is to attack the user’s machine.

Traditional Trojan Horses A traditional Trojan horse is simply an independent program that can be run by a user or administrator. Numerous traditional Trojan horse programs have been devised, including:

• the familiar birthday card or holiday greeting e-mail attachment described earlier • a software program that claims to be able to turn CD-ROM readers into CD writing devices (although this feat is impossible to accom- plish in software, many users have been duped into downloading this “tool,” which promptly deletes their hard drives upon activation) • a security vulnerability scanner, WinSATAN (this tool claims to provide a convenient security vulnerability scan for system and security administrators using a Windows NT system; unfortunately, an unsus- pecting user running this program will also have a deleted hard drive)

Countless other examples exist. While conceptually unglamorous, traditional Trojan horses can be a major problem if users are not careful and run untrusted programs on their machines.

RootKits A RootKit takes the concept of a Trojan horse to a much more powerful level. Although the name implies otherwise, RootKits do not allow an attacker to gain “root” (superuser) access to a system. Instead, RootKits allow an attacker who already has superuser access to keep that access by foiling all attempts of an administrator to detect the invasion. RootKits consist of an entire suite of Trojan horse programs that replace or patch critical system programs. The various tools used by administrators to detect attackers on their machines are routinely undermined with RootKits. Most RootKits include a Trojan horse backdoor program (in UNIX, the /bin/login routine). The attacker will install a new Trojan horse version of /bin/login, overwriting the previous version. The RootKit /bin/login routine includes a special backdoor userID and password so that the attacker can access the system at later times. Additionally, RootKits include a sniffer and a program to hide the sniffer. An administrator can detect a sniffer on a system by running the

A PRIMER ON CRACKING: PART 2 ifconfig command. If a sniffer is running, the ifconfig output will con- tain the PROMISC flag, an indication that the Ethernet card is in promis- cuous mode and therefore is sniffing. RootKit contains a Trojan horse version of ifconfig that does not display the PROMISC flag, allowing an attacker to avoid detection. UNIX-based RootKits also replace other critical system executables, including ps and du. The ps command, emloyed by users and administrators to determine which processes are running, is modified so that an attacker can hide processes. The du command, which shows disk utiliza- tion, is altered so that the file space taken up by RootKit and the attacker’s other programs can be masked. By replacing programs like /bin/login, ifconfig, ps, du, and numerous others, these RootKit tools become part of the operating system itself. Therefore, RootKits are used to cover the eyes and ears of an administrator. They create a virtual world on the computer that appears benign to the system administrator, when in actuality, an attacker can log in and move around the system with impunity. RootKits have been developed for most major UNIX systems and Windows NT. A whole variety of UNIX RootKits can be found at http://packetstorm.securify.com/UNIX/penetration/rootkits, while an NT RootKit is available at http://www.rootkit.com. A recent development in this arena is the release of kernel-level Root- Kits. These RootKits act at the most fundamental levels of an operating system. Rather than replacing application programs such as /bin/login and ifconfig, kernel-level RootKits actually patch the kernel to provide very low-level access to the system. These tools rely on the loadable kernel modules that many new UNIX variants support, including Linux and Solaris. Loadable kernel modules let an administrator add functionality to the kernel on-the-fly, without even rebooting the system. An attacker with superuser access can install a kernel-level RootKit that will allow for the remapping of execution of programs. When an administrator tries to run a program, the Trojanized kernel will remap the execution request to the attacker’s program, which could be a backdoor offering access or other Trojan horse. Because the kernel does the remapping of execution requests, this type of activity is very difficult to detect. If the administrator attempts to look at the remapped file or check its integrity, the program will appear unaltered, because the program’s image is unaltered. However, when executed, the unaltered program is skipped, and a malicious program is substituted by the kernel. Knark, written by Creed, is a kernel-level RootKit that can be found at http://packetstorm.securify.com/UNIX/penetration/rootkits.

Trojan Horses and RootKit Defenses To protect against traditional Trojan horses, user awareness is key. Users must understand the risks associated with downloading untrusted pro-

DATA SECURITY MANAGEMENT grams and running them. They must also be made aware of the problems of running executable attachments in e-mail from untrusted sources. Additionally, some traditional Trojan horses can be detected and eliminated by anti-virus programs. Every end-user computer system (and even servers) should have an effective, up-to-date anti-virus program installed. To defend against RootKits, system and security administrators must use integrity checking programs for critical system files. Numerous tools are available, including the venerable Tripwire, that generate a hash of the executables commonly altered when a RootKit is installed. The administrator should store these hashes on a protected medium (such as a write-protected floppy disk) and periodically check the veracity of the programs on the machine with the protected hashes. Commonly, this type of check is done at least weekly, depending on the sensitivity of the machine. The administrator must reconcile any changes discovered in these critical system files with recent patches. If system files have been altered, and no patches were installed by the administrator, a malicious user or outside attacker may have installed a RootKit. If a RootKit is detected, the safest way to ensure its complete removal is to rebuild the entire operating system and even critical applications. Unfortunately, kernel-level RootKits cannot be detected with integrity check programs because the integrity checker relies on the underlying kernel to do its work. If the kernel lies to the integrity checker, the results will not show the RootKit installation. The best defense against the kernel-level RootKits is a monolithic kernel that does not support loadable kernel modules. On critical systems (such as firewalls, Internet Web servers, DNS servers, mail servers, etc.), administrators should build the systems with complete kernels without support for loadable kernel modules. With this configuration, the system will prevent an attacker from gaining root-level access and patching the kernel in real-time.

OVERALL DEFENSES: INTRUSION DETECTION AND INCIDENT RESPONSE PROCEDURES Each of the defensive strategies described above deals with particular tools and attacks. In addition to employing each of those strategies, organizations must also be capable of detecting and responding to an attack. These capabilities are realized through the deployment of intrusion detection systems (IDS) and the implementation of incident response procedures. An IDS acts as a burglar alarm on the network. With a database of known attack signatures, an IDS can determine when an attack is under- way and alert security and system administration personnel. Acting as an early warning system, the IDS allows an organization to detect an attack in its early stages and minimize the damage that may be caused. (See also Eugene Schultz and Eugene Spafford, “Intrusion Detection: How to Uti-

A PRIMER ON CRACKING: PART 2 lize a Still Immature Technology,” Data Security Management, October 1999, 84-10-28.) Perhaps even more important than an IDS, documented incident response procedures are among the most critical elements of an effective security program. Unfortunately, even with industry-best defenses, a sufficiently motivated attacker can penetrate the network. To address this possibility, an organization must have procedures defined in advance de- scribing how the organization will react to the attack. These incident response procedures should specify the roles of individuals in the organization during an attack. The chain of command and escalation procedures should be spelled out in advance. Creating these items during a crisis will lead to costly mistakes. Truly effective incident response procedures should also be multi-dis- ciplinary, not focusing only on information technology. Instead, the roles, responsibilities, and communication channels for the legal, human resources, media relations, information technology, and security organizations should all be documented and communicated. Specific members of these organizations should be identified as the core of a Security Inci- dent Response Team (SIRT), to be called together to address an incident when it occurs. Additionally, the SIRT should conduct periodic exercises of the incident response capability to ensure that team members are effective in their roles. (See also Chris Hare, “CIRT: Responding to an At- tack,” Data Security Management, June 2000, 82-02-66.) Additionally, with a large number of organizations outsourcing their information technology infrastructure by utilizing Web hosting, desktop management, e-mail, data storage, and other services, the extension of the incident response procedures to these outside organizations can be critical. The contract established with the outsourcing company should carefully state the obligations of the service provider in intrusion detection, incident notification, and participation in incident response. A specific service level agreement (SLA) for handling security incidents and the time needed to pull together members of the service company’s staff in a SIRT should also be agreed upon.

CONCLUSIONS While the number and power of these attack tools continue to escalate, system administrators and security personnel should not give up the ﬁght. All of the defensive strategies discussed throughout this article boil down to doing a thorough and professional job of administering systems: know what is running on the system, keep it patched, ensure appropriate bandwidth is available, utilize IDS, and prepare a Security Incident Re- sponse Team. Although these activities are not easy and can involve a great deal of effort, through diligence, an organization can keep its systems secured and minimize the chance of an attack. By employing intru-

DATA SECURITY MANAGEMENT sion detection systems and sound incident response procedures, even those highly sophisticated attacks that do get through can be discovered and contained, minimizing the impact on the organization. By creating an effective security program with sound defensive strategies, critical systems and information can be protected.

Edward Skoudis ([email protected]) is Account Manager and Technical Director for Gobal Integrity.