Advanced Web Hacking Matthias Luft Security Research mluft@ernw.de ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de 6/23/2010 1
ERNW GmbH Sicherheitsdienstleister im Beratungs- und Prüfungsumfeld mit Sitz in Heidelberg, aktuell 18 Mitarbeiter Unabhängig Tiefgreifende technische Kenntnisse Strukturierter Ansatz Geschäftsrelevante und vernünftige Empfehlungen Wir verstehen den Betrieb in großen Unternehmen Blog: www.insinuator.net Konferenz: www.troopers.de ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de
Agenda 1. SSL Renegotiation Attack 2. SQL Injection gegen MS 2008 3. Session Highjacking ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de 6/23/2010 3
TLS RENEGOTIATION ATTACK
TLS Renegotiation Attack Entdeckt durch Marsh Ray und Steve Dispensa von PhoneFactor - 08/2009
TLS Handshake
TLS Handshake mit Cert (ideal)
TLS Handshake mit Cert (typisch)
TLS Renegotiation Attack Phase 1
TLS Renegotiation Attack Phase 2
Impact Der Angreifer muss in einer Man-in.the-Middle Position sein Angreifer injiziert Daten im Kontext des Clients Der Angriff erfolgt blind Kein grossflächiges Mitlesen des verschlüsselten Datenverkehrs Aber es gibt praktische Beispiele
Gegenmassnahmen Patchen, wenn ein Patch verfügbar ist (aktueller Status unter http://www.phonefactor.com/sslgap/ssl-tlsauthentication-patches) Abschalten der Renegotiation, wenn möglich
SQL INJECTION
SQL Injection Einschleusen von SQL Kommandos Benutzereingaben werden nicht validiert Umfangreiche Funktionen bei MS SQL Server, z. B. Stored Procedures wie xp_cmdshell Kritische SPs sind seit SQL Server 2005 per default deaktiviert SQL Injection Probleme im Code nehmen ab, werden aber immer noch zu häufig gefunden
SQL Injection: xp_cmdshell Xp_cmdshell ermöglicht das Ausführen von Kommandos Benutzer können angelegt werden Download von Dateien (TFTP, FTP) Erzeugen von Batch Dateien, z. B. über echo Für Hacker eine wünschenswerte Funktion
xp_cmdshell aktivieren Voraussetzung: Eine SQL Injection Vulnerabiltiy ein ausreichend berechtigter Zugriff der WebApp auf den SQL Server SQL Server läuft mit Admin Berechtigungen EXEC sp_configure 'show advanced options',1 RECONFIGURE EXEC sp_configure 'xp_cmdshell',1 RECONFIGURE
xp_cmdshell aktivieren
xp_cmdshell aktivieren
xp_cmdshell aktivieren
xp_cmdshell aktivieren
xp_cmdshell aktivieren
xp_cmdshell aktivieren
xp_cmdshell aktivieren
SQL Injection realistisch Voraussetzung: Eine SQL Injection Vulnerabiltiy => realistisch ein ausreichend berechtigter Zugriff der WebApp auf den SQL Server => kommt drauf an SQL Server läuft mit Admin Berechtigungen => Nicht Default!!!! Szenario cool, aber weniger realistisch Realistisch: Abgreifen von sensiblen Daten => Blind Folded SQL Injection
SQL Injection realistisch DB Version ermitteln: ' union select null,@@version,null,null,null -- DB Name ermitteln: ' union select null,catalog_name,null,null,null from information_schema.schemata -- Tabellen ermitteln: ' union select null,table_name,null,null,null from db_name.information_schema.tables --
SQL Injection realistisch Feldnamen ermitteln: ' union select null,column_name,null,null,null from db_name.information_schema.columns where table_name = 'Customers'-- und daten abgreifen: ' union select null,first_name + ' ' + last_name + ' ' + cc_num + ' ' + cc_type,null,null,null from customers --
SQL Injection realistisch
SQL Gegenmassnahmen Secure Coding, z. B. Prepared Statements und Input Validation SQL Server nicht mit hohen Berechtigungen laufen lassen (nicht als Local System) Keine Verbindung zum SQL Server als DBA (User SA bei MS-SQL)
SESSION HIJACKING
Session Management HTTP ist ein verbindungsloses Protokoll, daraus ergibt sich folgende Fragestellung: Wie wird festgestellt, ob ein User erfolgreich authentifiziert wurde? Durch Session Management, welches meist über einen der folgenden Mechanismen durchgeführt Cookies Query Strings 30 ERNW Web
Session Management mit Cookies Cookies Sind kleine Text-Dateien (max. 32KB), die von einem Server auf dem Client abgelegt werden können Web Anwendungen können beliebige Daten in einem Cookie speichern Cookies werden unter Windows im Verzeichnis C:\Documents and Settings\UserName\Cookies im Format UserName@DomainName.txt abgelegt Wird eine Web Site im Browser geladen, schickt dieser den dazugehörigen Cookie automatisch mit Man unterscheidet zwischen permanenten und temporären Cookies 31 ERNW Web
Session Management mit Cookies Sessions und Cookies GET /default.aspx SessionID vghwkw1 zrhab8 Data HTTP/1.1 200 OK Set-Cookie: SessionId=zrhab8..; path=/ GET /default.aspx Cookie: SessionId=zrhab8.. SessionID vghwkw1 zrhab8 Data HTTP/1.1 200 OK 32 ERNW Web
Cookie Attribute Secure Attribut Gibt an, wie Browser Cookie an Web Server senden darf Gesetztes Secure Attribute erlaubt Übermittlung nur via HTTPS Nicht gesetzt erlaubt Versenden via HTTP (unverschlüsselt) Verhindern das Inhalte von Cookies unverschlüsselt versendet werden HttpOnly Attribut Gibt an, wie auf das Cookie zugegriffen werden darf Gesetztes HttpOnly Attribut verhindert den Zugriff durch Scriptsprachen Verhindert, dass Cookie Inhalte von Scripten (z.b. JavaScript) ausgelesen werden können. 33 ERNW Web
Session Hijacking Bezeichnet die Übernahme einer authentifizierten und/oder autorisierten Session Im Fokus ist der Session Cookie bzw. die Session ID Wer diese Session ID besitzt, kann die Session übernehmen Wer die Session ID erraten kann, kann eine Session übernehmen / initiieren
Session Hijacking Angriffsvektoren Sniffing inkl. ARP Spoofing und SSL Man-in-the-Middle Angriff Cookie stehlen, z. B. über Cross-Site Scripting Vorhersagbarkeit Cross-Site Request Forgery
Session Hijacking Angriffsvektoren
Session Hijacking Angriffsvektoren
Session Hijacking Angriffsvektoren
Session Hijacking
Session Hijacking Angriffsvektoren
Session Hijacking Angriffsvektoren
Session Prediction
Session Prediction
Cross-Site Request Forgery (CSRF) ein kleines Beispiel Schritt 1: Bob (Opfer) meldet sich an einer Applikation an Schritt 2: Server akzeptiert Auth., erzeugt eine neue Session und setzt ein Cookie mit der Session ID User meldet sich an Set-Cookie: SID=12345 Bob www.bank.de 44 ERNW Web 44
Cross-Site Request Forgery (CSRF) Schritt 3: Mallory (Angreifer) erstellt einen Link, der eine bestimmte Aktion auslöst http://www.bank.de/transfer.php?to=mallory&euro=1000000 Mallory 45 ERNW Web 45
Cross-Site Request Forgery (CSRF) Schritt 4a: Mallory lockt Bob auf eine Website <img src= http://www.bank.de/transfer.php?to=mallory&euro=1000000 width=1 higth=1> Schritt 4b: Mallory schick Bob eine HTML Mail <a href= http://www.bank.de/transfer.php?to=mallory&euro=1000000 >Pictures</ a> HTML Mail mit Link Mallory Bob 46 ERNW Web 46
Cross-Site Request Forgery (CSRF) Bob klickt auf den Link oder besucht die Website Get Request wird ausgeführt Bobs Browser überträgt automatisch das Cookie Aktion wird ausgeführt GET http://www.bank.de/transfer.php?to=mallory&euro=1000000 Cookie: SID=12345 Bob www.bank.de 47 ERNW Web 47
Session fixation GET http://unsafe/ Set-Cookie: abc Cool link: http://unsafe?sid=abc GET http://unsafe?sid=abc ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de 6/23/2010 48
Session fixation GET http://unsafe?sid=abc Confidential Information Please Login Username + Password ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de 6/23/2010 49
Cross Service Authentication Nahezu alle komplexen Applikationen bestehen aus verschiedenen Diensten Applikation zur Generierung von Content SOAP REST Dienste laufen häufig auf verschiedenen Systemen um Skalierbarkeit zu gewährleisten Verarbeiten einer Session auf einem System nicht möglich Asynchrone Aufrufe ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de 6/23/2010 50
Cross Service Authentication Problem: Authentifizierung des Benutzers muss erhalten bleiben Cookie kann auch an zweiten Service mitgesendet werden Dieser Service weiß allerdings nichts über den Hintergrund des Cookies Häufig internes Durchschleifen von Authentifizierungsdaten Bietet Raum für Angriffe auf schlecht geschützte Authentifizierungdaten oder fehlerhafte Crypto- Implementierungen Ggfs. Vernachlässigung der Authentifizierung bei Backenddiensten ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de 6/23/2010 51
Gegenmassnahmen Nutzung vorhandener Standard Methoden, diese sind kryptografisch bereits verifiziert Kein eigenes Session Management implementieren, da die kryptografischen Anforderungen Nicht-Kryptologen überfordern Secure und HTTPOnly Attribute setzen Secure Coding z.b. Hash aus SessionID, Aktionsname, Secret jeder URL und jedem Formular hinzufügen Dadurch kann ein Angreifer keine gültigen Request mehr erzeugen Redundante Übertragung der Session ID in Hidden Fields 52 ERNW Web
Ajax Problem Statement: Deutlich mehr Schnittstellen zum Applikationsserver über die Daten ausgetauscht werden Vermischung von client- und serverseitiger Entwicklung Erhöhte Komplexität ;-) Einfaches Einbinden von Plugins möglich Einbinden von nicht-vertrauenswürdigem Code Falsche Sicherheit über serverseitige Validierung von Eingaben ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de 6/23/2010 53
XML Injection Ajax Daten werden in XML Form übertragen Neue Möglichkeit für Injection Angriffe Direkte Injezierung von JavaScript ist nicht mehr nötig Falls beispielsweise <script> Tags gefiltert werden Es können XML Elemente injiziert werden, die dann von der Clientanwendung ausgeführt werden. ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de 6/23/2010 54
XML Injection Beispiel Username = foo< Resultierendes XML <user> <username>foo<</username> <password>geheim</password> <userid>500</userid> <mail>user@invalid.com</mail> </user> ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de 6/23/2010 55
Summary ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de 6/23/2010 56
Danke für die Aufmerksamkeit! ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de 18.06.2009 57
Fragen? ERNW GmbH. Breslauer Str. 28. D-69124 Heidelberg. www.ernw.de 18.06.2009 58