1. Hacking Day 2011
Application Security Audit
in Theorie und Praxis
Jan Alsenz & Robert Schneider
© 2011 OneConsult GmbH 16. Juni 2011
www.oneconsult.com

2. Agenda
→ Vorstellung
→ Application Security Audit
→ Optimaler Zeitpunkt
→ Testansatz
→ Schlussbericht
→ Live Demo
→ Fragen
© 2011 OneConsult GmbH 2
www.oneconsult.com

3. Vorstellung
© 2011 OneConsult GmbH 3
www.oneconsult.com

4. Referenten
Jan Alsenz
MSc ETH CS, OPST & OPSA
Team Leader Security Audits
jan.alsenz@oneconsult.com
+41 79 377 15 15
Robert Schneider
BSc FH CS, OPST
Security Consultant
robert.schneider@oneconsult.com
+41 79 269 29 29
© 2011 OneConsult GmbH 4
www.oneconsult.com

5. Unternehmen
→ OneConsult GmbH
◦ Gründung 2003
◦ IT Security Consulting & strategische Beratung
◦ Kein Verkauf von Hard- und Software
◦ 11 Mitarbeitende, wovon 9 Consultants
◦ Christoph Baumgartner, CEO & Inhaber
◦ Jan Alsenz, Teamleiter Security Audits & Teilhaber
◦ Dr. Cathrin Senn, Senior Consultant & Teilhaberin
→ Standorte
◦ Schweiz: Hauptsitz in Thalwil
◦ Österreich: Niederlassung in Wien
© 2011 OneConsult GmbH 5
www.oneconsult.com

6. Dienstleistungen
→ Security Audits → Incident Response
◦ Security Scan ◦ Emergency Response
◦ Penetration Test ◦ Computer Forensics
◦ Application Security Audit
◦ Ethical Hacking → Training & Coaching
◦ Conceptual Security Audit ◦ OSSTMM Zertifizierungskurse
◦ Security Awareness Training
→ Consulting ◦ Coaching
◦ Strategy & Organisation
◦ Policies & Guidelines → Security as a Service
◦ Processes & Documentation
◦ Business Continuity & Disaster Recovery
◦ Engineering & Project Management
© 2011 OneConsult GmbH 6
www.oneconsult.com

7. Application Security Audit
© 2011 OneConsult GmbH 7
www.oneconsult.com

8. Definition
Gründliche, technische, unprivilegierte und privilegierte
Sicherheitsüberprüfung einer Applikation und der zugehörigen
Systeme aus der Perspektive eines Angreifers mit Skill Level
«Hacker / Cracker».
© 2011 OneConsult GmbH 8
www.oneconsult.com

9. Berücksichtigt beispielsweise
→ Architektur → Compliance
→ Infrastruktur → Verantwortlichkeiten
◦ Vertrauensstellungen → User Management
◦ Authentisierungs-
→ Dokumentationspflege
mechanismen
→ Umgang mit Source Code
→ Implementation
→ Patching-Prozess
→ Source Code
© 2011 OneConsult GmbH 9
www.oneconsult.com

10. Stichwörter
→ Applikationen → Ansätze
◦ Online-Shops ◦ Client und Server
◦ Interbanking-Portale ◦ Dediziert vs. virtualisiert
(Cloud)
◦ Mailserver ◦ Mobile Client
◦ Datenbanken ◦ Web Application vs. Web
◦ Branchenlösungen Service
◦ Mobile Apps ◦ Etc.
◦ Etc.
→ Environment
◦ Betriebssystem
◦ Programmiersprache
◦ Framework
◦ Etc.
© 2011 OneConsult GmbH 10
www.oneconsult.com

11. Zweck und Nutzen
→ Qualitätssicherung dank (unabhängiger) IT Security-Analyse
→ Compliance: Nachweis bezüglich gesetzlicher
Rahmenbedingungen und Vorgaben
→ Prävention: Ermöglicht (in der Zukunft) direkte und indirekte
Kosteneinsparungen
© 2011 OneConsult GmbH 11
www.oneconsult.com

