Meine kurze Geschichte des Security Testing
Marc Ruef | 07.03.2011

Mit dem Umsetzen von professionelen Sicherheitsüberprüfungen habe ich im Jahr 1998 begonnen. Damals habe ich zwischendurch als Freelancer für eine bekannte Antiviren-Firma entsprechende Tests durchgeführt. Im Jahr 2000 habe ich dann vollberuflich Vulnerability Assessments und Penetration Tests umgesetzt.

Damals war vieles noch anders. Ein Grossteil der Tests hat sich auf grundsätzliche Netzwerkanalysen fokussiert. Zum Beispiel war neben Ping vor allem Traceroute ein wichtiges Element zur Charakterisierung einer Zielumgebung. Die meisten der entsprechenden Zugriffe musste manuell umgesetzt werden. Eine wohl fast unendlich erscheinende Anzahl an Eingaben habe ich mit der Form "traceroute 192.168.x.x" umgesetzt. Das Erkennen von Netzwerkapplikationen hat sich vorwiegend auf Banner-Grabbing abgestützt, denn automatisierte Mechanismen zum Application Mapping und Application Fingerprinting haben noch nicht existiert.

Zwar gab es damals schon einige automatisierte Vulnerability Scanner. SATAN (http://www.porcupine.org/satan/) wurde grösstenteils durch Nessus (http://www.nessus.org), welches damals noch quelloffen war, abgelöst. Doch die rudimentäre Auswertung, wie eben Route-Traceing und Portscanning, war damals noch nicht sauber integriert. Nessus wurde halt primär genutzt, um effektive Schwachstellen auszumachen.

Aus diesem Grund habe ich mich mit einfachen Skripten beholfen, die eine Automatisierung der immerwährenden Eingaben ermöglichen sollten. Viele Jahre (2001-2006) habe ich catwalk.sh (http://www.computec.ch/mruef/software/catwalk.sh) eingesetzt, um besonders breitflächige Analysen effizienter gestalten zu können.

Einige kommerzielle Hersteller wollten diesen Markt ebenfalls für sich erschliessen. Mit Symantec Netrecon wurde ein sehr effizienter Vulnerability Scanner eingesetzt. Leider waren viele Prüfungen etwas oberflächlich, da er sich vorwiegend auf Banner-Informationen verlassen hat. Im Gegenzug konnte der ISS Internet Scanner vor allem durch umfangreiche Tests überzeugen, die ihrerseits aber auch wieder sehr langwierig ausfallen sollten. Beide Produkte verschwanden um 2003/2004 in der Versenkung (Netrecon wurde beispielsweise nicht mehr weiterentwickelt).

Nessus wurde immer professioneller, hat vor allem mit einer Vielzahl an Plugins (http://www.scip.ch/?nasldb) überzeugen können. Das Testing wurde somit aber auch immer zeitaufwendiger, da immer mehr Analysen und Zugriffe durchgeführt werden müssen. Durch das Einbringen einer besseren Applikationslogik hat man versucht diese Prozesse zu optimieren, was zu einem Grossteil gelungen ist. Dennoch ist die Qualität der Nessus-Plugins, vor allem älteren Datums, nicht besonders gut. Ab Anfang 2006 haben wir Nessus deshalb nicht mehr als zentrales Element unserer Netzwerküberprüfungen eingesetzt.

Stattdessen haben wir wieder vermehrt auf manuelle Tests gesetzt, um Schwachstellen ausfindig zu machen. Die Anzahl der False-Positives bei breitflächigen Scans war schlichtweg zu hoch und ein Aussondieren zu aufwendig. Und bei der Prüfung von Individual-Software konnte Nessus aufgrund der produktspezifischen Plugins auch nicht helfen (das gleiche Problem wie beim Pattern-Matching bei Antiviren-Lösungen).

Mit der Zunahme des Verlangens für Penetration Tests wurden Exploiting-Frameworks immer wichtiger. In dieser Hinsicht tat sich - noch während meiner Entwicklung am Attack Tool Kit (http://www.computec.ch/projekte/atk/) - vor allem MSF (MetaSploit Framework) (http://www.metasploit.com/) hervor. Die hohe Anzahl zuverlässiger Exploit-Module und die hohe Flexibilität aufgrund der modularen Architektur helfen dabei, Schwachstellen finden und effizient auszunutzen. In einer Exploiting-Phase greifen wir gut und gerne auf MSF zurück.

Mit der dritten Generation von Nessus hat sich auch bei diesem Produkt einiges getan. Einerseits wurde die Plugin-Qualität massgeblich verbessert. Die Anzahl der False-Positives ist bedeutend geringer als früher. Zudem wurden generische Plugins (http://www.scip.ch/?labs.20100312) eingeführt, die auch produkteunabhängige Fehler finden können (z.B. Cross Site Scripting und SQL-Injection).

Mittlerweile haben wir jedoch ein eigenes Testing-Framework (http://www.scip.ch/?labs.20101119) umgesetzt, welches die Vorteile der unterschiedlichen Mechanismen und Produkte kombinieren soll. Die Datensammlung erfolgt durch eigene NSE-Plugins, die über Nmap ausgeführt werden. Die Datenausgabe erfolgt als XML, wodurch sie in die Datenbank unseres Expertensystems geschrieben werden kann. Dort kann eine abstrahierte und modulare Moderation der Findings erfolgen, weiterführende Tests vorbereitet oder Resultate aufbereitet werden.

Durch die genannten Mechanismen und Produkte hat sich das Security Testing in den letzten 10 Jahren enorm entwickelt. Einerseits wurde damit massgeblich die Effizienz erhöht. Durch die Automatisierung konnte aber ebenso die Genauigkeit der Datensammlungen und Auswertungen verbessert werden. Würde man das gleiche Vulnerability Assessment vor 10 Jahren und heute nocheinmal durchführen, wären diese Unterschiede offensichtlich.

Doch noch lange nicht wurde das gewünschte Ziel erreicht. Auch die heutigen Ansätze können in Bezug auf Effizienz und Genauigkeit verbessert werden. Doch im Unterschied zu damals sind heute die meisten Werkzeuge schon vorhanden. Man muss sie nur noch richtig kombinieren und erweitern. Wir werden auch weiterhin auf unseren Ansatz mit NSE/Nmap und einer zentralen Datenbank setzen.