Embed Size (px)
Citation preview
2
Über Christopher Kunz
• Wohnt und arbeitet in Hannover• PHP-Erfahrung seit 1999• Mitglied im Hardened-PHP Project• URLs
– http://www.christopher-kunz.de/– http://www.hardened-php.net/– http://www.php-sicherheit.de/
3
Weiterführende Informationen
Christopher Kunz, Peter Prochaska
PHP-Sicherheit
dpunkt.verlag 2006
(2. Auflage 2007)
ISBN 3-89864-369-7
€ 36,00
4
Agenda
• Aktuelle Entwicklungen in Webapp-Security
• Client-Side Angriffe• Server-Side Angriffe• Härten des Webservers / PHP• Request Filtering mit Apache-Modulen• (Alle Slides werden auch online sein!)
5
So sieht's aus...
• "Wurm schlängelt sich durch MySpace"• "StudiVZ: Belohnung für
Sicherheitslücken"• "Web-Kalender Kronolith lässt sich Code
unterschieben"• "deV!L`z Clanportal - SQL Injection
[061124a]"
6
Aktuelle Problemfelder
• Angriffe gegen Nutzer– Cross-Site Scripting (XSS)– Cross-Site Request Forgery (CSRF)
• Angriffe gegen Server– SQL Injection– Command Injection– Local/Remote Code Execution
7
Angriffe gegen den Nutzer
• Nutzer webbasierter Applikationen sind gefährdet!
• Aktuelles Beispiel: StudiVZ• Ausspähen sensitiver Informationen per
JavaScript/DOM• Ausnutzen von Browser-Komfort für
eigene Zwecke („AutoVervollständigung“)• Sehr große Spanne an Möglichkeiten
8
XSS – Cross-Site-Scripting
• Grundidee: Zonenmodell moderner Browser austricksen
• Angreifer sucht Möglichkeit, eigenen Code (JavaScript, nicht PHP/Perl o.ä.) auf Zielsite einzubetten
• Browser des Opfers führt diesen Code aus• Sicherheitszone: Die der Zielsite
9
XSS – Einfache Beispiele
• Bei Formular-Textfeldern– "><script>alert('xss')</script>– ' onfocus=javascript:alert('xss')
• In HTML-Tags– <IMG SRC="javascript:alert('XSS');">– <BODY
BACKGROUND="javascript:alert('XSS')">• XSS Cheatsheet enthält mehr Beispiele
– http://ha.ckers.org/xss.html
10
XSS - Komplexität
• Durch DOM beliebige Manipulationen am Dokumentbaum möglich– Ersetzen von Text– Austauschen von Formularfeldern / -zielen– Automatischer Versand von Formularen
• Durch Browserkomfort (Paßwort-Safe) auch Login-geschützte Seiten kein Problem
11
XSS und "Web 2.0"
• Moderne Websites sind überladen mit JavaScript (AJAX, Besuchertracking etc.)
• Injektion von HTML-Tags oft nicht nötig• Eine verwundbare JS-Variable reicht• Komplette Anwendung ist nicht mehr
vertrauenswürdig• Bei Webmail etc. praktisch unbegrenztes
Abuse-Potential• Auch nett: JS in Quicktime, Cross-Domain XML
per Flash
12
XSS und PHP
• Hauptgrund: Ungeprüfte Ausgabe von Userinput
• echo $_GET['irgendwas']• PHP-Gegenmittel
– htmlentities(); – strip_tags()
• Kein Administratorenproblem
13
SQL Injection
• Angriffe gegen Datenbanklayer • Manipulation ungenügend geprüfter SQL-
Queries• Fehlende Typ-/Inhaltsprüfung• Resultat: Verfälschtes Resultatset
– Auslesen privilegierter Daten– Umgehung von Autorisierung / Authentifizierung– Je nach DBMS: Zugriff aufs Dateisystem
14
SQL Injection in PHP
• Angreifbares Query:• $query = "SELECT is_authorized FROM
users WHERE username = '" . $_POST['username'] . "' AND password = '" . $_POST['password'] . "'";
• $_POST['username'] = "admin' /*"Authentifizierung umgangen
15
SQL Injection: Gegenmaßnahmen
• Usereingabe nicht vertrauen!• Maskieren von SQL-Sonderzeichen
– mysql_real_escape_string($_POST['username']
• Prepared Statements– mysqli->prepare() etc.
• Hauptsächlich Entwicklerproblem
16
Angriffe gegen den Server
• Automatisierte Scans nach verwundbaren Applikationen
• Professionelles Management der Angreifer• Zunehmende professionelle Tools• Ziel: Server rooten / als Spambot
verwenden• Das IST ein Administratorenproblem ☺
17
Klassifikation
• Local/Remote Code Injection• Arbitrary file inclusion
– meist "dank" eval/include und Konsorten– Klassiker: include($_GET['page'])
• Königsklasse: Nachladen von Exploitcode per HTTP– Neu in PHP: Stream-Handler data: - praktisch
für Exploits
18
C99shell
19
r57shell.php
20
Defacing Tool Pro v2.5
21
"PHP ist unsicher!"
• Oft verbreitetes "Argument" gegen PHP• Nicht PHP ist unsicher, sondern PHP-
Anwendungen– Schwache Typisierung erleichtert Entwicklerfehler
• Ist C schuld an Sendmail oder Bind 7?• Allerdings: Lücken im PHP-Kern noch immer
(zu) häufig• Tainted Mode fehlt nach wie vor
22
Bordmittel für PHP-Security
• Geeignete Auswahl der SAPI• CGI/FastCGI statt mod_php
– Separation der Nutzer mittels suExec– Eigene php.ini pro Nutzer– Auch versch. PHP-Binaries pro Nutzer
möglich• ini-Einstellungen für mehr Sicherheit
23
Safe Mode
• UID/GID Checks bei Dateioperationen• Seit PHP 4 in PHP, stets Notlösung• Extension-abhängig, häufige Lücken in der
Vergangenheit• Wird in PHP 6 abgeschafft• Oft falsches Gefühl der Sicherheit
24
open_basedir
• open_basedir=/var/www/kunde1• Überprüft bei Dateioperationen
Verzeichnis• Direktive gibt Basisverzeichnis an,
außerhalb dessen nicht zugegriffen werden darf
• Im Beispiel: include("/etc/passwd") wird verhindert
25
disable_functions
• disable_functions="system,passthru,eval"• Funktionen selektiv verbieten• Wird oft für Prozeßkontroll-
/Systemfunktionen eingesetzt• Unerwünschte Seiteneffekte• Kompatibilitätsprobleme
26
system() und Co.
• PHP-Funktion system() forkt Shell• Oft für Helper-Binaries wie ImageMagick• Eingesetzt u.a. bei Typo3• Problem: Shell + Binaries kümmern sich
nicht um Safe Mode Sicherheitsleck!• Lösung: Keine externen Binaries zulassen!
27
allow_url_fopen
• Großes Problem für PHP-Anwendungen: Include auf unsichere Ziele
• Direktive "allow_url_fopen Off" verbietet Öffnen von URLs komplett– Unerwünschte Nebenwirkungen
• Seit PHP 5.2.0: "allow_url_include" –berücksichtigt nur include/require(_once)
• Empfehlung: Ausschalten!
28
Register Globals
• Registrierung von Requestvariablen als globale Variablen
• Aus $_GET['foo'] wird $foo• Häufig noch aktiviert, obwohl seit 4.2.0 default
off• register_globals on vereinfacht unsauberen
Code• register_globals Off! Immer!• register_globals verschwindet in PHP 6
29
Suhosin
• Freier Patch / Extension für PHP vom Hardened-PHP Project
• Früher: "Hardened-PHP" bzw. "Hardening Patch for PHP"
• Per php.ini konfigurierbar• http://www.suhosin.org/
30
Extension / Patch
• Funktionalität aufgeteilt in – PHP-Extension– Patch für PHP-Quellcode
• Extension kompatibel zu allen anderen PHP-Extensions
• Suhosin-Teile können unabhängig voneinander genutzt werden
• Verfügbar in OpenSUSE, diversen BSDs, Gentoo, Debian etc.
31
Suhosin-Patch
• Schutz gegen Overflows– Canary Protection für Zend Memory Manager
• Schutz gegen Formatstring-Angriffe
32
Suhosin: Simulationsmodus
• Konfiguration: suhosin.simulation• Tut alles, nur keine „richtigen“ Aktionen• Sehr nützlich zum Überprüfen auf
Probleme mit lokaler Installation• Testen / Austarieren der Blacklist /
Whitelist
33
Suhosin: Variablen-Features
• Variablenfilter– GET/POST/COOKIE darf keine geschützten
Variablen enthalten– Variablenlänge, Variablenzahl, Arraytiefe etc.
limitierbar– Superglobals gegen extract() etc. geschützt
34
Suhosin: Runtime-Features
• Rekursionstiefe limitierbar• memory_limit kann nicht mehr vom User
geändert werden• Neue realpath() Funktion
35
Suhosin: Whitelist/Blacklist
• Per Vhost konfigurierbar• Whitelist für Funktionen• Blacklist für Funktionen• Zwei Modi
– Normal– Innerhalb eval()
36
Suhosin: Include-Filter
• (Konfigurierbares) Verbot von include auf...– URLs (Blacklist/Whitelist möglich)– Überlange Dateinamen (BSD)– Abgeschnittene Dateinamen (%00)– Hochgeladene Dateien– Schutz gegen Directory Traversal
(„../../etc/passwd“)
37
Suhosin: Diverse Features
• Kryptographiefunktionen– CRYPT_BLOWFISH-Algorithmus für crypt()– Sha256() und sha256_file() für Message
Hashing• Transparente Cookieverschlüsselung• Transparente Verschlüsselung von
Sessiondaten• Umfangreiches Logging
38
mod_security
• Freies Apache-Modul• Analyse eingehender Requests• Blacklist-Approach• Regex-basierte Regeln• Aktuelle Versionen: 1.9.x / 2.0• Grundlegende Änderungen in 2.0
39
mod_security: Features
• Überprüfung des gesamten Scopes oder einzelner Bestandteile (GET, POST, Cookie etc.)
• Überprüfung von XML-Dokumenten mit xPath
• Sprachunabhängig• Logging / IDS-Funktionalität• chroot-Umgebung für Apache
40
mod_security Installation
• Download von http://www.modsecurity.org/• Version 1.9
– apxs -cia mod_security.c– apachectl stop / start– Fertig!
• Version 2.0– Makefile editieren (top_dir =/usr/local/apache2)– make; apachectl stop; make install– Konfiguration– apachectl start
41
mod_security: Konfiguration
• LoadModule security2_module modules/mod_security2.so
• SecRuleEngine [On|Off|DetectionOnly]– Vor 2.0: SecFilterEngine
• SecServerSignature PwnServer/1.0• SecChrootDir /home/chroot
42
mod_security: Regeln
• Regeln bestehen aus 2-3 Komponenten– optional: Wo? (Variablen-Scope)– Was? (Filterausdruck)– Was tun? (Aktion)
• SecFilter prüft gesamtes Scope• SecFilterSelective prüft Teilscope
– In mod_security 2: SecRule– SecRule VARIABLES OPERATOR [ACTIONS]
43
mod_security: Scoping
• REQUEST_URI• REQUEST_HEADER:Content-Length • ARGS • ARGS|!ARGS:safe• ARGS:unsafe• Regexp: ARGS:/^pageid_/ • XML:/xPath/Expression• etc.
44
mod_security: Operatoren
• Pre-2.0: Regexp für Regeln• 2.0: viele zus. Funktionen
– Performance-Impact!• Operatoren
– Numerisch: eq, ge, gt, le, lt– Regexp: rx (impliziert durch Regex am Regelbeginn)– rbl – RBL-Lookup z.B. auf REMOTE_ADDR– etc.
• SecRule ARG:id "@gt 0"
45
mod_security: Aktionen
• pass – An dieser Regel vorbeilassen• allow – An allen Regeln vorbeilassen• deny – HTTP-Status 403 senden (= status:403)• status:x – HTTP-Status x senden• redirect:x – HTTP-Redirect auf URI x• exec:x – externes Executable x ausführen• nolog, log – Meldung (nicht) loggen• skipnext:x – Nächste x Regeln überspringen• chain – Verkettung mit nächster Regel• pause:x – Ausführung um x ms verzögern• u.a.m.
46
mod_security: Fazit
• Blacklistansatz unnütz gegen 0Day• Fängt mit passenden Rulesets extrem
viele automatisierte Exploits• "Web-IDS" im DetectionOnly-Modus
47
mod_parmguard
• Freies Apache-Modul• Analyse eingehender Requests• Apache 1.3, 2.x• Whitelist-Ansatz• XML-Konfigurationsdateien
48
mod_parmguard
• Whitelist-Ansatz gilt allg. als sicherer– Keine "überflüssigen Variablen"– Klare Definition der möglichen Schnittstellen
• Constraints– Datentyp– Wertebereich– Bei Aufzählungen: Mögliche Optionen
49
mod_parmguard: Installation
• Download von http://www.trickytools.com/php/mod_parmguard.php
• ./configure –with-apxs[2]=/usr/sbin/apachectl
• make && make install• apachectl stop / start• Fertig!
50
mod_parmguard: httpd.conf
• Konfiguration innerhalb von <Location>-Blöcken
<Location />ParmguardEngine OnParmguardConfFile /etc/parmguard.xml
</Location>
51
mod_parmguard: XML-Konfiguration
• Konfigurationssprache: XML• Validierung gegen mitgelieferte DTD• Schachtelung / Gruppierung von Parametern• Benutzung herkömmlicher XML-Tools zur
Generierung möglich<url>
<match>foobar.php</match>[parameter]
</url>
52
mod_parmguard: Beispiel
<xml version="1.0"?><!DOCTYPE parmguard SYSTEM
"mod_parmguard.dtd"/><parmguard>
<global name="http_error_code" value="403"/><url><match>adresse.php</match><parm name="name"><type name="string"/><attr name="maxlen" value="20"/><attr name="charclass" value="^[a-zA-Z]+$"/>
</parm><parm name="PLZ"><type name="integer"/><attr name="minval" value="00000"/><attr name="maxval" value="99999"/>
</parm></url>
</parmguard>
<form>
<input type="text" name="name">
<input type="text" name="PLZ">
<input type="submit">
</form>
53
mod_parmguard: Fazit
• Interessanter Ansatz für kontrollierte Umgebung
• Aufwand kaum vertretbar bei großen Anwendungen
• Für Administratoren Variablenliste schwer zu erstellen
54
Vielen Dank
• Slides online: http://www.php-sicherheit.de/
• Fragen? • Kontakt: christopher.kunz@hardened-
php.net
