Selten vergeht eine Woche, in der keine neuen Sicherheitslücken oder Exploits für bekanntere oder weniger bekanntere PHP-Anwendungen auf einer der Sicherheits-Mailinglisten auftauchen. Mit diesen Veröffentlichungen beginnt in der Regel eine Welle von Angriffen auf betroffene Server und Administratoren haben alle Hände voll damit, Würmer und Skript-Kiddies abzuwehren. Besonders schwierig gestaltet sich dies immer dann, wenn den Anwendungsentwicklern keine Zeit gelassen wurde, die Sicherheitsprobleme zu beheben, bevor die Öffentlichkeit informiert wird oder wenn die Probleme bereits von Würmern ausgenutzt werden, bevor überhaupt irgendjemand informiert wurde. Beide Fälle traten in jüngster Vergangenheit vermehrt auf und führten zur Verzweiflung des einen oder anderen Administrators, der erkennen musste, dass seine PHP-Konfiguration gegen derlei Angriffe nicht gefeit ist. Solche Fälle waren Gründe, die zur Entwicklung der Suhosin PHP-Erweiterung führten.
Die Idee hinter Suhosin ist, dass zum einen viele der heutigen Sicherheitsprobleme von PHP-Anwendungen auf Unkenntnis bestimmter PHP-Eigenarten zurückzuführen sind, die zur Laufzeit abgefangen werden können. Zum anderen können typische Fehler bei der Kommunikation mit dem Client oder anderen Subsystemen direkt an den jeweiligen Schnittstellen abgesichert werden, ohne dass Eingriffe in die Applikationen nötig werden. Durch Beachtung dieser beiden Punkte gelingt es Suhosin daher nicht nur bekannte, sondern auch viele unbekannte Angriffe abzublocken. Für den Fall, dass ein Angriff diese automatische Schutzschicht durchbricht, bringt die Erweiterung zudem diverse Konfigurationsflags mit, die es dem Administrator viel detaillierter ermöglichen, gefährliche Features von PHP abzuschalten, wie dies in einer normalen PHP-Installation nicht möglich ist.
Installation und Konfiguration
Suhosin hat bereits seinen Weg in diverse Linux- oder BSD-Distributionen gefunden. Daher ist es in vielen Fällen möglich, Suhosin direkt aus dem Paketangebot zu laden. Es lohnt sich jedoch, vor der Installation die Versionsnummer mit der aktuellen Version auf der Webseite zu vergleichen, da es häufig neue Versionen mit neuen Features gibt, die für den eigenen Einsatz interessant sein könnten. In diesem Fall empfiehlt es sich, das aktuelle Archiv herunterzuladen und die Installation manuell durchzuführen. Dies verläuft analog zur Installation anderer PHP-Erweiterungen. Eine genaue Anleitung hierzu finden Sie in der Suhosin-Dokumentation. Wenn die Installation erfolgreich war, finden Sie den in Abbildung 1 gezeigten Eintrag in der Ausgabe von phpinfo(). Aktiviert und konfiguriert wird Suhosin über die php.ini. Eine erklärte Beispielkonfiguration liegt dem Suhisin-Archiv bei. Die gleichen Informationen finden sich jedoch auch in der Dokumentation.
Simulation und Logging
Viele potentielle Anwender von Suhosin werden zunächst von der Vielzahl der Features und Konfigurationsoptionen abgeschreckt und befürchten, dass eine falsch gesetzte Option direkt zu massiven Problemen in der eigenen Applikation führen wird. Der Schein trügt. Die meisten Optionen müssen niemals angefasst werden, da die Standardkonfiguration in den allermeisten Fällen zu keiner Beeinträchtigung führt. Darüber hinaus existiert für genau diese Problematik der Simulationsmodus. Über den Schalter suhosin.simulation wird festgelegt, ob nur simuliert werden soll oder die Erweiterung scharf geschaltet ist. In der Simulation wird nichts geblockt, sondern lediglich geloggt, dass etwas geblockt werden würde. Auf diese Weise kann der Anwender testen, ob die Konfiguration kompatibel zur Applikation ist.
Geloggt werden kann von Suhosin auf eine ganze Reihe von Arten. Normalerweise wird nach Syslog Ausschau gehalten. Es ist jedoch auch möglich, direkt in eine Datei oder per Shell- oder PHP-Skript zu loggen. Die Logeinträge sehen dabei folgendermaßen aus:
Oct 31 06:06:06 debian suhosin[4252]: ALERT - Include filename is an uploaded file (attacker '192.168.1.17', file '/home/www/test.php')
Das folgende Listing zeigt, wie Sie das Logging mit einem PHP-Skript erledigen. In dem Beispiel werden zusätzlich zur Fehlermeldung der aktuelle Backtrace und der Inhalt aller Variablen per E-Mail an den Admin versendet.
<?php$nachricht = "Suhosin hat den folgenden Angriff geloggt\n\n";$nachricht .= htmlentities($SUHOSIN_ERROR)."\n\n";$nachricht .= htmlentities(var_export(debug_backtrace(), true))."\n\n";$sg = array("_GET", "_POST", "_COOKIE", "_SERVER");foreach ($sg as $name) {$nachricht .= $$name."\n";$nachricht .= htmlentities(var_export($$name, true))."\n\n";}mail("admin@example.com", "Suhosin-Alert", $nachricht);?>
Sicher vor Remote Includes
Die am weitesten verbreitetste und gefährlichste Sicherheitslücke in PHP-Anwendungen sind include- oder require-Statements, die ohne Prüfung mit vom Nutzer kommenden Daten gefüllt werden. Dies führt oftmals dazu, dass beliebiger PHP-Code von außen nachgeladen und ausgeführt werden kann. Suhosin blockt dies, indem in der Standardkonfiguration keinerlei URLs in include- oder require-Statements akzeptiert werden. Dies ist vergleichbar mit der allow_url_include-Funktionalität ab PHP 5.2.0 – mit dem Unterschied, dass Suhosin diese Funktionalität auch alten PHP-Versionen (zum Beispiel PHP 4) zur Verfügung stellt und durch seine Implementation als Whitelist/Blacklist-Ansatz eine Konfiguration mit Ausnahmen erlaubt. Darüber hinaus existieren noch weitere Schutzmaßnahmen, so dass beispielsweise nicht Dateien includiert werden können, die im gleichen Request mittels POST-Dateiupload hochgeladen wurden.
Variablenfilter
Suhosin wendet konfigurierbare Filter auf GET-, POST- und COOKIE-Variablen an, um eventuelle Angriffe auf das Skript schon vor der Variablenregistrierung abzufangen. Es existieren dabei drei Typen von Filtern:
- Dimensionsfilter
- Namensfilter
- Zeichenfilter
Die Dimensionsfilter erlauben es, auf die Länge von Variablennamen oder des Inhalts, auf die Tiefe von Arrays und auf die Anzahl zu filtern. Sinn dieser Filter ist es zum einen, überlangen Input abzufangen, der zu Bufferoverflows in PHP führen könnte, und zum anderen ,um DOS-Attacken durch sehr tiefe Array-Strukturen oder übermäßig viele Variablen zu stoppen. Variablen, die diese Filterung verletzen, können ignoriert werden oder aber der Request geblockt oder umgeleitet werden.
Die Namenfilter verbieten, dass Variablen, die über GET, POST oder COOKIE hereinkommen, bestimmte reservierte Namen haben können. Dies sind zum Beispiel GLOBALS, _GET, _REQUEST und ähnliche. Der Sinn dieses Filters beruht darauf, dass viele PHP-Applikationen, die entweder register_globals emulieren oder rückgängig machen wollen, dazu verleitet werden können, GLOBALS, _SERVER oder eine der anderen superglobalen Variablen zu überschreiben. Dies hat in jüngster Vergangenheit zu diversen Remote-Code-Execution-Lücken in populärer Software wie Joomla geführt.
Die letzte Klasse an Filtern sind die Zeichenfilter. Suhosin verbietet beispielsweise das ASCII-Null-Zeichen in den Requestvariablen, da dieses zu einer Vielzahl von Problemen führen kann, insbesondere, wenn es um die Behandlung von Dateinamen geht. Sollte das Zeichen tatsächlich gebraucht werden, was eher untypisch ist, dann kann dieser Filter deaktiviert werden. Neue Versionen von Suhosin tauschen zudem die Zeichen < > " und ' in bestimmten _SERVER-Variablen gegen '?' oder ihre URL-Codierung aus, um so automatisch eine ganze Reihe von XSS-Verwundbarkeiten über Dinge wie PHP_SELF abzufangen.
Session-Sicherheit
Viele PHP-Programmierer benutzen das PHP-Sessionmanagement, ohne sich darüber Gedanken zu machen, dass es sich dabei nur um ein Rohgerüst handelt, das erst durch die richtige Programmierung in der Applikationslogik sicher gemacht werden muss. Rufen Sie also die jeweiligen Funktionen, wie die Neugenerierung des Session-Identifiers mit session_regenerate_id() nicht selbst auf, dann ist Ihre Anwendung anfällig gegenüber Session-Hijacking und ähnlichen Angriffen. Darüber hinaus speichert PHP die Sessiondaten aller Applikationen aller Nutzer in Dateien, die alle im gleichen Verzeichnis liegen, wenn dies nicht explizit anders konfiguriert wird. Das führt dazu, dass man Sessiondaten nicht mehr vertrauen kann, da diese von anderen Applikationen oder Nutzern eingesehen oder gar manipuliert werden könnten.
Was bedeutet Suhosin?
Suhosin ist ein südkoreanisches Wort und hat eine ähnliche Bedeutung wie Schutzengel. Ausgesprochen wird Suhosin wie su-ho-schin.Da insbesondere viele alte Applikationen diese beiden Problematiken aufweisen, kann Suhosin auf Wunsch die Sessiondaten verschlüsseln. Dies geschieht transparent für die Anwendung, indem Suhosin sich zwischen die (De-)Serialisierung der Sessiondaten und der jeweiligen Session-Storage-Engine hängt. Der Schlüssel, der dabei verwendet wird, setzt sich dabei je nach Konfiguration aus verschiedenen Teilen zusammen, die es erlauben, verschiedene Grade an Sicherheit zu erreichen, ohne dass ein Eingriff in den Applikations-Code nötig wird. Die konfigurierbaren Teile sind
- cryptua – rechnet den User-Agent des Nutzers in den Schlüssel
- cryptkey – rechnet einen anwendungsspezifischen Schlüssel hinein
- cryptdocroot – rechnet das Document-Root-Verzeichnis herein
- cryptclient – rechnet ein Client-Cookie in den Schlüssel
- cryptraddr – rechnet 0 bis 4 Octets der IP in den Schlüssel
Werden alle diese Optionen aktiviert, dann ist die Session relativ sicher gegen die erwähnten Angriffe, da sie zum einen an die IP des Nutzers gebunden ist, und zum anderen können die Sessiondaten nur noch bei Kenntnis des Anwendungs- und Client-Schlüssels entschlüsselt oder manipuliert werden. Da IP- und Client-Schlüssel nur durch Abhören einer aktiven Verbindung ermittelt werden können, können Sessiondaten auch nicht entschlüsselt werden, wenn ein Angreifer oder eine andere Applikation kompletten Zugriff auf die verschlüsselten Daten und die Konfiguration hat. Sollte man die IP in den Schlüssel hinein rechnen wollen, muss man beachten, dass insbesondere die Nutzer von großen Providern, Proxies und Firmen während eines Visits unterschiedliche IPs haben können.
Cookie-Sicherheit
Ähnlich wie Sessions werden Cookies in PHP-Anwendungen häufig benutzt, ohne dass sich der Programmierer dabei im klaren ist, dass der Inhalt des Cookies abgehört oder aber auch manipuliert werden kann. Dies ist insbesondere dann kritisch, wenn im Cookie sensitive Informationen wie der Nutzername, das Passwort oder gar ein Auto-Login-Key übermittelt werden. In solch einem Fall kann eine einzelne XSS-Verwundbarkeit in der Anwendung genügen, um an die Zugangsdaten eines Nutzers zu gelangen. Im Gegenzug hat die Vergangenheit gezeigt, dass dem Inhalt des Cookies oftmals mehr vertraut wird als anderen Request Parametern, obwohl diese im gleicher Weise manipuliert werden können. Dies führt nicht selten zu immensen Sicherheitslücken, die zum Beispiel ein Einloggen ohne Passwort ermöglichen, indem einfach die im Cookie gespeicherte UserID geändert wird. Zum anderen speichern immer noch viele Applikation serialisierte Daten im Cookie, ohne dass diese verifiziert werden. Das sorgte dafür, dass zum Beispiel Server, die phpBB verwenden, in der Vergangenheit über die Sicherheitslücken in PHPs unserialize()-Funktion angegriffen werden konnten.
Um diesen Problemen entgegen zu wirken, klinkt sich Suhosin in die Behandlung der HTTP-Header ein. Auf diese Weise kann es ausgehende Cookies verschlüsseln und eingehende Cookies wieder entschlüsseln. Die Cookies der Anwendung werden auf diese Weise vor dem Ausspähen durch zum Beispiel Javascript und vor der Manipulation geschützt, da sich der Schlüssel auch hier analog zu dem Schlüssel für die Session aus verschiedenen Teilen zusammenbauen lässt. Außerhalb des Servers ist es daher nicht möglich, die echten Daten einzusehen oder zu ändern, sofern die Konfiguration des Schlüssels geheim gehalten wird.
Da es durchaus Applikationen gibt, in denen Javascript Zugriff auf den Inhalt einzelner Cookies braucht, kann Suhosin über einen kombinierten Whitelist/Blacklist-Ansatz dazu veranlasst werden, bestimmte Cookies nicht zu verschlüsseln oder nur bestimmte Cookies zu verschlüsseln.
Datei-Upload
Viele PHP-Anwendungen, die mit Usergenerated Content arbeiten, erlauben beispielsweise das Hochladen von Bildern, Dokumenten und anderen Medien auf den Server. Dies kann zu diversen Sicherheitsrisiken führen. Ist es beispielsweise möglich, aktive Inhalte hochzuladen, die dann vom Browser interpretiert werden, kann das XSS oder ähnliche Attacken nach sich ziehen. Viel simpler ist aber die Gefahr, die durch das Hochladen von Viren entsteht. PHP-Applikationen sind in der Regel nicht dazu ausgelegt, Viren zu erkennen oder hochgeladene Dateien von externen Virenscannern verifizieren zu lassen. Deshalb hängt sich Suhosin in die Routinen zum Dateiupload und erlaubt es, ein beliebiges Shellskript aufzurufen. Liefert dies eine 1 zurück, dann wird der Upload erlaubt – ansonsten nicht.
Das folgende kleine Shellskript, das über die Konfigurationsoption suhosin.upload.verification_script aufgerufen wird, übergibt die temporäre Datei, die von PHP beim Upload angelegt wird, an ClamAV, um sie nach Viren zu scannen. Falls ein Virus gefunden wird gibt das Skript eine 0 aus, was für Suhosin ein Zeichen ist, den Upload nicht zuzulassen. Die temporäre Datei wird dann gelöscht und der Upload gar nicht erst in _FILES registriert.
#!/bin/bashif [-n "`clamscan --infected --no-summary $1`" ]; thenecho 0;elseecho 1;fi
Fazit
Suhosin ist eine reichhaltige Toolbox zur Absicherung von PHP-Applikationen. In der Regel lassen sich alle Features nutzen, ohne dass ein Eingriff in die Applikation nötig wird. Durch diese Funktionsweise wird es zu einer Erleichterung, insbesondere dann, wenn man dazu gezwungen ist, alte und womöglich nicht mehr gewartete Applikationen einzusetzen. Dieser Artikel kann nur als kurze Einführung in Suhosin dienen, da eine vollständige Aufzählung aller Features, die von Version zu Version mehr werden, bereits jetzt den Rahmen sprengt. Wer sich einen vollständigen Überblick verschaffen will, sollte deshalb auf die Webseite des Projektes schauen und Suhosin einfach einmal ausprobieren. Am besten zunächst im Simulationsmodus, damit man sehen kann, an welchen Stellen die Applikation mit der aktuellen Konfiguration kollidiert.
Stefan Esser ist Gründer und Security Consultant der Firma SektionEins, die verschiedene Dienstleistungen rund um Web Application Security anbietet. Durch zahlreiche aufgedeckte Sicherheitslücken in PHP und anderen Applikationen hat er sich international einen Namen gemacht.
