4. The Reference Intrusion Model

With Part I's theory and deployment issues behind us, we can turn to the products that collect full content, session, statistical, and alert data, along with tools that analyze packets and strain detection software. All of the tools discussed in Part II are open source and available at no cost on the Internet. All of them have been tested on FreeBSD 4.9 RELEASE, although most if not all will work on other UNIX-like operating systems (Linux, Solaris, and so on). With only a few exceptions, all of the tools are available as ports and packages for FreeBSD, ensuring simple installation and maintenance.

To provide a consistent set of data for these tools to manipulate, in this chapter I present a reference intrusion model that will be used in the discussions of tools in Chapters 5 through 10. Think of this as a case study, except that I describe what happens in the attack before showing any traffic. (The traffic traces for the intrusion are posted at the book's Web site at http://www.taosecurity.com; feel free to analyze them with the tools presented in Part II.) The purpose of this case study is not to demonstrate the latest and greatest intrusion methods. Rather, I wanted to give you a variety of malicious activities to investigate.

The Scenario

The scenario for the reference intrusion model involves compromise and other malicious actions by an external party. Each of the tools described in Part II will yield different insights into the intrusion.

The victim of this contrived intrusion is CHM Plans, a fictious developer of high-technology products. CHM stores the plans for its new fixed-rotor-capable helicopter on a development server on its internal network.¹ Access to the internal network is protected by a firewall. CHM's network includes a DMZ with several servers, one of which offers FTP access. CHM does a good job restricting access from the Internet to its internal systems, but it is lax in securing the internal network from systems in the DMZ. Along with poor network management practices, this carelessness will prove CHM's undoing.

Because of the limitations inherent with creating sample intrusions, I used certain conventions regarding IP addresses. In the scenario, systems with IP addresses in the 172.27.20.0/24 subnet should be considered “foreign.” Although they share the same class C space, think of them as being scattered across the public Internet. The 192.168.60.0/24 address space is used by the victim's DMZ. The 10.10.10.0/24 space is used for CHM's internal network. We'll see a diagram of CHM's network later in Figure 4.3.

The Attack

A foreign competitor to CHM called Dragos Designs decides it will steal the plans to CHM's experimental vehicle. Dragos hires a black hat named Ardala to break into the CHM network and acquire the sensitive information Dragos desires. After bribing a low-paid, disgruntled CHM employee, Ardala acquires important information about the CHM network, including details of the development server that hosts the vehicle plans. She learns that CHM reuses accounts and passwords on many of its systems. The CHM traitor promises Ardala he will reactivate a previously disabled development FTP server and place it in CHM's DMZ. While the FTP server will not house sensitive information, it will give Ardala the stepping-stone she needs to move deeper into the CHM network.

Ardala begins her exploitation of CHM by scanning its DMZ for systems that offer services on ports 21 and 22 TCP, which correspond to the FTP control channel and Secure Shell, respectively. She conducts the reconnaissance from 172.27.20.4, one of many stepping-stones she owns across the Internet. She finds that CHM servers 192.168.60.3 and 192.168.60.5 offer some of the desired services: 192.168.60.3 offers port 22 TCP, and 192.168.60.5 offers ports 21 and 22 TCP (see Figure 4.1).

Figure 4.1. Reconnaissance from 172.27.20.4 to the victim's DMZ

The operating system fingerprint reveals that 192.168.60.5 is running an old Linux kernel. Ardala concludes this is the system the CHM traitor deployed for the express purpose of providing a chink in CHM's armor. She launches an exploit against port 21 TCP from a new system, 172.27.20.3. The exploit succeeds and yields remote root interactive access on 192.168.60.5 (see Figure 4.2). Figure 4.3 explains Ardala's actions thus far.

Figure 4.2. Exploiting 192.168.60.5 from 172.27.20.3

Figure 4.3. CHM network scanned and exploited by Ardala

Once Ardala obtains interactive access on 192.168.60.5, she takes several actions to reinforce and consolidate her position. First she copies the /etc/passwd and /etc/shadow files to the /tmp directory and places a copy of the system's entire file system listing in /tmp. She then connects to her drop site, 172.27.20.5, via FTP. She places the password files and directory listing on her FTP server and retrieves two tools: Server.c and Datapipe. Server.c is the server component of the Mstream distributed denial-of-service (DDoS) tool.² Datapipe is a simple port-forwarding application that takes input on one socket and sends it to another.³

While Ardala enjoys the remote interactive access she's acquired on 192.168.60.5, her shell does not have the appearance or robust nature of a normal session. Figure 4.4 displays the sort of commands run in the shell. She does not see many error messages, and when Ardala connects to the FTP server she sees only a few of its replies. Ardala needs to move beyond this level of interactivity and acquire a more normal shell. Besides, anyone inspecting traffic on port 21 TCP will see her commands passed in the clear. It would be better for her purposes to use the Secure Shell daemon already present on 192.168.60.5 and 192.168.60.3, assuming she can gain access to the second system.

Figure 4.4. Working through the exploit shell on 192.168.60.5

After finishing her FTP session, Ardala adds two new accounts to 192.168.60.5. The first is murdoc, a user with user ID 0. This indicates murdoc will have root-level access on the victimized server. She also creates user pete, who has normal privileges. Ardala guesses that using 192.168.60.5's built-in Secure Shell server prevents remote logins for root-level accounts. Therefore, when she next connects to the system, she'll log in as pete and then switch users with su to murdoc. Figure 4.5 shows Ardala's progress at this point.

Figure 4.5. Pillaging 192.168.60.5 and transferring files to 172.27.20.5

With the password files in her hands, Ardala begins cracking them to further leverage her network access. With her new accounts ready on 192.168.60.5, she abandons the creaky FTP exploit shell. She connects via Secure Shell from 172.27.20.105 to 192.168.60.5 as user pete. Once on 192.168.60.5, she switches to user murdoc and revels in her root access. She compiles Server.c and activates it.

Checking the progress of her distributed password-cracking system, she finds several accounts have already yielded suitable credentials. Ardala decides to try them on 192.168.60.3 and eventually succeeds in logging in to that system. By once again using Secure Shell, Ardala is confident her activities are hidden from prying eyes. On 192.168.60.3 Ardala connects back to 172.27.20.5 to retrieve Server.c and Datapipe (see Figure 4.6).

Figure 4.6. Jumping from 192.168.60.5 to 192.168.60.3

After compiling Server.c, Ardala decides to run Datapipe on 192.168.60.3. Because Datapipe is already compiled, she activates it with the following syntax:

datapipe 53 3389 10.10.10.3

This tells Datapipe to listen on port 53 TCP and send any connections to that port to port 3389 TCP on 10.10.10.3. Because CHM allows connections from its DMZ to internal systems on its 10.10.10.0/24 network, Ardala plans to exploit this design flaw. She learned from the CHM traitor that the company houses its secret plans on 10.10.10.3, a Windows system that offers Terminal Services. Ardala plans to cruise in through port 53 TCP, bounce off 192.168.60.3, and land inside CHM's network.

Ardala is now ready to execute the main thrust of her plan. She has already set up a separate instance of Datapipe on one of her stepping-stones, 172.27.20.3. This system is configured to take connections to its port 3389 TCP and send them to port 53 TCP on 192.168.60.3. This allows Ardala to use Tsgrinder against 10.10.10.3 via redirection through 172.27.20.3 and 192.168.60.3.

Tsgrinder is a program that implements brute-force techniques to crack usernames and passwords on systems running Microsoft Terminal Services.⁴ Ardala feeds usernames and passwords stolen from DMZ systems into Tsgrinder. While brute-forcing accounts on 10.10.10.3 through 172.27.20.3 and 192.168.60.3, Ardala sees the results shown in Figure 4.7.

Figure 4.7. Launching Tsgrinder against 10.10.10.3 through 172.27.20.3 and 192.168.60.3

Eventually Ardala's plan achieves its goal. She correctly guesses the administrator password on 10.10.10.3 and uses her own Terminal Services client to connect to the system. She bounces through 192.168.60.3 from another stepping-stone because her Terminal Services client allows her to specify port 53 TCP on 192.168.60.3. (She used Datapipe on 172.27.20.3 in conjunction with Tsgrinder because Tsgrinder doesn't accept a user's input regarding target port.)

Once she is interacting with 10.10.10.3, Ardala locates the sensitive files in a development folder. She uploads them to 172.27.20.5 via FTP (see Figure 4.8). Figure 4.9 summarizes Ardala's recent round of actions.

Figure 4.8. Copying files from 10.10.10.3 to 172.27.20.5 via FTP

Figure 4.9. Gaining remote interactive access to 10.10.10.3

To divert attention from her intrusion to 10.10.10.3, Ardala instructs the Mstream clients (i.e., Server.c) on 192.168.60.3 and 192.168.60.5 to perform a DDoS attack against 172.27.20.102, a popular IRC server. She issues the commands from 172.27.20.5. In response, 192.168.60.3 and 192.168.60.5 spew TCP ACK segments from random source IP addresses against 172.27.20.102, which responds with RST segments.⁵

Ardala actually skips one of the stages of Mstream's DDoS capability. She runs the master program on 172.27.20.5 and connects to its default listening port (6723 TCP) directly from the same machine. She uses the Netcat program, shown as nc in Figure 4.10.⁶ She could have easily connected to port 6723 TCP on 172.27.20.5 from another machine, but she saw no benefit in doing so. For her purposes, all of the systems involved are throwaway systems she will never use again anyway.

Figure 4.10. Using Mstream against 172.27.20.102

Figure 4.11 shows Ardala's concluding actions on the CHM network.

Figure 4.11. Launching a DDoS attack against 172.27.20.102

The DDoS attack against 172.27.20.102 is the end of our look at the compromise of CHM Plans. Fortunately for the victim, CHM's security team was collecting full content data on an NSM sensor. The sensor's sf1 interface was plugged into the DMZ hub, while its gigabit em0 interface listened silently on a SPAN port on the internal network switch.

CHM Plans created two sets of libpcap-formatted files by running Tcpdump in the following manner.

tcpdump –n –i sf1 –s 1515 –w sf1.lpc
tcpdump –n –i em0 –s 1515 –w em0.lpc

In Part II we'll use this data, sf1.lpc and em0.lpc, as the basis for demonstrating the capabilities and limitations of each open source NSM tool.

Conclusion

This chapter gives us a starting point for analyzing tools discussed in the rest of Part II. To the extent possible, we use traffic collected during this fictitious scenario to demonstrate the capabilities of various tools and techniques. The traffic collected for this scenario will be available through http://www.taosecurity.com.

With this background, we're ready to take a look at various open source NSM tools. We start with full content data in Chapter 5.