entwickler.com

Was macht man, wenn im eingesetzten Webserver oder anderen für den Betrieb der Webanwendung benötigten Komponenten eine Schwachstelle entdeckt wird? Erst mal muss man selbst davon erfahren, und das am besten, bevor es zu einem Angriff auf den eigenen Server gekommen ist. Wo man entsprechende Informationen finden, wurde in About Security #208 beschrieben.

Schwachstelle gefunden - was nun?

Erster Anlaufpunkt ist immer der jeweilige Hersteller: Gibt es einen Patch oder zumindest einen empfohlenen Workaround? Dabei sollte man nicht nur die auf der Hersteller-Website verfügbaren Informationen durchsuchen, sondern ggf. auch mit dem Support des Herstellers Kontakt aufnehmen. Ein verantwortungsbewusster Hersteller wird seine Kunden über öffentlich bekannte Schwachstellen informieren, evtl. weiss man dort aber noch gar nichts von der Schwachstelle.

Gibt es weder einen Patch noch einen vom Hersteller empfohlenen Workaround, ist Selbsthilfe angesagt: Kann auf Basis der vorhandenen Informationen selbst ein Workaround entwickelt werden? Evtl. reicht eine Änderung der Konfiguration, oder ein Angriff kann über Firewall- oder IPS-Regeln erkannt und abgefangen werden, bevor er Schaden anrichtet. Besonders einfach ist das bei Pufferüberlauf-Schwachstellen: Verwirft die Firewall überlange Werte für den betroffenen Parameter, ist kein Angriff mehr möglich. Dabei braucht man sich nicht darum zu kümmern, ob evtl. auch erwünschte Eingaben verworfen werden: Ist der Wert für den betroffenen Parameter zu lang, kann er sowieso nicht verarbeitet werden. Eine eigentlich erwünschte, aber zu lange Eingabe führt dann sowieso zu einem Fehler, meist einem Absturz des betroffenen Programms. Und das war dann auch schon vor dem Entdecken der Schwachstelle so. Der einzige Unterschied zwischen einer harmlosen und einer bösartigen Eingabe besteht darin, das bei einer harmlosen Eingabe kein eingeschleuster Code ausgeführt wird.

Je nach Gefahrenpotential der Schwachstelle kann es evtl. notwendig sein, vorübergehend Funktionen zu deaktivieren, um einen Angriff zu verhindern. Im Notfall ist es besser, nur eine abgespeckte Website online zu haben, als durch einen Angriff z.B. wichtige Daten ausspähen zu lassen. Von der Peinlichkeit, nach einem erfolgreichen Angriff das Ausspähen von Daten zugeben zu müssen, bzw. "defaced" zu werden, ganz zu schweigen.

Es ist sowieso empfehlenswert, eine "Notfall-Website" aus statischen Seiten mit den notwendigsten Informationen bereit zu halten. Wenn man die nie braucht, ist es um so besser. Aber wenn man eine braucht, und sei es nur zur Überbrückung einer technischen Störung oder einer dringend notwendigen Wartung, hat man i.A. genug anderes zu tun und keine Zeit, sich noch über eine Ersatzseite Gedanken zu machen.

Schwachstellen suchen

Schwachstellen im Webserver und den anderen verwendeten Programmen könnte man suchen, im allgemeinen verzichtet man aber darauf und prüft nur, ob überall die jeweils aktuellste Version samt aller evtl. vorhandenen Patches etc. installiert ist. Wichtiger ist das Prüfen der richtigen Konfiguration bzw. die Suche nach falsch konfigurierten Programmen. Teilweise werden unsichere Default-Konfigurationen ausgeliefert, die ohne Änderung unnötige Angriffspunkte liefern.

Default-Zugangsdaten

Viele Programme und auch Geräte wie Switches und Router stellen eine Webbasierte Administrationsoberfläche zur Verfügung, für die allgemein bekannte Default-Zugangsdaten verwendet werden. Werden die bei der Konfiguration nicht geändert, kann ein Angreifer darüber auf die Administrationsoberfläche zugreifen und Schaden anrichten. Sammlungen von Default-Zugangsdaten gibt es z.B. bei CIRT.net und Phenoelit. Jede Administrationsoberfläche sowie alle sonstigen Zugänge wie z.B. FTP oder SSH müssen auf solche Default-Zugangsdaten geprüft und diese ggf. gelöscht bzw. ersetzt werden.

"Default-Inhalte"

Viele Webserver werden mit einer Reihe von "Default-Inhalten" ausgeliefert, wie Debug- und Testfunktionen, Beispielanwendungen, eigentlich nicht für die Öffentlichkeit gedachte Funktionen, Online-Handbücher,..., die alle unnötige Angriffsflächen bieten.

Debug-Funktionen liefern einem Administrator ebenso wie einem Angreifer nützliche Informationen über die Konfiguration und den Status des Webservers. Ein typisches Bespiel dafür sind Seiten mit der Ausgabe der Funktion phpinfo(), z.B. in Form des in vielen Apache-Installationen vorhandenen Skripts phpinfo.php.

Beispielanwendungen können zum einen unerwünschte Funktionen und zum anderen Schwachstellen enthalten. So wurden in der Vergangenheit z.B. in mehreren mit Tomcat ausgelieferten Beispielanwendungen XSS-Schwachstellen gefunden. Ein typisches Beispiel ist auch das Skript CodeBrws.asp, das in älteren Versionen von Microsofts IIS enthalten war. Eigentlich sollten die Benutzer damit nur den Quelltext anderer Beispielskripte betrachten können, aufgrund einer Directory-Traversal-Schwachstelle konnten aber beliebige Dateien im Webroot-Verzeichnis ausgegeben werden.

Weitere Beispiele für unerwünschte "Default-Inhalte" sowie Hinweise zur sicheren Konfiguration des Webservers gibt es in der nächsten Folge.

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