12. Zweck und Nutzen
→ Awareness auf allen Stufen
→ Know-how Transfer
→ Argumentationsgrundlage für zukünftige
◦ IT Security-Investitionen
◦ Aktivitäten
© 2011 OneConsult GmbH 12
www.oneconsult.com

13. Knackpunkte
→ Fach- und Sozialkompetenz der Tester und der am Projekt
beteiligten Mitarbeiter
→ Vergleichbarkeit und Nachvollziehbarkeit von
◦ Offerten
◦ Vorgehen
◦ Resultaten und Dokumentationen
→ Compliance zu Gesetzen, Standards und Vorgaben erwünscht,
aber:
◦ Nur rudimentäre Behandlung von technischen Audits in Standards
(z.B. ISO/IEC 2700x)
◦ Keine offiziellen Checklisten oder Guidelines verfügbar
© 2011 OneConsult GmbH 13
www.oneconsult.com

14. Optimaler Zeitpunkt
© 2011 OneConsult GmbH 14
www.oneconsult.com

15. Typische Szenarien
→ Neuentwicklung
→ Neuer Release
→ Bestehende Lösung
© 2011 OneConsult GmbH 15
www.oneconsult.com

16. Typische Zeitpunkte
© 2011 OneConsult GmbH 16
www.oneconsult.com

17. Typische Zeitpunkte
→ Frühe Entwicklung: Eher Konzept-Review
© 2011 OneConsult GmbH 17
www.oneconsult.com

18. Typische Zeitpunkte
→ Frühe Entwicklung: Eher Konzept-Review
→ In der Entwicklung: Eher Code-Review
© 2011 OneConsult GmbH 18
www.oneconsult.com

19. Typische Zeitpunkte
→ Frühe Entwicklung: Eher Konzept-Review
→ In der Entwicklung: Eher Code-Review
→ Gegen Ende der Entwicklung:
◦ Häufig noch nicht alles fertig oder nicht funktionierend (-)
◦ Nicht finales Umfeld (-)
© 2011 OneConsult GmbH 19
www.oneconsult.com

20. Typische Zeitpunkte
→ Frühe Entwicklung: Eher Konzept-Review
→ In der Entwicklung: Eher Code-Review
→ Gegen Ende der Entwicklung:
◦ Häufig noch nicht alles fertig oder nicht funktionierend (-)
◦ Nicht finales Umfeld (-)
→ In der Test-Phase:
◦ Nicht finales Umfeld (-)
◦ Teilweise noch nicht alles fertig / komplett funktionierend (-)
© 2011 OneConsult GmbH 20
www.oneconsult.com

21. Typische Zeitpunkte
→ In Produktiv-Umgebung vor Go-Live: optimal
◦ Funktion komplett (+)
◦ In Zielumgebung (+)
◦ Noch nicht produktiv (+)
◦ Meistens dedizierte Testingzeit nötig (-)
© 2011 OneConsult GmbH 21
www.oneconsult.com

22. Typische Zeitpunkte
→ In Produktiv-Umgebung vor Go-Live: optimal
◦ Funktion komplett (+)
◦ In Zielumgebung (+)
◦ Noch nicht produktiv (+)
◦ Meistens dedizierte Testingzeit nötig (-)
→ Live:
◦ Funktion komplett (+)
◦ In Zielumgebung (+)
◦ Produktiv (evtl. Ausfälle) (-)
© 2011 OneConsult GmbH 22
www.oneconsult.com

23. Testansatz
© 2011 OneConsult GmbH 23
www.oneconsult.com

24. Typische Phasen
→ Offerte
→ Kick-off
→ Audit
→ Report (Diskussion/Präsentation)
© 2011 OneConsult GmbH 24
www.oneconsult.com

25. Typische Stolpersteine
→ Offerte
◦ Kein Geld/Budget eingeplant
◦ Offerte zu früh: genauer Scope noch nicht bekannt
◦ Offerte zu spät: zu wenig Zeit vor Go-Live
→ Kick-off
◦ Parteien kommunizieren auf unterschiedlichen Ebenen
◦ Zu viele/falsche Personen sind anwesend
◦ Änderung des Scopes
→ Audit
◦ Verschiebungen
◦ Applikation/Umgebung noch nicht fertig
◦ Kundenseitige Vorbereitungen nicht abgeschlossen
© 2011 OneConsult GmbH 25
www.oneconsult.com

26. OneConsult Testansatz
Mischung aus zwei bekannten und verbreiteten Methoden
→ OSSTMM
→ OWASP
© 2011 OneConsult GmbH 26
www.oneconsult.com

27. OSSTMM
→ Open Source Security Testing Methodology Manual
→ Entwicklung unter der Leitung von ISECOM,
Institute for SECurity and Open Methodologies,
http://www.osstmm.org
→ Erstausgabe 2001, aktueller offizieller Release OSSTMM 3.0
→ Offene und frei verfügbare Methode zur
◦ Planung
◦ Durchführung
◦ Grobdokumentation
von (technischen) Security Audits
© 2011 OneConsult GmbH 27
www.oneconsult.com

28. OSSTMM
→ Sicherheitsniveau als neutraler Zahlenwert (Risk Assessment Value)
→ Umfassender Verhaltenskodex (Rules of Engagement)
→ Compliant zu ISO/IEC 17799/27001, ITIL, BSI-Standard-100-1/4, SOX, Basel
II etc.
→ Optionale Zertifizierung (Projekte, Personen und Organisationen) durch
ISECOM
→ OneConsult
◦ ISECOM Licensed Auditor (Platinum Level)
◦ ISECOM Partner (akkreditierter Schulungsanbieter)
◦ Aktive Mitarbeit am OSSTMM: 3 Mitarbeiter im ISECOM Core Team
◦ Mehr als 300 Projekte nach OSSTMM seit 2003
© 2011 OneConsult GmbH 28
www.oneconsult.com

29. Open Web Application Security Project (OWASP)
Idee
→ Unternehmen können mit Hilfe von OWASP-Bordmitteln
Applikationen
◦ Entwickeln
◦ Beschaffen und
◦ Pflegen
Ziel
→ Mehr Sicherheit in Applikationen
© 2011 OneConsult GmbH 29
www.oneconsult.com

30. Open Web Application Security Project (OWASP)
Gratis und offen für jeden, der den Sicherheitsaspekt von
Applikationen verbessern möchte.
→ OWASP Top 10
→ Tools
→ Dokumente
→ Foren
→ Teilnahme an Meetings der Ortsverbände
http://www.owasp.org
© 2011 OneConsult GmbH 30
www.oneconsult.com

31. Generischer Ablauf Application Security Audit
© 2011 OneConsult GmbH 31
www.oneconsult.com

32. Schlussbericht
© 2011 OneConsult GmbH 32
www.oneconsult.com

33. Schlussbericht
Die Dokumentation sollte mindestens die folgenden Punkte
beinhalten:
→ Kurze und prägnante Zusammenfassung (Management
Summary)
→ Liste mit den detektierten Risiken (inkl. Kategorisierung)
→ Massnahmen und Empfehlungen (inkl. Priorisierung)
© 2011 OneConsult GmbH 33
www.oneconsult.com

34. Live Demo
© 2011 OneConsult GmbH 34
www.oneconsult.com

35. Live Demo
Live-Vorstellung der Beispiel-Applikation
Credits
→ Für die Live Demo wird Hacme Bank v2.0 von McAfee
(Foundstone) verwendet.
http://www.mcafee.com/
© 2011 OneConsult GmbH 35
www.oneconsult.com

