Nach dem Sammeln von Informationen über die Webanwendung und der Suche nach zustandbasierten Angriffen, Cross-Site-Scripting- und SQL-Injection-Schwachstellen geht es als nächstes um

Directory-Traversal-Angriffe

Die Grundlagen eines Directory-Traversal-Angriffs sind einfach: Der Angreifer übergibt für einen Parameter statt eines vorgesehenen Dateinamens eine Reihe von ../-Sequenzen zum Wechseln des Verzeichnisses sowie nach seiner Wahl Verzeichnisnamen und einen Dateinamen und greift damit auf eine nicht für ihn bestimmte Datei zu (siehe About Security #177). Dadurch kann er z.B. den Quelltext von Skripten anzeigen lassen oder auf Konfigurationsdateien zugreifen (#178). Je nachdem, wie von der Webanwendung auf die Datei zugegriffen wird, kann der Angreifer evtl. auch Daten in eine Datei schreiben und so z.B. eigenen Code einschleusen. In PHP gibt es noch den Sonderfall der Funktionen include()/include_once() und require()/require_once(), die in der damit eingebundenen Datei enthaltenen PHP-Code ausführen, was als Local File Inclusion bezeichnet wird (#179). Bei der Suche nach Directory-Traversal-Schwachstellen müssen alle Parameter geprüft werden, über die evtl. auf eine Datei zugegriffen wird (#180). Dabei kann das Verzeichnis nicht nur über ../ gewechselt werden, diese Zeichen können ggf. auch umkodiert und dadurch an Schutzfunktionen vorbei geschmuggelt werden. Auch ein fest vorgegebenes Suffix und/oder Präfix ist kein Hindernis für einen Angriff (#181). Um Directory-Traversal-Angriffe zu verhindern, verzichtet man am besten auf die Verwendung von vom Benutzer manipulierbaren Parametern für Dateizugriffe, stattdessen kann man eine Liste zulässiger Werte aufstellen und den gewünschten Wert über einen Index auswählen. Müssen vom Benutzer manipulierbare Parameter verwendet werden, müssen sie sehr sorgfältig geprüft werden (#182).

In PHP ist eine Local File Inclusion schon übel genug, kann so doch z.B. in Logfiles eingeschleuster PHP-Code ausgeführt werden. Aber die Local File Inclusion hat noch einen großen und viel böseren Bruder, die Remote File Inclusion, bei der eine Datei von einem anderen Server eingebunden wird. Darüber kann ein Angreifer dann z.B. eine auf seinem Server gespeicherte komfortable PHP-Shell einbinden und die Kontrolle über den Webserver übernehmen (#183).

Nach den Zugriffen auf Dateien geht es um das

Einschleusen von Shell-Befehlen

Das Einschleusen von Shell-Befehlen, die sog. OS Command Injection, ist immer dann möglich, wenn Parameter an externe Programme übergeben werden: Enthält der Parameter nicht nur Daten, sondern auch Shell-Metazeichen, können danach weitere Programmaufrufe folgen (#184). Ob ein eingefügter Befehl wirklich ausgeführt wird, kann man z.B. durch das Einschleusen eines ping-Befehls testen (#185). Evtl. vorhandene Einschränkungen können oft umgangen werden. Um OS Command Injection zu verhindern, sollte man für den Aufruf externer Programme am besten gar keine vom Benutzer manipulierbaren Parameter verwenden oder diese zumindest sehr sorgfältig prüfen (#186).

Es gibt noch viele weitere Möglichkeiten, einer Webanwendung bzw. Funktionen darin zusätzliche Anweisungen unterzuschieben, was alles unter den Oberbegriff "Injection" fällt: Scriptcode Injection, XPath-Injection, SOAP-Injection, ... - oder kurz:

Injection-Angriffe

In manchen Fällen können statt Shell-Befehlen auch Befehle der verwendeten Skriptsprache eingeschleust werden, was als Scriptcode Injection bezeichnet wird (#187). Nachdem man die Webanwendung daraufhin geprüft hat, kann man gleich mit der Suche nach XPath-Injection weiter machen, bei der die Abfrage vom XML-Daten aus einer XML-Datei manipuliert wird (#188). Die ist u.U. nur blind möglich, was analog zur Blind SQL-Injection als Blind XPath-Injection bezeichnet wird (#189). SOAP, das Simple Object Access Protocol, dient dem Austausch von Daten und dem Durchführen von Remote Procedure Calls (RPC, entfernte Prozedur-Aufrufe) zwischen verschiedenen Servern. Kann ein Angreifer dabei eigene Befehle einschleusen, spricht man von SOAP-Injection (#190). Solche Schwachstellen sind schwer zu finden, dass die benötigten XML-Metazeichen die SOAP-Nachricht leicht zerstören und dann nur zu einer allgemeinen Fehlermeldung führen. Um SOAP-Injection zu verhindern, müssen XML-Metazeichen in die entsprechenden HTML-Entities umgewandelt werden, so dass sie vom XML-Interpreter als Daten behandelt werden (#191).

Versendet eine Webanwendung E-Mails, wird dafür das Simple Mail Transfer Protocol SMTP verwendet. Kann ein Angreifer dabei eigene Header einschleusen und damit eigene Empfänger oder auch Mail-Inhalte hinzufügen, spricht man von SMTP-Header-Injection (#192). Unter Umständen können auch weitere SMTP-Befehle eingeschleust werden, so das es sich um SMTP-Command-Injection handelt. Darüber kann ein Angreifer dann beliebige Mails verschicken. Zum Verhindern beider Arten von SMTP-Injection gilt mal wieder (und jetzt alle im Chor:) "Benutzereingaben prüfen bzw. filtern" (#193). Das gilt natürlich auch für die Parameter für LDAP-Abfragen, denn sonst ist LDAP-Injection möglich, über die ein Angreifer nicht für ihn bestimmte Daten abfragen kann (#194). Für die Suche nach LDAP-Injection-Schwachstellen gibt es wie üblich verschiedene Testmuster (#195).

In der nächsten Woche gibt es anlässlich des fünfjährigen Jubiläums von About Security und des Erscheinens der 250. Folge einen Ausblick auf die mögliche zukünftige Entwicklung der IT-Sicherheit. Diese Zusammenfassung wird in About Security #251 fortgesetzt.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #248: Schwachstellen-Suche im Überblick
• About Security #249: Schwachstellen-Suche im Überblick (2)