Low-Level Enumeration With TCP/IP

{LANG_NAVORIGIN} Vulnerability Management Auditing
By: Randy Williams, 02/16/2005



We've all used most of the popular stealth scanning techniques out there right now. Tools such as nmap are excellent for enumerating remote hosts with increasingly complex techniques. The only problem being most of the nmap users out there do not take the time to find out exactly what is going on behind the scenes to make these scans work. In the following paragraphs I will attempt to explain the theory and concept behind many of today's advanced scanning techniques, and try to show you what is going on behind the scenes with them.


Syn Scanning

I know. Most of you are thinking syn scans are just about on the bottom of scans in a technical sense, and indeed you are correct. This section is being offered in this text as a step for beginners to be able to better comprehend some of the later subjects of the article.

Syn scanning, a technique that emerged into the hacking community several years ago, is still widely in use across the internet today. While it has been replaced by more stealthy and firewall negating scans, it is still the best balance of stealth and speed. The syn scan, also called the "half open" scan, is the ability to determine a ports state without making a full connection to the host. As such, the majority of systems do not log the attempt, and discard it as a communications error. To understand how this vulnerability is exploited by scanning software, you must first understand the concept of the "three way handshake" technique that is used to establish all tcp connections between systems.

Standard tcp communications are controlled by flags in the tcp packet header. These flags control what happens to the connection between the hosts, and helps give order to the system. The flags are as follows:

Synchronize - also called "SYN", used to initiate a connection between hosts.
Acknowledgement - also called "ACK", used in establishing a connection between hosts
Push - "PSH", Instructs receiving system to send all buffered data immediately
Urgent - "URG", states that the data contained in the packet should be processed asap
Finish - also called "FIN" tells remote system that there will be no more transmissions
Reset - also called "RST", also used to reset a connection.

As far as syn scanning is concerned, we are only worried about three of these flags, syn, ack, and rst. Tcp is a connection based protocol, which means before any application later data can be exchanged, a connection must first be established. This connection is established with what is called a "three way handshake". The three way handshake is illustrated below:

192.168.1.2:2342 ------------------syn-----------------------> 192.168.1.3:80
192.168.1.2:2342 <----------------syn/ack---------------------192.168.1.3:80
192.168.1.2:2342-------------------ack-------------------->192.168.1.3:80
				Connection Established

The above diagram shows what a connection initiation between a host and a http server would look like. The initiating host ( 192.168.1.2 ) initiates a connection to the server ( 192.168.1.3 ) via a packet with only the syn flag set. The server, then replies with a packet with both the syn and the ack flag set. For the final step, the client responds back the server with a single ack packet. If these three steps are completed without complication, then a tcp connection has been established between the client and server.

So how is the three way handshake exploited by stealth scans? Simple, you simply don't complete the third step. By examining each packet as it enters the interface, you can guess the remote port's state, and terminate the connection before it is even established. Take the example below:

192.168.1.2:2342 -------------------------syn------------------->192.168.1.3:80
192.168.1.2:2342<---------------------syn/ack------------------192.168.1.3:80
192.168.1.2:2342-------------------------rst-------------------->192.168.1.3:80

Those of you with little tcp/ip experience have no clue what the point of that was. Just hang with me and you'll begin to see. The initiation begins the same as in the previous example, the client sends a single syn packet to the server on the appropriate port. It is in the server's response that shows the idea behind stealth scanning. If the server responds with a syn/ack packet, we can very safely assume that the port is in state "open". If the server responds with an rst packet, then the remote port is in state "closed" As seen in the example, the server did indeed respond with the syn/ack packet, knowing that this means the port is open, we then respond with a rst packet, to close the initiation before a connection can ever be established.

This scan type also comes with a risk. If a host is scanned to long, it is possible to "syn flood" the remote host. This is a result of the scan filling up the servers connection table, causing it to stop responding to legitimate traffic. However, this side effect has been remedied in modern version of the majority of operating systems in use. The developers simply coded the kernel to limit the amount of connection attempts that could be made from one ip address. While this eliminates the danger of inadvertently disabling the host, is does hold another hazard for the scanner. If you were to scan to many ports on a given system, you will eventually reach the threshold of half open connections allowed on the host, consequently ending your scan. To deal with this problems, the hacking community simply began limiting the scan to only ports that will be relevant for their attack, instead of the large range of ports that would trigger the os's ip filtering methods.


