Conducting a penetration test is like conducting any other type of attack—the more you know about what you’re attacking, the more likely you are to be successful. In Chapter 9, and Chapter 10, you learned how to gain information about the network. In Chapter 11, you learned about how to find which ports are active. In this chapter, you’ll put all these skills together to take the next step: finding information from a particular host.
This chapter provides examples of tools in use rather than details about specific tools. The tools that are available change quickly; some are likely to be obsolete and others to have been updated by the time you read this book. Also, each operating system has different sources of information, and this information can change from one version to the next. Although the actual tools and available information change over time, the underlying principles do not change as rapidly.
Fingerprinting involves gathering information that allows you to make educated guesses about the operating system or application you’re looking at. There are two major approaches to fingerprinting: passive and active.
A passive fingerprint is gathered when a system sends you data, and your system does or does not reply. Another scenario involves intercepting data coming from the system. A probe as simple as a ping can sometimes determine what type of operating system is probing you. Passive fingerprinting is a major concern for people creating an intrusion detection system (IDS) or a honeypot. Honeypots are a very interesting way to learn the methods of attackers, and there are some good books on the subject. This chapter is more concerned with what you can learn by actively probing a system. Some aspects of avoiding detection are covered in Chapter 21, and Chapter 22.
More Info
If you’re interested in more information about honeypots, check out http://www.honeynet.org and Know Your Enemy, written by Lance Spitzner and several other members of the Honeynet Project; it is a fun and informative read.
Active fingerprinting is the act of sending requests to a host, testing for replies (or the occasional lack thereof), and using the test results to determine as much as you can about the host. Fingerprinting can take place at many levels. The behavior of the TCP/IP implementation, including ICMP behaviors, usually reveals which operating system is running, often down to the version and even the patch level. Here are some of the major sources of fingerprinting information:
IP implementation
ICMP implementation
TCP responses
Listening ports
Banners
Service behavior
Remote operating system queries
IP and ICMP fingerprinting involves testing the poorly defined and less-used nooks and crannies of the protocols. Many of the fields within an IP packet are well defined, and the behavior associated with the fields is predictable. For example, the Time-to-Live (TTL) field might be interesting in terms of helping you determine where the routers are, but all IP stacks are likely to handle this field in much the same way. Sending out packets with this field set to zero won’t get many replies. However, the default TTL that a given operating system chooses can be interesting: 32, 64, 128, and 255 seem to be commonly used values. In rare cases, you’ll find a system that modified the TTL, so like all fingerprinting data, you’re looking for a preponderance of the evidence. This is only one piece of information, and it might not tell you much. For example, if a system replies to your probe and you deduce that the original TTL was 128, you can infer that the system is probably running Microsoft Windows but not Windows 95. It could still be running Windows 98, Windows NT 4.0, Windows 2000, Windows XP, and so on.
You can find some of the most up-to-date material on IP and ICMP fingerprinting in the Xprobe tool developed by Ofir Arkin. You can get Xprobe and some long and detailed papers at http://www.sys-security.com.
Here’s a quick synopsis of some useful fields in the IP header:
Type of Service (TOS). There are two unused bits in this 8-bit field. Operating systems also vary regarding whether they will reply with the same TOS flags as the packet that originated the probe.
Identification. Certain operating systems have distinctive behaviors in terms of how this 16-bit field is generated.
Fragmentation flags. Illegal combinations of the fragmentation flags in this 3-bit field can sometimes provide information—for example, setting "don’t fragment" and "more fragments follow" at the same time. Fragmentation reassembly behavior can also show differences.
TTL. Different operating systems use different default values, as described earlier.
Protocol. Almost anything with an IP stack will support ICMP, UDP, and TCP, but support for other protocols varies from one type of host to another. Nmap is capable of conducting a protocol scan. If a protocol isn’t supported, an ICMP error message will be returned, so all 256 possible protocols can be quickly enumerated. Obviously, you’d save some time testing only for legal protocols.
IP Options. Many of the originally defined options are no longer supported, and this support varies from one system to the next. For example, source-routing was known to be a useful attack, and many systems quit supporting it as a result.
Also, the ICMP protocol allows for some interesting probes. For example, many versions of Linux and Sun Solaris reply to ICMP echo requests sent to the broadcast address, but Windows systems do not. A set of three ICMP requests can reduce the system you’re probing to a small subset of information requests, timestamp requests, and address mask requests. Ofir has written over 200 pages on this topic alone, so if you’re the type of person who enjoys knowing the gory details of networking protocols, read the papers on his website.
TCP fingerprinting, like IP and ICMP fingerprinting, uses variations on TCP implementations to identify operating systems, often down to a certain patch level or service pack. A number of TCP fingerprinting tools have been created. One of the most current and up-to-date is Nmap, maintained by Fyodor (not to be confused with Fyodor Yarochin, who works with Ofir Arkin). There are a couple of caveats with Nmap:
It has been known to take down some network devices, but usually not mainstream operating systems. Search the BUGTRAQ archives at http://www.securityfocus.com to get an idea of what to look out for. To be fair, completely ordinary port scans have been known to crash fragile network devices, but fingerprinting almost by definition involves sending unusual packets.
There has never been a full, native port to the Windows operating system, and the Windows version is known to be slower and, by some reports, less reliable than the same software running under Linux or UNIX.
Fyodor also wrote an article on fingerprinting techniques in Phrack 54-9, found at http://www.phrack.org/show.php?p=54&a=9. As usual, TCP fingerprinting takes advantage of odd, poorly defined corners of the protocol. Here’s a short list of some techniques that can be used:
Initial sequence number prediction and patterns. Different operating systems have used different methods to generate initial TCP sequence numbers, and the patterns and predictability of the numbers coming back can sometimes tell you the operating system. For example, Windows NT 4.0 had a different algorithm for release up to SP3, SP4, SP5, and SP6. More recent versions do not have such identifiable differences.
Sending unusual combinations of flags. As discussed in Chapter 11, there are six legal TCP flags and two more that are unused, for a total 256 possible combinations, but only a small subset of these are legal and shown on a normal TCP finite state machine. Not counting URG and PSH variants, only about six legal flag combinations are possible. As you can see, a rich set of possible illegal packets can be sent to both open and closed ports. Whether an operating system drops the unusual packet or whether it replies (and with what) is information that can be used to create a fingerprint.
TCP options. Different operating systems can support different options. Sending a packet packed with TCP options and then checking responses can also yield interesting information.
Initial window size. This is another TCP header field, and its size can vary from one operating system to another.
SYN flood resistance. Some operating systems are very good at resisting SYN floods, and others are not. This can be a destructive test, so unless you can find a non-critical port to operate on, this approach isn’t advisable. It can also set off intrusion detection systems, though many of these techniques will also be flagged.
Short of implementing your own IP stack that confuses fingerprinting tools, you can’t do much to foil IP-level fingerprinting. If the system is exposed to the Internet, be conservative with the packets that you allow to reach your system. For example, if the only traffic that reaches your system is headed for port 80, and that port is open, few fingerprinting techniques are still available. Another approach is to use a firewall or inline IDS device to normalize incoming traffic; however, low-level fingerprinting techniques identify only the firewall device.
The best bet is to assume that your attacker knows exactly what version of the operating system is running and to make sure it is secure. As you’ll see shortly, defeating application-level fingerprinting is more difficult and can frequently give the attacker the same information. Normalizing the incoming traffic and reducing the attack surface are always advantageous, but take these measures on their own merits—your security should never depend on your attacker being unable to fingerprint a system.
One of the easiest ways to see what is running is to probe for banners. For example, my Windows 2000 FTP server will yield this:
220 servername Microsoft FTP Service (Version 5.0).
Because changing the banners on most Windows services is inconvenient, especially considering that you have to deal with Windows File Protection, you could conclude from the preceding code fairly quickly that this system is probably a Windows 2000 server. What is less certain is whether someone running another type of FTP server, possibly on a different operating system, modified her banner to pretend to be Windows 2000. Banners come back from FTP, SSH, Telnet, SMTP, HTTP, LDAP, and POP—and that’s just to name a few common services. Although banners are convenient and easy, these tend to be unreliable and you should confirm what the banner tells you with additional probes.
A better approach is to test the behavior; a growing set of tools can fingerprint individual applications. To use Telnet as an example, people might change the banner, but changing the implementation would be very unusual and somewhat difficult. Deciphering the Telnet options that the server would like to negotiate can be very informative. For example, a Windows 2000 or later server running Telnet typically attempts to negotiate NTLM authentication instead of using clear-text passwords. FTP servers are also distinctive in the commands that are supported, and there are subtle differences in the directory listing output. A Web server is supposed to accept a request that looks like GET / HTTP/ 1.0<cr><lf><cr><lf>, but as it turns out, an IIS server accepts a trailing <lf><lf> pair as being the same as two pairs of carriage return–linefeed characters. However, many other servers, including Apache, insist on the exact RFC format.
One basic countermeasure is to change banners that give operating system information, but this isn’t always easy, especially with commercial products. Although you could edit the binary, Windows File Protection makes this more difficult, and you’d also have to edit the binary every time the vendor released a patch. You might also find that editing the binary invalidates the signature on the binary and it might not run at all. As with low-level fingerprinting, the best approach is to assume the attacker knows what you are running and to focus your efforts on real security measures, not on security through obscurity. (See Chapter 8, for more information.) Although it has very limited value, changing banners can foil badly written attack tools and the least competent attackers. It is normally not possible nor advisable, even with an open source application, to significantly change the implementation of the service. Using tools such as URLScan (discussed in Chapter 24), you might be able to drop known fingerprinting attempts, but there are many other better places to spend your time.
Once you have some port scan results, you also have a list of open ports. If the system is unfiltered, that list can be quite informative. Finding ports 137, 139, and 445 open tells you that you’re probably looking at Windows 2000 or later. An official and current list of assigned ports is kept at http://www.iana.org/assignments/port-numbers.
Tip
Be warned that some operating systems listen on semi-random ports. For example, Windows systems usually listen on RPC endpoints in the range just above port 1024, and to determine what’s really on the port, you must probe the RPC endpoint mapper located on port 135.
As with banners, regard what Internet Assigned Numbers Authority (IANA) says about the service as a hint: the possibility always exists that someone has placed a Web server on a strange port in the name of security by obscurity, and some applications run application-specific Web servers on unusual ports. Some user might have placed the chargen service on some large number of random ports just to make life difficult for you and non-authorized attackers.
When confronted with a common port, first assume that the port is what it should be—don’t try to negotiate Telnet options with port 80 under normal conditions. This is going to work nearly all the time. The next step is to simply Telnet to the port, or use Netcat to connect, and see what it tells you. Many services will give you distinctive initial connection messages. One of the last strategies to try is to send the system every type of initial sequence you can think of. Some scanning applications can try this approach, but I would caution you against using them in most cases. A number of bugs have been found where sending unexpected data to a server causes it to fail.
In some cases, trying specific protocols is the only practical approach—for example, ONC RPC services. ONC RPC is the RPC standard created by Sun Microsystems and can be found on nearly all flavors of UNIX and UNIX-like systems. Implementations exist for other operating systems, such as Microsoft Services for UNIX, so don’t assume that because you find ONC RPC services, you have also found a UNIX or Linux system. In many cases, users running ONC RPC services turn off the portmapper and require clients to know which port has been configured. Several tools overcome the problem by locating open ports and attempting to negotiate as different RPC services. A current implementation is found in Nmap, or rpcinfo can be used on UNIX-derived systems.
To summarize, here are the steps to take when you find a listening port:
Look up the port number in the IANA listings if you’re not already familiar with it.
Attempt to connect using a standard client if you think you know what the service is.
If you’re not sure about the service, try connecting with something benign first, such as Telnet or Netcat, to see whether you get a banner or other response.
Try connecting with protocols you suspect might work, especially if they are found in a range typical for RPC services.
You might find some backdoor applications running. Frequently, you find these on certain default ports; lists of commonly used backdoor ports exist. If you search, you might find clients for these backdoors and be able to establish that they are indeed backdoors. If the attacker leaves the application running with a poorly chosen password, you might be able to take over the system. You could then pursue this avenue further to get a good idea of what the attacker might have accessed.
A number of protocols can enable a remote user to find information about a host. One of the primary reasons for giving information to remote users is to enable management tools, and a secondary reason is to be user friendly. One of the classic applications used to find information was finger—typing finger @host produced a list of logged-on users, and finger user@host provided information about those users, frequently including jokes and other messages. SNMP, the "Security Not My Problem" protocol (really, the Simple Network Management Protocol), is another classic service that provides information. A community string of "public" or blank will often get you a large amount of interesting information, including the exact operating system version and user accounts for that system, and many other items, depending on the operating system, version, and installed extensions. SNMP version 3 does correct many problems with the original SNMP service, but because many network devices support only SNMP version 1, version 3 isn’t often used.
Many of the mechanisms to provide information also exist on most common operating systems, but the tools and exact techniques vary. Consistently, the trend is to require higher levels of authentication for the same information, because Microsoft and other operating system vendors have recognized how useful leaked information can be to an attacker. Let’s take a look at some of the information that can be obtained.
Note
The goal of this book is to offer overall techniques that don’t need to be updated every year, and for this reason, as mentioned earlier, this chapter won’t get into details about the nuances of each tool and technique. For example, password policy information was available to anonymous users on Windows NT 4.0 until a post-SP3 fix was applied and RestrictAnonymous was enabled. That same information isn’t available to anonymous users on Windows XP and later. This sort of arcana can be tedious and you can find it in other places.
The first and most obvious piece of information to have is the list of user accounts, locally and at domain level. With valid user names, the immediate attack that comes to mind is password guessing, but there’s a lot more to user names than a simple password. That machine named TESTBOX with a user named Bob might well have the same password as the domain-level user of the same name. User names can also tell you which machines are likely to be managed by the same group, for example, systems that have local accounts with the same names, or the local administrator’s account being "renamed" to the same thing.
The next piece of information you’d like to know about a user account is the last time that account logged on. A fundamental fact of network computer security is that if you can achieve complete control of an operating system, you can cause your code to run as any user who is either currently logged on or who will log on in the future. As a penetration tester, you don’t have all the time in the world to see whether a highly privileged user will log on to a system; you need to find the systems that user logs on to regularly. Leaving a Trojan on the terminal server that a user logged on to six months ago isn’t likely to ever get run. Reporting to management that you took over important resources in less than a day will get more attention than reporting that it took you three months to break in. If a user is currently logged on, or better yet is being used to run a system service (known on UNIX systems as a daemon), you know that you can subvert that user right away.
The first target for group information would be highly privileged users. Members of the administrators group are the most highly valued, but members of other groups are also important. On a Windows 2000 or later system, members of the Power Users group can achieve higher levels of access, but it might take them a little work. Backup Operators can obtain anything from the file system or registry. At the domain level, Account Operators can change the membership and user account information for anyone except administrators. For example, suppose you find a Datacenter Operators group that has administrator-level access to a large number of servers. You next notice that a member of the Domain Admins group is regularly logging on to a system where Datacenter Operators are administrators. As an account operator, you can add a new user to the group. A better approach that is a little less likely to be noticed is to find an account that hasn’t been used for a long time in the Datacenter Operators group and reset the password. Because you’re also interested in protecting your systems, an event log monitoring service can be configured to flag changes to important groups and password resets.
If you’ve been guessing passwords and probing for unpatched systems, and you’re coming up empty, looking through file shares can sometimes yield results. More than once, a website’s source was shared with a weak access control list, the server-side script contained an sa (sys-admin) password to a SQL server, and the SQL server itself was running with a high level of privilege. Batch files and scripts can also be promising. Even if you can’t obtain any passwords, you can often obtain sensitive information that could help in social engineering attacks (covered in Chapter 23). Or, perhaps this sensitive information itself is the goal.
One of the reasons file shares often enable escalation of privilege attacks is that a well-managed network runs vulnerability auditing tools frequently, and machines with weak passwords or unpatched vulnerabilities might be rare. A penetration tester can find a password embedded in a file on a share relatively easily (though tediously), but writing an application to automatically find passwords in files is difficult.
If a user mistakenly shares out an entire drive, you have many more options. A number of vulnerabilities were found in which applications that were prompted for passwords stored these passwords in a temporary file on disk and then forgot to erase them. Prior to Windows 2000, access to the SAM._ file allowed you to brute force attack the passwords using something like L0phtcrack. In Windows 2000 and later, the syskey feature was enabled by default, so administrator-level access was required to obtain the password hashes. Write access to a user’s personal directory also can allow various Trojan attacks.
On a Windows system, remote system calls exist that make fingerprinting easy—you merely ask the operating system what kind and version it is. With user-level access, you can also determine the service pack level. Depending on how they are configured, UNIX systems sometimes give you the same type of information, though good fingerprinting tools tell you this even when the operating system does not. One issue to be aware of is that non-Windows servers running the Server Message Block (SMB) service, such as but not limited to Samba, often give you confusing results.
Depending on the operating system version and available services, you can also query a system and discover how many network interfaces are available. If SNMP information is available, you can usually get details about the network interfaces, including the number of packets sent. On earlier versions of Windows, a tool known as Epdump could use the RPC endpoint mapping service to show all active IP addresses on a system.
Most operating systems also tell you the time of day. Many systems have a time-of-day service, and invoking net time \server from the command line of one Windows system to another will yield the time at the remote server. You might be wondering just how you’re going to use time of day to attack anything; time of day can yield clues about the location of a system. For example, if the time zone is GMT -8 (or UTC -8), the system is probably located in the western United States. A more direct use is when you have administrator-level control and want to schedule tasks to run, usually immediately. If you can determine what time it is on the remote system, you can avoid doing things like scheduling tasks 23 hours and 58 minutes from now because there is a 3-minute skew in your clocks, or scheduling a task for 21 hours and 1 minute from now when you really want it to run in 1 minute. Finally, in some circumstances a user can base a predictably random number on the time of day. This is a very bad practice, but problems like this have been known to happen, although it would be rare to actually use this during a penetration test.
As mentioned previously, Windows systems will also give you information about password policies, depending on your authentication level and the version and patch level of the operating system. In the Platform SDK, you can find password policy information using the NetUserModalsGet function, which returns the password lockout policy—that is, whether lockouts are set; if they are set, then the number of failed passwords that trigger a lockout; and the duration of the lockout. Another bit of information available from the same call returns the minimum password length, maximum password age, minimum password age, and the password history length. Because this information is obviously helpful to an attacker, it has become more tightly controlled with each version of the operating system. On a Windows 2000 or later domain controller, the ability to read this information is controlled by the access control list on the Active Directory object.
User session information includes the user name attached to your share, where the user logged on, and the type of client system being used. Session information is important for many reasons, the first being that you can get one system to tell you where another user is actively logging on. Second, if you need to boot a user off, you can make sure that any established sessions are dropped.
You can obtain this information from the command line by typing net session. Using the Windows NetSessionEnum API call, you can obtain it on remote systems. Let’s take a look at an example:
C:Documents and Settingsadministrator.MYNET>net.exe session Computer User name Client Type Opens Idle time ------------------------------------------------------------------------------ \192.168.0.8 Windows 2002 2600 0 00:00:03 The command completed successfully.
The user name is blank because I created an anonymous session to the server. The client, shown as Windows 2002 2600, is actually Windows XP. A more user-friendly way to obtain this information is the Netwatch.exe tool shipped in the Windows NT 4.0 Resource Kit. Source code for the tool is available in the Platform SDK at http://msdn.microsoft.com/library/en-us/vcsample98/html/vcsmpnetwatch.asp. Many successful penetration testers don’t write scripts very well, but if you do have an aptitude for programming, being able to create your own tools can make you much more effective.
As was briefly discussed in the "User Information" section, you can interrogate the Service Control Manager (SCM) as a user on a Windows system to determine which services are running, and better yet, the accounts being used to run the services. The accounts you’re usually most interested in are domain-level accounts. Here’s an example using Sc.exe, which is in the Resource Kit and ships with the Windows XP and Windows 2003 operating systems.
[C:sc.exe \server qc alerter
[SC] GetServiceConfig SUCCESS
SERVICE_NAME: alerter
TYPE : 20 WIN32_SHARE_PROCESS
START_TYPE : 3 DEMAND_START
ERROR_CONTROL : 1 NORMAL
BINARY_PATH_NAME : C:WINNTSystem32services.exe
LOAD_ORDER_GROUP :
TAG : 0
DISPLAY_NAME : Alerter
DEPENDENCIES : LanmanWorkstation
SERVICE_START_NAME : mynetadministratorThis example uses the Alerter service: the issue illustrated here is that if an attacker can become an administrator on this system, the password for that user can be obtained in the clear using the Lsadump tool created by Todd Sabin of Bindview, found at http://razor.bindview.com. As you can imagine, it is extremely important to very carefully manage systems with services running as domain users, especially as highly privileged domain users. As a penetration tester, you need to verify the security of these systems, and once you put on your security and network administrator hats, you must start finding ways to limit the scope of these services and reduce the need for services that run as domain users. One way to accomplish this is to run services as LocalSystem and grant the computer account (on networks with Windows 2000 and later domain controllers) the rights that it needs to accomplish its task. On Windows XP and later, you can use the network service account.
It’s important to note that the Lsadump tool’s function does not mean there is a flaw in the operating system. First, you have to be an administrator to run it. If you can become an administrator, you can modify the operating system, and the damage you can do is limited only by your available tools and your ability to build new tools. Second, if you cannot obtain the password as an administrator, you can reconfigure the service to point at another arbitrary binary and then restart it. This lets you execute arbitrary code as the user the service is configured to run under.
The first and most obvious step to take is to not expose unnecessary services to attackers. Either disable the service entirely or filter the traffic coming to that port. One approach that is being used internally at Microsoft is to require IPSec on all systems that participate in the managed infrastructure. Some of the information that can be leaked is available only to authenticated users. Using scanning tools to locate and patch accounts and services with weak passwords will reduce the amount of information available.
The information that’s available changes with every version of an operating system, service pack, and sometimes even with a hotfix. The countermeasures change almost as often, so the best approach is to check the most up-to-date security guides. For Microsoft operating systems, you can find this at http://www.microsoft.com/technet/security/bestprac/default.asp. Take a close look at all the information available under the section titled "Host Defenses."
Q. | How do I protect against IP and TCP fingerprinting? |
A. | Use a network device that can normalize your traffic. Many routers, firewalls, and inline IDS devices, as well as some dedicated software, can normalize traffic for you and make low-level fingerprinting more difficult. |
Q. | |
A. | In general, you don’t. You need to properly secure your system so that even if attackers know what it is, you remain secure. In some cases, it is possible to host different types of software as a front-end or proxy to another type of system and be able to hide the internal system. |
Q. | How do I reduce the amount of information my operating system will give to attackers? |
A. | You read the fine manual. If you’re running a Microsoft operating system, you can find up-to-date configuration information and best practices at http://www.microsoft.com/security/guidance/default.mspx. Additionally, a good vulnerability detection tool will have a help system that describes how to reduce information leaks. |