Offen wie Scheunentore

Inhaltsverzeichnis

Skriptsprachen wie Perl und das mittlerweile ebenfalls sehr häufig eingesetzte PHP machen Websites interaktiv: Online-Shops, Gästebücher, Foren et cetera lassen sich damit realisieren. Doch stellen PHP- und Perl-Skripte in den günstigen Shared-Hosting-Umgebungen, bei denen sich mehrere Domains einen Server teilen, ein großes Risiko dar: Als Bestandteil des Webservers haben die Skript-Laufzeitumgebungen mitunter Zugriff auf viele sicherheitsrelevante Teile des zugrundeliegenden Systems.

Wir haben mit einem in PHP geschriebenen einfachen Datei- und Verzeichnis-Browser getestet, wie gut verschiedene Provider die damit verbundenen Gefahren abfangen. Um ein solches Skript auf dem Server eines Providers zum Einsatz bringen zu können, muss man dort über Webspace verfügen, sprich Kunde sein.

Die auf dem Server ablaufende Anwendung zeigt im Browser mehr als die Verzeichnisstruktur, die der Provider seinem Kunden für dessen Web-Präsenz vorgibt. Das Programm kann - wenn der Provider sein System nicht ordentlich abdichtet - aus der vordefinierten Dateistruktur ‘ausbrechen’, darunter liegende Systemverzeichnisse öffnen und von dort aus in Verzeichnisse verzweigen, die der Kunde ohne das Skript nicht zu Gesicht bekäme. Auf diese Weise lassen sich zum Beispiel vertrauliche Daten anderer Kunden, System-Files und Passwörter ausspähen.

Aus dem Pfad ausbrechen

Bei BAIS zum Beispiel konnten wir nicht nur völlig uneingeschränkt die Verzeichnisse anderer Kunden einsehen. Auch unter den Web-Präsenzen liegende Systemdateien waren völlig ungeschützt für den Zugriff per PHP. So fand sich zum Beispiel im Ordner /etc die Datei passwd, die Passwörter von einigen Dutzend Kunden enthielt. Die Passwörter waren zwar verschlüsselt; ein Angreifer hätte die Datei allerdings herunterladen und in aller Ruhe auf seinem lokalen Rechner versuchen können, die Verschlüsselung mit einem Brute-Force-Tool zu knacken.

Auch Dateien für die SNMP- und die http-Server-Konfiguration sowie das Verzeichnis /proc, in dem Linux-Prozesse ihre Daten zwischenspeichern, waren bei BAIS für PHP-Skripte frei zugänglich - allesamt Bereiche, die dem Administrator, aber auf keinen Fall einem beliebigen Kunden offen stehen dürften.

Den Vogel aber schoss WebJanssen ab. Bei dem Anbieter, der Windows NT als Server-Betriebssystem einsetzt, war so gut wie jede Datei im gesamten System zugänglich. Ein ungebetener Besucher hätte in aller Ruhe den Server nach Schwachstellen durchsuchen können. Und die fanden sich schnell: So setzt der Provider Serv-U als ftp-Server ein. Die ini-Datei, in der die Software Serv-U die Zugangsdaten verwaltet, war offen zugänglich; eine solche Datei enthält sämtliche ftp-Passwörter im Klartext: Ein Angreifer hätte also mit minimalem Aufwand vollen ftp-Zugriff auf alle Dateien sämtlicher Domains erhalten und sie, statt mit unserem Skript nur zu lesen, per ftp auch austauschen oder löschen können.

Doch auch bei Hostern, die ihre Server auf den ersten Blick abgeschottet hatten, fanden sich Lücken. So versuchen mehrere Provider offenbar, durch trickreich vergebene Verzeichnisnamen und Beschränkungen der Leserechte Kunden den Zugriff auf fremde Serverbereiche zu verwehren. Einige Provider bauen beispielsweise die Webspace-Basisverzeichnisnamen ihrer Kunden in der Form // auf. Wenn PHP-Skripte zwar auf die Domain-Namen-Verzeichnisse zugreifen dürfen, nicht aber auf die darunter liegenden Kennungsverzeichnisse, dann ist Datei-Browsern wie dem unseren zunächst der Weg versperrt: Ohne genaue Kenntnisse des kompletten Pfades kann er nicht den Inhalt eines fremden Webserver-Verzeichnisses anzeigen. Die Zuordnung von Kennungen zu Domains und damit die vollständigen Pfade zu den Webserver-Verzeichnissen sollten aber nur dem Provider bekannt sein.

