Web Application Security Wir sind bestens vor Angriffen gesichert, wir haben eine Firewall!

Transkript

1 Web Application Security Wir sind bestens vor Angriffen gesichert, wir haben eine Firewall! IT-SeCX Version: 1.0 Autor: A. Kravitz / K. Bauer Verantwortlich: A. Kravitz Datum: Vertraulichkeitsstufe: Öffentlich

2 SEC Consult Advisor for your information security (1) Berater für Information Security Experte für die Einführung von Sicherheitsprozessen und Policies (ISO 27001, BS 25999, GSHB) Führend bei technischen Sicherheits-Audits und bei der Umsetzung Spezialist für Applikations- und Webapplikationssicherheit auf Basis A 7700 Unabhängigkeit von Produktherstellern Behörden, Banken, Versicherungen, börsennotierte Unternehmen in Zentraleuropa als Kunden Branchenspezifische Ausrichtung (Defense, Public, Finance, Industry) 2

3 SEC Consult Advisor for your information security (2) Gegründet 2002 Zentrale in Wien Niederlassungen in Wiener Neustadt (Österreich), Frankfurt (Deutschland) und Montreal (Kanada) Fokus auf Zentraleuropa Eigenes SEC Consult Vulnerability Lab Partner: Secure Systems 3

4 SEC Consult Advisor for your information security (3) is certified according to ISO

5 über die Vortragenden Avi Kravitz Security Consultant, Trainer Methodical Competences: Penetration Testing, ÖNORM A 7700, ISO/IEC 27001:2005, BSI Grundschutz, Risk Management Konstantin Bauer (k.bauer@sec-consult.com) Security Consultant, Trainer Methodical Competences: Penetration Testing, Akkreditierter ÖNORM A 7700 Auditor, OWASP, OSSTMM, Source Code Audits 5

6 Die Top-5 Mythen über die Sicherheit von Webauftritten Unser Webauftritt ist sicher, weil... Wir 128 Bit SSL Verschlüsselung verwenden 6

7 Die Top-5 Mythen über die Sicherheit von Webauftritten Unser Webauftritt ist sicher, weil... Wir 128 Bit SSL Verschlüsselung verwenden SSL macht nur die Verbindung zwischen Client und Server abhörsicher. 7

8 Die Top-5 Mythen über die Sicherheit von Webauftritten Unser Webauftritt ist sicher, weil... Wir 128 Bit SSL Verschlüsselung verwenden SSL macht nur die Verbindung zwischen Client und Server abhörsicher. Unsere Firewall schützt unsere Webserver 8

9 Die Top-5 Mythen über die Sicherheit von Webauftritten Unser Webauftritt ist sicher, weil... Wir 128 Bit SSL Verschlüsselung verwenden SSL macht nur die Verbindung zwischen Client und Server abhörsicher. Unsere Firewall schützt unsere Webserver Nur dann, wenn sie den Zugriff auf ebendiesen nicht zulässt. 9

10 Die Top-5 Mythen über die Sicherheit von Webauftritten Unser Webauftritt ist sicher, weil... Wir 128 Bit SSL Verschlüsselung verwenden SSL macht nur die Verbindung zwischen Client und Server abhörsicher. Unsere Firewall schützt unsere Webserver Nur dann, wenn sie den Zugriff auf ebendiesen nicht zulässt. Unser ISS/Eeye/Nessus Scanner zeigt keine Fehler am Webserver 10

11 Die Top-5 Mythen über die Sicherheit von Webauftritten Unser Webauftritt ist sicher, weil... Wir 128 Bit SSL Verschlüsselung verwenden SSL macht nur die Verbindung zwischen Client und Server abhörsicher. Unsere Firewall schützt unsere Webserver Nur dann, wenn sie den Zugriff auf ebendiesen nicht zulässt. Unser ISS/Eeye/Nessus Scanner zeigt keine Fehler am Webserver Derartige Scanner finden NUR bekannte Fehler in bekannten Services. 11

