Weitere Details und Schutzmaßnahmen zur TCP-Schwachstelle

Dass TCP ein unsicheres Protokoll ist und mehrere Schwachstellen enthält, ist nicht wirklich neu. TCP ordnet einzelne Pakete einer Verbindung aufgrund der Sequenznummern zu. So lassen sich Daten in bestehenden Verbindungen manipulieren, indem man denselben TCP-Header mit veränderten Nutzdaten sendet. Ein Angreifer muss dazu nur die initiale Sequenznummer -- also den Startwert der Sequenznummer (Initial Sequence Number ISN) -- der Verbindung erraten und davon ausgehend selbst eine aktuell gültige Sequenznummer errechnen. Frühere Implementierungen nach RFC 793 generierten ISNs durch das Erhöhen interner Zähler, womit sie leicht vorhersagbar waren. Hat man eine bestehende Verbindung zu einem Server, so kann man anhand seiner eigenen ISN die ISN anderer Verbindungen erraten. Die darauf basierenden TCP-Sequenznummerattacken sind seit 1985 bekannt. Um das Vorhersagen der Nummern zu erschweren, greift man heute auf Pseudo-Zufallszahlen-Generatoren zurück.

Allerdings wies schon im März 2001 CERT/CC auf die statistische Schwäche von TCP-Sequenznummern-Generatoren in der Implementierung einiger Hersteller hin: Mit statistischen Analysen ließen sich die ISNs trotzdem erraten. Paul Watson hat dazu nun weitergehende Untersuchungen angestellt und die TCP-Window-Size zur Vorhersage hinzugezogen. Ergebnis ist der Artikel "Slipping In The Window: TCP Reset Attacks" und ein Proof-of-Concept-Tool, um TCP-Verbindungen unautorisiert zu beenden. Allerdings sind RST-Attacken auch schon seit 1995 bekannt: Simple Active Attack Against TCP.

RST-Pakete zum Beenden einer Verbindung sind an sich nichts Schlimmes, lassen sich aber mit obigen Tricks für Denial-of-Service-Attacken verwenden. Meist sind die Auswirkungen gering: Wird eine Client-Server-Verbindung terminiert, so baut sie der Client automatisch wieder auf. Anders bei Verbindungen zwischen Internet-Routern die das Border Gateway Protocol (BGP) zur Übertragung von Routing-Informationen verwenden. BGP benutzt langlebige persistente Verbindungen, die oft nicht einmal kryptographisch geschützt sind. Nach dem Abbruch einer Verbindung nimmt der Router zwar sofort wieder Kontakt mit seinen Nachbarn auf, allerdings aktualisiert er erst einmal seine Routing-Tabelle -- und das kann dauern. In der Folge kann das Routing in Teilen des Internet für kurze Zeit zusammenbrechen.

Paul Watson hat eine Überschlagsrechnung angestellt, wie schnell ein solcher Angriff vonstatten geht: Mit einer DSL-Verbindung sei es möglich, alle 5 Minuten ein gültiges Paket zum Beenden einer BGP-Session zu verschicken, mit einer T1-Leitung (1,544 MBit/s) sogar alle 15 Sekunden. Setzt man Bot-Netze für solche Angriffe ein, verkürzt sich der Zeitraum noch weiter.

Über Angriffe gegen BGP und deren Abwehr wird seit langem diskutiert. Möglich ist es, BGP-Pakete nach RFC 2385 mit MD5-Hashes zu authentifizieren: Beide Peers sind im Besitz eines geheimen Schlüssels, um zu prüfen, ob die Pakete echt sind. Auch der Einsatz von IPSec zum Tunneln der BGP-Pakete ist denkbar, allerdings auf Kosten der Performance. SSL/TLS und SSH eignen sich nicht zum Schutz von BGP-Sessions, da sie selbst über TCP transportiert werden -- eine Reset ist weiterhin möglich. Am naheliegendsten ist es, seine Router zu schützen, in dem man RST-Pakete von außen gar nicht erst zum Router gelangen lässt. Paketfilter stellen sicher, dass nur definierte Router miteinander reden dürfen.

Siehe dazu auch: (dab)

• TCP-Schwachstelle ermöglicht Reset-Attacken auf Internet-Schaltstellen auf heise Security
• Vulnerabilities in TCP vom US-CERT
• RFC 1948 -- Defending Against Sequence Number Attacks
• The Border Gateway Protocol relies on persistent TCP sessions without specifying authentication requirements vom US-CERT