TECHNICAL PREPARATION

Technically preparing to execute a test is arguably one of the most undocumented elements of a penetration test. Everyone has his or her own expectations, favorite operating system, tools, and practices, but rarely are these communicated, much less appear in the deliverable. In this section, we look at some of the common aspects of getting technically ready to run an attack.

ATTACKING SYSTEM

Building a system, or several, to perform an attack is not as simple as some would like you to think, and if they tell you such, I would question their preparedness. The selected operating system, tools, and how the collected data is protected all play an important role in how the test will be performed, ultimately affecting the value of the test.

There are several attributes to building an attacking system:

• Operating System. The operating system selected for use as the foundation of an attack can greatly influence the ability to perform certain tasks. These can come in the form of the available tools that can run on the operating system to the actual capabilities of the system to perform as needed.

• Tools. Tools are an essential part of performing a test. Tools can range from off-the-shelf products to outright hacker tools. Tools also need to reflect the systems and networks that are unique to the target.

• Data Management and Protection. During a test, piles of data are collected to log the various activities and to gather information for the final deliv- erable. Protecting information about the inner workings of a client and evidence of a hole is essential to maintain integrity of the test and privacy of the client.

• Communications. Once teams are established, the security communication between the teams should be afforded the same security applied to the information collected.

Operating System

Every operating system (OS) has unique traits that can be beneficial to the attacker: its flexibility in allowing the user to create scripts, perform rare and known malicious activities, and support the tools required. The availability of the OS and the hardware necessary to run it plays a role as well. Windows 2000 does not require any special hardware and the system requirements are not excessive. Also, it’s not too difficult to get a free copy, especially for a determined hacker. On the other hand, OSs such as HP-UX, Solaris, VMS, IRIX, and XENIX usually require specialized or very expen- sive hardware, are difficult to obtain, and do not offer substantial advantage to a hacker. Linux is usually the choice for many hackers as a general-purpose system because it is free, easily obtained, and powerful. Linux is a very capable and strong OS that is incredibly customizable, and for the price, it can’t be beat. Linux has been modified to run on telephones, PALM Pilots, and even gaming consoles, to name a few applications. Companies such as TiVo, WatchGuard, Cobalt, IBM, and many others use it as the foundation of some of their products. This is a testament to Linux’s flexibility, stability, and power.

But why do hackers and testers alike use Linux? You can liken it to a driving enthusiast and cars. A new Yugo off the line is fine for people driving to work or dropping off the kids at school; it’s functional and gets you from point A to point B. A Yugo may be functional but is usually difficult to modify as a high-performance car because it was not originally designed at the factory with those characteristics. A car enthusiast looks for a car that can be manipulated, added to, and modified to accommodate desires. A specialized car may apply to the basic rules to work within the fabric of roads, highways, and parking lots with an accelerator, wheels, and brakes, but beyond that, anything is possible. Linux is that car and the computer simply provides the necessities to interact with the rest of the digital world.

Given that Linux provides so much power and adaptability with almost no cost, it is perfect for hackers to create tools for attacking systems. Therefore, it is the logical starting point for testers.

One of the desirable features of an operating system is to allow the user to accomplish tasks that a traditional system would simply not allow. An example of this is the TCP/IP protocol stack. The protocol stack is what the operating system uses to manage communication with other systems. It is what builds the packets, assembles them, applies attributes and flags, and is responsible for managing the virtual connection between the network card and the upper-level services and appli- cations. In Windows, the stack operates based on a set of rules as defined by the

creators at Microsoft with few options for modification. However, Linux’s stack is wide open and free for anyone to change to make it function according to a new set of rules that permit the manipulation of the communication. Therefore, a remote system abiding by the standard rules can be affected by a rogue computer that does not. Programs can be written to take advantage of a willing and able protocol stack to build packets to which unsuspecting systems fall victim.

In some scenarios, having an operating system similar to the one being targeted can be an advantage as well. Because Microsoft is everywhere and is arguably the most used operating system in the world, it is also a desirable platform to launch attacks against other similar systems. It is not used because of the flexibility, but rather the similarities it has with the target system. It is much easier to leverage existing flaws in a system than it is to try to mimic them in a different operating system.

Tools

