Shared Hosting: Angriff auf Sessions möglich

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 Webhosting ist es, dass alle Webseiten (von verschiedenen Kunden) auf ein und demselben Server liegen und nur durch entsprechend gesetzte Zugriffsrechte voneinander getrennt sind. Das erste Problem ist, dass diese Zugriffsrechte nicht 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 "httpdocs") ist es dann möglich, durch Anlegen einer einzigen Datei (".htaccess" bei Apache Servern) 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! Schonmal von Session Hijacking gehört? Bei Shared-Hosting Angeboten ist es ein Kinderspiel!
Der Grund: alle Kunden auf derselben Maschine nutzen die gleiche PHP-Instanz! Um die Verwaltung der Sessions zu erleichtern, werden diese meistens in einem gemeinsamen Verzeichnis für alle Kunden gespeichert - an sich auch kein Problem: die Session-IDs sollten sowieso möglichst zufällig gewählt sein (am besten von PHP selbst bestimmt werden) und in den Ordner, in dem die Sessions liegen, kann ja eh keiner gucken.
Falsch gedacht! Durch das weiter oben beschriebene CGI-Probleme kann man natürlich nicht nur die Daten der anderen Kunden auskundschaften (Wortspiel 😉 ), sondern auch die Systemdateien durchsuchen. Und wie jeder PHP-Programmierer weiß, ist es relativ einfach möglich, herauszufinden, wo die Session-Dateien abgelegt werden.
Direkten Zugriff per CGI hat man zwar meistens nicht (wegen der Zugriffsrechte), aber wozu teilt man denn eine gemeinsame PHP-Instanz unter Freunden? Richtig! Um auch auf die Session-IDs der Freunde zugreifen zu können 😀 !

Je nach Webanwendung reicht diese Freundschaft vom Auslesen und Modifizieren des Einkaufskorbs bis zur selbst-gegebenen Administratoren-Rolle: 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 Domain-Adressen der Mit-Gehostenen kriegt man dank der Ordnerstruktur des Servers manchmal sogar frei Haus geliefert), kann man die Session-Strukturen meist den einzelnen Domains zuordnen: und schon weiß man anhand der Daten in einer Session, dass da grad jemand auf der Domain XYZ.ab etwas bestellen will.
Glücklicherweise können sich die Kunden dagegen schützen, indem sie den Session-SavePath von PHP manuell anpassen!

Leider wird dies nur in seltenen Fällen von den Kunden bedacht und auch die Entwickler von Fertig-PHP-Lösungen gehen anscheinend stets davon aus, dass die Kunden eine 100%ig sichere Server-Umgebung zur Verfügung haben.
Am praktikabelsten hat sich (imho) erwiesen, den Session-SavePath in den eigenen Public-HTML-Ordner zu verlagern und den designierten Speicherort (benötigt meist chmod 777) nach außen hin via .htaccess zu sperren.
Denn beherzigt man auch das oben beschriebene CGI-Problem, schlägt man auf diese Weise gleich 2 Fliegen mit einer Klappe: die eigene Seite kann nicht gehijackt werden und die Session-IDs können nicht ausgespäht werden - da für beide Aktionen die nötigen Zugriffsrechte auf den Ordner fehlen 😉 .

Zum Schluss sei noch etwas erwähnt:
Die hier bereitgestellten Informationen dienen lediglich der eigenen Weiterbildung und zur Absicherung der eigenen Systeme. Unter keinen Umständen darf dieses Wissen zur Manipulation von fremden IT-Systemen missbraucht werden: dies ist nach deutschem Recht unter Androhung einer Freiheitsstrafe verboten. Bitte beachten Sie diesbezüglich auch §202a StGB ("Ausspähen von Daten")!

Wie nützlich fandest du diese Informationen? Denkst du, du könntest betroffen sein? Wie wichtig ist dir die Sicherheit deiner Hosting-Plattform?
Update:
Habe gerade mal versucht, diesen Artikel zu ergooglen und bin dabei über das PHP Security Consortium gestolpert, das über genau dasselbe Problem schreibt: anstelle den Ort der Session-Dateien zu modifizieren, schlagen sie vor, die Session-Informationen in einer Datenbank zu speichern.
Informierende Grüße, Kenny

P.S.: Nutzer von WordPress sind zwar vom CGI-Problem, nicht aber vom Session-Problem betroffen - zumindest, soweit ich das in Erfahrung bringen konnte. Denn meines Wissens nach verwendet WordPress keine Sessions, sondern Cookies zur Speicherung der Sitzungsdaten.

Schreibe einen Kommentar

Um Ihnen beim weiteren Kommentieren auf dieser Webseite die erneute Eingabe Ihrer Daten zu ersparen, wird beim Absenden Ihres Kommentars ein Cookie an Ihren Browser gesendet und von diesem gespeichert. Mit dem Absenden eines Kommentars auf dieser Webseite stimmen Sie der Speicherung und Übertragung dieses Cookies explizit zu.

Pflichtfelder sind mit * markiert.