12 Die Top-5 Mythen über die Sicherheit von Webauftritten Unser Webauftritt ist sicher, weil... Wir 128 Bit SSL Verschlüsselung verwenden SSL macht nur die Verbindung zwischen Client und Server abhörsicher. Unsere Firewall schützt unsere Webserver Nur dann, wenn sie den Zugriff auf ebendiesen nicht zulässt. Unser ISS/Eeye/Nessus Scanner zeigt keine Fehler am Webserver Derartige Scanner finden NUR bekannte Fehler in bekannten Services. Unser IDS jeden Einbruchsversuch sofort aufzeigt und im Keim erstickt 12

13 Die Top-5 Mythen über die Sicherheit von Webauftritten Unser Webauftritt ist sicher, weil... Wir 128 Bit SSL Verschlüsselung verwenden SSL macht nur die Verbindung zwischen Client und Server abhörsicher. Unsere Firewall schützt unsere Webserver Nur dann, wenn sie den Zugriff auf ebendiesen nicht zulässt. Unser ISS/Eeye/Nessus Scanner zeigt keine Fehler am Webserver Derartige Scanner finden NUR bekannte Fehler in bekannten Services. Unser IDS jeden Einbruchsversuch sofort aufzeigt und im Keim erstickt Ein IDS kennt leider auch nur bekannte Fehler in bekannten Service 13

14 Die Top-5 Mythen über die Sicherheit von Webauftritten Unser Webauftritt ist sicher, weil... Wir 128 Bit SSL Verschlüsselung verwenden SSL macht nur die Verbindung zwischen Client und Server abhörsicher. Unsere Firewall schützt unsere Webserver Nur dann, wenn sie den Zugriff auf ebendiesen nicht zulässt. Unser ISS/Eeye/Nessus Scanner zeigt keine Fehler am Webserver Derartige Scanner finden NUR bekannte Fehler in bekannten Services. Unser IDS jeden Einbruchsversuch sofort aufzeigt und im Keim erstickt Ein IDS kennt leider auch nur bekannte Fehler in bekannten Service Unsere neue Web Application Firewall blockt alle Angriffe 14

15 Die Top-5 Mythen über die Sicherheit von Webauftritten Unser Webauftritt ist sicher, weil... Wir 128 Bit SSL Verschlüsselung verwenden SSL macht nur die Verbindung zwischen Client und Server abhörsicher. Unsere Firewall schützt unsere Webserver Nur dann, wenn sie den Zugriff auf ebendiesen nicht zulässt. Unser ISS/Eeye/Nessus Scanner zeigt keine Fehler am Webserver Derartige Scanner finden NUR bekannte Fehler in bekannten Services. Unser IDS jeden Einbruchsversuch sofort aufzeigt und im Keim erstickt Ein IDS kennt leider auch nur bekannte Fehler in bekannten Service Unsere neue Web Application Firewall blockt alle Angriffe Eine Web Application Firewall korrekt zu konfigurieren ist mind. genauso aufwändig (oft sogar aufwändiger!) wie die Applikation initial sicher zu programmieren. 15

16 Typische Konfiguration eines sicheren Websystems 16

17 Webapplikation das schwächste Glied Attacker Internet Webserver with vulnerable web application DB AD File- Share Public (External) DMZ LAN (Internal) 17

18 Warum (Web-)Application Security? Analyse von Webseiten verifizierte Schwachstellen 64% der getesteten Webseiten haben derzeit mindestens eine Schwachstelle, deren Risiko als Hoch oder Kritisch eingestuft wird. Quelle: WhiteHat Security, % aller Cyberattacken finden heute auf Applikationsebene statt (Gartner, 2009) Anzahl der Website Defacements Q1/2010 Prognose 2010 Quelle: zone-h.org 18

19 WhiteHat Security Top 10 Vulnerabilites Quelle: WhiteHat Security,

20 WhiteHat Security Top 10 Vulnerabilites Quelle: WhiteHat Security,

