What do hackers spend most of their time doing? Most of the time, they’re gathering information about potential victims and searching for weaknesses in remote systems. In this Daily Drill Down, I’ll examine the different methods that hackers use to analyze the security of remote systems. I’ll also discuss some ways in which you can defend against such intrusive analysis.

The Old School method
One way of analyzing remote systems is referred to as the Old School method. (You’ll see this term in almost any hacker’s chat room.) Basically, it refers to the way in which hackers used to obtain important information—before system administrators caught on and began to make such information harder to get. Now, the Old School method is so out-of-date that it is rarely used. Still, understanding this method will help you see why certain changes have been implemented.

Banners
In the past, applications that provided a service (such as FTP or HTTP) greeted incoming users with a banner. These short plain-text messages contained information about the application, including which version it was, which platform it ran, and other technical information. Looking at banners was always the first thing that hackers did when they wanted to know which operating system a particular server was running. They simply opened a telnet connection and looked at the banner’s information:
hacker:~>telnet victim.com
Trying 192.168.1.1…
Connected to victim.com.
Escape character is ‘^]’.

HP-UX hpux B.10.01 A 9000/715 (ttyp2)

login:

At first, this information didn’t seem very dangerous; the chattiness of these banners established good rapport among systems administrators. Unfortunately, this information was a great source of information for hackers, too. Systems administrators learned from their mistakes, though; now these banners contain false information—or no information at all. Although some operating systems still have banners that contain correct information, most systems administrators are smart enough to change /etc/issue.net (in Linux), etc/gettytab (in FreeBSD), /etc/inittab (in Solaris), and any other files with this type of information.
Of course, hackers have other methods of learning which version of an operating system you’re using. Many programs offer this kind of information, and some of these programs won’t even let you hide this information. One example is Sun’s ftpd for Sun architecture servers:hacker:~>telnet victim.com
Trying 192.168.1.1…
Connected to victim.com.
Escape character is ‘^]’.
220 ftp FTP server (UNIX(r) System V Release 4.0) ready.
SYST
215 UNIX Type: L8 Version: SUNOS
Such strategic mistakes are very rare, and you won’t need to make any plans for defending against these types of mistakes. Hackers have to resort to more sophisticated methods than banner observation.
According to RFC1945, the HTTP 1.0 protocol supports the transmission of the Server: field with such information as the server’s name and version and the operating system’s name and/or version. The following method is suitable for use against a lot of different services:
hacker:~>telnet www.victim.com 80
Trying 192.168.1.2…
Connected to www.victim.com.
Escape character is ‘^]’.
GET / HTTP/1.0

HTTP/1.1 200 OK
Date: Thu, 24 Feb 2000 18:04:38 GMT
Server: Apache/1.3.6 (Unix) ApacheJServ/1.0b4
Connection: close
Content-Type: text/html

RFC’s authors noted this potential problem. Revealing the specific software version of a server makes the server machine more vulnerable to attacks against any software with security holes. That’s why the Server: field should be made a configurable option. Unfortunately, it rarely is. Hackers still scan ports and banners in order to collect important information.

Sendmail
Another valuable source of information for hackers is a popular mail transport agent (MTA) called Sendmail. Until recently, the Received: field of every e-mail message contained the whole trip route of the message. This field also contained information about the host MTA (from which the message came), starting with the date of transfer and finishing with a platform name. This information helped the hacker find and break into the originating server.

Systems administrators have learned from their mistakes. Now, in the Received: header, you’ll see only dummy information, like “Sendmail v.8.xx or Sendmail v.8.who cares,” instead of the real version number string. The solution is to avoid sending internal technical information. Doing so eliminates the possibility of information sniffing.

In the case of Sendmail MTA systems, the administrators have to follow only a few extra compilation steps in order to hide all necessary information from potential intruders. First, before compiling (but after the configuration process of Sendmail), you should change the Version[] variable in the rc/version.c file:
src/version.c.old:
char Version[] = “8.9.3”;
src/version.c:
char Version[] = “x”;

Then, after compiling Sendmail, you must change the version of your configuration file (which is often the same as Sendmail’s program). You can do so by placing this string into your Sendmail’s configuration source file:
define(‘confCF_VERSION’,’y’)

Otherwise, you can add some changes to your configuration file:
/etc/sendmail.cf.old:
DZ8.9.3/BSD
O SmtpGreetingMessage=$j Sendmail $v/$Z; $b
/etc/sendmail.cf:
DZx/y
O SmtpGreetingMessage=Service ready.

These changes are simple and easy to make, and they give your system a much better chance in any fights with intruders.

Binary stew
A more serious hacker trick involves downloading the /bin/ls file for examination through FTP (using anonymous access). This binary helps the hacker get to know the type of operating system that runs on the server. For example, if this is an ELF binary, the hacker can use the GNU Debug (gdb) program to view the functionality of its routines. The most important characteristics are the system calls. For listing the directory, the ls program uses the system call getdents(), but each system has a different way of spelling that call; it could be sys_getdents() or o_getdents().The hacker can also check for platform-dependent system calls that aren’t used in other systems. All the hacker needs to do is get the tables of system calls for other platforms and make a full comparison.

What is the solution? Many UNIX-based FTP servers (like wu-ftpd or proftpd) have the ability to disable the downloading of the /bin/ls file. They just parse it like a usual FTP protocol command—like other, non-UNIX systems do.

The New School method
Another approach to information analyzing is referred to as the New School method. It isn’t widely used, but it offers far more opportunities to hackers. Over the past few years, all of the Old School methods have become less effective because servers’ defenses have improved. Systems administrators have become much more careful, and the hackers have lost many opportunities to obtain valuable information through these outdated methods.