36. Typische Schwachstellen
→ Typische Schwachstellen-Liste:
◦ Injection
◦ Cross Site Scripting (XSS)
◦ Broken Authentication and Session Management
◦ Insecure Direct Object References
◦ Cross Site Request Forgery (CSRF)
◦ Security Misconfiguration
◦ Insecure Cryptographic Storage
◦ Failure to Restrict URL Access
◦ Insufficient Transport Layer Protection
◦ Unvalidated Redirects und Forwards
© 2011 OneConsult GmbH 36
www.oneconsult.com

37. SQL Injection
→ Bedeutung
◦ Applikation wird so angesprochen, dass diese (vom Betreiber nicht
gewünschte) Kommandos an die Datenbank weiterleitet.
→ Datenbank
◦ Führt die eingeschleusten Kommandos aus
→ Impact
◦ Auslesen und unter Umständen Modifikation der gesamten Datenbank
◦ Voller Datenbank-Schema-, Account- oder sogar OS-Level-Zugriff
© 2011 OneConsult GmbH 37
www.oneconsult.com

38. SQL Injection
Inputfeld
1 $id = $_GET['id'];
$querry = "SELECT name FROM users WHERE id = '$id'";
2
Webserver
© 2011 OneConsult GmbH 38
www.oneconsult.com

39. SQL Injection: Abhilfe
→ Verwendung einer Schnittstelle welche Bind-Variablen
unterstützt (Prepared Statements, Stored Procedures)
→ Encoding der Benutzereingaben vor Übergabe an Datenbank
→ Inputvalidation anhand einer „White List“
→ Minimalberechtigungen für Datenbankuser
© 2011 OneConsult GmbH 39
www.oneconsult.com

40. Cross Site Scripting (XSS)
→ Bedeutung
◦ Rohdaten eines Angreifers werden an den Browser eines Users gesendet
→ Rohdaten
◦ In Datenbank abgespeichert: Stored XSS
◦ Von Web-Input reflektiert: Reflected XSS
› Formularfeld, verstecktes Feld, URL, etc.
→ Impact
◦ Stehlen von
› Aktiven Benutzer-Sessions
› Sensitiven Daten
› Benutzer-Zugangsdaten (Phishing)
◦ Umschreiben der Webseite (Defacement)
◦ Installation eines XSS-Proxys
› Monitoring und Steuerung des Benutzerverhaltens
› Umleiten auf andere Seiten
© 2011 OneConsult GmbH 40
www.oneconsult.com

41. Cross Site Scripting (XSS)
1
<script>
// Stehlen der aktiven
2 // Benutzer-Sessions
</script>
3
Webserver
Angreifer
Opfer 4
<script>
// Stehlen der aktiven
// Benutzersessions
</script>
© 2011 OneConsult GmbH 41
www.oneconsult.com

42. Cross Site Scripting (XSS): Abhilfe
→ Unterbinden der Schwachstelle
◦ Keine vom Benutzer gelieferten Eingaben in Seiten einbinden
→ Schutzmassnahmen
◦ Output Encoding
› Benutzereingaben werden vor der Ausgabe encodiert
◦ Inputvalidation
› Benutzereingaben werden mittels „White List“-Ansatz validiert
© 2011 OneConsult GmbH 42
www.oneconsult.com

43. Session-Handling
→ Bedeutung
◦ Session-IDs ermöglichen es aus dem ansonsten statuslosen HTTP,
statusorientierte Anfragen zu versenden
◦ Session-IDs können oft an den folgenden Stellen ausgelesen werden:
› Netzwerke (WLAN)
› Browser (Cookie)
› Logs
› Etc.
→ Impact
◦ Session Hijacking
› Angreifer gelangt an gültige Session-ID
› Im Kontext des betroffen Benutzers agieren
© 2011 OneConsult GmbH 43
www.oneconsult.com

