Ein Audit, der an der Software scheitert Marc Ruef | 20.11.2005 Ich habe mal versucht nachzurechnen, wieviele Security Audits und Penetration Tests ich in meinem Leben schon gemacht habe. Dies waren wahrlich ein paar. Das weiss ich vor allem deswegen, weil ich mich an praktisch keine technischen Details dieser zurückerinnern kann. Derlei sinnfreie Daten (z.B. auf welchem System fand ich welche Schwachstelle) messe ich ein solch geringes Mass an Relevanz bei, dass ich sie lediglich mit der Hilfe von Papier für die Zukunft festhalten kann. An einen Penetration Test kann ich mich jedoch noch sehr gut erinnern - Okay, dessen Durchführung ist auch gar nicht lange her. Damals ging es darum zu beweisen, dass man auf elektronischem Wege von einer Bank in eine andere - unter des Missbrauchs einer Vertrauensbeziegung - einbrechen könne. Quasi durch den Lieferanteneingang hereinspazieren und durch eben diesen sensitive Daten abtransportieren. Die zu überprüfende Bank war in bester Weise abgesichert. So habe ich das selten gesehen. Umso mehr musste ich auf Details achten, um in der entsprechenden Umgebung erweiterte Rechte erlangen zu können. Angriffe auf Standarddienste wie Web- oder Mailserver waren aufgrund eines stets aktuellen Patchlevels von Vornherein ausgeschlossen. Individuelle Angriffe auf unpopuläre Services waren erforderlich. Wie bei jedem technischen Audit verschaffe ich mir zuerst mit Hilfe von automatisierten Tools einen Überblick. Bei dieser Informationssammlung kommen Klassiker wie nmap oder Nessus zum Tragen. In einigen Fällen greife ich auch auf eine ältere Version des kommerziellen Vulnerability Scanners Symantec NetRecon zurück, für den ich noch eine gültige Auditor-Lizenz besitze. Da ich nur ungern in Etappen scanne, um innerhalb der Produkte eine möglichst effiziente Korrelation gewährleisten zu können, füttere ich die Tools meistens mit sämtlichen Zielen zeitgleich. So musste innerhalb des Banken-Tests ein ganzes Klasse-B-Netzwerk scannen. Dies umfasste 65'535 potentielle Ziele - Das sind enorm viele! An der Zeitdauer, die der automatisierte Scan in Anspruch nahm, sollte es nicht scheitern. In derlei Dingen bin ich ausserordentlich geduldig. Als NetRecon etwa 6 Stunden Daten gesammelt hatte, wurde aber plötzlich mein System - sowohl die Scanning-VMware als auch das Hostsystem - enorm träge und gar erste Zeichen von Instabilität machten sich bemerkbar. Eine Überprüfung mit dem Taskmanager zeigte, dass die Ressourcen-Auslastung meines Laptops am absoluten Limit war. Das gesamte RAM - das sind dann doch 512 MByte - war aufgebraucht. Es blieb mir sodann nichts anderes übrig, als den Testlauf abzubrechen und mit den bisher eingeholten Informationsfragmenten Vorlieb zu nehmen. Dies wäre eigentlich nicht so tragisch gewesen, kann man die gleichen Informationen auch mit anderen Utilities einholen. Wie es sich aber zeigte, versagten die meisten Produkte ihren Dienst. Vor allem grafische Lösungen für Microsoft Windows konnten ihre Aufgabe nicht erfolgreich erledigen. Aber auch einige zeilenbasierte Utilities für GNU/Linux patzten zu meinem Erstaunen. Beim Erstaunen blieb es nicht lange, denn so sah ich zunehmends mein Repertoire an Software für das automatische Abarbeiten der Aufgaben schwinden. Und es kam, wie es kommen musste: Es blieb mir nichts anderes übrig, weder mühsame Teilscans umzusetzen, die Daten manuell zu verifizieren und zu korrelieren. Klar, mein Ziel habe ich erreicht. Aber nicht so, wie man es im Zeitalter der Computer erwarten könnte. Genau für mühselige Arbeit wurden die Rechenmaschinen erfunden - Und nun brauchte ich sie wirklich dringend und sie versagen ihren Dienst. Schöne neue Welt, in der Dinge zu einem Zweck erschaffen werden, den sie nicht erfüllen können.