entwickler.com

In dieser Folge wird die Beschreibung von Intrusion-Detection-Systemen mit praktischen Beispielen fortgesetzt. Für verschiedene Angriffe werden passende Regeln für die Mustererkennung vorgestellt. Das Intrusion-Detection-System soll u.a. Directory-Traversal-Angriffe (About Security #16), das Heraufladen von PHP-Dateien und Angriffe auf eine Pufferüberlauf-Schwachstelle (About Security #5 ff.) erkennen.

Bevor die einzelnen Schwachstellen behandelt werden, müssen die für die Regeln notwendigen Informationen festgelegt werden. Zum einen muss das IDS wissen, wo es suchen, d.h. auf welche Pakete es achten soll. Dazu sind die gleichen Informationen wie bei einer Firewall nötig (About Security #29 ff.): Senderadresse und -Port, Zieladresse und -Port, das Protokoll und ob es sich um eine bestehende Verbindung handelt oder nicht. Zur Erkennung von Angriffen auf eine Webanwendung ergibt das folgende Regeln:

Außerdem muss das IDS wissen, was es suchen soll, d.h. nach welchen Mustern.

Directory-Traversal

Die angenommene Directory-Traversal-Schwachstelle befindet sich im Skript anwendung/hilfe/anzeige.pl:

http://www.server.example/anwendung/hilfe/anzeige.pl?
 parameter=[Directory-Traversal]

Die Webanwendung speichert ihre Benutzerdatenbank im Verzeichnis /datenbanken im Wurzelverzeichnis des Webservers. Es ist ein Wurm im Umlauf, der sich über die Webanwendung verbreitet und dabei zuerst über die Directory-Traversal-Schwachstelle die Benutzerdatenbank herunterlädt. Der dazu notwendig HTTP-Request lautet

GET /anwendung/hilfe/anzeige.pl?
 parameter=../../datenbanken/admin.db

Um diesen Angriff zu erkennen, muss das Intrusion-Detection-System auf entsprechende HTTP-Requests achten. Als erster Ansatz bietet sich für die Suche folgendes Muster an:

"/anwendung/hilfe/anzeige.pl?
 parameter=../../datenbanken/admin.db"

Damit würde ein Angriff des bekannten Wurms erkannt. Für Versuche, andere Dateien über die Schwachstelle herunterzuladen, wäre das IDS aber blind. Das lässt sich leicht ändern, indem auf die Angabe des Datenbankverzeichnisses und der Datenbank verzichtet wird:

"/anwendung/hilfe/anzeige.pl?parameter=../../"

Dies ist natürlich nur möglich, wenn die Webanwendung die Zeichenfolge ../../ selbst nicht verwendet. Ansonsten würde jeder zulässige Aufruf, der die Zeichenfolge enthält, einen Fehlalarm (false positive) auslösen.

Aber auch dieses Muster lässt sich umgehen, z.B. indem ein zusätzlicher Parameter eingefügt wird:

GET /anwendung/hilfe/anzeige.pl?
 gibts=nicht&parameter=../../datenbanken/admin.db

Da die Webanwendung den ihr unbekannten Parameter ignoriert, funktioniert der Exploit trotzdem. Das Muster muss also weiter verbessert werden. Dazu kann es aufgespalten werden:

"/anwendung/hilfe/anzeige.pl" UND "parameter=../../"

Das IDS prüft jetzt, ob die Daten diese beiden Zeichenketten enthalten. Eingefügte zusätzliche Parameter oder der Zugriff auf andere Dateien verhindern die Erkennung eines Angriffs nicht mehr.

Heraufladen von PHP-Dateien

Ein Skript, das in einem Forum zum Heraufladen von Bildern verwendet wird, prüft die Endung der heraufgeladenen Dateien nicht. Dadurch kann über

GET /forum/upload.php?bild=boese.php

das PHP-Skript boese.php heraufgeladen werden. Für das IDS ergibt sich mit den obigen Überlegungen das folgende Muster:

"/forum/upload.php" UND "bild=" UND ".php".

Pufferüberlauf

Der eingesetzte POP3-Server enthält eine Pufferüberlaufschwachstelle, die durch einen überlangen Parameter für den Befehl USER ausgenutzt wird. Um einen Angriff zu erkennen, soll das IDS nicht auf bestimmte bekannte Parameter, sondern allgemein auf einen überlangen Parameter achten (vgl. About Security #46). Statt des Webservers ist diesmal der POP3-Server, Port 110, Ziel der Pakete:

In den Daten muss nach dem Befehl USER, gefolgt von einem Parameter, der länger als z.B. 50 Zeichen ist, gesucht werden.

Weitere Parameter

Die Regeln können weiter eingeschränkt werden, um unnötige Analysen zu vermeiden. So kann die Flussrichtung der Daten von Interesse sein: Für die Suche nach Directory-Traversal-Angriffen müssen nur Pakete untersucht werden, die von außen an den Webserver gesendet werden. In der Gegenrichtung könnte z.B. mit bestimmten Mustern nach der Übertragung vertraulicher Daten gesucht werden. Auch die zu untersuchende Datenmenge kann in manchen Fällen eingeschränkt werden: Erfordert ein bekannter Angriff z.B. zwingend eine bestimmte Zeichensequenz in den ersten n Bytes der übertragenen Daten, muss der Rest des Pakets nicht mehr darauf untersucht werden. Selbst wenn die Sequenz dort vorkommt, wäre sie kein Zeichen für einen Angriff.

Nächste Woche gibt es einen Bericht über Neuigkeiten von der CeBIT 2006. In der nächsten regulären Folge wird die Umsetzung der obigen Beispiele mit dem Open-Source-IDS Snort beschrieben.

Carsten Eilers

About Security – Übersicht zum aktuellen Thema "Intrusion Detection und Prevention Systeme"

• About Security #42: Intrusion-Detection-Systeme – Grundlagen
• About Security #43: Intrusion-Detection-Systeme – Positionierung
• About Security #44: IDS-Kommunikation
• About Security #45: IDS in hochverfügbaren Netzen
• About Security #46: Angriffe auf IDS
• About Security #47: Beispiele für IDS-Regeln
• About Security #48: Umsetzung der IDS-Beispiele mit Snort
• About Security #49: Intrusion Prevention