Xmas, FIN, and NULL scanning

While Xmas, FIN, and NULL scans are among the most undetected by intrusion detection systems, they are also among the most unreliable. Unreliable in the fact that a multitude of different conditions could result in the scanning software reading the port as open, when it is in fact not. Illustrations for the Xmas scan are shown below:

Xmas scan directed at open port:

192.5.5.92:4031 -----------------------FIN/URG/PSH--------------->192.5.5.110:23
192.5.5.92:4031 <---------------------NO RESPONSE---------------192.5.5.110:23

Xmas scan directed at closed port:

192.5.5.92:4031 ----------------------FIN/URG/PSH--------------->192.5.5.110:23
192.5.5.92:4031<--------------------------RST/ACK-----------------192.5.5.110:23

As you can see, the xmas tree scan simply sets the initial tcp packets control flags to FIN ( Finish ), URG ( Urgent ), and PSH ( Push ). If a system's tcp/ip implementation is developed according to RFC 793, then the above packet sent to an open port will not elicit a response from the host. Where as if the port is in state closed, the remote host will reply with a RST/ACK. Given this, we can assume any port scanned on an active host that does not return a response to the client system is in state open.

One disadvantage to this technique was partially discussed in the above paragraph, the system's tcp/ip implementation MUST correspond with RFC standard 793. As such, this method will not work against any current version of Microsoft Windows. Xmas scans directed at any Microsoft system will show all ports on the host as being closed. This is because Microsoft followed their usual habit of negating inter-compatibility standards and go about their merry way with their coding. When a Microsoft system receives an xmas packet, it will respond with a RST/ACK, regardless of whether or not the port is open or closed. Since an xmas scan deems that a response from the remote host indicates a closed port, a Microsoft system is invulnerable to the xmas tree scan, as it will show all ports closed regardless of their state.


FIN and NULL scans

Both the FIN and NULL scans work on exactly the same principle as the Xmas scan, with the exception of the initiating packet structure. As you may have guessed, the initiation of the FIN scan is simply a tcp packet with only the FIN flag set, and a NULL scan begins with a packet that has no flags set. The actual process of determining the ports state is identical to that of the Xmas scan. For those still interested, examples of both the FIN and the NULL scans are below:

FIN scan directed at open port:

   
192.5.5.92:4031--------------------------------FIN--------------------------->192.5.5.110:23
192.5.5.92:4031<---------------------NO RESPONSE-----------------------192.5.5.110:23

FIN scan directed at closed port:

192.5.5.92:4031-------------------------------FIN--------------------------->192.5.5.110:23
192.5.5.92:4031<---------------------------RST/ACK-----------------------192.5.5.110:23

NULL scan directed at open port:

192.5.5.92:4031----------------------NO FLAGS SET--------------------->192.5.5.110:23
192.5.5.92:4031<---------------------NO RESPONSE-----------------------192.5.5.110:23

NULL scan directed at closed port:

192.5.5.92:4031-----------------------NO FLAGS SET------------------->192.5.5.110:23
192.5.5.92:4031<---------------------------RST/ACK-----------------------192.5.5.110:23

As you can see, the process of determining closed and open ports is identical to that of the Xmas scan. So in the light, it also falls prey to the same limitations that its predecessor does, it cannot be used against non RFC compliant systems, such as Microsoft Windows. The positive aspect of this limitation is that even though it cannot be used to determine a remote operating system, and can be used to determine what the remote operating system is not. For example if you were to scan a host that you know to be active, and the result is that of all remote ports being closed, it can safely be assumed that the remote system is non RFC compliant, so more than likely, is Windows.

Another problem that lies within these types of scans is that the majority of firewalls in use on the internet today will not send back the standard RST/ACK when an Xmas, FIN, or NULL packet hits a filtered port. It simply drops the packet and continues on with its business. The problem being that these scans take the absence of a response to mean that the port is open and listening. So any of these scans directed at a firewalled system will result in the scan showing all attempted ports as being open. Obviously not very effective as far as enumeration goes. Never the less, these three scans remain a powerful, and extremely stealth way to enumerate a remote system's ports.














Your IP address will be sent with this e-mail

From e-mail to e-mail