URL dieser Newsmeldung:

Webserver enthalten außer den in About Security #209 beschriebenen Beispielanwendungen weitere, oft unerwünschte "Default-Inhalte", die beim Missbrauch durch einen Angreifer unter Umständen großen Schaden anrichten können.

Nicht für die Allgemeinheit gedachte Funktionen

Viel Webserver-Software (was nicht nur den Webserver im Sinne des HTTP-Servers, sondern auch für die Webanwendung verwendete Applicationserver, Datenbankserver usw. umfasst) enthält mächtige Funktionen, die zwar nicht für die Nutzung durch normale Benutzer der Webanwendung gedacht sind, die aber trotzdem von ihnen aufgerufen werden können. Ein gutes Beispiel dafür ist das vom Oracle Application Server installierte PL/SQL-Gateway, mit dem über eine Weboberfläche Befehle an die Backend-Datenbank geschickt werden können. Dadurch können beliebige Parameter an Datenbankprozeduren übergeben werden, indem ein URL nach dem Muster

https://www.anwendung.example/pls/dad/package.procedure?param1=wert1
  &param2=wert2

aufgerufen wird. Eigentlich soll das PL/SQL-Gateway dabei helfen, die Anwendungslogik (Business Logic) der Datenbank mit der Webanwendung zu verbinden. Da jedoch beliebige Prozeduren aufgerufen werden können, kann ein Angreifer das Gateway verwenden, um darüber für ihn eigentlich nicht zugängliche Prozeduren aufzurufen. Ein beliebtes Beispiel dafür ist die Prozedur SYS.OWA_UTIL.CELLSPRINT, mit der sich beliebige SQL-Abfragen durchführen und dadurch beliebige Daten abfragen lassen:

https://www.anwendung.example/pls/dad/SYS.OWA_UTIL.CELLSPRINT?_THEQUERY=
  SELECT+*+FROM+users

Um solche Angriffe zu verhindern, hat Oracle eine Schutzfunktion in Form der PL/SQL Exclusion List vorgesehen, anhand derer die aufgerufenen Prozeduren geprüft und Zugriffe auf viele potentiell gefährliche Pakete der Datenbank unterbunden werden. Leider lässt sich diese Liste umgehen, und es gibt weitere gefährliche Prozeduren, die nicht auf der List enthalten sind und die von einem Angreifer missbraucht werden können.

Unerwünschte Funktionen finden

Bei der Suche nach unerwünschten Funktionen sowie allgemein nach "Default-Inhalten" ist der Schwachstellenscanner Nikto eine große Hilfe. Eine weitere Möglichkeit ist das Lesen der Dokumentation aller eingesetzten Komponenten oder eine Suche bei z.B. Google.

Während sich Debug- und Testfunktionen sowie Beispielanwendungen meist problemlos entfernen lassen oder zumindest der Zugriff darauf über den Webserver auf befugte Benutzer beschränkt werden kann, müssen die evtl. zumindest teilweise benötigten Funktionen vor unbefugter Nutzung geschützt werden. Wie, verrät (hoffentlich) die Dokumentation des betroffenen Programms.

Unsichere Konfigurationen

Webserver bieten viele verschiedene Konfigurationmöglichkeiten. Einige davon können zu Schwachstellen führen, die einen Angriff erleichtern oder sogar erst ermöglichen.

Verzeichnislistings

Wird statt einer Datei ein Verzeichnis aufgerufen, kann der Webserver darauf auf drei Arten reagieren:

• Er gibt eine Default-Ressource aus dem Verzeichnis aus, z.B. index.html
• Er gibt einen Fehlermeldung aus, weil der Aufruf nicht erlaubt ist, z.B. den HTTP-Statuscode 403
• Er gibt eine Auflistung des Verzeichnisinhalts aus

In vielen Fällen hat die Ausgabe des Verzeichnisinhalts keinerlei sicherheitsrelevante Auswirkungen, da auf die im Verzeichnis enthaltenen Dateien auch ganz normal über die Webanwendung zugegriffen werden kann. Es gibt aber zwei gute Argumente dafür, die Ausgabe des Verzeichnisinhalts aus Sicherheitsgründen zu unterbinden:

• Manche Webanwendungen enthalten Schwachstellen in der Zugriffskontrolle und/oder verlassen sich darauf, das die einzelnen Seiten/Funktionen in der richtigen Reihenfolge aufgerufen werden. Eine Liste der Dateien der Webanwendung kann einem Angreifer dabei helfen, die Anwendungslogik anzugreifen, siehe z.B. das URL-Jumping in About Security #153.
• Oft befinden sich Verzeichnisse bzw. Dateien unterhalb des Webroot-Verzeichnisses, die nicht für normale Besucher der Website gedacht sind, wie z.B. Logfiles, Backup-Dateien, alte Skriptversionen usw. Errät ein Angreifer so einen Verzeichnisnamen, kann er danach mit Hilfe des Verzeichnislistings die für ihn interessanten Dateien auswählen. Ohne die Liste kann er nur versuchen, Dateinamen zu raten.

Verzeichnislistings finden

Beim Test der eigenen Webanwendung ist der erste Schritt das Prüfen der Konfiguration des Webservers: Ist darin die Ausgabe der Verzeichnisinhalte nicht aktiviert, ist man eigentlich bereits fertig. Wird die Webanwendung auch auf anderen Webservern eingesetzt, die ja durchaus anders konfiguriert sein können, muss für jedes Verzeichnis geprüft werden, ob es eine Default-Ressource wie z.B index.html enthält, die auch bei aktivierter Ausgabe der Verzeichnisinhalte die Ausgabe verhindert.

Beim Test einer fremden Webanwendung muss für jedes während der Sammlung der Informationen über die Webanwendung gefundene Verzeichnis einmal ein Zugriff auf das Verzeichnis probiert werden. Wird der Inhalt des Verzeichnisses aufgelistet, sollte das als Schwachstelle betrachtet werden, die es zu beheben gilt. Dazu kann entweder der Webserver umkonfiguriert oder eine Default-Ressource in die betreffenden Verzeichnisse kopiert werden.

In der nächsten Folge geht es weiter um die Konfiguration des Webservers.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #206: Schwachstellen-Suche: Webserver identifizieren
• About Security #207: Schwachstellen-Suche: Webserver angreifen
• About Security #208: Schwachstellen-Suche: Webserver schützen
• About Security #209: Schwachstellen-Suche: Webserver untersuchen
• About Security #210: Schwachstellen-Suche: Webserver-Konfiguration