Channel Security

Die Suche nach DoS-Schwachstellen ist etwas komplizierter als die nach allen anderen. Zum einen kann man sie nicht mit dem Produktivsystem durchführen, da jeder Erfolg gleichzeitig zum echten DoS der Anwendung wird, zum anderen gibt es extrem viele Möglichkeiten, eine Webanwendung für die Benutzer unbrauchbar zu machen.

Viele Wege führen zum Ziel

Die Daten der Webanwendung können ganz oder teilweise gelöscht oder unzugänglich sein, Programme der Webanwendung können den Betrieb eingestellt haben, der Webserver oder das zugrund liegende System können den Betrieb eingestellt haben, der Server kann aus dem Internet nicht mehr erreichbar sein - all das und weitere Möglichkeiten führen dazu, dass die Benutzer die Webanwendung nicht nutzen können, für sie also ein Denial of Service vorliegt.

DoS als Option

Viele der zuvor bereits beschriebenen Schwachstellen erlauben auch einen DoS-Angriff. Ein Angreifer kann über persistentes Cross Site Scripting Code einschleusen, der jeden Benutzer sofort auf eine andere Seite weiterleitet oder aus der Webanwendung ausloggt: Die Webanwendung steht zwar weiter zur Verfügung, kann von den Benutzern aber nicht genutzt werden. Ein Angreifer kann über SQL-Injection statt Befehlen zum Abfragen von Daten auch solche zur Manipulation von Daten einschleusen, und ein simpler 'DROP DATABASE'- oder 'DROP TABLE'-Befehl löscht die gesamte Datenbank oder Tabelle, sofern der verwendete Benutzeraccount dazu berechtigt ist: Die Webanwendung kann nicht mehr auf die Daten zugreifen, Anfragen der Benutzer also nicht erfüllen. Ein Angreifer kann beim Ausführen beliebigen Codes natürlich jede beliebige Aktion ausführen, auch z.B. die gesamte Rechenleistung nutzlos verbrauchen und damit die Ausführung der Webanwendung verhindern. Ein Angreifer, der Shellbefehle einschleusen kann, kann natürlich auch das berühmt-berüchtigte 'rm -rf /' oder einfach nur 'rm -rf *' einschleusen, woraufhin alle Dateien, die der verwendete Benutzeraccount löschen darf, gelöscht werden. Selbst wenn der Account nur die allernötigsten Rechte besitzt, kann das ausreichen, einige von der Webanwendung benötigte Dateien zu löschen. Die Frage ist in solchen Fällen ab: "Wieso sollte ein Angreifer das tun?" Wer sich erst einmal Zugang zu einem Server verschafft hat, hat i.A. wenig Interesse daran, ihn danach lahm zu legen. Dazu gibt es außerdem einfachere Wege.

DoS als Nebenwirkung

Neben gezielten gibt es auch unabsichtliche DoS-Angriffe: Bei der Suche nach z.B. Pufferüberlauf- oder Formatstring-Schwachstellen kann es zu Abstürzen der angegriffenen Komponenten kommen, was zu einem DoS führt, vom Angreifer auch in Kauf genommen wird, aber eben nicht in erster Linie erzielt werden soll. Ein schlecht konzipierter oder implementierter Schutz vor Brute-Force-Angriffe könnte als Reaktion auf einen Brute-Force-Angriff dazu führen, dass sich eine Zeit lang überhaupt keine Benutzer mehr anmelden können - auch das fällt in die Kategorie "Dumm gelaufen", denn der Angreifer wollte ja in die Webanwendung eindringen und sie nicht lahm legen.

DoS als Ziel

Kommen wir nun zu gezielten DoS-Angriffen, bei denen der Angreifer wirklich "nur" einen DoS zum Ziel hat. Soll nur ein einzelner Benutzer an der Nutzung der Anwendung gehindert werden, reicht es u.U., durch fortlaufende Anmeldeversuche mit dessen Benutzerkennung den Brute-Force-Schutz zu aktivieren, so dass er sich nicht mehr anmelden kann. Soll die Webanwendung lahm gelegt werden, wird meist die Datenbank das Ziel der Angriffe sein: Können die Daten über SQL-Injection gelöscht oder der Datenbankserver mit Hilfe einer bekannten DoS-Schwachstelle an der Beantwortung der Abfragen der Webanwendung gehindert werden, ist die Webanwendung selbst nicht mehr benutzbar. Genauso können aber auch Schwachstellen in der Webanwendung selbst dazu genutzt werden, den korrekten Betrieb zu verhindern.

DoS-Schwachstellen in der Webanwendung finden

Alle Möglichkeiten, Daten zu manipulieren oder den Server zu kompromittieren, wurden bereits bei der Suche nach den anderen Schwachstellen erfasst. Ist allgemein keine SQL Injection möglich, kann darüber auch insbesondere nicht die Datenbank gelöscht werden, usw. usf.. Was bisher unberücksichtigt blieb, ist die Auslastung der Webanwendung. Gelingt es einem Angreifer, einen rechenintensiven Prozess oft genug zu beanspruchen, bleibt der Anwendung keine Zeit mehr zur Beantwortung anderer Benutzeranfragen. Es müssen also alle Aktionen ermittelt werden, die lange dauern und/oder die Anwendung stark belasten. Dazu gibt es für jede mögliche Webanwendung meist mehrere Möglichkeiten, daher hier nur ein paar allgemeine Hinweise. Potentiell gefährlich sind u.a. Datenbankabfragen, über die ein Angreifer viele und/oder umfangreiche Daten anfordern kann, z.B. eine Suche nach allen vorhandenen Artikeln in einem Onlineshop. Auch alle Aktionen mit vom Benutzer gelieferten Dateien, z.B. das Prüfen heraufgeladener Dateien oder das Erstellen von Vorschaubildern hochgeladener Bilder können evtl. für DoS-Angriffe genutzt werden. Übergroße Dateien oder präparierte Bilder können die zuständigen Programme so stark belasten, dass für weitere Prozesse keine Rechenleistung mehr übrig ist. Archivbomben wie z.B. das bekannte 42.zip verbrauchen beim Entpacken sämtlichen verfügbaren Speicherplatz und legen darüber das System lahm.

Weitere Möglichkeiten werden in der nächsten Folge beschrieben, in der es dann auch um DoS-Angriffe auf den Webserver geht.

Carsten Eilers