21 Aufbau des Tests von Webapplikationen Vorbereitung Security Audit Information Gathering Identifizieren & Ausnutzung der Schwachstellen Technische Risikoeinschätzung Lösungsvorschläge Phase 1: Vorbereitung des Security Audits Festlegung des Audit-Ansatz (Blackbox, Glassbox oder Sourcode review) Permission to Attack Phase 2: Sammeln von Informationen Es wird versucht, so viele Informationen wie möglich über die Anwendung herauszufinden Phase 3: Identifizieren & Ausnutzen der Schwachstellen Für jede gefundene Schwachstelle wird ein Proof-of-Concept Exploit durchgeführt und versucht, so weit wie möglich ins System einzudringen Phase 4 & 5: Risiko-Einschätzung und Lösungsvorschläge Für jede Schwachstelle wird ein individueller Risk-Score vergeben und Vorschläge erläutert, wie die Probleme behoben werden können 21

22 22

23 23

24 Cross Site Scripting (XSS) Clientseitige Skripte (z.b. JavaScript) werden mit Hilfe von Fehlern in Webapplikationen in den Webbrowser potentieller Opfer geschleust Entsteht durch: Unzureichende Eingabe/Ausgabe Validierung Und fehlende HTML - Codierung von Ausgabedaten z.b. < < > > ' Unterscheidung in Permanent Non-Permanent / Reflected 24

25 Cross Site Scripting (XSS) manuelle Suche/Verifizierung 25

29 Cross Site Scripting (XSS) - Auswirkungen Angreifer kann mittels XSS: Zugangsdaten stehlen Session Hijacking Relogin-Trojaner Browser vom Opfer fernsteuern (XSS Trojaner) Malware über Drive-by Downloads (z.b. mpack) 29

30 Cross Site Scripting (XSS) Wer ist davon betroffen? Auf xssed.org bereits ~ XSS Schwachstellen dokumentiert! Darunter sind unter anderem folgende Domains betroffen: Google.com Yahoo.com Youtube.com Facebook.com Twitter.com ebay.com Barackobama.com imdb.com cia.gov adobe.com parlament.gv.at help.gv.at justiz.gv.at orf.at bankofamerica.com thepiratebay.org nasa.gov 30

31 Funktionsweise eines XSS Trojaner Abholen von XSS- Trojaner-Script und Befehlen (periodisch, asynchron) Senden Infektion Server sendet von mit XSS beliebigen Trojaner Befehle Befehlen Kommunikation wird vom XSS Trojaner abgefangen und manipuliert Anfrage an Server Aufruf von XSS-modifizierter Seite Script SRC=attacker.com Antwort des Servers Example.com 31

32 Live Hack Rechtliche Situation für Live Hacks ist klar: Sie sind verboten SEC Consult arbeitet auf einer selbst entwickelten Webapplikation Läuft lokal auf diesem Laptop Enthält die häufigsten Sicherheitslücken Die gezeigten Sicherheitslücken sind in wirklichen Anwendungen sehr weit verbreitet 32

33 Live Hack Cross Site Scripting Web Site Defacement Cookie Theft XSS Trojaner 33

34 Live Hack Netzplan 34

