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

Seit Herbst machen Berichte über die Anfälligkeit des grundlegenden Internetprotokolls für DoS-Attacken die Runde; ein Sicherheitsexperte stellte auf dem Berliner Hackertreffen nun denkbare Szenarien und Tipps zur Abhilfe vor.

In Pocket speichern vorlesen Druckansicht 78 Kommentare lesen
Lesezeit: 5 Min.
Von
  • Stefan Krempl

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 Recurity Labs 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 Sequenznummer von Paketen kennen, um einen Abbruch des Transfers bewerkstelligen zu können. Auf Grund von Performanceoptimierungen wie der variablen Fenstergröße lässt sich diese jedoch leichter erraten als angenommen. Als Gegenmaßnahme einigten sich die Experten vor allem darauf, dass man die Quell-Ports von TCP-Anfragen zufällig wählen sollte – wer sich dabei an das DNS-Problem erinnert fühlt, liegt durchaus richtig.

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 bearbeiten 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 nicht etwa 5000 Verbindungen gleichzeitig annehme. Auf Grund der systeminternen Timeouts beim Abbau von Verbindungen (FIN_WAIT1, FIN_WAIT2, LAST_ACK, etc.), die bis zu zehn Minuten betragen können, eröffnet sich sonst beispielsweise die Möglichkeit, mit sehr kurzlebigen Verbindungen, Systemressourcen zu blockieren. Implementierungsfehler könnten derlei Überflutungsangriffe noch einfacher machen.

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.

Zum 25C3 siehe auch:

(Stefan Krempl) / (pmz)