Die Webseite ist die Außendarstellung von Firmen und Institutionen - sozusagen die virtuelle Empfangshalle. Aus Komfortgründen dient sie häufig sowohl für Besucher als auch für Mitarbeiter als Plattform; und auch die Gestalter und Redakteure benötigen in irgendeiner Form Zugriff, um Aktualisierungen vornehmen zu können. Eine entsprechende Konfiguration ist leicht zu erstellen, doch bieten diese leichtsam eine Einfallsschneise für ungebetene Besucher; auf einige Probleme möchte ich in diesem Artikel am Beispiel des Apache-Webservers hinweisen.

Allgemeine Hinweise

...möchte ich hier nicht breittreten. Dinge wie das regelmäßige Einspielen von Updates sollten selbstverständlich sein. Die Angriffsfläche sollte prinzipiell klein gehalten werden: Keine unnötigen Dienste auf dem Webserver, aber auch möglichst wenig Informationen über das System preisgeben. Unglücklicherweise sind diesbezüglich viele Webserver sehr gesprächig und versorgen einen Angreifer in den HTTP-Headern mit detaillierten Informationen über die verwendete Software, die Version und mitunter sogar die verwendeten Module (z.B. PHP-Header) oder die eingesetzte Distribution (als Teil der Versionskennung). Beim Apache-Webserver kann dies beispielsweise durch Verwendung von mod_headers unterbunden werden.

Kompromittieren eines Webservers

Der einfachste Weg, der Zugriff auf die Interna eines Webservers erlaubt, ist ein Exploit, der einen Shellzugang zum Server ermöglicht. Ein solcher Angriff erfordert das Einschleusen von Code, der dann vom Server (unfreiwillig) ausgeführt wird und die Shell erzeugt. Klassische Buffer-Overrun-Exploits dürften die bekanntesten Beispiele hierfür sein.
Dank der Existenz von Skriptsprachen gibt es sozusagen eine "Metaebene" für Angriffe: Es genügt, eine Möglichkeit zu finden, ein Skript auf dem Server auszuführen. Eine Möglichkeit ist es, in ein CGI-Verzeichnis eine eigene Datei einzuschleusen. Einfacher ist jedoch die Verwendung von web-typischen Skripten wie z.B. PHP, bei denen der entsprechende Interpreter meist im Webserver selbst integriert ist - hier fällt meist die Beschränkung auf bestimmte Verzeichnisbereiche weg. Hier genügt es, entweder wiederum eine geeignete Datei einzuschleusen, oder aber fehlerhafte Skripte auszunutzen, über welche es möglich ist, eigene Skriptkommandos auszuführen.
Letztere Methode ist in den vergangenen Jahren äußerst populär geworden - man findet im Netz komfortable PHP Shells, welche weiteres Arbeiten auf dem kompromittierten System sehr bequem machen.

Rechte-Probleme 1: WebDAV & Co.

Um ein bequemes Bearbeiten einer Webseite zu ermöglichen, wird häufig WebDAV eingesetzt - die Problematik gilt aber prinzipiell für alle Techniken mit Schreibzugriff auf das Dateisystem. Die Überprüfung der Benutzerrechte (wer darf wo lesen und schreiben) erfolgt ausschließlich innerhalb des WebDAV-Moduls; die Unix-typischen Rechte sind hierbei außen vor, denn das Betriebssystem "sieht" nur den Prozeß des Webservers. Dementsprechend müssen alle Dateien und Verzeichnisse, die via Webinterface (und dazu zählt auch WebDAV) veränderbar sein sollen, auch von diesem Benutzer beschreibbar sein. Umgekehrt bedeutet das, daß ein Angreifer, der an nur einer Stelle eine (Skript)shell erzeugt hat, auf alle Daten, die der Webserver lesen kann Zugriff erlangt und alle Daten, die der Serverprozess verändern kann nun auch manipulieren kann.
Da eine typische Einstellung für WebDAV-Zugriff das Wurzelverzeichnis der Website ist, ist in diesem Fall das Ergebnis meist besonders fatal.

Rechte-Probleme 2: Shared Hosting

In der Ausgabe 18/07 der Zeitschrift c't wurden die Konfigurationen verschiedener Webhoster verglichen. Dabei fiel auf, daß einige Webhoster mod_php verwenden, obwohl verschiedene Kunden auf demselben Rechner gehostet werden. Dies bedeutet, daß intern die Skripte verschiedener Kunden mit demselben Serverprozeß und damit mit den selben lokalen Rechten ausgeführt werden. Selbst wenn die eigene Webseite sicher ist, kann sie durch einen anderen Kunden mitkompromittiert werden.
Solche weiteren Domänen können sozusagen einen Seiteneingang für einen Angreifer bieten. Das normale DNS-System zeigt zwar längst nicht alle Web-Domänen (via reverse dns) an, aber es gibt im Netz Suchdienste (wie z.B. myIPneighbors), mit denen man die "Mitbewohner" eines Servers finden kann.

Quellen für Login-Informationen

Um Zugriff auf geschützte Bereiche zu erlangen, ist (hoffentlich) ein Login mit Benutzername und Paßwort erforderlich. Daß die Wahl guter Passwörter häufig ein Problem darstellt, habe ich bereits mehrfach erwähnt. Erschreckend oft funktioniert auch das ganz platte Social-Engineering mit einem einfachen Telefonanruf. Bei Benutzern mit schlechtem Paßwort ist der Benutzername die sicherere Komponente der Authentisierung (das Paßwort läßt sich bei diesen Leuten rasch mit Hilfe eines Wörterbuchangriffs herausfinden).
Um an Benutzernamen zu gelangen, kann man natürlich die Webseite selbst durchforsten. Häufig findet sich eine Randnotiz oder ein Kommentar im HTML-Quelltext, welcher das letzte Änderungsdatum und den Benutzernamen enthält.
Sehr ergiebig können aber auch die Metainformationen sein, die in Dokumenten stecken, welche auf der Webseite zum Download angeboten werden. Das Tool MetaGooflil sucht automatisch nach solchen Dokumenten, läd diese herunter und extrahiert die darin enthaltenen Metainformationen. Diese beinhalten Pfadangaben, Benutzernamen und vieles mehr - alles Informationen, die für einen Angreifer sehr wertvoll sein können. Um nicht als "Crawler" aufzufallen, nutzt MetaGoofil für die Suche dieser Dateien die Suchmaschine Google

Fazit

Es gibt eine ganze Reihe von Möglichkeiten für einen Angreifer, auf einen Webserver einzudringen. Die obige (sicherlich nicht vollständige) Liste zeigt einige Beispiele hierfür. All diese Probleme lassen sich durch geeignete Konfiguration umgehen; unglücklicherweise erkennt man die Schwierigkeiten erst, nachdem man einmal "um die Ecke" gedacht hat - oder selbst Opfer eines entsprechenden Angriffs wurde.
Ich hoffe, daß dieser Artikel bei diesem "um-die-Ecke-denken" hilft - bevor man selbst eine entsprechend schmerzliche Erfahrung macht.