TCP sequence number prediction difficulty, and guessed operating system. nmap –O sparky

(The 1495 ports scanned but not shown below are in state: closed)

TCP Sequence Prediction: Class=random positive increments Difficulty=46112 (Worthy challenge)

Remote OS guesses: Solaris 2.6 - 2.7, Solaris 7

Using nmap –O to scan the Solaris host sparky and identify the operating system discovers that the generation of initial sequence numbers is based on a formula using "random positive increments." And, it reports that predicting a new TCP sequence number would be a "worthy challenge." Sparky is a Solaris 2.7 host, and it appears to be fairly impervious to someone

guessing a new TCP sequence number based on a previous one or based on time.

Acknowledgement Numbers

The method that TCP uses to ensure that data is received is via an acknowledgement. The receiving host sets the acknowledgement flag and the acknowledgement number, which are validation that the receiving host did indeed get the data. The acknowledgement number sent by the receiving host actually represents the next expected TCP sequence number it should receive.

Because a SYN connection consumes one sequence number, and because the acknowledgement value is one more than this sequence number, a valid acknowledgement number must be greater than 0. There is one rare qualification of this. It is possible to use all 2 billion plus TCP sequence numbers available with the 32-bit field in which they are stored. If, by chance, the last TCP sequence number sent is the largest 32-bit number allowed, the receiving host wraps around and acknowledges that the next expected sequence number is 0. This is an infrequent occurrence.

Nmap can attempt to identify live hosts by sending a remote host a TCP connection with an unsolicited ACK flag set. This method of host identification is often more successful than pinging the host because many sites now block inbound ICMP echo requests. Yet, a router that doesn't maintain state may allow in "established" traffic in which the ACK flag is set. The desired response to the unsolicited ACK is a RESET from the remote host, which indeed indicates that the remote host is alive regardless of whether the scanned port is listening. Current versions of nmap have a telltale signature because the ACK flag is set, yet the acknowledgement number is

0 as shown in the following output.

verbo.52776 > win98.netbios-ssn: . ack 0 win 4096 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>

TCP Flags

TCP flags are used to indicate the function of a given TCP connection or session. The SYN flag starts a session and the FIN flag terminates a session gracefully. A RESET is used to abort a session. The ACK flag is set to indicate an acknowledgement of data by the receiver. The ACK flag is set on all packets after the initial SYN. The PUSH flag is typically used to tell the sending host to write all of its buffered data to send to the destination host and for the destination host to PUSH it up to the TCP layer. It is actually possible to send data without the PUSH flag set when all of the data in the sending buffer is not completely emptied. Finally, the URGENT flag is used to indicate that data has the highest priority.

The TCP flags have many different valid combinations. And, there are many different invalid

combinations that are used for different purposes. Early in the evolution of NIDS, many would examine traffic for initial SYN attempts only. Scanners realized this and would send a SYN/FIN combination that might elicit a response from a host. Different operating system TCP/IP stacks respond differently to mutant flag settings, so this is used to attempt to fingerprint the operating system. We will examine some of the situations in which valid and invalid flag combinations can occur over the next several sections.

TCP Corruption

Just because you see mutant TCP flag combinations, it is not necessarily an indication of malicious behavior. Packets can and do get corrupted, and it is possible for TCP flags to be unnaturally set after some kind of corruption in the TCP portion of the packet.

Look at the following packet received on a Shadow NIDS. This was an attempted Napster

connection back in the days when Napster was a free and legal method of exchanging MP3s: host.home.com.1310 > napster.com.6699: SRP [bad hdr length] (DF)

There are two anomalies that stand out looking at the record. The first is the mutant flag

settings of SRP, meaning that all three of the SYN, RESET, and PUSH flags are set simultaneously. The next sign is TCPdump's notation of bad hdr length.

A bad hdr length is an error generated by TCPdump when the specified TCP header length is

greater than the actual TCP segment (header and data) length. Because there is no field in the IP datagram that holds the value of the TCP segment length (header and data), TCPdump computes this value by using fields it does have. It subtracts the IP header length from the IP datagram total length. For properly formatted packets, this reflects the true TCP segment length. One of the validity checks performed by TCPdump is to test if the packet's specified TCP header length in bytes is greater than the computed TCP segment length. If this comparison is true, there is something definitely wrong with a length field, and that is when the bad hdr

length error is displayed.

It will be become apparent why TCPdump believes this by examining the following hex dump output. First, the IP header is contained between the brackets and the TCP header between the

less than and greater than signs:

[4500 0028 8974 4000 7406 a9c5 1804 ee22 80f4 4c7b] <051e 1a2b 0000 029d 9efe a721 a7ae 5010 2058 ac31 0047 0050>

Now let's turn our attention to the length fields in the packet. First, look at the IP total datagram length in the bolded 2nd and 3rd bytes offset of the IP header. You should see a 0x28 or 40-byte IP datagram length. The IP header length is found in the bolded low-order nibble of the 0 byte offset of the IP header. As we know, this value of 5 represents a 20-byte IP header. The protocol field in the 9th byte offset of the IP header has been bolded to highlight the embedded protocol. Because we discover a 06 in that field, we know that a TCP header follows. The computed TCP segment length is then 40–20, giving us 20 bytes for TCP header and data. This is room enough for a TCP header with no options and no data such as might be found on a plain SYN attempt.

Yet, in the TCP header length, we find a length of 0xa in the bolded high-order nibble of the 12th byte offset, which indicates a 40-byte TCP header after we multiply it by 4 to translate

from 32-bit words to bytes.

Using these fields, do you know why TCPdump generates the bad hdr length error? This is a

datagram with a total length of 40, including a 20-byte IP header length, yet a TCP header that professes to be 40 bytes. We need a minimum IP datagram length of 60 to house this data if indeed there has been no corruption.

