Document ID: /fineweb-2-swissfilter-quality_10-filterrobots/filtered/03287.jsonl.gz/842

totemomail
Mark Zeman
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.
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.
Zwei Arten, auf die TCP Timestamps momentan hauptsächlich in einem Angriff verwendet werden:
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=<ip-pii> ttl=64 DF id=0 sport=80 flags=SA seq=0 win=14480 rtt=1.3 ms TCP Timestamp: tcpts=500722
len=56 ip=<ip-pii> 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=<ip-pii> 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=<ip-pii> 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:
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.
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.
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:
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:
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.
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.
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.
Unsere Spezialisten kontaktieren Sie gern!
Mark Zeman
Marisa Tschopp
Tomaso Vasella
Marc Ruef
Unsere Spezialisten kontaktieren Sie gern!
Weitere Artikel im Archiv