Unix Insider –
One of the things hackers most want to know about a site they're planning to break into is the operating system that's being used on exposed systems. The more a hacker knows about a particular system (e.g., the OS, the hardware architecture, and services that are running), the greater are his or her chances of launching a successful attack. By knowing the operating system and system type, a hacker can do a little research and come up with a list of known vulnerabilities. Add to that a list of services you're running (see last month's column), and he's ready to go.
Let's look at a seasonal analogy. You've just drawn a name from a tub in your company's Secret Santa solution game. You want to give a gift that the recipient will enjoy, but the name isn't familiar. What pieces of information might help you select a gift that's likely to be well received? You might want to know if the recipient is a new employee, a recent college graduate, or a company veteran about to retire and sail around the world. You might like to know if the individual has any obvious interests. You'd probably like to avoid buying chocolates if the recipient is a diabetic or fine wine if he or she is an AA member.
Once you have a few pieces of information about the person for whom you're shopping, your chances of buying a gift that's neither offensive nor wasteful are considerably improved. Similarly, a hacker, once he or she knows the operating system your server is running, can select an attack with a much higher chance of success. He might learn, for example, that he can subvert IIS on your Windows 2000 system by sending malformed
<font face="Courier">HTTP GET</font>requests and retrieving files that should be off limits.
OS identification in the good old days
When I was a mere babe in the ways of Unix, identifying the operating system that a particular system was running wasn't that hard. I would first try to telnet to the system in question, and most systems would offer up some insights.
<font face="Courier"> boson% telnet 184.108.40.206 Trying 220.127.116.11... Connected to stovepipe. Escape character is '^]'. <P> SunOS 4.1.3 <P> login: </font>
The banner, by itself, might have told me what I wanted to know. The system in question was running SunOS. If the target system didn't respond with a login prompt, I would ping it and determine from the new entry in my arp cache (provided the system was on the local network) what type of network adaptor it contained. That would tell me the manufacturer of the card and, in most cases, the type of system as well.
<font face="Courier"> boson% ping 18.104.22.168 stovepipe is alive boson% arp -a | grep 111 22.214.171.124 08:00:20:c0:ff:ee </font>
But let's face it. In the good old days, not too many people were hacking, and the likelihood that a server was running Telnet and providing valid and useful information in its login banners was extremely high.
These days it's much more likely to find that standard services (such as Telnet) aren't running at all or that login banners don't contain any information that's useful in identifying the OS or hardware. In that case, it's still possible that some other service (e.g., FTP, HTTP, POP, or sendmail) might provide helpful information, but often those services aren't running either.
Determining the operating system by examining the responses you get from Telnet, FTP, and other such services is referred to as banner grabbing.
OS identification, state of the art
If your systems aren't gratuitously providing information about their operating systems and hardware, what can average hackers find out about them, and what kinds of techniques will they use?
A number of tools (most notably nmap and queso) can be used to identify the operating system in use. Some of those tools are specifically designed to do that and nothing more (e.g., checkos), while others offer OS identification as one of many options.
Keep in mind that hackers will be after as precise an identification as possible. If they can determine the OS, the hardware, specific services, and specific versions of specific services, they'll be able to identify attacks that are extremely likely to succeed.
Active stack fingerprinting
The basis of identifying an operating system by probing its stack is quite clever. It's tempting to think that TCP/IP is TCP/IP is TCP/IP. After all, TCP/IP is a standard. However, that assumption is far from the truth. A degree of latitude can be exercised by those implementing any standard. As a result, fine details exist in any particular implementation of a standard that may uniquely identify the vendor. TCP/IP is no exception. By sending probes and looking at the results, hackers (or, more often, the software they use) can determine which operating system is responding.
Let's take a simple example. You might recall from last month's column that the basis of port scanning is to send probes to ports and examine the responses. If you send a
<font face="Courier">FIN</font>probe to an open port, according to the specification, the port should not respond. In some TCP/IP implementations (e.g., Windows NT), however, a
<font face="Courier">FIN/ACK</font>is returned. In others, a
<font face="Courier">RESET</font>is sent. By knowing how each implementation of TCP/IP responds, you can identify or at least narrow down the OS in question. By using more than one type of probe to differentiate, a hacker has an extremely high chance of determining the OS on the target system. To make matters worse, your options for closing down access to that information are limited. You can't easily modify the behavior of your stack. Your only realistic option is to make your systems as inaccessible as possible.
Other active port-scanning techniques include:
Bogus flag probe. That involves sending an undefined TCP flag in the TCP header of a
<font face="Courier">SYN</font>packet. Some OSs (e.g., Linux versions earlier than 2.0.35) keep the flag set while others reset the connection.
TCP Initial Sequence Number (ISN) sampling. That involves detecting patterns in the initial sequence numbers chosen when responding to connection requests. The likelihood is that, using that technique, a hacker will classify your system into one of a number of discrete groups. Some TCP implementations use random increments (e.g., Solaris, FreeBSD), while others use a time-dependent model in which small increments are added with each time period. Still other implementations use true random numbers or constants. Using that technique, a hacker narrows down the OS candidates.
Don't fragment bit. That involves determining whether the don't fragment bit is set on certain types of packets. Certain OSs set that bit for performance reasons.
TCP initial window size. That involves checking the window size on returned packets. For many TCP implementations, the initial window size is unique, and it identifies the operating system. For others, it simply narrows the possibilities.
<font face="Courier">ACK</font> value. That involves looking at the sequence value used in the
<font face="Courier">ACK</font>field. Most implementations return the value sent, while others return the value incremented by one.
ICMP error message quenching That involves narrowing the possible operating systems by determining whether or not they adhere to RFC 1812 guidelines with respect to limiting the rate at which error messages are sent. Some (e.g., Linux) do while others do not. That process involves sending packets to random high-numbered UDP ports and counting the number of destination unreachable messages returned in a given time period.
ICMP message quoting. That involves determining how much information from an ICMP message is returned when an error is generated. Most implementations, for example, send only the required IP header with an additional 8 bytes. Both Solaris and Linux send more. That technique, based on ICMP, does not require any listening ports.
ICMP error message echoing integrity. That involves examining the degree to which IP headers are modified in ICMP error messages. Some are returned with inconsistent checksums, invalid total length fields, and corrupted IP IDs. The type of errors that are made can identify the target OS.
Type of service (TOS). That technique examines the TOS value of ICMP port unreachable messages. Most implementations set that field to 0 while Linux systems set the value to 0xC0 (i.e., hexadecimal C0).
Fragmentation handling. That technique relies on differences in the way that implementations handle overlapping IP fragments. Some overlay old portions with new while others do the opposite.
TCP options. That involves determining which options are in use. If a packet is sent with an option set, the receiving system will set the option in the reply only if it is supported.
<font face="Courier">SYN</font> flood resistance . That is used to determine whether the target system stops accepting new connections after receiving a number of forged
Passive stack fingerprinting
Passive stack fingerprinting is similar to its active counterpart but doesn't involve sending probes. Instead, the hacker passively monitors network traffic and attempts to make many of the same determinations as with active stack fingerprinting by looking at packets generated by normal network activity. By looking at a small number of attributes (e.g., TTL, window size, TOS, and whether the don't fragment bit is set), a hacker can make an educated guess about what operating system a particular system is running.
The benefit to passive stack monitoring is that it doesn't send probes that might be detected. On the other hand, passive monitoring will take longer and be less precise.
Whether or not your systems clearly identify their hardware, software, and operating system, hackers with access and a sophisticated tool or two can learn a lot more than you likely want them to know.