25C3: "Denial of Service"-Schwachstellen in TCP näher beleuchtet

Seit Herbst machen Berichte über die Anfälligkeit des TCP (Transmission Control Protocol) für "Denial of Service"-Attacken die Runde, die aber nach wie vor größtenteils auf Spekulationen basieren. Auf dem 25. Chaos Communication Congress (25C3) in Berlin stellte Fabian Yamaguchi von der Hackergruppe Phenoelit nun denkbare und getestete Szenarien für derartige Angriffe auf das grundlegende Internetprotokoll sowie erste Tipps zur Abhilfe vor. Die nicht zu vernachlässigenden "Bugs" sind demnach vielfach in TCP-Implementierungen zu suchen, werden aber auch durch das grundsätzliche Design des Protokolls begünstigt.

Die Internetpioniere Robert Kahn und Vint Cerf entwickelten TCP in den 1970ern letztlich in militärischem Auftrag. Die erste Standardisierung erfolgte 1981. "Verfügbarkeit war dabei ein großes Thema", erläuterte Yamaguchi. Gemäß dem Ende-zu-Ende-Paradigma werde mit TCP die Intelligenz von Anwendungen in die Endknoten des Netzes verlagert; das Protokoll setze insgesamt auf dezentrale Strukturen. Mit Teenagern, die von ihren Kellerzimmern aus Zugang zum Netzwerk haben und sich DoS-Attacken ausdenken, hätten die TCP-Erfinder aber nicht gerechnet. Es seien zwar Funktionen zur Feststellung von Datenquellen und zur richtigen Aneinanderreihung von Paketen in das Protokoll eingebaut worden, dabei handle es sich aber nicht um Sicherheitsfunktionen.Schon seit längerem ist bekannt, dass TCP mit sogenannten Reset-Attacken angreifbar ist. Paul Watson demonstrierte diese Schwachstelle 2004. Demnach musste ein Angreifer nur die Übertragungsnummer von Paketen kennen, um einen Abbruch des Transfers bewerkstelligen zu können. Als Gegenmaßnahme einigten sich die Experten unter anderem auf eine nicht ganz wasserdichte Protokollerweiterung für höhere Leistungsanforderungen sowie auf die zufällige Generierung von Quelladressen (Source Port Randomization).

Damit ist TCP laut Yamaguchi aber keineswegs wetterfest. Grundsätzlich sei es bei dem Netzprotokoll wünschenswert, so viele Verbindungen wie nur möglich gleichzeitig laufen zu lassen. Entwickler hätten daher im Nachhinein eine "Backlog"-Funktion eingebaut, die sich nicht in der originalen Spezifikation befunden habe. Sie greife ein, wenn zu viele Verbindungen bestünden und eine Überlastung des Speichers des betroffenen Servers drohe. Es sei aber leicht, dieses künstliche Limit an seine eigenen Grenzen zu bringen. Traditionell könne dies per SYN-Flooding erfolgen, wobei Verbindungen bewusst halboffen gehalten und so die Ressourcen aufgebraucht werden. Für einen solchen DoS-Angriff gebe es inzwischen bekannte Abhilfen.

Schwieriger beizukommen ist dem Sicherheitsforscher zufolge dem ähnlich gelagerten Fall des "Connection Flooding". Dabei würden Verbindungen angeleiert, die der Server dann nicht schnell genug alle akzeptieren könne. Die Verantwortung für Gegenmaßnahmen liege hier nicht bei einem Webadministrator, sondern beim Entwickler TCP-basierter Dienste. Dieser müsse dafür sorgen, dass eine entsprechende Anwendung etwa nicht 5000 Verbindungen gleichzeitig annehme und die Phase zur Signalisierung der Annahme einer Anfrage kurz bemessen sei. Bisher seien die Spannen bis zum Abbruch mit sieben bis zehn Minuten deutlich zu lang angesetzt. Implementierungsfehler könnten derlei Überflutungsangriffe noch einfacher machen. Der Mechanismus zur Datenflusskontrolle etwa hänge sich in der Regel auf, wenn er die (manipulierte) Information erhalte, dass nur noch wenige Bytes im Speicher frei seien. Ferner könnten Verbindungen angeleiert werden, die auf der Sitzungsschicht des Kommunikationsprotokolls gar nicht herzustellen seien.

Eine andere Form der Attacke kann sich gemäß den Ausführungen des Experten auf das Verfahren konzentrieren, mit dem kontrolliert werden soll, wie viele Daten TCP in ein Netzwerk leitet. Schon in den Achtzigern seien an dieser Stelle Zusammenbrüche aufgrund von Verstopfungen vorgekommen. Möglich sei dies etwa, indem ein Angreifer eine Gigabit-Leitung vortäusche und sich so auf der Empfangsseite das TCP-Fenster aufgrund der Verstopfungsgefahr weit öffne. So sei das Netzwerk tatsächlich zu überfluten. Man könne auch den Empfang eines Pakets quittieren, bevor es wirklich angekommen sei, und so die Sendefrequenz gefährlich erhöhen. Der Forscher Rob Sherwood habe zu diesen Verstopfungsproblemen bereits eine Studie veröffentlicht und Abwehrmittel aufgezeigt, die aber bislang unbeachtet geblieben seien.

Größtes Problem bei dieser Angriffsform ist laut Yamaguchi, dass für eine echte Abhilfe die TCP-Protokollarchitekturen weltweit geändert werden müssten. Der Datenempfänger habe dazu einen Nachweis mithilfe einer Prüfsumme zu erbringen, dass er gewisse Pakete tatsächlich empfangen hat. Es gebe zwar auch eine rückwärts kompatible Lösung, die aber neue Probleme aufwerfen könne und erst weiter zu erforschen sei. Beim Ausblick auf künftige Attacken verwies der Hacker erneut auf die Datenflusskontrolle, die auch durch eine große, auf einen Schlag überbrachte Datensendung lahm zu legen sei. Danach würde automatisch das nächste Paket nicht mehr verarbeitet.

Yamaguchis Boss FX betonte, dass die auch im Fall der schweren Probleme mit dem Domain Name System (DNS) von Dan Kaminsky praktizierte Teilenthüllung von Schwachstellen wenig hilfreich sei. Sicherheitsfirmen konfrontiere sie mit teils "panischen" Kunden, denen man zunächst nicht weiterhelfen könne. Nach den Gerüchten über die TCP-Lücken habe er daher die Phenoelit-Forschungsabteilung um Aufklärung gebeten.