The purpose of this chapter is to introduce a suite of tools that can be used to facilitate a security analysis—to examine, test, and secure personal computers and networks for and against security vulnerabilities. The goal here is take the mystery out of security and bring it directly to the consumer and/or technology professional, where it belongs. TigerSuite was developed to provide network security tools that are unique to the computer industry and sorely needed by individuals, commercial organizations, network professionals, and corporate managers concerned with maintaining a secure network. Such security includes protection against personal attacks, external attacks, and internal attempts at viewing or leveraging confidential company or private information against the "victim." At the time of this writing, a complete suite of security products does not exist on the market; TigerSuite is the first to provide a complete suite of products in one package.
Tiger Terminology
But before launching into a discussion on the inner workings of the TigerSuite, some definitions are in order, some "tiger terminology," if you will.
We begin by identifying the role of a tiger team. Originally, a tiger team was a group of paid professionals whose purpose was to penetrate perimeter security, and test or analyze inner-security policies of corporations. These people hacked into the computer systems, phone systems, safes, and so on to help the companies that hired them to know how to revamp their security policies.
More recently, a tiger team has come to refer to any official inspection or special operations team that is called in to evaluate a security problem. A subset of tiger teams comprises professional hackers and crackers who test the security of computer installations by attempting remote attacks via networks or supposedly secure communication channels. Tiger teams are also called in to test programming code integrity. Many software development companies outsource such teams to perform stringent dynamic code testing before putting software on the market.
As the world becomes increasingly networked, corporate competitors and spies, disgruntled employees, and bored teenagers more frequently are invading company and organization computers to steal information, sabotage careers, or just to make trouble. Together, the Internet and the World Wide Web have opened wide a backdoor through which competitors and/or hackers can launch attacks on targeted computer networks. From my own experience, it seems approximately 85 percent of the networks wired to the Internet are vulnerable to such threats. With the growth of the Internet and continued advances in technology, these intrusions are becoming increasingly prevalent. In short, external threats are a real-world problem for any company with remote connectivity.
For those reasons, hackers and tiger teams rely on what's called a TigerBox to provide the necessary tools to reveal security weaknesses; such a box contains tools designed for sniffing, spoofing, cracking, scanning, and penetrating security vulnerabilities. It can be said that the TigerBox is the ultimate mechanism in search of the hack attack.
The most important element of a TigerBox is the operating system foundation. A first-rate TigerBox is configured in a dual-boot setting that includes UNIX and Microsoft Windows operating systems.
Currently, TigerBox utility compilations for Microsoft's OS are not as popular as those for its UNIX counterpart, but Windows is becoming more competitive in this regard. As you know by now, UNIX is a powerful operating system originally developed at AT&T Bell Laboratories for the scientific, engineering, and academic communities. By its nature, UNIX, is a multiuser, multitasking environment that is both flexible and portable, and that offers electronic mail, networking, programming, text-processing, and scientific capabilities. Over the years, two major forms (with numerous vendor variants of each) of UNIX have evolved: AT&T UNIX System V and the University of California at Berkeley's Berkeley Software Distribution (BSD). But it is Linux, the trendy UNIX variant, that is commonly configured on a TigerBox. Linux offers direct control of the O/S command line, including custom code compilation for software stability and flexibility. In fact, most of the exploits in this book can be compiled with Linux.
Currently, Linux is customized, packaged, and distributed by many vendors including: RedHat Linux (www.redhat.com), Slackware (www.slackware.org), Debian (www.debian.org), TurboLinux (www.turbolinux.com), Mandrake (www.linux-mandrake.com), SuSE (www.suse.com), Trinux (www.trinux.org), MkLinux (www.mklinux.org), LinuxPPC (www.linuxppc.org), SGI Linux (http://oss.sgi.com/projects /sgilinuxll), Caldera OpenLinux (www.caldera.com), Corel Linux (http://linux.corel.com), and Stampede Linux (www.stampede.org).
A dual-boot configuration makes it easy to boot multiple operating systems on a single TigerBox. (Note, the Windows complement should be installed and configured prior to Linux.) At the time of this writing, the Windows versions that are most stable and competent include Windows 98 Second Edition and the Millennium Edition (the Windows 2000 Edition was being tested as this book was going to press). The Linux flavor regarded as most flexible and supportive is RedHat Linux (www.redhat.com). And note that if multiboot, third-party products "rub the wrong way," the RedHat installation program now offers the option of making a boot diskette (containing a copy of the installed kernel and all modules required to boot the system). The boot diskette can also be used to load a rescue diskette. Then, when it is time to execute Windows, simply reboot the system minus the boot diskette; or when using Linux, simply reboot with the boot disk, and presto, you will see:
Red Hat Linux release 6.x Kernel on an i586 login:
The inexperienced should use a program such as BootMagic (www.powerquest.com/ products/index.html) by PowerQuest Corporation for hassle-free, multiple boot setup with a graphical interface.
LEGAL RAMIFICATIONS OF USING A TIGERBOX
To the best of my knowledge, the first United States statute that specifically prohibits hacking is the Federal Fraud and Computer Abuse Act of 1986, enacted to fill legislative gaps in previous statutes. Subsection (a) of this act makes it a felony to knowingly access a computer without authorization and to obtain information with the intent to injure the United States or to benefit a foreign nation. This subsection protects any information that has been determined, pursuant to an executive order or statute, to be vital to this nation's national defense or foreign relations. In addition, the 1986 act prohibits unauthorized access of information contained in a financial record or consumer-reporting agency, provided a "federal interest computer'' is involved.
The first successful prosecution under the 1986 act was United States of America v. Robert Tappan Morris (#774, Docket 90-1336. United States Court of Appeals, Second
Circuit. Argued Dec. 4, 1990, Decided March 7, 1991.), which involved a typical hacking offense and its resultant damage.
The defendant was charged and convicted under subsection (a), which makes it a felony to access intentionally any "federal interest" computer without authorization and alter, damage, destroy, or prevent the authorized use of information resulting in the loss of at least $1,000.
In the fall of 1988, Morris was a first-year graduate student in Cornell University's computer science Ph.D. program. Through undergraduate work at Harvard and in various jobs he had acquired significant computer experience and expertise. When Morris entered Cornell, he was given an account on the computer at the Computer Science Division. This account gave him explicit authorization to use computers at Cornell. Morris engaged in various discussions with fellow graduate students about the security of computer networks and his ability to penetrate them.
In October 1988, Morris began work on a computer program, later known as the Internet "worm" or "virus." The goal of this program was to demonstrate the inadequacies of current security measures on computer networks by exploiting the security defects that Morris had discovered. The tactic he selected was the release of a worm into network computers. Morris designed the program to spread across a national network of computers after being inserted at one computer location connected to the network. Morris released the worm into Internet, a group of national networks that connected university, governmental, and military computers around the country. The network permited communication and transfer of information between computers on the network.
Morris sought to program the Internet worm to spread widely without drawing attention to itself. The worm was supposed to occupy little computer operation time, and thus not interfere with normal use of the computers. Morris programmed the worm to make it difficult to detect and read, so that other programmers would not be able to "kill" the worm easily. Morris also wanted to ensure that the worm did not copy itself onto a computer that already had a copy. Multiple copies of the worm on a computer would make it easier to detect and would bog down the system and ultimately cause the computer to crash. Therefore, Morris designed the worm to "ask" each computer whether it already had a copy of the worm. If the computer responded "no," then the worm would copy itself onto the computer; if it responded "yes," the worm would not
duplicate. However, Morris was concerned that other programmers could kill the worm by programming their own computers to falsely respond "yes" to the question. To circumvent this protection, Morris programmed the worm to duplicate itself every seventh time it received a "yes" response. As it turned out, Morris underestimated the number of times a computer would be asked the question, and his one-out-of-seven ratio resulted in far more copying than he had anticipated. The worm was also designed so that it would be killed when a computer was shut down, an event that typically occurs once every week or two. This should have prevented the worm fro m accumulating on one computer, had Morris correctly estimated the likely rate of reinfection.
Morris identified four ways in which the worm could break into computers on the network: (1) through a "hole" or "bug" (an error) in SEND MAIL, a computer program that transferred and received electronic mail on a computer; (2) through a bug in the "finger demon" program, a program that permited a person to obtain limited information about the users of another computer; (3) through the "trusted hosts" feature, which permited a user with certain privileges on one computer to have equivalent privileges on another computer without using a password; and (4) through a program of password guessing, whereby various combinations of letters are tried out in rapid sequence in the hope that one will be an authorized user's password, which is entered to permit whatever level of activity that user is authorized to perform.
On November 2, 1988, Morris released the worm from a computer at the Massachusetts Institute of Technology. MIT was selected to disguise the fact that the worm came from Morris at Cornell. Morris soon discovered that the worm was replicating and reinfecting machines at a much faster rate than he had anticipated. Ultimately, machines at locations around the country either crashed or became "catatonic." When Morris realized what was happening, he contacted a friend at Harvard to discuss a solution. Eventually, they sent an anonymous message from Harvard over the network, instructing programmers how to kill the worm and prevent reinfection. However, because the network route was clogged, the message did not get through until it was too late. Computers were affected at numerous installations, including leading universities, military sites, and medical research facilities. The estimated cost of dealing with the worm at each installation ranged from $200 to more than $53,000.
Morris was found guilty, following a jury trial, of violating 18 U.S.C. Section 1030(a)(5)(A). He was sentenced to three years of probation, 400 hours of community service, a fine of $10,050, and the costs of his supervision.
The success of this prosecution demonstrated that the United States judicial system can and will prosecute domestic computer crimes that are deemed to involve national interests.
That said, the federal government to date has been reluctant to prosecute under the 1986 act, possibly because most state legislatures have adopted their own regulations, and Congress is hesitant before usurping state court jurisdiction over computer related crimes. Therefore it is a good idea to become familiar with local legislative directives as they pertain to discovery, hacking, and security analysis.
Hardware requirements depend on the intended usage of the TigerBox. For example: Will the system be used for programming? Will the system serve as a gaming PC? Currently, the minimum requirements, to accommodate most scenarios, include the following:
• Processor: Pentium 160+.
• RAM: 64 MB.
• HDD: 8 GB.
• Video: Support for at least 1024 x 768 resolution at 16 K colors.
• Network: Dual NICs, at least one of which supports passive or promiscuous mode. (When an interface is in promiscuous mode, you are explicitly asking to receive a copy of all packets, whether addressed to the TigerBox or not.)
• Other: Three-button mouse, CD-ROM, and floppy disk drive.
Introduction to TigerSuite
Designed using proprietary coding and technologies, TigerSuite is a compilation of everything you need to conduct a professional security analysis; that is, hacking to discover, scan, penetrate, expose, control, spy, flood, spoof, sniff, infect, report, monitor, and more. In a 9/2000 benchmark comparison conducted by ValCom Engineers (www.pccval.com), between TigerSuite and other popular commercial discovery/scan software, for a simple 1,000-port scan, Tiger Tools completed an average scan in less than one minute, compared to an average of 35 minutes with the same results found in both scans. Their overall viewpoint simply states, the design and developed product are awesome.
Installation
TigerSuite can be activated using one of two methods: local or mobile. The local method requires a simple installation from the CD-ROM. The mobile method involves a new technological feature that allows TigerSuite to be run directly from the CD. Utilizing portable library modularization techniques, the software is executed from the CD by running the main program file, TSmobile.EXE. This convenient feature permits the conventions of software without modifying a PC configuration and/or occupying essential hard disk space.
Local Installation Method
The TigerSuite local installation process takes only a few minutes. The Setup program (included on this book's CD) automatically installs, configures, and initializes a valuation of the tool suite.
The minimum system requirements for the local installation process are as follows:
• Operating System: Windows NT Workstation 4.0, Windows NT Server 4.0, Windows NT Server 5.0, Windows 95, Windows 98, Millennium Edition, or Windows 2000
• Operating System Service Pack: Any
• Processor: Pentium or better
• Memory: 16 MB or more
• Hard Drive Space: 10 MB free
• Network/Internet Connection: 10BASET, 100BASET, Token Ring, ATM, xDSL, ISDN, cable modem, or regular modem connection using the TCP/IP protocol
The installation process can be described in six steps:
1. Run TSsetup.EXE. When running the Setup program, the application must first unpack the setup files and verify them. Once running, if Setup detects an existing version of TigerSuite, it will automatically overwrite older files with a newer upgrade. A welcome screen is displayed (see Figure 12.1).
2. Click Next to continue.
3. Review the Licensing Agreement. You must accept and agree to the terms and conditions of the licensing agreement, by clicking Yes, to complete the Setup process. Otherwise, click No to exit the Setup. The following is an extract from this policy:
This software is sold for information purposes only, providing you with the internetworking knowledge and tools to perform professional security audits. Neither the developers nor distributors will be held accountable for the use or misuse of the information contained. This software and the accompanying files are sold "as is" and without warranties as to performance or merchantability or any other warranties whether expressed or implied. While we use reasonable efforts to include accurate and up-to-date information, it makes no representations as to the accuracy, timeliness, or completeness of that information, and you should not rely upon it. In using this software, you agree that its information and services are provided "as is, as available" without warranty, express or implied, and that you use this at your own risk. By accessing any portion of this software, you agree not to redistribute any of the information found therein. We shall not be liable for any damages or costs arising out of or in any way connected with your use of this software. You further agree that any developer or distributor of this software and any other
parties involved in creating and delivering the contents have no liability for direct, indirect, incidental, punitive, or consequential damages with respect to the information, software, or content contained in or otherwise accessed through this software.
4. Enter user information (see Figure 12.2). Simply enter your name and/or company name, then click Next to continue.
5. Verify the installation path (see Figure 12.3). If you wish to change the path where Setup will install and configure TigerSuite, click Browse and choose the path you wish to use. Click Next to continue.
6. File copy verification. At this point, Setup has recorded the installation information and is ready to copy the program files. Setup also displays a synopsis of the Target Location and User Information from previous steps. Click Back if you want to change any settings, or click Next to have Setup start copying the program files. Setup will monitor the file copy process and system resources (as shown in Figure 12.4). If Setup runs into any problems, it stops running and displays an alert.
When Setup is finished, TigerSuite can be executed by following the directions in the "Mobile
Figure 12.4 Monitoring the file copy process. Mobile Installation Method
To invoke TigerSuite directly from the CD, follow these steps:
1. Run the TSmobile.EXE file. The program will initialize and commence (as shown in Figure 12.5) as if previously installed with the Setup program just described. (When TigerSuite is installed locally, selecting the file from Start/Programs/TigerSuite/TS will start the main program module.) At this time TigerSuite will initialize itself for your system and place itself as a background application, displayed in the taskbar.
2. Click on the mini TigerSuite icon in the taskbar, typically located next to the system time, to launch the submenu of choices (see Figure 12.6). Note: Closing all open system modules does not shut down TigerSuite; it closes only open System Status monitoring and information modules. To completely exit TigerSuite, you must shut down the service by selecting Exit and Unload TigerSuite from the submenu.
Program Modules
The program modules consist of system status hardware and internetworking analyses tools, designed to provide system, networking, and internetworking
status and statistics, before, during, and after a security analysis. Furthermore, these tools serve as invaluable counterparts to the TigerBox Toolkit (described shortly), by aiding successful and professional security audits.
System Status Modules
The System Status modules can be activated by clicking on the mini TigerSuite icon in the taskbar, then on System Status from the submenu of choices (see Figure 12.7).
The Hardware category (Figure 12.8) maintains these System Status modules: Cmos Contents, Drives (Disk Space and Volume guides), and finally, Memory, Power, and Processor monitors. The Internetworking category includes the following statistical network sniffers: IP, ICMP, Network
Parameter, TCP, and UDP.
The Hardware modules are defined as follows:
CMOS Contents (Figure 12.9). This module reports crucial troubleshooting information from the system CMOS (nonvolatile RAM). CMOS, abbreviation of complementary metal oxide semiconductor, is the semiconductor technology used in the transistors manufactured into computer microchips.) An important part of configuration troubleshooting is the information recorded in CMOS, such as device detail regarding characteristics, addresses, and IRQs. This component is helpful when gathering information prior to installing a TigerBox-compatible operating system.
Drives: Disk Space and Volume Info (Figure 12.10). These modules report important data statistics about the current condition of hard drive
disk space and volume data. The information provided here facilitates a partitioning scheme before installing a TigerBox-compatible operating system.
• Memory Status, Power Status, and Processor Info (Figure 12.11). These modules provide crucial memory, power, and processor status before, during, and after a security analysis and/or penetration-testing sequence. From the data gathered, an average baseline can be predicted in regard to how many threads can be initialized during a scanning analysis, how many discovery modules can operate simultaneously, how many network addresses can be tested at one time, and much more.
System Status Internetworking Modules
The System Status Internetworking sniffer modules can be activated by clicking on the mini TigerSuite icon in the taskbar, then System Status, and finally Internetworking, from the submenu of choices (Figure 12.12). Recall that a network sniffer can be an invaluable tool for diagnosing
network problems—to see what is going on behind the scenes, so to speak—during communication between hosts and nodes. A sniffer captures the data coming in and going
out of the network interface card (NIC) or modem and displays that information in a table. The Internetworking modules are defined as follows:
IP Stats (Figure 12.13). This module gathers current statistics on interface IP routes, datagrams, fragments, reassembly, and header errors. Remember, IP is a protocol designed to interconnect networks to form an Internet to pass data back and forth. It contains addressing and control information that enable packets to be routed through this Internet. The equipment that encounters these packets, such as routers, strip off and examine the headers that contain the sensitive routing information. These headers are then modified and reformulated as a packet to be passed along. IP datagrams are the primary information units in the Internet. The IP's responsibilities also include the fragmentation and reassembly of datagrams to support
links with different transmission sizes. Packet headers contain control information (route specifications) and user data. This information can be copied, modified, and/or spoofed.
• window is implemented to make stream transmissions more efficient. The sliding window, often termed ''the handshake process," uses bandwidth more effectively, as it will allow the transmission of multiple packets before an acknowledgment is required. TCP flooding is a common form of malicious attack on network interfaces; as a result, this module was developed to monitor and verify such activity.
• UDP Stats (Figure 12.16). UDP provides multiplexing and demultiplexing between protocol and application software. Multiplexing is the term used to describe the method for multiple signals to be transmitted concurrently into an input stream, across a single physical channel. Demultiplexing is the separation of the streams that have been multiplexed back into multiple output streams. Multiplexing and demultiplexing, as they
pertain to UDP, transpire through ports. Each station application must negotiate a port number before sending a UDP datagram. When UDP is on the receiving side of a datagram, it checks the header (destination port field) to determine if it matches one of the station's ports currently in use. If the port is in use by a listening application, the transmission proceeds. If the port is not in use, an ICMP error message is generated, and the datagram is discarded. Other common flooding attacks on target network interfaces involve UDP overflow strikes. This module monitors and verifies such attacks for proactive reporting and testing successful completions.
TigerBox Toolkit
Accessing the TigerBox toolkit utilities is a simple matter of clicking on the mini TigerSuite icon in the taskbar, then TigerBox Toolkit, and finally Tools from the submenu of choices (as shown in Figure 12.17).
TigerBox Tools
The TigerBox tools described in this section were designed for performing serious network discoveries; they include modules that provide finger, DNS, hostname, NS lookup, trace route, and Whois queries. Each tool is intended to work with any existing router, bridge, switch, hub, personal computer, workstation, and server. Detailed discovery reporting, compatible with any Web browser, make these tools an excellent resource for inventory, and management as well. As declared in previous chapters, the output gathered from these utilities is imperative for the information discovery phase of a professional security assessment.
Finger Query. A finger query is a client daemon module that inquires a finger-d (finger daemon) that accepts and handles finger requests. If an account can be fingered, inspecting the account will return predisposed information, such as the real name of the account holder, the last time he or she logged in to that account, and sometimes much more. Typically, .edu, .net, and .org accounts utilize finger server daemons that can be queried. Some accounts, however, do not employ a finger server daemon due to host system security or operational policies. Finger daemons have become a popular target of NIS DoS attacks because the standard finger daemon will willingly look for similar matches.
DNS Query (Figure 12.18). The DNS is used primarily to translate between domain names and their IP addresses, and to control Internet email delivery, HTTP requests, and domain forwarding. The DNS directory service consists of DNS data, DNS servers, and Internet protocols for fetching data from the servers. The records in the DNS directory are split into files called zones. Zones are kept on authoritative servers distributed all over the Internet, which answer queries according to the DNS network protocol. Also, most servers are authoritative for some zones and perform a caching function for all other DNS information. This module performs DNS queries for the purpose of obtaining indispensable discovery
information; usually one of the first steps in a hacker's course of action. DNS resource record types include:
A: Address. Defined in RFC 1035.
AAAA: IPv6 Address. Defined in RFC 1886.
AFSDB: AFS Database location. Defined in RFC 1183.
CNAME: Canonical Name. Defined in RFC 1035.
GPOS: Geographical position. Defined in RFC 1712. Obsolete.
HINFO: Host Information. Defined in RFC 1035.
ISDN. Defined in RFC 1183.
KEY: Public Key. Defined in RFC 2065.
KX: Key Exchanger. Defined in RFC 2230.
LOC: Location. Defined in RFC 1876.
MB: Mailbox. Defined in RFC 1035.
MD: Mail destination. Defined in RFC 1035. Obsolete.
MF: Mail forwarder. Defined in RFC 1035. Obsolete.
MG: Mail group member. Defined in RFC 1035.
MINFO: Mailbox or mail list information. Defined in RFC 1035.
MR: Mail rename domain name. Defined in RFC 1035.
MX: Mail Exchanger. Defined in RFC 1035. NS: Name Server. Defined in RFC 1035.
NSAP: Network Service Access Point Address. Defined in RFC 1348. Redefined in RFC 1637 and
1706.
NSAP-PTR: Network Service Access Protocol. Defined in RFC 1348. Obsolete.
NULL. Defined in RFC 1035.
NXT: Next. Defined in RFC 2065. PTR: Pointer. Defined in RFC 1035.
PX: Pointer to X.400/RFC822 information. Defined in RFC 1664.
RP: Responsible Person. Defined in RFC 1183.
RT: Route Through. Defined in RFC 1183.
SIG: Cryptographic signature. Defined in RFC 2065. SOA: Start of Authority. Defined in RFC 1035. SRV: Server. Defined in RFC 2052.
TXT: Text. Defined in RFC 1035.
WKS: Well-Known Service. Defined in RFC 1035.
X25. Defined in RFC 1183.
An example DNS query request for one of the most popular Internet search engines, Yahoo (http://www.yahoo.com), would reveal:
->>HEADER<<- opcode: QUERY, status: NOERROR, id: 13700 ;; flags: qr rd ra; QUERY: 1, ANSWER: 7, AUTHORITY: 3, ADDITIONAL: 19 yahoo.com, type = ANY, class = IN
yahoo.com. yahoo.com. yahoo.com. yahoo.com. yahoo.com. yahoo.com. yahoo.com. yahoo.com.
12h44m31s IN NS NS3.EUROPE.yahoo.com. 12h44m31s IN NS NS1.yahoo.com. 12h44m31s IN NS NS5.DCX.yahoo.com.
23m3s IN A 204.71.200.243 23m3s IN A 204.71.200.245
3m4s IN MX 1 mx2.mail.yahoo.com. 3m4s IN MX 0 mx1.mail.yahoo.com.
12h44m31s IN NS NS3.EUROPE.yahoo.com.
yahoo.com. 12h44m31s IN NS NS1.yahoo.com.
yahoo.com. 12h44m31s IN NS NS5.DCX.yahoo.com.
NS3.EUROPE.yahoo.com. 1h13m23s IN A 194.237.108.51 NS1.yahoo.com. 7h18m19s IN A 204.71.200.33
• IP/Hostname Finder. This module is very simple to use for querying the Internet for either a primary IP address, given a hostname, or vice versa. The particular usage for this module is to quickly determine the primary address or hostname of a network during the discovery phases. Just enter in the hostname, for example, www.yahoo.com and click Get IP Address, as shown in Figure 12.19.
• NS Lookup. This module is an advanced cohort of the IP/Hostname Finder just described, as it will search for multiple secondary addresses in relation to a single hostname, as shown in
Figure 12.20.
• Telnet Session. Before there were Web browsers with graphical compilers, or even the World Wide Web, computers on the Internet communicated by means of text and command-line control using telnet daemons. Typically, you gained access to these hosts from a "terminal," a simple computer directly connected to the larger, more complex "host system." Telnet software is "terminal emulator" software; that is, it pretends to be a terminal directly connected to the host system, even though its connection is actually made through the Internet (customarily through TCP port
23). Recall using telnet to verify a router's virtual administration interface: This module was designed to help perform discovery functions, such as verifying router administration interfaces, connecting to a mail server's SMTP and POP ports, and much more.
Trace Route (Figure 12.21). Trace route displays the path for data traveling from a sending node to a destination node, returning the time in milliseconds and each hop count in between (e.g., router and/or server). Tracing a route is typically a vital mechanism for troubleshooting connectivity problems. A hacker would use this command to discover various networks between his or her TigerBox and a specific target, as well as potentially to ascertain the position of a firewall or filtering device.
WhoIs Query (Figure 12.22). This module is a target discovery Whois that acts as a tool for looking up records in the NSI Registrar database. Each record within the NSI Registrar database has a unique identifier assigned to it: a name, a record type, and various other fields. To use Whois for a domain search, simply type in the domain you are looking for. If the domain you are searching for is not contained within the NSI
Registrar Whois database, Whois will access the Shared Registry System and the Whois services of other remote registrars to satisfy the domain name search.
TigerBox Scanners
The idea behind scanning is to probe as many ports as possible, keeping track of the ones that are receptive or useful to a particular need. A scanner program reports these receptive listeners, which can then be used for weakness analysis and further explication. The scanners in this section were designed for performing serious network-identified and stealth discoveries; it contains the following modules: Ping Scanner, IP Range Scan, IP Port Scanner, Network Port Scanner, Site Query Scan, and Proxy Scanner.
The TigerBox Toolkit scanners can be launched by clicking on the mini TS icon in the taskbar, then TigerBox Toolkit, and finally, Scanners, as shown in Figure 12.23.
A subinstruction module common to all scanners is activated by a right- click over
Here are the scanner descriptions:
Ping Scanner. Recall that Ping sends a packet to a remote or local host, requesting an echo reply. If the echo is returned, the node is up, and at the very least, listening to TCP port 7; therefore, it may be vulnerable to a Ping flood. If the echo is not returned, it can indicate that the node is not available, that there is some sort of network trouble along the way, or that there is a filtering device blocking the echo service. As a result, Ping is a network diagnostic tool that verifies connectivity. Technically, Ping sends an ICMP echo request in the form of a data packet to a remote host, and displays the results for each echo reply. Typically, Ping sends one packet per second, and prints one line of output for every response received. When the program terminates, it displays a brief summary of round-trip times and packet-loss statistics. This module is designed for a custom-identified or half-stealth Ping scan, indicating the time-out, size, and Ping count.
IP Range Scan (Figure 12.25). This module is essentially an advanced discovery Ping scanner. It will sweep an entire range of IP addresses and report nodes that are active. This technique is one of the first performed during a target network discovery analysis.
IP Port Scanner/Network Port Scanner (Figure 12.26). These modules perform custom single IP and multiple network IP address range port scanning, respectively. In a comparison between TigerSuite and popular commercial discovery scan software, for a simple 10,000-port Class C network scan, TigerSuite finished in less than 9 minutes, in contrast to an average 65 minutes from the other packages, with the same results.
Site Query Scan/Proxy Scanner. The main purpose of these modules is to take the guesswork out of target node discovery. These scanning techniques complete an information query based on a given address or hostname. The output field displays current types and versions for the target
operating system, FTP, HTTP, SMTP, POP3, NNTP, DNS, Socks, Proxy, telnet, Imap, Samba,
SSH, and/or finger server daemons. The objective is to save hours of information discovery to allow more time for penetration analysis.
Vulnerability penetration testing of system and network security is one of the only ways to ensure that security policies and infrastructure protection programs function properly. The TigerSuite penetration modules are well designed to provide detailed penetration attacks that test strengths and weaknesses by locating security gaps. These hacking procedures offer an in-depth assessment of potential security risks that may exist internally and externally.
The TigerBox Toolkit penetrators can be launched by clicking on the mini TS icon in the taskbar, then TigerBox Toolkit, and finally, Penetrators, as shown in Figure 12.27. The software modules found in this submenu include: Buffer Overloader, FTP Cracker, FTP Flooder, HTTP Cracker, HTTP Flooder, Mail Bomber, Mail Cracker, Password Crackers, Ping Flooder, Server-Side Crasher, Spammer, TigerBreach Penetrator, and WinCrasher.
TigerBox Simulators
For penetration technique testing, the TigerSim Virtual Server Simulator will shorten your learning curve. Using TigerSim, you can simulate your choice of
network server daemon, whether it be email, HTTP Web page serving, telnet, FTP, and more.
The TigerBox Toolkit penetrators are accessed by clicking on the mini TS icon in the taskbar, then TigerBox Toolkit, and finally, Simulators, as shown in Figure 12.28.
As part of TigerSuite and a TigerBox, the server simulator requirements are the same:
• Processor: Pentium 160+
• RAM: 64 MB
• HDD: 8 GB
• Video: Support for at least 1024 x 768 resolution at 16K colors
• Network: Dual NICs, at least one of which supports passive or promiscuous mode
• Other: Three-button mouse, CD-ROM, and floppy disk drive
Upon execution, individual TigerSim virtual servers can be launched from the main control panel. For example, Figure 12.29 shows that the HTTP Web Server daemon has been chosen and connected with Netscape.
The Session Sniffer field indicates the communication transaction sequences as reported by the virtual Web server. This is useful for monitoring target penetrations and verifying spoofed techniques, recording hack trails, and much more. The Script field, on the other hand, allows for instant replies, hack script uploads, and more to the hacking station or TigerBox (see Figure 12.30).
Sample Real-World Hacking Analysis
Chapters 5-9 described the techniques relevant to the first few phases of a security audit, through the discovery process of a target company, XYZ, Inc. In this section we will re-create our findings with TigerSuite, and further probe for susceptibility to penetration.
Hackers The findings in this analysis have been completely altered to protect the target Note1*" company's real name and network.
We'll start only with our TigerBox running TigerSuite, various tools described in this book, access to the Internet, and the given target (XYZ, Inc).
Step 1: Target Research
As part of the target research phase of our hack, we'll employ the following techniques: Internet search, Whois query, company Web site investigation for employee names and/or email addresses, and finally an Underground search for previous hacks, cracks, or tipoffs involving our target.
In Chapter 5, we ascertained the importance and defined the procedures of Whois. Moving forward, things will become easier with the TigerSuite WhoIs Query module, featuring XYZ, Inc. To get underway, we'll open our browser and perform an Internet search for our target domain using leading engines such as: Yahoo (www.yahoo.com), Lycos (www.lycos.com), AltaVista (www.altavista.com), Excite (www.excite.com), InfoSeek (http://infoseek.go.com), LookSmart (www.looksmart.com), Thunderstone (http://search.thunderstone.com), and Netscape (http://search.netscape.com), as illustrated in Figure 12.31.
Once we have our target domain (www.xyzinc.net), we click on the TigerSuite icon in the taskbar, followed by the submenu options TigerBox Toolkit/Tools/WhoIs Query. With the WhoIs Query program, we'll look up this domain from Network Solutions (domain-related information for North America), as shown in Figure 12.32.
As you might have deduced, the significant discovery information from this query includes the administrative contact and domain servers:
Administrative Contact, Technical Contact: hostmaster@xyzinc.net
Domain servers listed in order: NS1.XYZINC.NET 206.0.139.2
NS2.XYZINC.NET 206.0.139.4
We'll note this information, as it will come in handy during the next few steps.
The next part of our target research incorporates detailed target domain Web site inspections. At this point, hackers browse for information ''oversights" in Web pages to supplement their research. These oversights include network diagram extracts, server platform references, personal email address postings, data center locations, phone number prefixes, and so forth. It is surprising how many corporate sites brag about their security by listing the platform and firewall type. Let's visit www.xyzinc.net and further scrutinize for any potential giveaways (see Figure 12.33).
Our sample analysis will exploit common vulnerabilities found in the majority of current site designs. The contact page shown in Figure 12.33 is an exam
ple that specifies three notable research breaches: a contact name, email address, and hint of Web server daemon. We'll add this information to our previous discoveries, then venture forth.
Hackers use many clever practices to research targets, each uniquely formulated for a specific style. To hammer home this point, we'll search the Underground for previous hacks, cracks, or tipoffs involving our target, starting with the infamous Underground gateway AstaLaVista (www.astalavista.com), shown in Figure 12.34. AstaLaVista is renowned as one of the official Underground site-listing spiders. But using these search engines, we do not come across any relevant Tom Friedman of Public Relations
• Email: pr@xyzinc.net
• Potential Web Server Daemon:
• Microsoft Internet Information Server (IIS)
We'll start this step by resolving the target domain name to an IP address using TigerSuite TigerBox Toolkit/Tools/IP/Hostname Finder (see Figure 12.35).
Because the domain and name server IP addresses are all part of the same network, we can assume the target perimeter network consists of a Class C network with the address block 206.0.139.0/24. With this in mind, the remaining discovery modules can be executed in any particular order, but we'll move forward with a TigerSuite TigerBox Toolkit/Scanners/Site Query Scan, illustrated in Figure 12.36.
As we anticipated, the target Web server daemon is IIS, Version 4.0, and it's residing on an NT server using HTTP Version 1.1. Remember the IIS vulnerability attacks discussed in Chapter 9? These exploits can be practical assessments for potential Web page hacking.
Let's continue with target IP address and port scans. Assuming a Class C network block, we'll use the TigerSuite TigerBox Toolkit/Scanners/IP Range Scan to verify our active addresses and possibly to uncover other listening nodes (see Figure 12.37).
With these findings, a hacker would consider our target administrator to be a "lamer," basically an ignorant or inexperienced IS technician—whose job may be in jeopardy if these potentially vulnerable nodes contain security breaches. More important, we'll carefully note the following:
Host IP DNS Resolution
Address
206.0.139.8 mtopel.xyzinc.net
206.0.139.89 kflippel.xyzinc.net
Chances are that these are usernames, possibly those belonging to IS technicians who opened some firewall test ports for their nodes. This leads to the conclusion that two additional email addresses have been uncovered: mtopel@ xyzinc.net and kflippel@xyzinc.net. The most obvious step a hacker would take next would be to invoke this TigerSuite module: TigerBox
Toolkit/Scanners/IP Port Scanner. For conciseness, only pertinent extractions from each scan are shown in Figure 12.38.
Clearly, the network administrators responsible for the security of this particular network have overlooked monumental, gaping holes. Let's see what the next step, some social engineering, reveals.
Step 3: Social Engineering
Previous chapters described various forms of social engineering techniques that are commonly used by hackers all over the world. In this example we have exposed more than enough vulnerabilities to cause pandemonium for the defenseless xyzinc.net. For the purposes of this discussion, however, we will delve into the most devious stealthy penetration of them all: the Backdoor Mail Spam.
This attack outlines a hacking method to gain, retain, and cover access to a target system. Using TigerSuite Penetrator Spammer or others as mentioned in Chapter 8, and found on this book's CD, this infiltration is bound with a spammed e-message and a backdoor attachment to the following addresses:
hostmaster@xyzinc.net pr@xyzinc.net mtopel@xyzinc.net kflippel@xyzinc.net
We'll send both Windows and UNIX backdoor kit attachments to each of these addresses, even though the two subsequent email addresses doubtless are from UNIX apprentices, as determined from prior port scan results. We'll
spoof these messages with subjects such as Domain Update Utility, from their upstream providers, and/or Press Kit Release, from a prestigious public relations firm, for example. Remember, all it takes is for one user to execute the spoofed backdoor attachment.
Step 4: Hack Attacks
Before attempting to utilize a penetrator from TigerSuite, or hack attacks from previous chapters, it's a good idea to practice with the TigerSim Virtual Server Simulator, as well as with the TigerSuite System Status Monitors (see Figure 12.39). Together, these will ensure proper system resource usage and optimum use of the TigerBox, and will aid in successful penetration attempts.
Conclusion
The topic of network security is currently receiving a lot of attention in the media, especially since the CIA, FBI, and the White House have all been successfully hacked. Recent studies indicate that the cost to corporate America for each incident of network break-ins is in the hundreds of thousands of dollars. What does this all mean?
Even to a nontechnical observer, it is obvious that if government agencies can be hacked, the possibility for network intrusion in a corporate environment is very real. Though the necessary information for protecting a corporate enterprise is available, few understand it; and fewer, beyond large corporations with deep pockets, can afford to pay computer security experts and security auditors to check (and double-check) to absolutely ensure that their data is secure. The need for knowledge in this area is critical and immediate. Without question, network administrators and corporate information officers must gain a better understanding of the technologies, techniques, and tools being used to gain unauthorized access to company networks. The key to stopping these intruders is thorough knowledge of their environment.
As stated in the Introduction to this book, this book was written for those administrators just described, as well as for other IT professionals. The objective of this book was to provide this audience with a solid understanding of network communications and security, not just for the purposes of revealing the secrets of hacking, but to lay the foundation for understanding the characteristics of the security threat.
The main focus of this book was to heighten awareness. Network hacking is an everyday phenomenon that can no longer be ignored or handled haphazardly. Too many network administrators are experiencing anomalies in their networks that they can't explain. Server crashes, email loss, data loss, virus invasions, and other network problems raise unanswered questions and cause an enormous amount of resource hours to fix. Network downtime is an event every organization wants to avoid.
One cause of such events is a network hack attack. How does a company prevent such access? A sound, well-planned network security policy and complementary tools are the answer. Unfortunately, many companies do not have the knowledge, resources, or reference material to implement such a policy. To meet that need, this book also explored a dynamic approach to network security by outlining the known technological advances used to break into a private or public network.
At this juncture you are no doubt eager to get to the next stage, which is to defend against weakness penetration by becoming a security prodigy. You'll accomplish this and more by continuing with the companion to this book, Hack Attacks Denied. See you there.
IP Reference Table and Subnetting Charts
The IP reference table and subnetting charts in Tables A.1-A.4 can be used for quick stats and calculation values. Sub net numbers and hosts can be obtained quickly via subnet mask bit count. For your convenience, the major IP Address classes have been categorized.
Table A.1 IP Address Classes
FIRST OCTET
OR OCTETS AS
CLASS SERIES NETWORK VS. HOST NETMASK BINARY
1111 1111 0000 0000 0000 0000 0000
0000
A 1 - 126 Network.Host.Host.Host or
255.0.0.0
1111 1111 1111 1111 0000 0000 0000
0000
B 128 - 191 Network.Network.Host.Host or
255.255.0.0
1111 1111 1111 1111 1111 1111 0000 0000
C 192 - 223 Network.Network.Network.Host or
255.255.255.0
D Defined for multicast operation; not used for normal operation.
E Defined for experimental use; not used for normal operation.
Table A.2 Class A
BITS
SUBNET MASK
NUMBER OF SUBNETS
NUMBER OF HOSTS
/8
255.0.0.0
0
16777214
/9
255.128.0.0
2 (0)
8388606
/10
255.192.0.0
4 (2)
4194302
/11
255.224.0.0
8 (6)
2097150
/12
255.240.0.0
16 (14)
1048574
/13
255.248.0.0
32 (30)
524286
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment