Reversing, Reversing, Reversing, ... Marc Ruef | 21.08.2006 In der letzten Dekade hat das Denken von Sicherheitexperten einen enormen Wandel erlebt. Computersicherheit wurde und war durch den Boom des Internets Mitte der 90er Jahre eine primär netzwerkorientierte Thematik. Firewall-Systeme waren mitunter die ersten Lösungsansätze zur Sicherung von Umgebungen, die vor allem im professionellen Umfeld für die Sicherheitsunternehmen sehr viel Gewinn einzufahren in der Lage waren. Ein Netzwerk ohne Firewall wurde pauschal als unsicher abgestempelt. Intrusion Detection-Systeme versuchten, kommerziell gesehen, an diesem Erfolg anzuknüpfen. Gerade diese Fokussierung auf das Netzwerk als Medium, das die Angriffe ermöglichen sollte, führte dazu, dass sich auch bei Sicherheitsüberprüfungen in erster Linie alles um das Netzwerk drehte. Durch netzwerkbasierte Security Scanner (z.B. nmap und Nessus) sollten automatisch bekannte Sicherheitslücken in Umgebungen identifiziert werden. Durch das Entdecken dieser liessen sich schnellstmöglich Gegenmassnahmen einleiten und damit das Zeitfenster für erfolgreiche Angriffe sowie die Angriffsfläche ansich minimieren. Ein jeder technischer Security Audit eines vernetzten Systems wurde primär auf der Netzwerkebene abgehalten. Was über das Netzwerk nicht erreichbar war, konnte nicht als einem Risiko ausgesetzt eingestuft werden. Das Kommunikationsmedium Netzwerk ist für eine Sicherheitsüberprüfung jedoch höchst ineffizient. Das Übertragen der Daten ist nur in beschränktem Masse möglich und zudem lassen sich nur durch relativ simple Reiz/Reaktions-Schemen unter Zuhilfenahme des fehleranfälligen Pattern-Matchings der Erfolg eines Angriffs und damit die Schwachstelle identifizieren. Äussert sich ein erfolgreicher Angriff nicht über das Netzwerk oder lässt sich darüber ausmachen, muss von einem Ausbleiben des Erfolgs ausgegangen werden. Erinnerungen an das Halteproblem von Alan Turing werden wach. Die Zuverlässigkeit eines Tests ist somit nicht optimal. Hostbasierte Scanning-Technologie, die zwar über das Netzwerk betreut werden können, waren die Folge davon. Produkte wie Symantec ESM (http://enterprisesecurity.symantec.com/flashfiles/esm/index.cfm) sollten Agent-orientiert eine host-basierte Überprüfung der jeweiligen Systeme in einem Netzwerk zulassen. Im Rahmen des Nessus-Projekts wurden ebenso Plugins geschrieben, die sich durch einen Agent auf einem Test-System ausführen lassen und direkt auf der Ebene des Betriebssystems Schwachstellen identifizieren können. Der kommerzielle Erfolg dieses Ansatzes, der in Bezug auf Effizienz und Zuverlässigkeit das Netzwerkscanning bei weitem zu übertrumpfen in der Lage ist, blieb aus. Ebenso ein Verlust auf akademischer Ebene. Dennoch haben vor allem die Spezialisten bemerkt, wie sehr sich entsprechende Tests doch optimieren lassen, werden sie auf verschiedenen Ebenen durchgeführt. Führe ich einen Penetration Test eines Produkts durch, ist neben der klassischen Netzwerk-Analyse ein Blick in den Quelltext und/oder das Reverse Engineering angestrebt. Dadurch lassen sich potentielle Fehler finden oder zuvor identifizierte Schwachstellen verifizieren. Hierbei handelt es sich meistens um Offline-Analysen oder um Nachbildungen der Zielumgebungen im Labor. Da sich die Simulation dessen aufgrund der Komplexität gegenwärtiger Entwicklungen nicht mit 100 %er genauigkeit umsetzen lässt, kann es auch da zu Abweichungen (z.B. ein leicht anderes Verhalten, da eine spezifische Version einer Bibliothek eingesetzt wird) kommen. Dennoch sind derartige Tests bei weitem akkurater, weder die klassische Netzwerküberprüfung. Eine Weiterführung der Optimierungen der Tests würde zur Folge haben, dass sich das Reverse Engineering direkt auf dem produktiven Zielsystem umsetzen lässt. Durch Kernel-Debugger liessen sich die effektiv in der Realität genutzten Register auslesen, ihr Verhalten bestimmen und damit Schwachstellen ableiten. Dies ist natürlich, und da wird wohl kaum die Zukunft daran rütteln können, eher unrealistisch. Ein Eingriff in ein produktives System zur Determinierung etwaiger Schwachstellen wird von keinem verantwortlichen Administrator oder dessen Arbeitgeber bewilligt werden. Nach dem Motto "Never touch a running system" sollten negative Auswirkungen, seien sie auch ungewollt, ausgeschlossen werden. Desweiteren ist die altbekannte Problematik der Unschärfenrelation, wie sie von Werner Heisenberg im Jahre 1927 definiert wurde, nicht zu unterschätzen. Das Konzept, dass bei einer Messung eines Zustands eben dieser messbar verändert wird, wurde ebenfalls in den Bereich des Debuggings von Software übernommen. Mit dem Begriff Heisenbug (http://www.cs.rutgers.edu/~rmartin/teaching/spring03/cs553/papers01/06.pdf) werden Programmierfehler zusammengefasst, die sich in ihrer Verhaltensweise durch das Umsetzen des Debuggings ändern. In ähnlicher Weise verhielte es sich, würde man bei einer Sicherheitsüberprüfung auf einem Zielsystem einen weitreichenden Eingriff wie die Installation eines Kernel-Debuggers anstreben: Das Verhalten des Systems wäre massgeblich verändert und damit nicht mein sein ursprünglicher Zustand messbar. Dies könnte man dann einen Heisentest oder ein Heisenengineering nennen. Eines ist sicher: Netzwerkbasierte Tests haben je länger je mehr als eigenständige Analysetechniken in einem professionellen Projekt ausgedient. Nur unter Zuhilfenahme weiterer Methoden, wie die Quelltext-Analyse oder das klassische Software Reverse Engineering, können mit einem Höchstmass an Effizienz und Zuverlässigkeit bestehende Fehler identifiziert werden. Zur Umsetzung dieser umfassenden Überprüfungen fehlen jedoch noch immer effiziente Werkzeuge, obschon auch in diesem Bereich in den letzten Jahren enorme Fortschitte gemacht wurden (z.B. die neuen Erweiterungen (http://www.datarescue.be/freefiles/ida5preview.htm) von Datarescue IDA Pro 5.0). Und auch das Wissen bezüglich Assembler-Programmierung und Code-Analysen ist bei den meisten Auditoren gar nicht vorhanden.