Untauglicher Schutz

Der ganze Schutzmechanismus fällt allerdings in sich zusammen, wenn der Server-Betreiber sein System auf den niedrigeren Dateiebenen nicht ebenfalls verrammelt und sich ein Angreifer die dort benötigten Informationen zusammensuchen kann. Bei Haispeed beispielsweise konnte man frei in den Systemdateien ‘surfen’. Im Apache-Verzeichnis fand sich eine Datei mit dem viel sagenden Namen domains, die die genaue Zuordnung von Kennungen zu Domains enthielt. Bei anderen Providern standen die benötigten Informationen an anderer Stelle, HostEurope zum Beispiel listete die absoluten Pfade aller Domains in der Webserver-Konfigurationsdatei httpd.conf auf. Kennt ein Eindringling erst einmal den genauen Verzeichnispfad eines anderen Kunden, so kann er frei in den Verzeichnissen herumschnüffeln, die zu den Domains anderer Kunden gehören.

Spionage leicht gemacht

Wir haben auf Versuche verzichtet, Dateien in fremde Verzeichnisse hochzuladen - auch wenn wir in vielen Fällen Schreibrechte gehabt hätten. Aber selbst wenn ein Eindringling ‘nur’ lesend auf die Verzeichnisse anderer Provider-Kunden zugreifen kann, so ist das Missbrauchspotenzial bereits enorm: ‘Hintenrum’ per PHP-Browser hat ein Angreifer beispielsweise freien Zugriff auf Server-Bereiche, die der Domain-Besitzer für den normalen http-Zugriff mit einem Zugangsschutz per Passwort versehen hat. Die dazu notwendigen htpasswd-Dateien, in denen die Benutzernamen und Passwörter stehen, kann der ungebetene Gast herunterladen und mit einem Passwortcracker, ein wenig Zeit und Rechenleistung knacken. Anschließend kann er auch ‘von vorne’ ungestört und unauffällig in geschützten Bereichen der Website surfen, zum Beispiel in Administrations-Oberflächen oder in Extranet-Inhalten von Firmen.

PHP wird insbesondere zur Datenbankanbindung von Webseiten gerne eingesetzt. Der Datenbank-Servername, der Benutzername und das Passwort stehen dabei häufig im Klartext von PHP-Skripten. Beim normalen http-Abruf des Skripts arbeitet der Server die PHP-Befehle ab und gibt nur HTML aus; der Surfer bekommt dabei die Zugangsdaten nie zu Gesicht. Unser Browser dagegen zeigt PHP-Skripte (und auch Perl-Skripte, Active Server Pages et cetera) im Quelltext an. Damit kann sich ein Schnüffler Zugang zur Datenbank verschaffen und beispielsweise Kundendatenbanken eines Webshops einsehen oder dessen Preisverzeichnisse manipulieren. Abgesehen von den Datenbank-Zugangsdaten kann schon der Zugriff auf die Skript-Quelltexte an sich ein Sicherheitsproblem darstellen - wenn die Skripte aufgrund ihrer Entwicklungskosten einen Wert darstellen.

PHP vs. Sicherheit

PHP-Unterstützung und Sicherheit sind zwei Anforderungen, die sich in Shared-Hosting-Umgebungen nicht zwangsläufig zuwiderlaufen. So kann der bei den meisten Providern eingesetzte Apache-Webserver grundsätzlich in einer so genannten chroot-Umgebung laufen. Damit würde dem gesamten Server ein neues Basisverzeichnis vorgegeben. Jeder Kunde könnte zwar noch in die Verzeichnisse seiner ‘Nachbarn’ sehen; die Systemverzeichnisse stünden aber zumindest nicht mehr offen. Offensichtlich scheint aber selbst dieser Grundschutz vielen Providern schon zu viel des Guten zu sein.

