Before any attack is launched an attacker tries to get as much information about the target as possible. It will be done by passive information gathering like Google dorking as well as active information gathering, like port scanning. Information gathering using TCP timestamps is considered active information gathering, since it interacts directly with the systems. First we will take a closer look at what TCP timestamps are and how they work. Then we will discuss ways how TCP timestamps have been used, to then move on to how networks have changed and how that has introduced new challenges to information gathering. Last we will introduce a not previously published way to utilize TCP timestamps and also how to mitigate these attacks.

TCP timestamps

If at any point in the article it states just “timestamp” then it refers to TCP timestamps. TCP timestamps as defined in RFC 1323 are an extension of the original TCP Stack. They were introduced to protect against wrapped sequence numbers and to improve Round Trip-Time Measurement. The timestamp echo reply is sent in any ACK or data segment. A TCP timestamps option (TSOpt) looks like this:

Kind: 8
Length: 10 bytes

    +-------+-------+---------------------+---------------------+
    |Kind=8 |  10   |   TS Value (TSval)  |TS Echo Reply (TSecr)|
    +-------+-------+---------------------+---------------------+
        1       1              4                     4

Quote RFC 1323:

The Timestamps option carries two four-byte timestamp fields. The Timestamp Value field (TSval) contains the current value of the timestamp clock of the TCP sending the option.

The Timestamp Echo Reply field (TSecr) is only valid if the ACK bit is set in the TCP header; if it is valid, it echos a timestamp value that was sent by the remote TCP in the TSval field of a Timestamps option.

Information Gathering

There are two main ways TCP timestamps have been used until today to help during attacks on systems:

1. Uptime calculation
2. Host identification using clock skew

Most systems start with timestamp 0 when they are booted. From multiple timestamps it is possible to infer the frequency. Frequency and the actual timestamp then can be used to calculate uptime. The tool hping3 does all of this for you.

# hping3 -c 4 -S -p <open port> --tcp-timestamp <ip>

The output will give you the actual timestamp, the frequency and the uptime:

len=56 ip=172.20.75.36 ttl=64 DF id=0 sport=80 flags=SA seq=0 win=14480 rtt=1.3 ms
  TCP timestamp: tcpts=500722
len=56 ip=172.20.75.36 ttl=64 DF id=0 sport=80 flags=SA seq=1 win=14480 rtt=1.1 ms
  TCP timestamp: tcpts=500972
  HZ seems hz=100
  System uptime seems: 0 days, 1 hours, 23 minutes, 29 seconds
len=56 ip=172.20.75.36 ttl=64 DF id=0 sport=80 flags=SA seq=2 win=14480 rtt=1.0 ms
  TCP timestamp: tcpts=501222
  HZ seems hz=100
  System uptime seems: 0 days, 1 hours, 23 minutes, 32 seconds
len=56 ip=172.20.75.36 ttl=64 DF id=0 sport=80 flags=SA seq=3 win=14480 rtt=1.0 ms
  TCP timestamp: tcpts=501472
  HZ seems hz=100
  System uptime seems: 0 days, 1 hours, 23 minutes, 34 seconds

Knowing the uptime can be utilized in various ways.

• It can confirm if a DoS-Attack has been successful, by comparing uptime before and after.
• It can also help you determine the patch level of the system.

If you have fingerprinted the system properly you have a good chance of knowing if this system has to be rebooted for applying patches. Keep in mind that it is not a requirement of TCP timestamps to start at 0 at boot time. It is theoretically possible to set a random start value.

Network Layout Information Gathering

Systems used to often connect directly to the internet. Nowadays systems usually connect to the internet through firewalls. Firewalls often use Network Address Translation , short NAT. NAT translates an IP address from one network to an IP address of another network. For example: the internal server DMZ to the Internet. This IP is then used throughout the internet. But firewalls have more features, one of which is that different servers can have one outgoing IP address, by using different ports.

Network mapping has been a topic of research that was limited by the scenario above. My research has overcome this problem using the attacks described below.

First, let’s gather some information about the network layout despite the firewall. We will send valid TSOpts to the server and there are three possible cases, if we’ve received TSval in the <SYN,ACK> packet on two different ports on the same IP:

1. Timestamps are different
2. Timestamps are the same
3. At least one port doesn’t answer with set TSopts

Since timestamps are continuously increasing (strong monotony is required from the clock) and timestamps are incremented somewhere in the range of milliseconds, it is highly unlikely that two systems are having a timestamp difference of less than a second, so we will call it “same”. Knowing that we can determine which ports of an externally facing IP belong to the same system behind the firewall. Let us look at each case:

1. It is very likely that timestamps are coming from different systems
2. It is likely that timestamps are coming from the same system
3. If only one port responds without set TCP timestamp options, it is safe to assume that two different systems are responding. If TSopts are not included in the answer or TSval = 0 on both ports, then no knowledge can be gained, because it could be the same system having timestamps disabled or timestamps got disabled on all systems.

This information gives us an idea of how the target structures their DMZ.

Second, one bit of information that is helpful if not necessary before attacking is to know the running operating system of a server. For that a technique called fingerprinting is used. Just like a human fingerprint, a computer has a fingerprint based on the running services, TTL, the way a server responds to a closed port during port scanning, etc.

For example: A server is running Microsoft IIS. It has an initial TTL guess of 80. Therefore it is likely a Microsoft Windows.

Fingerprinting functionalities, as used in port scanners like nmap, often assume that the IP being scanned is one system only. The problem, depicted in scenario in figure 1 ,is that multiple systems behind a firewall are NAT-ed to one IP address and thus create an unusable fingerprint. As shown, we can determine if one or multiple systems are NAT-ed through one IP. Using only ports that belong to one system, will likely eliminate closed ports as sources, but will remove the noise from having other systems in the fingerprint, und thus result in a clearer fingerprint.

There is a Proof-of-Concept (PoC)-Script that reads the tcp-timestamp and based on that returns if there are services running on different servers.

Known problems are that some firewalls end the tcp connection and then build a new one – the timestamp is then of the firewall or reverse-proxy and thus it is impossible to find out more about the network behind the firewall using timestamps. Another known problem: If multiple servers are run virtually on the same machine, they can have almost same timestamps.

Proof of concept:

The setup is a monowall with one external facing IP address, having port 80 and 443 binding to a Windows 2012 R2 Server with IIS 8.5 and port 22 and 8082 binding to a Debian running SSH and Apache.

The first screenshot shows a garbled, useless fingerprint. This occurs when all ports are used for fingerprinting. The other two show fingerprints, one for each system that we were able to identify using TCP timestamps.

As side note: Don’t let nmap fool you – a closed port is a good idea when fingerprinting a host directly. This is not the case anymore when the device is behind a firewall.

A special way of network layout information gathering is load-balance checking for a service. While there are several ways of figuring it out, TCP timestamps offer us another way to access that information. As seen in multiple systems on multiple ports, if there are multiple timestamps on one port, the service is likely to be active-active load-balanced.

Mitigation

Currently the best way to defend against all possible information gathering done using TCP timestamps is disabling them, which comes with the cost of lost Protection Against Wrapped Sequence numbers (PAWS) and less good Round-Trip Time Measurement (RTTM).

Disabling timestamps can be done under Linux using:

# echo 0 > /proc/sys/net/ipv4/tcp_timestamps

On Windows servers they can be disabled by setting:

Tcp1323Opts = 0

A proper solution to the above described problems does not currently exist.

• Update May 8th, 2015: Update chapter Network Layout Information Gathering to highlight that this attack is new.

About the Author

Veit Hailperin has been working in information security since 2010. His research focuses on network and application layer security and the protection of privacy. He presents his findings at conferences.

Links

• http://en.wikipedia.org/wiki/Network_address_translation
• http://nmap.org/book/os-detect.html
• http://nmap.org/man/man-port-scanning-techniques.html
• http://www.caida.org/publications/papers/2005/fingerprinting/KohnoBroidoClaffy05-devicefingerprinting.pdf
• http://www.exploit-db.com/google-dorks/
• http://www.ietf.org/rfc/rfc1323.txt
• http://www.m0n0.ch
• http://www.nmap.org
• https://github.com/luh2/timestamps/blob/master/identify-hosts.py
• https://www.scip.ch/labs/images/tcp_timestamps_beispiel_netzwerk_h_1200.png