Das Pentesting Experten System Marc Ruef | 26.07.2010 Seit meinem Eintritt in den Bereich der Netzwerksicherheit haben mich Vulnerability Scanner zur automatisierten Identifikation von Sicherheitslücken (http://www.scip.ch/?dienstleistungen.auditing) fasziniert. Erste Gehversuche mit einer eigenen Implementierung habe ich im Jahr 2000 mit dem Dante Projekt (http://www.computec.ch/mruef/?s=software) umgesetzt. Der auf modularen Shell-Skripten basierende Security Scanner sollte über eine Weboberfläche bedienbar und deshalb durch jedermann benutzbar sein. Rund vier Jahre später habe ich mit einer konkreten Implementierung für das Attack Tool Kit (ATK) (http://www.computec.ch/projekte/atk/) begonnen. Dieses sollte noch einen Schritt weitergehen und neben dem Identifizieren von Schwachstellen eben jene auch gleich Ausnutzbar machen. Dies geschah in jener Zeit, als das MetaSploit Framework (MSF) (http://www.metasploit.com/) entwickelt und damit der Begriff des Exploiting Frameworks geprägt wurde. Sowohl Dante als auch das ATK sollten mir bei meiner täglichen Arbeit als Penetration Tester helfen können. Sie sollten mich dabei unterstützen, Sicherheitsüberprüfungen automatisiert durchführen zu lassen. Dadurch sollte sich sowohl die Effizienz als auch die Qualität der Tests erhöhen lassen. Dies ist, natürlich unter Miteinbezug vergleichbarer Lösungen wie Nessus (http://www.scip.ch/?labs.20100312) und Qualys (http://www.scip.ch/?labs.20090814), möglich gewesen. Doch nie habe ich mich so richtig wohl mit diesem Flickwerk aus Werkzeugen gefühlt. Ein ursprünglich mit dem Arbeitstitel ATK.NET angefangenes Projekt sollte die Defizite bestehender Produkte, und dazu zählen selbstverständlich auch meine Ansätze, eliminiert werden. Diese Lösung sollte sowohl die Möglichkeiten eines umfangreichen Vulnerability Scanners, als auch eines intelligenten Fuzzing-Tools sowie eines Exploiting-Frameworks bieten. Eine Analyse sollte sich dabei in unterschiedlicher Genauigkeit (diese hat ebenso Auswirkungen auf die Dauer der Ausführung) als auch in unterschiedlichen und stufenlosen Graden an Automatisierung durchführen lassen (von nahezu manuellen Tests bis hin zu komplett automatisierten Scans). Insgesamt 10 Jahre meiner Entwicklungszeit wurde in diese Lösung investiert. Davon über 8 Jahre zusammen mit meinen hervorragenden Arbeitskollegen bei scip AG (http://www.scip.ch). Durch eine hochgradig modulare Lösung sehen wir uns in der Lage, anhand eines Expertensystems unsere hochgesteckten Ziele zu erreichen. Wir vereinen dabei die Möglichkeiten der unterschiedlichen Lösungsansätze, ohne auf Flexibilität verzichten zu müssen. Wir unterscheiden dabei zwischen verschiedenen Engines. Die Scan-Engine ist für das (semi-)automatisierte Zusammentragen der potentiellen und ausgemachten Schwachstellen verantwortlich. Dabei wird in einer ersten Phase versucht, den grundlegenden Aufbau eines überprüften Objekts (Netzwerk, System, Dienst, Applikation oder Daten) zu identifizieren. Anhand verschiedener Mechanismen wird versucht die eingesetzten Technologien und die angewandten Konfigurationseinstellungen auszumachen. Da es sich hierbei um dynamische Module handelt, lassen sich damit auch komplett unbekannte Lösungen und Eigenentwicklungen analysieren. Die durch die Scan-Engine gesammelten und als XML-Dateien bereitgestellten Daten werden durch einen Parser bearbeitet. Im Pre-Parsing wird es möglich, anhand der ermittelten Mechanismen erste statistische Auswertungen vorzutragen. Da das Parsing besonders effizient umgesetzt wird, lässt sich dies in Echtzeit an den Scanning-Prozess knüpfen. Theoretisch kann der Kunde in jedem Augenblick eines Projekts über den aktuellen Stand informiert werden. Das Pre-Parsing erlaubt jedoch ebenfalls eine erste Moderation der Resultate. Damit kann Einfluss auf den iterativen Prozess des Scannins, aber auch auf die Weiterverarbeitung der gesammelten Daten, ausgeübt werden. Zum Beispiel lassen sich On-The-Fly neue Tests generieren, bekannte False-Positives markieren (Flagging) oder weiterführende Validierungen anstreben. Durch das effektive Parsing werden die Daten in eine Datenbank geschrieben. Dort lassen sich erste Planspiele anstreben. Durch statistische Auswertungen können Hochrechnungen für die anstehenden Tests getätigt werden. Oder es lassen sich Delta- sowie Trendanalysen, auf der Basis vorangegangener Sicherheitsüberprüfen des gleichen Kunden oder vergleichbarer Kunden, umsetzen. Werden die Daten in der Datenbank abgelegt, kann eine feste Moderation umgesetzt werden. Dabei erlaubt das System eine durch unterschiedliche Analysten in unabhängiger Weise umgesetzte Moderation. Es können also verschiedene Leute die Einträge kontrollieren, beglaubigen und validieren. Dies müssen nicht zwingend die gleichen Personen sein, die die initialen Scans durchgeführt haben. Damit lässt sich ebenso ein Vieraugenprinzip anwenden, indem potentielle Schwachstellen nur dann als gegeben akzeptiert werden, wenn mindestens zwei Auditoren ihr "Accepted" abgegeben haben. Die Datenbank fungiert sodann als Expertensystem. Dieses weist die Analysten darauf hin, wie hoch die Chancen für False-Positives (und False-Negatives) sind, wie sich diese erkennen und eliminieren lassen. Durch Schritt-für-Schritt Anleitungen bzw. dynamisch generierte Scan-Scripte können sodann weiterführende Tests oder Validierungen durchgeführt werden. Der Tester muss sodann nich zwingend im Detail mit der Zielumgebung und den eingesetzten Technologien vertraut sein, da er sich auf den gesammelten Erfahrungsschatz unseres Unternehmens bzw. der anderen Analysten verlassen kann. Dieser Prozess des Prüfen, Validieren, Parsen, Moderieren und Dokumentieren kann iterativ und beliebig oft wiederholt werden. Zu jedem Zeitpunkt sind sämtliche Daten vorhanden und können auf Knopfdruck ausgegeben werden (Report, Statistiken, Trends). In der Regel wird ein Ablauf der Form Scan-Moderation-Scan-Moderation-Dokumentation angestrebt. Dadurch kann gewährleistet werden, dass Schwachstellen, die bei den ersten Tests nicht identifiziert werden konnten (da sämtliche Angriffsflächen so noch nicht bewusst waren) doch noch identifiziert werden können. In der Datenbank werden umfangreiche Informationen zu den jeweiligen Schwachstellen abgelegt. Neben einer Charakterisierung des Problems findet sich ebenfalls mindestens eine Schritt-für-Schritt Anleitung zur Ausnutzung des Problems und verschiedene Gegenmassnahmen (priorisiert nach ihrer Effektivität). Ebenso wird eine umfangreiche Attributisierung durchgesetzt. So werden Phase eines Angriffs (z.B. Auswertung), Angreifertyp (z.B. Skript-Kiddie), Schwachstellenklasse (z.B. Cross Site Scripting), betroffenes Objekt (z.B. Webapplikation) und Parent-Bug (die für die Existenz dieser Schwachstelle erforderliche Voraussetzung) festgehalten. Zusätzlich sind Referenzen auf andere Scanner (inklusive Deren Beschreibungen, Einstufungen und Testverfahren), Verwundbarkeitsdatenbanken, Webseiten und Bücher in dieser Wissensdatenbank festgehalten. Werden sämtliche Daten in der Datenbank eingetragen und moderiert, kann ein Report generiert werden. Durch die umfangreiche Report-Engine wird es möglich, verschiedene Ausgabeformen und Dateiformate zu unterstützen. Dies reicht von klassischen Word-/PDF-Reports mit allen Details über Excel-Dokumente mit den wichtigsten Gegenmassnahmen (Checklisten) bis hin zu XML-Dateien zur automatisierten Weiterverarbeitung (z.B. in einem Bugtracking-System). Das grundlegende Ziel des Reportings ist dabei, keine der gesammelten und vorhandenen Informationen zu verlieren. In einem Report sind also stets alle Daten enthalten, die von Nutzen sind. Zu jeder gefundenen Schwachstelle werden projektbezogene Informationen, wie die IP-Adresse des Scan-Systems und der Zeitpunkt der Identifikation, bereitgestellt. Damit kann ein Höchstmass an Transparenz und Nachvollziehbarkeit gewährleistet werden. Ganze Tests lassen sich also auch nach Abschluss bis auf die Sekunde genau rekonstruieren.