Der Safe Mode, eine speziellen PHP-Erweiterung für den Shared-Hosting-Betrieb, geht noch weiter. Der sichere Modus überprüft bei Dateioperationen, ob der Besitzer des jeweiligen Skriptes auch dem der zu bearbeitenden Dateien entspricht. Im Safe Mode laufen viele PHP-Befehle aber nur eingeschränkt, sodass die Gefahr besteht, dass bestehende Skripte nicht mehr funktionieren. Den Safe Mode sahen wir nur bei den Freehostern und bei Strato im Einsatz.

Laut der PHP-FAQ [1] kann aber auch der Safe Mode nicht wirklich als sicher gelten. Sie empfehlt für Shared-Hosting-Umgebungen sogar, PHP als CGI-Applikation einzusetzen. Damit ließen sich PHP-Skripte unter den Unix-Rechten ihrer Benutzer benutzen. Für viele Provider kommt diese Variante aber offensichtlich ebenfalls nicht in Frage: Serverlast und Administrationsaufwand würden wohl zu hoch ausfallen. Wie schwierig der Spagat ist, ein System soweit abzudichten, dass kein Kunde in einen fremden Bereich eindringen kann, gleichzeitig aber keine Anwendung behindert wird, zeigt das Beispiel HostEurope. Darauf angesprochen, dass die Datei httpd.conf für jedermann einsehbar war, konnte der Hoster sie nicht ohne weiteres sperren, da die Frontpage-Server-Erweiterungen darauf zugreifen müssen.

Dass eine sichere Shared-Hosting-Umgebung mit PHP kein Ding der Unmöglichkeit ist, konnten wir unter anderem bei mehreren Freehostern sehen, zum Beispiel bei Tripod, den wir nicht überlisten konnten. Auch bei Domainbox scheinen alle Türen versperrt zu sein. Bei den beiden größten deutschen Providern, Puretec und Strato, konnten wir ebenfalls nicht auf Kundendaten oder kompromittierende Systemdateien zugreifen, wenn man dort auch ziemlich tief in die Systemverzeichnisse hineinblicken konnte.

Wir haben alle im Text erwähnten Provider auf die Sicherheitslücken angesprochen. Bis zum Erscheinen dieses Heftes wollen sie die Probleme behoben haben. Da davon auszugehen ist, dass die Angebote von weiteren Internet-Dienstleistern ähnliche Lücken aufweisen, haben wir gemeinsam mit dem eco-Verband Hoster über das Risiko informiert. Interessierten Providern stellen wir unser Skript zur Verfügung, um ihr System zu testen.

Selbstschutz

Offensichtlich sind viele Provider nicht willens oder in der Lage, ihren Kunden eine sichere Server-Umgebung zu bieten. Anwender müssen jedoch darauf vertrauen, dass ihr Provider seinen Server sicher konfiguriert. Ein wenig kann sich jeder Webspace-Besitzer zusätzlich schützen, indem er in seinen Verzeichnissen die Schreib- und Leserechte restriktiv einstellt. Viele ftp-Programme unterstützen das Setzen von Dateiattributen. Dabei sollte man auf Linux-Systemen alle Verzeichnisse auf dem Webserver gegen das Lesen durch fremde Nutzer schützen. Der entsprechende Parameter für den chmod-Befehl lautet 751. Wer großen Wert auf den Schutz seiner Web-Präsenz legt, die bisher in einer Shared-Hosting-Umgebung untergebracht ist, sollte damit auf einen dedizierten Server umziehen. (jo)

Literatur

[1] Deutsche PHP-FAQ

[2] Securing a PHP Installation: www.onlamp.com/pub/a/php/2001/03/29/php_admin.html

Tobias Glemser und Reto Lorenz sind IT-Security-Consultants der Tele-Consulting GmbH (jo)