Simulation statt Infektion Malware-Erkennung durch Sandbox-Umgebungen Simulation statt Infektion Malware-Erkennung durch Sandbox-UmgebungenDie rasante Verbreitung aktueller Malware macht die Zeitspanne zum kritischen Faktor, die zwischen dem Entdecken eines neuen Virus und der Verfügbarkeit sowie Verteilung der Virensignatur bis zum letzten Endgerät liegt. An der klassischen Technik der Erkennung anhand von Code-Beschreibungen (Signaturen, Pattern etc.) wird man dabei nicht vorbeikommen. Denn nur damit ist letztlich zweifelsfreies Erkennen und sauberes Entfernen möglich. Liegen die entsprechenden Updates jedoch zu spät vor – und das kann bei Mass-Mailern und Würmern eine Frage von Minuten sein–, dann lässt sich der Ärger einer Infektion im eigenen Netz nicht verhindern.
Daher sind zusätzliche Mechanismen gefragt. Besonders im Gateway-Bereich zwischen dem Unternehmensnetz und dem Internet, vor allen Dingen am E-Mail-Gateway, ist eine proaktive Strategie sinnvoll. Beispielsweise kann die Sandbox-Technik neue, noch unbekannte Viren, Würmer und Trojaner dort erkennen, bevor sie sich in Netzwerken und Benutzersystemen "einzunisten" vermag. Verdächtige Dateien werden zur Analyse in Echtzeit auf einen virtuellen Computer, die "Sandbox", transferiert. Bei "bösartigem Verhalten", führt die Anti-Virus-Software, welche die Sandbox steuert, dann die nötigen Abwehrmaßnahmen durch. Neuere Sandbox-Umgebungen simulieren dazu ein komplettes Netzwerk inklusive Mail-Server, Freigaben (Windows Shares usw.), einem E-Mail-Adressbuch sowie Domain Name Service (DNS). Ein Virus kann in dieser Umgebung zwar keinen Schaden anrichten, enttarnt sich aber und wird dann von der Anti-Virus-Software gestoppt.
Damit verbessert sich der Schutz bis zur Erstellung eines Erkennungsmusters und der Aktualisierung der Anti-Virus-Software; dieser Vorsprung kann Katastrophen verhindern. Beispielsweise konnte Mitte Februar die Norman Sandbox den sich schnell verbreitenden Wurm NetSky.B isolieren, bevor hierfür spezielle Signaturen vorlagen.
Die Simulation eines (32-Bit-)Windows-Systems nebst Netzwerkumgebung ist allerdings keine leichte Aufgabe. Das Betriebssystem und die Ablaufumgebungen für Hochsprachen (Run Time Libraries) stellen große Mengen von Funktionen bereit. Fehlen in der Simulation Teile, die eine Malware benutzen will, so kann diese nicht oder nicht vollständig ablaufen und somit auch ihre "Bösartigkeit" nicht auffallen.
Die Ansprüche an das simulierte Betriebssystem der Sandbox beginnen mit dem Thread-Support. Dabei steht die Simulation denselben Management-Overhead-Problemen gegenüber wie sie auch das echte Windows kennt. Es ist jedoch äußerst einfach, mit Threads zu programmieren und Malware nutzt Threads und auch Remote Threads in anderen Prozessen – wiederum gilt: werden diese Funktionen nicht simuliert, lassen sich etliche Viren nicht erkennen.
Um sich in einem Windows-System einzunisten, können Viren verschiedene Wege missbrauchen, die auch legitimer Software ermöglichen, nach jedem Systemstart präsent zu sein. Aktuelle Malware nutzt dazu völlig andere Möglichkeiten als die ersten Windows-98-Viren. En vogue ist derzeit, externe Threads für bereits laufende Anwendungen anzumelden und diese mit zusätzlichen "Funktionen" auszustatten. Viele Würmer "leben" als eigenständiger Prozess, andere klinken sich beispielsweise in den Explorer ein. Der simulierte PC muss daher eine Vielzahl an Möglichkeiten und Schnittstellen bereithalten.
Da Malware häufig versucht, mehr System-Privilegien zu erhaschen, als die Ablaufumgebung für den aktuellen Anwender eigentlich vorsieht, muss die Simulation auch die Rechteverwaltung der Betriebssysteme widerspiegeln – inklusive der Anwender, Gruppen und Eigentümer sowie Security-Identifier (SID).
Eine weitere Schwierigkeit sind die unterschiedlichen Verhaltensweisen der verschiedenen Windows-Versionen: Windows NT und 98 laden beispielsweise bestimmte Bibliotheken (z. B. kernel32.dll) in ganz andere Speicherbereiche. Erst das Portable-Excecutable-(PE)-Format für Windows-Programme ermöglicht mit bestimmten Funktionen den Zugriff auf die korrekten Software-Schnittstellen.
Um reale Systeme nachzubilden, müssen etliche Dynamic Link Libraries (DLLs) mit einer ausreichenden Zahl von Funktionen des Originals "verfügbar" sein. Ein Update der simulierten Funktionen sollte dabei über das allgemeine Update der Anti-Virus-Lösung möglich sein, um sich neuen Gegebenheiten anpassen zu können. Nicht alle simulierten Funktionen müssen dabei tatsächlich auch etwas bewirken, bisweilen genügt die Rückgabe eines "Ok"-Codes an die zu untersuchende Software, damit diese weiterläuft. Auf der anderen Seite muss die Sandbox jedoch sicherstellen, Aktionen soweit zu simulieren oder zumindest übergebene Werte zu interpretieren und zu speichern, dass spätere "Rückfragen" des Programms korrekte Antworten erhalten. Hier sind vor allem Registry-Einträge und das Bereitstellen von Funktionen nachgeladener DLLs zu nennen.
Viele Windows-Schädlinge sind heutzutage in Hochsprachen wie C oder Visual Basic geschrieben, die auf Laufzeitbibliotheken zurückgreifen – beispielsweise benötigen Visual-C-Programme eine adäquate Version der msvcrt.dll, um überhaupt funktionieren zu können. Das Problem bei der Simulation ist, dass solche Bibliotheken dazu tendieren sehr groß zu sein, hunderte Funktionen zu umfassen und auf etliche Funktionen anderer DLLs zurückgreifen. Die msvcrt.dll nutzt beispielsweise über 140 Funktionen der kernel32.dll und exportiert selbst über 750 Funktionen.
Leider scheidet es aus verschiedenen Gründen aus, die auf dem realen System vorhandenen DLLs für den simulierten Computer zu nutzen. Zum einen gibt es üblicherweise verschiedene Versionen, sodass sich die Frage stellen würde, welche man auswählen sollte. Zudem könnten auch die real vorliegenden DLLs ja mit einem bis dato unbekannten Virus infiziert sein und in der Folge zu einem Fehlalarm führen, wenn eine zu untersuchende Software auf eine modifizierte Funktion zurückgreift. Und nicht zuletzt ist nicht sicherzustellen, dass auch wirklich alle typischerweise auf einem Client vorliegenden Bibliotheken auf dem untersuchenden System vorliegen, das womöglich nicht einmal unter Windows arbeitet.
Alle "handelsüblichen" Libraries in den Anti-Virus-Informationen mitzuführen kommt aus Platzgründen und wegen Urheberrechtsbedenken ebenfalls nicht infrage. Somit bleibt einem Sandbox-Entwickler eigentlich nur, auch diese Bibliotheken nachzubilden. Da dies kaum vollständig zu leisten ist, kommt es darauf an, "genug" Unterstützung nachzuprogrammieren, um das Virus glauben zu lassen, mit einer echten Ablaufumgebung zu arbeiten. Eine besondere Schwierigkeit stellen dabei Visual-Basic-(VB-)Programme dar, die aufgrund verschiedener Compiler-Modi mit verschiedenen Libraries arbeiten. Ein typisches ausführbares VB-Programm startet mit dem Aufruf einer Funktion der Laufzeitumgebung, der es als Parameter eine Struktur übergibt, die beschreibt, wie die Ablaufumgebung weiter vorzugehen hat. Um das zu simulieren, müsste man das vollständige VB-Executable-Format durchschauen und entsprechende Laufzeitfunktionen nachbilden, was kaum durchführbar erscheint.
Glücklicherweise kann ein Virus nicht nachsehen, ob ein Computer wirklich "verkabelt" ist. Auch für die Netzwerk-Erkundung kann sich eine Software nur auf die Programmierschnittstellen verlassen, die ihm die vorhandenen Netzwerkstrukturen aufzeigen. Um ein LAN vorzutäuschen, muss man daher nicht mehrere verschiedene Computer simulieren, sondern lediglich die (simulierten) Schnittstellen im Griff haben. Um typische Malware-Funktionen zu entlarven, dürften beschreibbare Freigaben und die Verfügbarkeit eines Mail-Servers (SMTP) wesentlich sein. Wichtig sind zudem auch ein "installierter" Internet-Account (mit den zugehörigen Registry-Einträgen), Dummy-Einträge im Windows-Adressbuch (WAB) sowie einige HTML-Dateien, in denen ein Wurm E-Mail-Adressen für seine infektiösen Nachrichten finden kann. Eine (simuliert) abgehende E-Mail an eine dieser Adressen ist dann ein recht stichhaltiger Beweis für einen Mass-Mailer-Virus.
Vordergründig sollte der simulierte PC in der Sandbox aus Sicherheitsgründen keinen Kontakt zur wirklichen Welt besitzen. Auf der anderen Seite bedeutet das aber auch, dass keine Möglichkeit besteht, die Gültigkeit oder Verfügbarkeit von angesprochenen IP-Adressen oder angeforderten Datei-Downloads zu überpüfen. Die Prüfsoftware sollte daher optional Anfragen an die Anti-Virus-Lösung vorsehen, um solche Dinge erledigen zu können – nur optional, damit Scanner auf Arbeitsplatzrechnern nicht durch eine Vielzahl solcher Anfragen ins Internet die verfügbare Bandbreite eines Unternehmens "auffressen". Am Gateway ist eine solche Funktion jedoch wertvoll, um beispielsweise E-Mail-Attachments umfassend zu prüfen. Schließlich könnte ein Wurm ohne erfolgreichen Download von seinem "Heimatserver" entscheiden, sich lieber unauffällig zu verhalten und würde dann womöglich nicht enttarnt, da ein bloßer Downloadversuch ein Attachment vermutlich noch nicht als hinreichend "bösartig" qualifiziert.
Dennoch bleibt die Frage schwierig, ob man einer verdächtigen Software gestatten sollte auf externe Systeme zuzugreifen. Schließlich könnte sich hinter einem Web-Download (HTTP GET) auch ein versuchter Angriff auf die Website verbergen: zum Beispiel per Buffer Overflow. Die eigenen Systeme wären zwar sicher, aber die Malware im simulierten Computer würde mithilfe der Anti-Virus-Lösung möglicherweise Systeme von Dritten angreifen. Um auf Nummer Sicher zu gehen, sollte eine Sandbox-Umgebung daher nur Anfragen in die wirkliche Welt gestatten, die überprüfbar "harmlos" sind. Uploads oder zweifelhafte Kommandos sollten hingegen nur auf ein lokal simuliertes System gelenkt werden. Zudem kann die Sandbox mithilfe eines Fake-DNS auch ohne Verbindung ins reale Internet eine Scheinwelt von Servern erschaffen und dort (ebenfalls simulierte) Ressourcen bereitstellen.
Heikel sind allerdings Würmer, die von externen Systemen eine Rückmeldung erwarten. Wenn zum Beispiel ein bösartiges E-Mail-Attachment (in der Sandbox) ausgeführt wird und gefundene Services an zuvor infizierte Systeme melden will, könnte eine Simulation zwar die ausgehenden Pakete annehmen, aber nicht wie das "Original" reagieren. Falls der Wurm eine spezifische Reaktion erwartet und sich bei deren Ausbleiben inaktiv verhält, kann die Sandbox ihn dann nicht sicher als Wurm erkennen... Zumindest wäre hierzu eine tiefe Analyse der abgesandten Daten notwendig.
Sandbox-Umgebungen in Anti-Virus-Scannern sind kein Allheilmittel, das alle Arten von Malware erkennen kann – so bleiben beispielsweise Makro- und Skriptviren wegen des immensen zusätzlichen Simulationsaufwands ungeprüft. Sandbox-Systeme können jedoch für die sich am schnellsten ausbreitenden Netzwerk- und E-Mail-Viren und -Würmer die gefährliche Zeitspanne zwischen dem ersten Auftreten und der Bereitstellung von Signatur-Updates überbrücken helfen. Zudem bilden sie eine wichtige Frühwarnstufe, da auffällige, aber bis dahin unbekannte Attachments von den Anti-Virus-Labors einer genauen Prüfung unterzogen werden können. Weitere Hürden und Details zur technischen Umsetzung der Norman-Sandbox sowie Ablaufbeispiele von W32/Sheer.A und W32/Klez.H enthält ein Norman-Beitrag zur Virus Bulletin Conference [1].
Volker Krause ist freier Berater für IT-Sicherheit. Uwe Rehwald ist Vertriebsleiter der Norman Data Defense Systems GmbH.
![[externer Link]](../../../../images/link.gif)
www.norman.com/documents/nvc5_sandbox_technology_2002.pdf http://download.norman.no/manuals/eng/BOOKON.PDF www.norman.com/papers.shtml
© SecuMedia-Verlags-GmbH, 55205 Ingelheim (DE),
<kes> 2004#2, Seite 97
| 