Tools can be defined in many ways. However, in general, a tool can be anything that is used to perform an automated function. Everything from standard applications, utilities, scripts, special-purpose programs, and protocols can be used as designed or pushed to their limits to exploit a system. Tools, in the context of performing a test, are usually designed to perform a task with the intention of identifying or exploiting a vulnerability. Other forms of standard software or utilities can be used to expand the attack or collect the necessary information.

Ping, telnet, and nslookup are standard utilities used to gather various informa- tion, support an attack, and determine vulnerabilities. For example, nslookup is typically used to gather domain name information from a DNS server. If used with the “ls –d” command option a DNS server could return all the aliases and their IP addresses assigned to a particular domain. The information collected could be very useful to an attacker, but the fact that the DNS server was not configured properly to avoid such a command demonstrates to the hacker the general awareness of security. Telnet is a very old utility permitting interactive sessions with a system. In most cases, a telnet daemon (telnetd) is running as a service on a remote system and supplies the client with a command-line session to perform various tasks as if sitting at the terminal. There are some applications that use telnet to publish simple character-based programs to a user community. Telnet has an interesting feature in that if you provide it with a target port, it allows human interaction with a service normally used only by applications. For example, the command, “telnet pop- server.domain.com 110” provides an interactive session with the POP service. By using a very basic and common utility, a hacker can directly manipulate a service that thinks it is receiving requests from a system.

Beyond utilities are software packages designed specifically for testing system security, such as ISS’s System Security Scanner, a popular tool used by many testers and hackers alike. Off-the-shelf products contain collections of exploits and vulner- ability scanners that are employed by a simple menu item checkbox. They can be configured to simply seek out opportunities, or actually attempt to exploit the vulnerability. Some even have DoS capabilities. In the wrong hands, commercially

available products can be harmful, even destructive. In addition, the wrong hands could be someone with noble intentions who simply does not know the power of the tool. One of the more common mistakes companies make is purchasing tools for internal use and providing them to local administrators that may have little or no experience in penetration testing. Examples of such a practice have led to enor- mous amounts of downtime, or the assumption of security because the tool did not find anything because it was improperly employed.

Then there are hacker tools. Some are mainstream such as NMap, LOpht, and Nessus, which have deep roots in the hacking community and have been recently popularized by the legitimate security community. LOpht Crack was a free hacker tool from many years ago that would crack passwords contained in a Windows system. Now, the tool is part of a suite of products offered by @Stake, and used as a standard administrative tool for many organizations to test password integrity.

Usually, the hacker tools that become popular and used by the average admin- istrator do so because they are well written, easy to use, easy to find, and easy to install. In addition, these types of tools are usually not destructive and help with the identification of a vulnerability rather than simply prying it open to gain access. On the other hand, there are tools designed for that very purpose, some with incredibly devious intentions. Some are very small programs designed to take advantage of a specific vulnerability in only one type of application and even specific versions.

The more specific the tool or the deeper underground you have to go to get it usually translates to more difficulty in compiling, installing, configuring, and using. It takes someone with strong skills and tenacity, but the result is a tool that can provide exceptional access to a system.

Obtaining, compiling, and using a tool is only a small part of the total equation. During an engagement it is how the tools are used, to what degree, when they are used, and the techniques they were involved in that make for a successful test. Tools have nearly become the proverbial monkey on the back of penetration testers. This is due to some customers being overly concerned about what tools are used, placing a great deal of emphasis on the value of the tool rather than the capabilities of the tester. Much of this can be seen based on the reliance of reports that are generated by a tool. With the introduction of ISS’s System Scanner, a detailed report on each identifiable weakness was considered acceptable. Unfortunately, these reports were just that, a report on the vulnerabilities that were identified by a computer without concern for the overall state of the security. Automated reports either led to the assumption of security, or raised awareness around a specific vulnerability, which may have had little to do with any true threat. Undoubtedly, tools play a critical role in a penetration test, but the value of the test is realized by the capabilities of the tester in using the tools.

Using hacker tools can represent a threat to the tester, the system, and ultimately the client. Given the popularity of many underground hacker tools in the corporate environment, the creators will build a Trojan into their software. They can also contain worms or viruses, but usually they are programs that give surreptitious access to the system. SATAN, which does not contain arbitrary code to implement a Trojan or virus, is nearly impossible to find.

