Security Scanner dienen der automatisierten Identifikation von Schwachstellen in Systemen mit verschiedenen Analysemethoden wie Scanning und Exploiting. Das Design umfasst modulare Test-Plugins, eine Datenbank für die Verwaltung von Schwachstellen und Reporting-Mechanismen zur Analyse der Ergebnisse. Die Architektur sollte flexibel sein, um in komplexe Netzwerke integriert zu werden und eine effektive Nutzung zu gewährleisten.

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

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

3. Einführung I: Vorstellung „ Die Kunst des Penetration Testing“ (2007), Computer & Literatur Böblingen, ISBN 3-936546-49-5 Letztes Buch http://www.computec.ch Private Webseite CTO, scip AG, Zürich Beruf Marc Ruef Name Übersetzung

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. 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 Quelle: http://www.scip.ch/?labs.20091106

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