Now, hackers are looking for more effective and dependable technologies and waiting for software developers to make mistakes. And they have made a mistake: It’s found in the TCP/IP protocol. In different systems, the TCP/IP protocol has certain, unique peculiarities that don’t affect work or violate any regulations. However, testing these peculiar features helps people learn which operating system they’re working with. Let’s examine the more popular tests that detector programs use in order to learn the version and type of various operating systems.

The FIN flag
Set the FIN flag (the No More Data From Sender control bit) to the packet and send it to the open port. Then, wait for an answer. According to RFC793 (Transmission Control Protocol Specification), the system doesn’t have to answer such a packet, but OSs like Windows, BSDI, HP/UX, and VMS and Cisco IOS running platforms send an answer packet with the R RESET command.

The BOGUS flag
There’s a flag—called by BOGUS-flag—which isn’t defined like any functional flag. It has the value of 64. When somebody sets this flag in a SYN packet, all Linux versions up to 2.0.35 will return it in the answer packet. All other operating systems will ignore it or reset the connection. (There’s no certain information about it; some servers don’t respond to it during the 15-minute period, and some just accidentally reset the connection.)

The ISN examination
In some operating systems, the Initial Sequence Number (ISN) changes—not by specification but by some definite function. This change helps the hacker get to know the operating system. The hacker can process several data points (such as the results of setting up 50 connections) on different servers and consequent algorithm assessment. For example, some operating systems (Linux 2.0.10 and higher, OpenVMS, IRIX, and AIX) generate their ISNs randomly with the /dev/random special device, which guarantees some level of reliability. Some later versions of Solaris, FreeBSD, Digital UNIX, and Cray add a randomly generated number to the current ISN. Windows uses a very unsafe method of generating an ISN: It uses a timer, which is visible if you build a graph of ISN(t). (This graph is a straight line with very little deviation.) Of course, some devices use a constant ISN. 3Com hubs, for example, always set the ISN to 0x803.

The unfragmentable bit
Many operating systems have an unfragmentable bit in their packets, which saves a lot of time. In certain situations, these systems operate differently. For example, in the Linux sources, there’s no place where this bit gets set automatically. Usually, Windows NT sets this bit automatically, but this frequency can be detected easily.

The ACK probe
Servers are supposed to return the old ISN after they get a packet with a set ACK bit. Sometimes, however, Windows NT, network printers by Hewlett-Packard, and some hubs just increase the ISN by 1 and return it. To test for this action, send a packet with set FIN, PSH and URG flags to the closed TCP port.

The message quoting in ICMP
According to the RFC, in case of ICMP errors, a system should return very little information. But Solaris, Linux, and HP/UX return a large amount of technical information. Furthermore, this feature gives an intruder the ability to detect these system types even when there are no open ports.

TOS in ICMP returns
In the event of an ICMP Unreachable error in the answer packet, the Type of Service (TOS) field is supposed to be set to zero. But with current Linux releases, you’ll see 0xc0 in the Type of Service field.

The TCP packets options
The most popular scanning program is nmap, which is available in source code at Insecure. The author of nmap, who’s known as Fyodor, developed the following technique from scratch:

  • You don’t have to set these options in your packets.
  • You can check all of these options at once by setting them in one packet and noting which ones return.

The options include Window Scale (WS), Max Segment Size (MSS), and Time (T). FreeBSD returns all of these options, but Linux returns only the MSS.

What can you do?
The target of modern scanning programs is changing. What will you see during a scanning probe? You’ll see consecutive server port scanning or strange packets as described above. Often, the sources of these strange packets and connection requests are the same. You’ll see packets with the SYN flag set addressed to closed ports. In most cases, you’ll see hundreds of these packets. A patient attacker can hide all of these little probes by stretching the scanning process over the course of several days. After that, nobody will see anything strange about these packets.

One task of a scanning program is to hide its source. The most popular method, one that is widely used, is to send a lot of different packets from different IP addresses and to hide your single packet in the middle. The victim SysAdmin will know that the server is being scanned but won’t know where the attack is coming from.

Of course, there are ways in which administrators can learn if they are being scanned (and, if so, from where). For example, some packets that come in for examination from a huge number of different IP addresses may have the Time to Live (TTL) field set to 255. That means that the scanning host is nearby. There’s another fact that might help you detect a running nmap scanner: By default, the source port is set to 49724 and the Time to Live field is set to 225.

How should the logger work? Remember, it must grab “empty” packets without processing them by system. These packets should be processed in the so-called “promiscuous mode.” Doing so makes it easier to get packets before the system processes them. Often, it allows you to cheat nmap and other scanners. You also can cheat the nmap scanner by writing a kernel module that will grab TCP/IP function calls and process them in its own way.

Conclusion
Scanning is one of the most important steps towards breaking into operating systems. Of course, in the future, we’ll see new methods of scanning, and we’ll have to develop new detection methods. It’s a never-ending cycle.

Alexander Prohorenko is a student of computer sciences. For the last three years, he worked as a leading system administrator and coder for one of the largest ISPs in Ukraine, and he installed and integrated much of the Internet infrastructure for that country. Now he’s engaged in quality systems programming and high performance web coding for Network Lynx, an American company that’s based in Rio Rancho, NM.

The authors and editors have taken care in preparation of the content contained herein, but make no expressed or implied warranty of any kind and assume no responsibility for errors or omissions. No liability is assumed for any damages. Always have a verified backup before making any changes.