Shared Hosting: Angriff auf Sessions möglich
08.05.2009 Yahe administration legacy linux security
Heute gibt es einen schon lange geplanten Artikel zu einem größeren Sicherheitsproblem. Meiner Erkenntnis nach könnte diese Lücke alle Shared Hosting Kunden betreffen, auch solche bei Reselling-Anbietern. Das Problem bei dieser Art des Webhostings ist, dass alle Webseiten von verschiedenen Kunden auf ein und demselben Server liegen und nur durch entsprechend gesetzte Zugriffsrechte voneinander getrennt sind. Das Problem hierbei ist, dass diese Zugriffsrechte nur mit viel Aufwand ganzheitlich durchsetzbar sind.
Mir ist z.B. aufgefallen, dass man zwar bei üblichen Angeboten auf FTP-Ebene und PHP-Ebene durch "SafeMode On" in dem eigenen Kundenverzeichnis "gefangen" ist, man jedoch unter Verwendung von CGI aus dem eigenen Verzeichnis ausbrechen kann. Danach ist es möglich, mithilfe von einfachen Befehlen z.B. alle Dateien und Ordner anderer Kunden suchen zu lassen, bei denen man selbst Schreibzugriff hat. Durch Zugriff auf den HTTP-Ordner eines anderen Kunden (z.B. "public_html", "public_http" oder "htdocs") ist es dann möglich, durch Anlegen einer einzigen Datei (".htaccess" bei Apache Webservern) die gesamte Domain zu hijacken.
Kunden können sich dagegen nur durch das korrekte Setzen der Ordner-Zugriffsrechte schützen.
Das war jedoch nur ein Szenario. Ein anderes ist viel gravierender, das sogenannte Session Hijacking. Bei Shared-Hosting Angeboten ist auch das möglich. Der Grund dafür ist, dass alle Kunden auf derselben Maschine die gleiche PHP-Instanz nutzen. Um die Verwaltung der Sessions zu erleichtern, werden diese meistens in einem gemeinsamen Verzeichnis für alle Kunden gespeichert. An sich ist das auch kein Problem, denn die Session-IDs sollten sowieso möglichst zufällig gewählt sein und in den Ordner, in dem die Sessiondateien liegen, kann ja eh keiner reingucken. Durch das weiter oben beschriebene CGI-Problem ändert sich diese Einschränkung jedoch. Dadurch wird es potentiell möglich, dass andere Kunden die eigenen Sessiondateien auslesen können. Direkten Zugriff per CGI hat man zwar meistens nicht, wenn die Zugriffsrechte ordentlich gesetzt sind, aber durch die gemeinsame PHP-Instanz erhält man auch Zugriff auf den gemeinsamen Sessionordner!
Je nach Webanwendung reicht diese Lücke vom Auslesen und Modifizieren des Einkaufskorbs bis zur Erlangung von Administratorrechten. Alles, was die Webanwendung in der Session speichert, können Kunden, die auf dem gleichen Shared-Server gehostet werden, lesen, modifizieren oder aber auch löschen (z.B. regelmäßig alle Sessions eines Webshops schließen, um den Shop unbrauchbar zu machen). Anhand von einfachem Ausprobieren (die Domainadressen der Mitgehostenen kriegt man dank der Ordnerstruktur des Servers manchmal sogar frei Haus geliefert), kann man die Sessionstrukturen meist den einzelnen Domains zuordnen. Und schon weiß man anhand der Daten in einer Session, dass da gerade jemand auf der Domain example.com etwas bestellen will.
Glücklicherweise können sich die Kunden dagegen schützen, indem sie den Session-SavePath von PHP manuell anpassen!
Das PHP Security Consortium hat zu diesem Problem ebenfalls einen Artikel veröffentlicht, empfiehlt jedoch alternativ, die Session-Informationen in einer Datenbank zu speichern.
