Category: linux

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.


Xpunge: Compression saved my Day!

22.03.2009 Yahe administration legacy linux windows

Ja, auch ich habe manchmal ein Brett vor dem Kopf, vor allem, wenn es um Mehrdeutigkeiten von Begriffen geht, wie z.B. dem Wort "Kompression". Ich als normaler Computernutzer verstehe darunter nämlich zuerst das "Zippen" von Dateien. Natürlich kann das auch bedeuten, dass irgendwelche Daten gelöscht werden, die unwichtig sind (z.B. verlustbehaftete Kompression im JPG- oder MP3-Format).

Wie ich darauf komme?

Nun, ich benutze zu Hause Thunderbird für mein E-Mailing, News-Grouping und RSS-Feeding. Um alles ein wenig sicherer zu machen, habe ich mein Thunderbird-Profil in einen TrueCrypt-Container verfrachtet, der genau so groß ist, dass ich ihn problemlos auf einer DVD sichern kann. Leider musste ich in letzter Zeit feststellen, dass es in dem Container langsam eng wurde. Nicht mal mehr 700MiB waren noch frei. Bei einem derzeitigen Mail-Aufkommen von ca. 5MiB/Tag kann man sich ausrechnen, wie lange das noch reicht. Also habe ich mal meine ganzen Papierkörbe ausgemistet und fand heraus, dass das keinerlei Auswirkung auf den freien Platz hatte. Da kam mir die Idee, dass die Mails evtl. gar nicht wirklich gelöscht werden, sondern, wie im Dateisystem, einfach nur als gelöscht markiert werden.

Aber wie werde ich die denn dann wirklich los?

Bei einem Knowledge-Base-Eintrag auf MozillaZine wurde ich fündig. Bei Thunderbird nennt man das Ausmisten der Speicherdateien "komprimieren" und mit dem Add-On Xpunge und der Funktion "MultiXpunge" kann man das sogar für alle E-Mail-Konten gleichzeitig ausführen lassen.

Nun habe ich erstmal wieder genug Platz und und bin für dieses Jahr gut gewappnet. Nach dem Studium kann ich ja dann eh einen ganzen Batzen Mailsin die Alt-Kleider-Sammlung geben.


Search

Links

RSS feed

Categories

administration (40)
arduino (12)
calcpw (2)
code (33)
hardware (16)
java (2)
legacy (113)
linux (27)
publicity (6)
review (2)
security (58)
thoughts (21)
windows (17)
wordpress (19)