Protect Your Windows Network: From Perimeter to Data

The first step in attacking any network is to figure out what to attackto 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.

NOTE: No network is any more secure than the least-secure device connected to it, including all the VPN users connecting to it.

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 linkthe 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 zonea 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 MechanismsThe 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

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 networkpierce the eggshell if you will.