Is it possible that this packet has been corrupted and the checksum is invalid? Remember, if this involved packet corruption in the TCP header or data, the only host that will detect this is the destination host. The NIDS sensor typically does not validate a TCP checksum.

Here is what we can deduce about this packet. Chances are that the IP header is fine because

the previous router did not drop it. Routers are supposed to validate the IP checksums and silently drop packets with inaccurate ones. Now, before reaching the destination host and having the TCP checksum validated, it passes by the sensor where TCPdump finds a problem with it. It is possible that the router corrupted the IP header after the checksum was computed, but the header otherwise appears to be normal.

At this point, we don't know if the packet has been accidentally corrupted or intentionally corrupted for whatever reason. The only other ways to verify packet corruption is to manually compute the checksum of the received packet on the sensor or examine how the receiving host (napster.com) reacts. The problem with looking at how napster.com reacts is that if the checksum is invalid, we will see no response. Yet, if the checksum is valid, this weird combination of flags might not elicit a response either. If we do observe an unlikely response from napster.com (most likely a RESET), this means that the checksum is valid and the packet wasn't corrupted on route from source to destination. This means that the packet was most likely crafted with mutant values at the source. Too, there is always the possibility of cleanly swapped 16-bit fields that would corrupt the packet, but there would be no manifestation of it in the checksum.

Vern Paxson, creator of an IDS named Bro, talks of traffic he has labeled "crud" in his paper "Bro: A System for Detecting Network Intruders in Real-Time." His definition of crud is "innocuous implementation errors" that create traffic pattern pathologies that look similar to genuine attacks. He cites examples of an errant TCP/IP stack that routinely sets the URG flag on a SYN attempt and another that sets the DF flag on traffic fragments. Although this is different than packet corruption, the important point to keep in mind is that not all-anomalous traffic you witness is malicious. It is remotely possible that a very small amount is due to corruption, or crud.

ECN Flag Bits

Until very recently, the two high-order bits of the TCP byte were known as the reserved bits. They had no purpose, and the value found in the bits should have been 0. However, when tools such as nmap came along, it was discovered that these bits could be used to try to help fingerprint a remote operating system. Different operating system TCP/IP stacks would respond uniquely when these bits were set.

Some would reset the bits to 0, and others would simply leave them with the current value. Hence, some insight could be made of the remote host's operating system TCP/IP stack. This alone might not be enough to inform the scanner of the operating system, but used in conjunction with several other tests, the operating system could be conjectured with a high probability.

Remember back when we were discussing the differentiated services byte in

"Examining IP Header Fields," we introduced a new purpose for the two low-order bits known as Explicit Congestion Notification (ECN)? The intent was for a router to be able to notify a sender that there was congestion in the network and to reduce its sending rate.

How exactly does that occur? Currently, as discussed in the ECN RFC 3168, the only transport capable of reacting to that congestion notification is TCP. So, TCP must be prepared to deal with this. The RFC offers using the two high-order bits of the TCP flag byte (see Figure 9.3) as fields for ECN. The bit to the right of the high-order bit is known as the ECN-echo bit. This bit is turned on when TCP receives a packet that has the Congestion Experienced bits set in the differentiated services byte of the IP header. This means that both end-points of the TCP conversation are ECN-capable, which is determined during the three-way handshake.

Figure 9.3. The ECN bits of the TCP flag byte.

If TCP sets the ECN-echo bit, the purpose is to inform the sender to reduce the rate at which it is sending data because there is congestion between the sender and receiver. Upon receipt of a TCP segment with the ECN-echo bit set, the sender reduces its congestion window, the size of the sending buffer, by half. After it reacts in this manner, it turns on the Congestion Window Reduced (CWR) bit to inform the other side of the conversation that remedial action to reduce congestion has occurred. This bit is found in the high-order bit of the TCP byte flag.

Although this mechanism helps reduce the number of packets dropped, it is anticipated that many existing NIDS will begin to alarm on these new TCP flag bytes being used. Right now, most uses of these bits are for scanning purposes only. Also, some packet-filtering devices will not allow inbound TCP segments with these bits set. So, much customization will have to be done to smoothly introduce ECN and distinguish it from the rogue scans.

Operating System Fingerprinting

When nmap is placed in operating system fingerprinting mode with the –O option, it sends some mutant flag combinations when an open port is discovered. Look at the following output

from nmap remote operating system scans: nmap –O win98

20:33:16.409759 verbo.47322 > win98.netbios-ssn: SFP 861966446:861966446(0) win 3072 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>

20:33:16.410387 win98.netbios-ssn > verbo.47322: S 49904150:49904150(0) ack 861966447 win 8215 <mss 1460> (DF)

nmap –O sparky

20:37:00.738412 verbo.50107 > sparky.echo: SFP 2326441544:2326441544(0) win 2048 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567[|tcp]>

nmap –O linux

20:44:50.370158 verbo.42318 > linux.ftp: SFP 1749165064:1749165064(0) win 1024 urg 0 <wscale 10,nop,mss 265,timestamp 1061109567 0,eol>

In the first scan of a Windows 98 host, the mutant flag combination of SYN/FIN/PUSH/URG is sent to the Windows port 139. This is a NetBIOS session service port, and the Windows host listens on this port. Yet, amazingly enough, it responds with an acknowledgement! This behavior is not what we expect.

In the second nmap scan, the same technique of sending the mutant combination of SYN/FIN/PUSH/URG flags to a listening Solaris port (echo) is attempted, and no response is elicited. This same combination of flags is sent to a listening Linux ftp port in the third scan, and no response is received. This is the expected behavior, which conforms to RFC specifications.