entwickler.com

Wie angekündigt gibt es diese Woche praktische Beispiele zu Intrusion-Detection-Systemen. 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–10) 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 Datenbank-Verzeichnisses 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, dass 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überlauf-Schwachstelle, 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. In der darauf folgenden Woche wird die Umsetzung der obigen Beispiele mit dem Open-Source-IDS Snort beschrieben.

Carsten Eilers

• About Security (#1): IT-Sicherheit – Was ist das eigentlich?
• About Security (#2): Angriffsszenarien
• About Security (#3): Eindringlinge abwehren
• About Security (#4): Gefährdung aus der Peripherie
• About Security (#5): Der Pufferüberlauf
• About Security (#6): Ausnutzung von Pufferüberlauf-Schwachstellen
• About Security (#7): Gegenwehr – Pufferüberläufe verhindern
• About Security (#8): Vorbeugung – Pufferüberläufe verhindern
• About Security (#9): Sourcecode Audit – Pufferüberläufe finden
• About Security (#10): Software-Audit – Schwachstellensuche in Binaries
• About Security (#11): SQL-Injection
• About Security (#12): SQL-Injection verhindern
• About Security (#13): Mit Stored Procedures gegen SQL-Injection
• About Security (#14): Cross-Site Scripting
• About Security (#15): Cross-Site Scripting verhindern
• About Security (#16): Skriptcode einschleusen
• About Security (#17): HTTP Request Smuggling
• About Security (#18): Spielarten des HTTP Request Smuggling, 1
• About Security (#19): Spielarten des HTTP Request Smuggling, 2
• About Security (#20): HTTP Request Smuggling erkennen und verhindern
• About Security (#21): HTTP Response Splitting, 1
• About Security (#22): HTTP Response Splitting, 2
• About Security (#23): Caches vergiften
• About Security (#24): Caches indirekt vergiften
• About Security (#25): Entführen von Webseiten
• About Security (#26): Gefahren für Webanwendungen
• About Security (#27): Gefahren für Webserver
• About Security (#28): Standorte für Webserver
• About Security (#29): Die Firewall, 1
• About Security (#30): Die Firewall, 2
• About Security (#31): Die Firewall, 3
• About Security (#32): Die Firewall, 4
• About Security (#33): Die Firewall, 5
• About Security (#34): Die Firewall, 6
• About Security (#35): Die Firewall, 7
• About Security (#36): Die Firewall, 8
• About Security (#37): Logfiles – Welche Daten speichern?
• About Security (#38): Logfiles – Wie auswerten?
• About Security (#39): Paketfilter-Logfiles manuell auswerten
• About Security (#40): HTTP-Proxy-Logfiles manuell auswerten,1
• About Security (#41): HTTP-Proxy-Logfiles manuell auswerten, 2
• 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