Das Ende der Automatisierung Marc Ruef | 24.07.2006 Die Wirtschaft lebt davon, Abläufe im Sinne der Wirtschaftlichkeit zu optimieren. Kosteneinsparung zwecks Vergrösserung der Gewinnausschüttung gibt es wohl seit Menschengedenken. Mit dem Einbruch des Neuen Markts in 2001/2002 wurde dieser Grundsatz wieder mehr dennje zu einem unumstösslichen Credo. Oftmals bedeutet dies, dass man Dinge automatisiert, um eine grösstmögliche Performance herauszuholen. Gerade weil die Dinge unbeaufsichtigt erledigt werden können, lässt sich nebenher noch weiterer Arbeiten, die ebenfalls Gewinn einfahren können, nachgehen. Ein unendliches Mass an Automatisierung verspricht ein unendliches Mass an Gewinn. Je mehr Penetration Tests ich jedoch mache, desto mehr wird mir bewusst, dass Automatisierung nur bis zu einem gewissen Grad verfolgt werden kann. Bei einer Sicherheitsüberprüfung ist dies das grundlegende Zusammentragen von Informationen zu einer Zielumgebung. Mapping-Zugriffe, Route-Traceing, Portscanning, Application Mapping, Application Fingerprinting, das sind alles typische Dinge, die mit einem einfachen Shell-Skript zu grossen Teilen automatisiert werden können. Auch das Vulnerability Scanning, also das Identifizieren von potentiellen Sicherheitslücken in einer Netzwerkumgebung, wurden zu grossen Teilen automatisiert. Tools in der Art wie Nessus oder GFI LANguard gehören nach wie vor in den Werkzeugkasten eines jeden technischen Auditors. Doch genau hier - oder eigentlich schon etwas vorher - hören die Möglichkeiten einer gescheiten Automatisierung auf. Das Auffinden von gegebenen Sicherheitslücken ist eine Arbeit, die zu grossen Teilen manuell verfolgt werden muss. Klar, Nessus und dergleichen sind in der Lage eine grundlegende Netzwerkauswertung zu machen und anhand dieser bekannte Schwachstellen zu finden. Durch ein simples Reiz/Reaktions-Schema wird dabei nach exponierten Ressourcen, die eine problematische Sicherheitsvergangenheit haben, gesucht. Dies kann zum Beispiel auf einem Webserver ein Skript sein, das sich bei einer Standard-Installation im Verzeichnis /admin/validate.php findet. Kann ein Scanner das Vorhandensein dieses bestätigen, wird mit grösster Wahrscheinlichkeit auch die dafür bekannte Sicherheitslücke vorhanden sein. Doch was ist nun, wenn der Administrator des Zielsystems seine lückenhafte Webapplikation unter /webadm/ betreibt? Der Scanning-Zugriff auf /admin/validate.php wird ins Leere laufen und die alternative Lokation gar nie ausgemacht werden. Ein False Negative ist absehbar. Oder was ist, wenn zwar das Skript /admin/validate.php vorhanden ist, dieses aber von einer anderen Software erstellt wurde, die gar nichts mit der lückenhaften Anwendung zu tun hat? Der Fehler wird identifiziert, obschon er gar nicht vorhanden ist. Wir haben es mit einem False Positive zu tun. Das Ausräumen dieser Falschmeldungen ist sodann die Aufgabe eines guten Auditors bzw. Penetration Testers. Er muss verstehen, wie die Schwachstellen funktionieren und wie sie wirklich ausgenutzt werden können, um die vagen und lückenhaften Resultate der Scanner validieren bzw. falsifizieren zu können. Ein erhebliches Mass an manueller Arbeit ist sodann erforderlich. Dies fängt bei der Erkundung zur vermeintlich identifizierten Schwachstelle an, indem die gängigen Verwundbarkeitsdatenbanken und Advisory-Archive durchsucht werden. Desweiteren muss man sich die Funktionsweise eines Exploits zu Gemüte führen. Der Trend der letzten Jahre geht jedoch dahin, automatisierte Tools zur Ausnutzung einer Schwachstelle nicht mehr einfach publik zu machen. Aus diesem Grund wird es erforderlich, dass man eine Quelltext-Analyse oder ein Reverse Engineering (z.B. Deadlisting) durchführt. Arbeiten, die nun ganz und gar nichts mehr mit den simplen in Nessus automatisierten Netzwerk-Mechanismen zu tun haben. Kommt Individual-Software in einer Zielumgebung zum Einsatz - zum Beispiel eine eigens geschrieben Webanwendung -, dann helfen Tools wie Nessus gar nichts mehr. Diese können lediglich nach bekannten Schwachstellen in populären Anwendungen suchen. Das Identifizieren von neuen Sicherheitslücken mit eigener Vorgehensweise lässt sich damit nun wirklich nicht automatisieren. Genau aus diesem Grund macht Nessus nur noch etwa 5 % der Resultate meiner Tests aus. Die Daten sind oftmals so lückenhaft, dass ich um manuelle Tests gar nicht mehr herumkomme. Also pflege ich ein Abstützen auf Nessus zunehmends abzulösen. Absolut, Automatisierung ist die beste und effizienteste Methode, um zu einem Ziel zu kommen. Aber dies auch nur, wenn die Automatisierungsmechanismen effizient und korrekt implementiert sind. Dies ist, vor allem in hochkomplexen sowie vielschichtigen Bereichen wie dem Penetration Testing, gar nicht immer Möglich. Handarbeit, Herumprobieren und "ineffiziente" Fehler machen, das ist dann plötzlich wieder viel wirtschaftlicher. Doch dies jemandem beizubringen, der keine Ahnung von Technik hat, ist eine noch komplexere Aufgabe.