Potentielle, existente, ausnutzbare oder ausgenutzte Schwachstellen
Marc Ruef | 17.05.2010

Ich arbeite nun schon über einem Jahrzehnt im Bereich der Computersicherheit, habe schon hunderte von Audit-Projekten durchgeführt, zehntausende von Hosts angegriffen und hunderttausende von Ports gescannt. Alle diese Projekte waren anders. Und doch hatten viele von ihnen etwas gemein: Der Kunde wusste oftmals nicht, was er genau möchte. Sehr generisch und dennoch knapp formuliert definiert sich das Ziel einer Sicherheitsüberprüfung meistens wie folgt: "Es sollen Schwachstellen aufgedeckt werden." Doch Schwachstellen sind nicht gleich Schwachstellen und Aufdecken ist nicht gleich Aufdecken.

So gilt es beispielsweise zu unterscheiden, ob man nun potentielle, existente, ausnutzbare oder ausgenutzte Schwachstellen ausmachen möchte. Jenachdem ist hierzu ein gänzlich unterschiedliches Vorgehen erforderlich. Bei potentiellen Schwachstellen wird versucht möglichst breitflächig zu agieren, um die gesamte Angriffsfläche ermitteln zu können. Beim Ausmachen existenter Schwachstellen muss sich hingegen eher auf Angriffspunkte fokussiert werden, um durch das explizite Ausnutzen dieser deren Vorhandensein zu beweisen.

Obschon diese Aspekte alle das gleiche höherwertige Ziel verfolgen, ist also ein gänzlich unterschiedliches Vorgehen und damit auch ein ganz anderes Toolset erforderlich. Breitflächige Analysen erfordern Tools und Skripte, die immerwiederkehrende Auswertungen automatisieren. Nmap (inkl. NSE-Engine) (http://www.scip.ch/?labs.20100507) oder Nessus (http://www.scip.ch/?labs.20100312) sind typische Hilfsmittel hierzu. Gezielte Angriffe erfordern hingegen Frameworks, die das Generieren und Replizieren von Zugriffen und Payloads erleichtern. Hier kommen Mechanismen wie die Web Developer Toolbar für Firefox (https://addons.mozilla.org/en-US/firefox/addon/60/) oder das MetaSploit Framework (MSF) (http://www.metasploit.com/) zum Tragen. Die eine Arbeit kann mit der Herangehensweise und den Werkzeugen der anderen nicht ebenfalls effizient oder gar nicht ausgeführt werden.

Da so mancher Kunde überhaupt nicht weiss, was er von einer Sicherheitsüberprüfung will, kann er von sich aus auch gar nicht nachvollziehen, welche Herangehensweise und welche Mittel zum Erreichen der Ziele - die man versucht hat mit ihm zu definieren - erforderlich sind. Unverständnis und Diskussionen können sodann plötzlich mitten in einem Projekt vorkommen.

Verkaufen wir beispielsweise einen netzwerkbasierten Security Scan (http://www.scip.ch/?dienstleistungen.securityscan), so erfordert dieser möglichst direkten Zugriff auf die Zielsysteme. Bei lokalen Scans vor Ort ist hierzu mindestens ein RJ45-Anschluss und eine legitime Adressierung in der gleichen Zone des Zielsystems erforderlich. Anpassungen am DHCP-Server oder in den VLAN-Konfigurationen können hierzu erforderlich sein. (Zwar lassen sich solche Scans theoretisch auch über verschiedene Zonen und Firewall-Systeme hinweg durchführen. Die akademische Genauigkeit der Analyse leidet jedoch unter den Bedürfnissen eines Real-World Angriffsszenarios.)

Im Rahmen eines solchen Projekts wurde uns leider am Tag des angesetzten Scans mitgeteilt, dass wir keinen Zugriff - so wie gewünscht und frühzeitig definiert wurde - erhalten würden. "Sehr schade", entgegnete ich, "denn so müssen wir halt nun auf die Umsetzung dieses Testmoduls verzichten." Dem Kunden war dies natürlich nicht recht, denn die Qualitätssicherung des Unternehmens sieht vor, dass vor einer Freigabe eines Dienstes dieser eben einer Sicherheitsüberprüfung durch eine externe Firma unterzogen werden muss.

Der Projektleiter auf der Kundenseite fragte sodann nach, ob wir denn nicht mit einem Direktzugriff auf die Systeme per SSH entsprechende Auswertungen durchführen können. "Selbstverständlich können wir das", war meine Antwort. "Doch eine derartige Betrachtung kann", führte ich weiter aus, "einen Netzwerkscan nicht gänzlich ersetzen." Meine Aussage generierte ausschliesslich Unverständnis.

Ich habe dem Kunden versucht zu erklären, dass ein Arzt zwar in so manchem Fall die gleiche Krankheit erkennen kann, egal ob er nun den Patienten einer Röntgenuntersuchung unterzieht oder ob er eine Blutprobe nimmt. Es gibt aber viele Krankheitsbilder, die lassen sich nur mit erheblichem Aufwand oder gar nicht zuverlässig mit nur einer der beiden Methoden ausmachen. Genauso verhält es sich bei Netzwerkscans und lokalen Analysen. Im besten Fall macht man natürlich beides bzw. alle möglichen Tests.

Das Problem hierbei ist, dass dem Kunden nur mit erheblichem technischen Verständnis bewusst wäre, welche Vor- und Nachteile die einzelnen Testvarianten mit sich führen würden. Jenachdem setzt er sich nämlich gewissen Risiken aus, wenn er auf bestimmte Tests verzichtet. Es ist sodann Aufgabe des Consultants, ihm die unterschiedlichen Aspekte zu erläutern. Eine Aufgabe, die manchmal nicht besonders einfach ist.