Security Scanner Design am Beispiel von httprecon

1. Security Scanner Designam Beispiel von httprecon Marc Ruef www.scip.ch

2. Agenda  Security Scanner Design • Einführung • Analysetechniken • Test-Module • Architektur • Reporting • Zusammenfassung

3. Übersetzung Einführung I: Vorstellung

4. Einführung II: Präsentation • Grundlegende Funktionsweise von Security Scanner • Ideale Umsetzung einer entsprechenden Lösung • Konkreter Vergleich zum httprecon project mit seinen Vor- und Nachteilen

5. Quelle: http://www.scip.ch/?labs.20091106 Einführung III: Security Scanner • Ein Security Scanner wird eingesetzt, um automatisiert, semi-automatisiert oder begleitet die Sicherheit einer Komponente zu ermitteln. • Im weitesten Sinn gehören dazu Lösungen wie: • Portscanner • Auswertungs-Utilities • Vulnerability Scanner • Exploiting Frameworks

6. Analysetechniken I - Ableitung • Beschreibung • Anhand einer allgemein identifizierten Gegebenheit wird die potentielle Existenz einer Schwachstelle abgeleitet. • HTTP-Fingerprint Apache <2.0.51 mod_dav LOCK Denial of Service • OS-Fingerprint Windows 95 Out of Band Denial of Service • Problem • Schwachstellen werden nur erahnt und nicht verifiziert. False-Positives sind genauso möglich wie False-Negatives.

7. Analysetechniken II - Scanning • Beschreibung • Anhand einer gezielt identifizierten Eigenschaft/Objekt wird die potentielle oder effektive Existenz einer Schwachstelle ermittelt. • Webserver bietet /FormMail.pl an Redirect Parameter Cross Site Scripting • Server benutzt ausschliesslich SSLv2 Kryptografisch unsichere Verbindung • Problem • Zugriffe müssen dediziert umgesetzt werden. • Die Qualität der Resultate ist massgeblich von der Intelligenz dieser abhängig.

8. Analysetechniken III - Exploiting • Beschreibung • Anhand einer gezielt ausgenutzten Sicherheitslücke wird die existente Schwachstelle ermittelt. • Microsoft IIS 6.0 Authentisierung umgehen WebDAV Remote Authentication Bypass • Citrix XenCenterWeb inkludiert Script-Code console.php Cross Site Scripting • Problem • Intrusive Tests können Manipulationen erzwingen und Schäden anrichten. • Stetige Entwicklung verlässlicher Exploits ist sehr aufwendig.

9. Test-Module I: Datenbank • Sämtliche Beschreibungen zu Tests und Schwachstellen werden in einer Datenbank dokumentiert. • Titel der Schwachstelle • Beschreibung des Problems • Einstufung des Risikos • Vorgehen zur Ausnutzung/Verifikation • Liste mir Gegenmassnahmen • Quellenangaben und Links • Manche Lösungen verwenden eine relationale Datenbank, andere pflegen Dateien zu nutzen.

10. Test-Module I: Datenbank (httprecon fdb Datei)

11. Test-Module I: Datenbank (Nessus NASL Datei)

12. Test-Module I: Datenbank (scip PenTest DB)

13. Test-Module II: Plugins • Die einzelnen Tests werden modular mit dedizierten Plugins realisiert. • Das Ausführen von Plugins ist zeitintensiv. Durch Abhängigkeiten sollten sie bestmöglich nur dann ausgeführt werden, wenn es „Sinn“ macht. • Tests sollten in Plugin-Familien gruppiert werden (z.B. Webserver, Mailserver, SNMP, Windows, …) • Plugins sollten quelloffen und/oder gut dokumentiert sein, um das Vorgehen nachvollziehen, adaptieren oder querprüfen zu können.

14. Test-Module III: Test-Sprache • Für das Umsetzen der Tests/Plugins muss eine simple Sprache genutzt werden. • Die Sprache sollte klare Schnittstellen für immer wiederkehrende Funktionen haben (z.B. Tests offener Ports, HTTP-Zugriffe, etc.) • Die Sprache sollte das Einbinden externer Skripte erlauben (z.B. Exploits).

15. Test-Module III: Test-Sprache (ATK/ASL)

16. Test-Module III: Test-Sprache (Nessus/NASL)

17. Architektur I - Standalone • Beschreibung • Simple Scanning-Lösungen agieren standalone. • Problem • Direktzugriffe auf Systeme/Dienste sind in topologisch komplexen Umgebungen (Routing/Firewalling) nicht ohne weiteres Möglich.

18. Architektur II - Multi-Tier • Beschreibung • Erweiterte Scanning-Lösungen für das professionelle Umfeld bieten eine Multi-Tier Architektur an. • Problem • Die Installation, Wartung und Nutzung wird mit jeder zusätzlichen Komponente erschwert.

19. Reporting • Mit dem Reporting steht und fällt die konkrete Nützlichkeit einer Analyse. • Reports müssen modular, detailliert und dennoch übersichtlich sein. • Verschiedene Darstellungsformen machen eine gute Lösung aus: • Listen und Tabellen zur Übersicht • Statistiken und Diagramme zwecks Analysen • Prosatext für umfassenden Einblick • Bildschirmausgaben mit technischen Details • Report-Dokumente sollten sich in verschiedenen Formaten generieren lassen (PDF, XML, CSV, …)

20. Reporting

21. Reporting (Qualys)

22. Zusammenfassung • Security Scanner helfen beim Finden von Schwachstellen. • Verschiedene Auswertungsmechanismen garantieren unterschiedliche Zuverlässigkeit. • Eine pluginbasierte Architektur erleichtert eine modulare Erweiterung von Tests. • Architektonische Eigenschaften helfen dem Einbinden im Unternehmensnetzwerk. • Das Reporting stellt den zentralen Übergangspunkt zur weiteren Absicherung dar.

23. Fragen? • „Man hört nur die Fragen, auf welche man imstande ist, eine Antwort zu geben.“– Friedrich Nietzsche • Kontaktieren Sie mich am besten per Email: maru@scip.ch