Bevor ein Hackangriff gestartet wird, sammelt ein Angreifer möglichst viele Informationen über sein Ziel. Dies kann durch passive oder aktive Informationssammlung geschehen. Unter passiver Informationssammlung fällt unter anderem Google dorking und unter aktiver Informationssammlung zum Beispiel port scanning. Informationsbeschaffung mittels TCP Timestamps fällt in die Kategorie der aktiven Informationssammlung, da es direkt mit den Systemen kommuniziert.

Als Erstes werden wir uns mit der Funktionsweise von TCP Timestamps vertrauen. Anschliessend zeigen wir mehrere Arten des Missbrauchs von TCP Timestamps welche bereits vorhanden sind und wie sich die veränderte Netzwerklandschaft darauf auswirkt. Als Letztes wollen wir zwei bisher unveröffentlichte Arten des Missbrauchs aufzeigen und auch wie man sich zumindest teilweise dagegen schützt.

TCP Timestamps

Wenn innerhalb des Textes nur von “Timestamp” gesprochen wird, so ist immer der TCP Timestamp gemeint. TCP Timestamps, definiert in RFC 1323, sind eine Erweiterung des ursprünglichen TCP Stacks. Sie wurden eingeführt um das Problem der Wrapped Sequence Numbers zu adressieren und die Messung der Round Trip-Time zu verbessern. Der Timestamps Echo Reply wird in jedem ACK oder Datensegment übertragen. Eine sogenannte TCP Timestamps Option (TSOpt) sieht folgendermassen aus:

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.

Informationsbeschaffung

Zwei Arten, auf die TCP Timestamps momentan hauptsächlich in einem Angriff verwendet werden:

1. Laufzeitsberechnung
2. Systemidentifkation mittels clock skew

Der Grossteil aller Betriebssysteme startet beim Boot mit einem Timestamp von 0. Von mehreren Timestamps lässt sich eine Frequenz ableiten. Die Frequenz zusammen mit dem tatsächlichen Timestamp erlauben die Berechnung der Laufzeit. Das Programm hping3 erledigt dies alles in einem:

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

Die Ausgabe zeigt den gelesenen Timestamp, die Frequenz sowie die Laufzeit:

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

Das Wissen über die Laufzeit kann unter anderem auf folgende Arten verwendet werden:

• Als Bestätigung, dass ein (D)DoS-Angriff erfolgreich war, durch den Vergleich von Timestamps vor und nach Angriff
• Als Indikator über den Patchzustand des Systems.

Ist der Fingerabdruck des Systems sauber genommen worden, so lässt sich meist ermitteln ob ein Neustart zur Aktivierung eines Patches benötigt wird. Als Erinnerung: Ein gültiger TCP Timestamps muss nicht mit 0 gestartet werden. Es ist daher theoretisch möglich mit einem zufälligen Wert zu starten.

Informationsbeschaffung über den Netzwerkaufbau

Computer haben sich früher oft direkt mit dem Internet verbunden. Heutzutage stehen zwischen Computer und Internet häufig Firewalls. Firewalls verwenden häufig Network Address Translation, kurz NAT. NAT übersetzt die IP Adresse eines Netzwerks in die eines anderen, wie zum Beispiel von der internen Server DMZ zum Internet. Eine weitere Funktion von Firewalls ist meist auch mehrere Systeme auf eine externe IP abzubilden, wobei hier die einzelnen Ports weitergeleitet werden. Abbildung 1 zeigt ein solches Szenario.

Die Informationsbeschaffung über den Netzwerkaufbau wird oft auch als Network Mapping bezeichnet. Dieses Thema wurde zwar erforscht, war aber in oberem Szenario immer etwas eingeschränkt. Meine jüngsten Forschungen haben ergeben, dass sich dieses Problem auf die folgende Art überwinden lässt.

Wird Informationsbeschaffung versucht in dem gültige TSOpts an einen Server geschickt werden – trotz des Netzwerkaufbaus – so ergeben sich drei mögliche Fälle, wenn wir TSval im <SYN,ACK> Paket auf verschiedenen Ports aber gleicher IP erhalten:

1. Die Timestamps sind unterschiedlich
2. Die Timestamps sind gleich
3. Mindestens von einem der Ports wird kein TSval geschickt

Wir wissen, dass Timestamps kontinuierlich grösser werden (strikte Monotonie ist eine Anforderung des RFC) und das Timestamps hochgezählt werden im Bereich von Millisekunden. Daher ist es äusserst unwahrscheinlich (aber möglich), dass zwei Systeme einen Timestampabstand von weniger als einer Sekunde haben. Timestamps die zeitlich nah beieinander liegen nennen wir deshalb gleich. Mit diesem Wissen können wir darauf schliessen welche Ports zu welchem System gehören. Für unsere Fälle bedeutet das:

