Channel Security

DoS-Angriffe auf den Webserver sind zum einen über entsprechende Schwachstellen, z.B. einem Pufferüberlauf beim Verarbeiten überlanger Requests, zum anderen durch eine Überlastung möglich.

DoS durch Schwachstellen im Webserver

Evtl. vorhandene Schwachstellen sollten im wesentlichen schon in den vorhergehenden Schritten, insbesondere bei der Suche nach Pufferüberlauf-Schwachstellen (siehe About Security #196), gefunden worden sein. Daher bleibt jetzt nur noch die Suche nach klassischen DoS-Schwachstellen. Zum einen sind das Schwachstellen im TCP/IP-Stack, die bereits Thema von About Security #58 ff. waren. Solche Schwachstellen treten, wenn auch sehr selten, immer wieder mal auf, werden meist aber auch früher oder später wieder behoben: Schwachstellen beim Verarbeiten von überlangen Paketen, überlappenden fragmentierten Paketen (Teardrop-Angriff), Selbst-referenzierenden Paketen (Land-Angriff), Out-of-Bank-Paketen (Nuke-Angriff) oder extrem fragmentierten Paketen. Ist ein Angreifer nicht sicher, ob ein Server überhaupt angreifbar ist, kann er auch alle Angriffe gleichzeitig starten und hoffen, dass zumindest einer davon erfolgreich ist.

Entsprechende Schwachstellen können z.B. mit Hilfe eines Fuzzers gefunden werden. Einfacher ist es, selbst auf die Suche zu verzichten und nur auf den einschlägigen Mailinglisten wie Bugtraq und Full-Disclosure, in Exploit-Sammlungen wie der Exploit Database von Offensive Security Training und der Sammlung auf Packet Storm oder im Bereich "Security aktuell" auf entwickler.de auf das Bekanntwerden entsprechender Schwachstelle zu achten. Da es sich dabei um Implementierungsfehler im TCP/IP-Stack handelt, können die Angriffe abgewehrt werden, indem präparierte Pakete von einer Firewall vor dem Webserver ausgefiltert werden. Sollte der TCP/IP-Stack der Firewall eine entsprechende Schwachstelle enthalten, ist das zum einen natürlich äußerst unangenehm, zum anderen aber auch ziemlich unwahrscheinlich, da die Komponenten einer Firewall natürlich besonders sorgfältig ausgewählt bzw. entwickelt werden, um Schwachstellen zu vermeiden.

DoS durch Überlastung

Der bekannte Slashdot-Effekt stellt im Prinzip einen (wenn auch unbeabsichtigten) DoS-Angriff durch Überlastung dar: Der Server bekommt mehr Anfragen, als er beantworten kann. Jede Webanwendung und jeder Webserver hat Kapazitätsgrenzen: Wenn der Angreifer genug Anfragen an die Webanwendung schickt, reicht z.B. die Kapazität des Speichers oder der Netzwerkverbindung oder die Rechenleistung nicht mehr aus, um weitere Anfragen entgegen zu nehmen oder in (angemessener) Zeit zu beantworten, und andere Nutzer werden an der Nutzung der Webanwendung gehindert. Dabei gilt theoretisch "Der Stärkere gewinnt": Kann der Angreifer mehr Anfragen senden als die Webanwendung verarbeiten kann, kommt es zum DoS, kann die Webanwendung mehr Anfragen verarbeiten als der Angreifer senden kann, nicht. Der Angreifer unterliegt natürlich ähnlichen Kapazitätsgrenzen wie sein Opfer: Auch seine Netzwerkverbindung kann nur eine bestimmte Menge Daten übertragen, auch sein Rechner kann nur eine bestimmte Anzahl Anfragen pro Zeiteinheit senden. Um diese Beschränkung zu umgehen, gibt es zwei Möglichkeiten: Entweder der Angreifer nutzt Schwachstellen im TCP/IP-Protokoll oder im Webserver bzw. der Webanwendung, um mit wenigen oder kurzen Anfragen eine große Wirkung zu erzielen, oder er besorgt sich (meist unfreiwillige) Helfer und startet einen Distributed Denial-of-Service-Angriff (DDoS).

Angriffe auf TCP/IP

Bei Angriffen auf den TCP/IP-Stack kommen vor allem die bereits in About Security #58 beschriebenen Angriffe über SYN- und UDP-Flooding oder Smurf- und Fraggle-Angriffe zum Einsatz. Beim Flooding werden solange halboffene Verbindungen aufgebaut, bis der Webserver keine weiteren mehr entgegen nehmen kann, bei Smurf und Fraggle führen gefälschte Anfragen an die Broadcast-Adresse des betroffenen Netzes mit der Absender-Adresse des Opfers dazu, dass alle anderen Rechner im betroffenen Netz das Opfer mit Antworten überschütten.

DDoS-Angriffe

DDoS-Angriffe werden von Botnets durchgeführt, siehe About Security #63 für die Angriffe und About Security #65 für die Botnets. Auch "normale" Schadsoftware kann dazu verwendet werden, von den infizierten Rechnern aus DDoS-Angriffe zu starten, wie es z.B. der Wurm W32.Blaster am 16. August 2003 auf Microsofts damaligen Update-Server windowsupdate.com tun sollte.

Schwachstellen in der Webanwendung ...

... wurden bereits weitgehend in About Security #240 behandelt - bis auf einen Punkt: Unvollständige Anfragen. In About Security #240 ging es um Aktionen, die mit wenig Aufwand für den Angreifer zu viel Aufwand für die Webanwendung führen. Aber auch Aktionen, die in der Webanwendung Ressourcen belegen, wenn sie nicht abgeschlossen werden, lassen sich für DoS-Angriffe nutzen. Das könnte z.B. beim Anlegen eines neuen Benutzers passieren: Die Anwendung fragt Name, Benutzername und Passwort ab, legt in der Datenbank eine neue Zeile mit diesen Daten an und fragt dann weitere Daten ab. Wird dabei ein Lock für die Tabelle mit den Nutzerdaten gesetzt, kann sich kein andere Benutzer neu registrieren, bis der erste Vorgang abgeschlossen ist. Normalerweise sollten solche Fehler schon beim Funktionstest der Anwendung auffallen, trotzdem lohnt es sich, bei der Suche nach Schwachstellen auch auf solche Möglichkeiten zu achten.

In der nächsten Folge geht es um die Abwehr von DoS-Angriffen.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #239: Schwachstellen-Suche: Denial of Service
• About Security #240: Schwachstellen-Suche: Denial of Service (2)
• About Security #241: Schwachstellen-Suche: Denial of Service (3)