One scenario is that of a system administrator responsible for maintaining several Web servers on the network. Left without any comprehensive security utilities, he looks for and finds a free tool on the Internet that looks for vulnerabilities. He installs the hacker tool and runs scans on his systems. Regrettably, the tool also carries a Trojan Horse program that upon installation looks for an Internet connection, con- tacts the creator, and sends sensitive files that could be used later to hack the network. One of the more interesting and devastating ways hackers infiltrate people who use tools is to distribute a modified library necessary for compiling many of the tools. A library is a collection of code used to support common functions within programs. For example, it may contain basic code to access the hard drive or network card, or provide utilities that perform other simple functions. The creator of a tool uses these standard libraries to avoid having to rewrite code. However, there are libraries out there for hacker tools that are usually modified versions of the originals to accommodate the hacker community. Some hackers modify the code even further to perform some other task in addition to the expected one called upon by the program. By doing this they can infect many different hacker-related programs that may use their modified library.

Data Management and Protection

One of the more overlooked aspects of technical planning is establishing security controls for the sensitive information being collected from a target’s systems and networks. If the engagement is supported by the company providing detailed infor- mation about its environment, the tester may have loads of proprietary information that could be useful to other companies or individuals. In addition to information and documents given to the tester, there is data collected during the various phases of the engagement. Raw data from systems, files collected from servers, screen shots, and detailed maps of the network may be obtained throughout the test. Finally, the consultant may generate information to assist in the overall project: attack plans and strategy, concepts, and miscellaneous communications with peers that could be useful to a real hacker.

NOTE10: THE HUNTER BECOMING THE HUNTED

Many years ago, a customer requested a very comprehensive attack on the company. It included outside threats, partner and customer threats, and internal employee threats. Several consultants were assigned to the engagement to oper- ate together to collect as much information as possible to determine the overall security of the client’s operation. One of the consultants worked his way into the office, found a quiet cubicle, connected to the network, and started browsing around. In addition to looking around and running a sniffer, he attempted to gain access to a Solaris server presumably in the data center. The attempt could be considered premature because there was little information about the server, or the entire network for that matter. Unfortunately (or fortunately, depending on your perspective), the administrators of the Solaris system immediately detected the intrusion and identified the system performing the attack. Being

security savvy themselves, they decided to hack the attacking system to get more information about who was on their network and trying to gain access into one of their core systems.

The consultant was running a default installation of Linux and was vulner- able to a multitude of attacks. Within minutes, the administrators obtained root access to the consultant’s laptop and proceeded to download everything from the system. Once they felt they had enough data, they deleted a handful of critical system files and shut down the system. After reviewing some of the collected documents, they quickly determined the company by which they were being hacked. The administrators stormed up to their boss’s office and presented the findings. As you may imagine, this was embarrassing to the consultant and the organization he represented, but no real harm was done—at least on the surface. Much of the data collected by the administrators was from no less than five previous penetration-testing engagements, detailing vulnerabilities, organi- zational structures, systems details, vulnerabilities that could not be fixed, sys- tem versions, competitive data, and finally sensitive information obtained from various servers and workstations. Luckily, the administrators returned all the collected information and it’s doubtful that they would use it for an attack. Nevertheless, this clearly demonstrates the need to protect client information, especially on an attacking system.

Protecting information from a would-be hacker requires the same planning for any system maintaining sensitive data. However, unlike a traditional server, the attacking system may have huge security holes because closing them would have an impact on its usability as a tool for testing. Some solutions are to mount a dedicated, removable hard drive or solid-state storage device that can be easily secured or removed if an attack is detected.

Ultimately, encryption is the best solution. Public-key cryptography, such as Pretty Good Privacy (PGP) that employs asymmetrical encryption, can be used to protect data. One method is to generate a key pair for each of the White and Red Team members with an administrative key. An administrative key is a master key that can be used to decrypt anything encrypted with a private key originally created with the administrative key. It is a protection mechanism so that someone with a private key cannot encrypt sensitive data and delete the key, rendering the informa- tion useless. In addition, many applications support split administrative keys, requir- ing two or more people to be present so the master key can be used. Each member of the Red Team can use a fob or key card to store his or her private key to be used only when data needs to be encrypted.

The end result is a private key maintained on a secure device separate from the attacking system that is used regularly to encrypt the collected information. To support an understanding of trust and access, the existence of an administrative key provides emergency access to the encrypted data in the event the tester quits, is hit by a truck, or anything that would hinder access to the data by authorized users. This is only one example of protecting information on an attacking system. However,

no matter the solution, it must be robust and effective, assuming any and all possi-