1. Die Ports gehören vermutlich zu unterschiedlichen Systemen.
2. Die Ports gehören vermutlich zum gleichen System.
3. Falls nur ein Port nicht mit TSval antwortet, so kann man mit grosser Sicherheit davon ausgehen, dass zwei Systeme antworten. Sollte auf keinem Port TSval zurückgeschickt werden, so kann keine Information gewonnen werden, da es ein System mit deaktivierten Timestamps sein könnte, aber ebenfalls mehrere Systeme auf denen keine Timestamps aktiv sind.

Diese Information liefert uns Auskunft wie das Opfer seine DMZ strukturiert.

Eine Information, die nicht nur hilfreich sondern teilweise zwingend notwendig ist, ist das auf dem Server befindliche Betriebssystem. Hierfür wird der Fingerabdruck eines Systems genommen. Wie auch bei einem menschlichen Fingerabdruck ist der Fingerabdruck aufgrund spezifischer Merkmale wie zum Beispiel laufende Dienste, TTL, die Art wie auf ein geschlossenen Port reagiert wird während eines Portscans etc.

Beispielhaft: Ein IIS Webserver antwortet auf Port 80. Der Server hat eine initiale TTL von 80. Bei diesem Server handelt es sich wahrscheinlich um ein Betriebssystem vom Typ Microsoft Windows.

Das Abnehmen eines Fingerabdrucks wird oft implementiert – zum Beispiel in Port Scannern wie nmap – in der Annahme, dass es sich um einen direkten Scan des Systems handelt.

Das Problem, das in Abbildung 1, dem Netzwerk-Layout, gezeigt wird, ist, dass mehrere Systeme mit NAT auf eine IP abgebildet werden und dadurch einen unbrauchbaren Fingerabdruck erzeugen.

Wie bereits gezeigt, können wir bestimmen, ob es sich um eines oder mehrere Systeme handelt. Da wir nur noch offene Ports verwenden können, wird der Fingerabdruck etwas unklarer, gewinnt allerdings im Gegenzug an Schärfe durch das Eliminieren anderer Systeme. Der gewonnene Fingerabdruck ist insgesamt brauchbarer geworden.

Es gibt ein Proof-of-Concept (PoC)-Script, welches den TCP Timestamp ausliest und daraufhin entscheidet, ob Dienste zum gleichen Server gehören oder nicht.

Ein mögliches Problem kann auftreten, da manche Firewalls TCP Verbindungen terminieren und eine Neue aufbauen. Der ausgelesene Timestamp ist dann jener der Firewall oder des anderen Geräts, welches die Verbindung beendet hat. Ein weiterer Störfaktor kann auftauchen, wenn mehrere Server virtuell aber auf dem gleichen Server laufen. Diese haben häufig einen ähnlichen Timestamp.

Experimentelle Daten:

Der Aufbau besteht aus einer monowall mit einer externen IP und den offenen Ports 80 und 443, die zu einem Windows 2012 R2 Server mit IIS 8.5 verbinden. Auch offen sind die Ports 22 und 8082, welche intern zu einem Debian mit Apache und SSH verbinden.

Der erste Screenshot zeigt den unkenntlichen und unbrauchbaren Fingerabdruck. Dieser entsteht durch das Einbinden aller Ports. Die folgenden Screenshots zeigen zwei Fingerabdrücke, die nach System zugeordnet wurden dank TCP Timestamps.

Randnotiz: Nmap schlägt vor, dass man einen geschlossenen Port beim Prozess einbinden sollte. Das ist nur eine gute Idee wenn man direkt auf das System zugreift, nicht aber wenn irgendwelche Geräte dazwischen stehen.

Ebenfalls interessant ist, ob ein Dienst mit Load Balancing versehen ist. Es gibt mehrere Arten dies herauszufinden, aber TCP Timestamps geben uns eine weitere Möglichkeit hierfür. Analog zu multiplen Timestamps auf einer IP vergleicht man hier aber, ob von einem Port verschiedene Timestamps geschickt werden. Hier ist vermutlich ein active-active Load-Balancing vorhanden.

Lösungsansätze

Momentan ist die beste Art, sich gegen alle in diesem Artikel beschriebenen Angriffe zu verteidigen, indem TCP Timestamps deaktivieren werden. Dies geht natürlich nur auf Kosten von verlorener Protection Against Wrapped Sequence numbers (PAWS) und schlechterem Round-Trip Time Measurement (RTTM).

Unter Linux können TCP Timestamps deaktiviert werden mit:

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

Unter Windows kann dies mit der folgenden Einstellung vorgenommen werden:

Tcp1323Opts = 0

Eine langfristige, saubere Lösung für den oben beschriebenen Missbrauch gibt es allerdings bisher nicht.

• Update: 08.05.2015: Aktualisierung des Abschnitts Informationsbeschaffung über den Netzwerkaufbau um die Neuheit des Angriffs herauszustellen.

Über den Autor

Veit Hailperin arbeitet seit 2010 im Bereich der Informationssicherheit. Seine Forschung konzentriert sich auf Network und Application Layer Security sowie auf den Schutz der Privatsphäre. Die Resultate präsentiert er an Konferenzen.

Links

• http://de.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