44. Session-Handling
1
Opfer Session-ID Webserver
2 3 4
Session-ID
Angreifer
© 2011 OneConsult GmbH 44
www.oneconsult.com

45. Session-Handling: Abhilfe
→ Session-IDs sollten immer durch SSL geschützt werden
→ Oder zusätzlich an IP oder Browser-Merkmale gebunden
werden
→ Session-IDs sollten zufällig und nicht vorhersagbar sein
→ Session-ID sollte bei der Anmeldung ausgetauscht werden
→ Zerstören der Session bei der Benutzerabmeldung / Timeout
© 2011 OneConsult GmbH 45
www.oneconsult.com

46. Cross Site Request Forgery (CSRF)
→ Bedeutung
◦ Browser des Opfers führt ungewollt Aktionen auf einer vom Angreifer gewählten
verwundbaren Seite aus.
◦ Funktioniert weil Browser automatisch einen Grossteil der Authentisierungsdaten
an jede abgesendete Anfrage anhängt
› Session-Cookies
› Basic Authentication Header
› IP-Adresse
› Client-seitige SSL Zertifikate
› Windows-Domänen-Authentisierung
→ Impact
◦ Initiieren von Transaktionen
› Überweisungen
› Benutzerlogout
› Etc.
◦ Änderung von Kontendaten
◦ Ausnutzen von XSS
© 2011 OneConsult GmbH 46
www.oneconsult.com

47. Cross Site Request Forgery (CSRF)
2 1
Angreifer Opfer Webserver
3
<script>
// Bank: überweise 500
</script>
© 2011 OneConsult GmbH 47
www.oneconsult.com

48. Cross Site Request Forgery (CSRF): Abhilfe
→ Verwenden eines nicht automatisch übermittelten Tokens für
alle Aktions-Anfragen
◦ Z.B. Hidden Post Parameter
◦ Token sollte kryptografisch stark zufällig sein
XSS Schwachstelle ermöglicht es diese Massnahme zu umgehen.
© 2011 OneConsult GmbH 48
www.oneconsult.com

49. Web Application Firewall (WAF)
→ Volle Unterstützung für HTTP:
◦ Der Zugriff auf einzelne Felder (Feldinhalt, Länge, Anzahlfelder, etc.)
◦ Gesamte Transaktion (beide, Anfrage und Antwort)
→ Kann gewisse Angriffe verhindern
◦ CSRF
◦ Session-Handling
→ Versucht andere Angriffe zu filtern
→ Anti-Evasion-Funktionen
◦ Normalisierung
◦ Kanonisierung
◦ Transformation
© 2011 OneConsult GmbH 49
www.oneconsult.com

50. Web Application Firewall (WAF)
© 2011 OneConsult GmbH 50
www.oneconsult.com

51. Web Application Firewall (WAF)
Eine WAF kann und wird NICHT alle Angriffe erkennen und
verhindern können!
© 2011 OneConsult GmbH 51
www.oneconsult.com

52. Fragen
© 2011 OneConsult GmbH 52
www.oneconsult.com

53. © 2011 OneConsult GmbH
www.oneconsult.com
OneConsult Ansprechpartner
Jan Alsenz Robert Schneider
MSc ETH CS, OPST & OPSA BSc FH CS, OPST
Team Leader Security Audits Security Consultant
jan.alsenz@oneconsult.com robert.schneider@oneconsult.com
+41 79 377 15 15 +41 79 269 29 29
Hauptsitz Büro Österreich
OneConsult GmbH Niederlassung der OneConsult GmbH
Schützenstrasse 1 Twin Tower, Wienerbergstrasse 11/12A
8800 Thalwil 1100 Wien
Schweiz Österreich
Tel +41 43 377 22 22 Tel +43 1 99460 64 69
Fax +41 43 377 22 77 Fax +43 1 99460 50 00
info@oneconsult.com info@oneconsult.at
© 2011 OneConsult GmbH
www.oneconsult.com