35 Schutz vor Cross Site Scripting Alle Benutzer-Ein- und Ausgaben müssen einer strikten Ein- und Ausgabeüberprüfung unterzogen werden. Whitelist-Methoden sind Blacklist-Methoden unbedingt vorzuziehen. Zusätzlich müssen spezielle Zeichen wie [;()" `,<>/\] in der Benutzerausgabe durch ihre HTML Äquivalente (", ', <, >,...) ersetzt werden. 35

36 Cross Site Scripting (XSS) Warum Codierung der Ausgabe? Woher kommen die zu verarbeitenden Informationen? 36

37 Web Application Firewalls? Bisherige Ansätze von WAFs beschränken sich auf 2 Methoden Blacklisting - Ich erlaube alles, außer + weit verbreitet + generische Blacklists vorhanden (mod_security Core Rules, PHP-IDS, ) - Absolut kein Schutz vor 0-Day Angriffen/Exploits - aufwändige Konfiguration wenn generische Blacklists false Positives liefern - Moderne Datenaustausch-Formate (XML, JSON, ) werden nur ungenügend unterstützt - Umgehen der Regeln oft mit einfachen Mitteln möglich - Oft nur einige Leerzeichen/Zeilenumbrüche ausreichend - Codierung des Inputs in Hex oder Unicode - Split String - 1: ping.php?ip= ; cat /etc/passwd 2: ping.php?ip= ; a=etc; cat /$a/passwd 37

38 Web Application Firewalls? Bisherige Ansätze von WAFs beschränken sich auf 2 Methoden Whitelisting - Ich erlaube nichts, außer + Schutz vor 0-Day Angriffen/Exploits + wenige/keine False Positives, da explizit konfiguriert wird was erlaubt ist - Konfiguration sehr aufwändig Die Applikation bereits Initial sicher zu programmieren ist meist mit weniger Aufwand verbunden 38

39 Web Application Firewalls? Anomaliebasierende WAFs Herausforderungen False Positives durch unvollständige Learning Phase und aufgrund fehlender KI Unterbinden von Attacken in der Learning Phase Applikation ist im Internet aber permanentem Angriff ausgesetzt Lösungsansätze isolierte Umgebung in der Learning Phase viele Tester Einsatz von Webroboter nur wie lange bleibt eine Webapplikation nach der Learning Phase unverändert? (Stichwort: Web 2.0) 39

40 SQL Injection SQL Injection birgt viele Gefahren: Ein Angreifer kann beliebige Daten aus der Datenbank lesen (z.b. Benutzernamen/Passwörter, Kreditkarteninformationen, etc.) Viele Datenbanken bieten Funktionen um Kommandos auszuführen (z.b. MS SQL Server: xp_cmdshell) Läuft die Datenbank am gleichen Server wie der Webserver, kann ein Angreifer mit hoher Wahrscheinlichkeit auch das Webservice komplett kompromittieren Ein einfaches Anführungszeichen in einem Parameter löst einen Datenbankfehler aus SQL Injection ist wahrscheinlich möglich Datenbankfehler rührt daher, dass das Anführungszeichen in das SQL Statement übernommen wird und dadurch eine ungültige Abfrage durchgeführt wird Nun kann der Angreifer versuchen, das SQL Statement so zu manipulieren, dass es andere Daten ausgibt 40

41 SQL Injection II Benutzerinput wird direkt in ein SQL Query übernommen Ausbrechen aus der Syntax und Einbringen von eigenen Queries Mittels spezieller Eingaben können weitere Abfragen in das Query eingebunden werden: union SELECT 1,2,3,4 Demonstration: Verschiedene Angriffe auf den Datenbankserver Können Dateien erzeugt werden, ist komplette Übernahme des Systems wahrscheinlich Demonstration: Erzeugen einer so genannten One-way-command-shell 41

42 Live Hack SQL Injection Login Bypass Umgehen von fehlerhaft implementierter Authentifizierung Sprechende SQL Injection Bequemes Auslesen von Datenbankinhalten Auslesen von Dateiinhalten Erzeugen von Dateien am Server Übernahme des Webservers Blind SQL Injection Bitweises Auslesen von Datenbankinhalten, Dateien, etc. 42

43 Schutz vor SQL Injections Verwendung von Prepared Statements oder parametrisierten Queries Falls durch die Programmiersprache unterstützt Verhindert SQL-Injection, wenn korrekt implementiert Escaping von Metazeichen $name="' OR '1'='1" $query = "SELECT * FROM customers WHERE username= '".mysql_escape($name)."'"; SELECT * FROM customers WHERE username = '\' OR \'1\'=\'1' Quoten von jeglichem Benutzerinput Auch number-typen $query = "SELECT * FROM customers WHERE id= '".mysql_escape($id)."'"; Whitelist-Filter von Benutzerinput 43

44 VIELEN DANK! Hoffentlich besteht Ihre Information Security nicht nur aus einer Firewall! 44

45 Wie erreichen Sie SEC Consult? SEC Consult Unternehmensberatung GmbH Österreich Mooslackengasse 17 A-1190 Vienna Austria Tel: +43-(0) Fax: +43-(0) Deutschland Bockenheimer Landstrasse D Frankfurt am Main Germany Tel: Fax: