Die Sandbox-Software lenkt alle sicherheitsrelevanten Systemzugriffe um und entscheidet anhand der Policy über deren Ausführung.
Fast täglich erscheinen neue Abarten von Viren, Würmern und Trojanischen Pferden. Die Anti-Virus-Software-Hersteller versuchen diese neuen Attacken durch immer ausgeklügeltere Updatemechanismen zu bekämpfen, haben aber immer erst eine Lösung, wenn schon irgendwo ein Schaden entstanden ist. Besonders neue Kompressionswerkzeuge, die mit dem Ziel entwickelt werden, die Signaturen bösartigen Codes für Anti-Viren-Programme unsichtbar zu machen, sorgen für immer neue Schwierigkeiten.
Prinzipiell gibt es zwei Arten, um unbekannte Angriffe zu verhindern: Heuristiken und Sandbox-Programme, die zur Laufzeit die Auswirkungen der Software untersuchen. Heuristiken verwenden eine Codeanalyse nach "Daumenregeln", um eine Entscheidung zu treffen. Das heißt, es gibt eine Datenbank, die Muster bekannten Angriffscodes enthält und daraus bei unbekanntem, aber ähnlichem Code eine Gefahr ableitet. Diese Wissensbasis wächst im Laufe der Zeit. Es wird aber immer nur aufgrund von Annahmen eine Entscheidung gefällt. Dies führt zum einen dazu, dass auch ungefährliche Programme blockiert werden (Overblocking). Zum anderen decken Heuristiken aber dennoch nicht alle Angriffsmuster ab, so dass manche Attacke unerkannt bleibt (Underblocking). Darüber hinaus bedeuten Heuristiken einen hohen Aufwand, bevor der Code ausgeführt wird.
Sicherungssoftware, die zur Laufzeit des Programmes auf dessen Verhalten reagiert, vermeidet diese Probleme. Solche so genannte Sandboxing-Software lässt potenziell gefährliche Dateien unter besonderer Beobachtung in einer geschützten Umgebung (der "Sandbox") ablaufen. Alle Programmoperationen werden dabei von einer Zwischenschicht abgefangen, die prüft, ob diese Operationen erlaubt oder verboten sind. Dazu dient in der Regel eine Sicherheitsrichtlinie, die vom Anwender oder zentral vom Administrator vorgegeben wird. Verletzt eine Software diese Sicherheitsrichtlinien, stoppt die Sandbox-Applikation den Aufruf. Ein in der Sandbox laufendes Programm funktioniert nur so lange, wie es sich an die Richtlinien hält. Die Schutzsoftware lässt sich allerdings auch so konfigurieren, dass sie nur verbotene Funktionsaufrufe unterbindet, das Programm aber fortgesetzt wird, damit man es weiter beobachten kann. Allerdings ist nicht immer sichergestellt, dass eine Software nach dem Abfangen eines Systemzugriffs noch stabil läuft.
Alle Programme, die ohne oder mit sehr wenig Benutzerinteraktion heruntergeladen und ausgeführt werden, sollten nur in der überwachten Umgebung ablaufen. Häufig nennt man solche Software "Mobile Code". Dazu zählen aktive Inhalte, die in Webseiten eingebunden sind, wie Java Applets, ActiveX Controls, JavaScript oder VB-Scripts, ferner Dokumente für Microsoft Excel oder andere Office-Anwendungen, die Makros enthalten. Aber auch Bildschirmschoner und EXE-Files aus unsicherer Quelle fallen in diese Kategorie. Bei Excel kommt hinzu, dass es möglich ist, bereits durch die Verwendung einer speziellen Funktion Code auszuführen. Wird eine Excel-Tabelle in eine Webseite eingebunden, wird diese automatisch von Excel im Browser dargestellt. Bloßes Web-Surfen kann dann unter Umständen Programmcode auf dem lokalen Rechner starten.
Die meisten Sandboxing-Anwendungen gibt es für die Win32-Plattform, zum Beispiel eSafe von Aladdin (www.aladdin.de), Secure4U von Sandbox Security (www.sand boxsecurity.com) und SurfinShield Corporate von Finjan Software (www.finjan.com), die sich als einer der ersten Anbieter mit Mobile Code befasst haben. Im Folgenden sollen am Beispiel von SurfinShield exemplarisch Möglichkeiten und Funktionsweise erörtert werden; die anderen Sandbox-Programme bieten aber im Wesentlichen dieselben Funktionen.
SurfinShield Corporate erfasst einen großen Teil von Mobile Code: Das Programm beobachtet EXE-Dateien, Java Applets und ActiveX Controls. Es kann die automatische Ausführung von Office Dokumenten unterbinden und bestimmte Dateiendungen von vornherein blockieren. Dazu zählen zum Beispiel .VBS (Visual Basic Script) oder .SHS (Scrap files). Scrap Files lassen sich beispielsweise missbrauchen, um den eigentlichen Sinn einer Anwendung zu verstecken (vgl. Seite8).
Entsprechende Filterprogramme können zwar Mobile Code zu einem beträchtlichen Teil bereits auf zentralen Gateways abfangen, bei verschlüsselten Verbindungen (etwa per Secure Socket Layer, SSL) ist dieser Schutz aber unwirksam. Laptop Benutzer können sich zudem, wenn sie unterwegs sind, bei jedem beliebigen Provider ins Internet einwählen. Dabei umgehen sie firmeninterne Gateways und können über diesen Umweg gefährliche Programme ins Firmennetz einschleppen.
Technisch gesehen muss ein Sandboxing-Programm alle sicherheitskritischen Operationen bereits auf Betriebssystemebene abfangen. Um die Einstellung der Sicherheitsrichtlinie zu erleichtern, können die sicherheitsrelevanten Operationen in vier Klassen eingeteilt werden: Datei-, Registry-, Netzwerk- und Betriebssystemzugriffe. Die vier Überwachungsklassen geben auch an, welche Betriebssystemschnittstellen die Sandboxing-Anwendung im Auge behalten muss.
Damit alle Programme in die Sandbox gelangen, die der Anwender aus dem Netz heruntergeladen hat, nicht aber solche, die für den lokalen Rechner als vertrauenswürdig angesehen und installiert wurden, muss eine Möglichkeit implementiert werden, diese beiden Anwendungsklassen zu unterscheiden. Dazu markiert die Sandboxing-Software EXE-Dateien aus dem Internet, indem sie ein kleines Programm an die ausführbare Datei anhängt, das die Anwendung bei jedem Start in die Sandbox stellt. In der Regel wird ja eine EXE-Datei zuerst abgespeichert und erst später ausgeführt. Wenn beispielsweise eine Datei SETUP.EXE per E-Mail auf einem Rechner ankommt, auf dem die Sandbox-Software installiert ist, so kann der Anwender das Attachment entweder direkt ausführen oder zunächst abspeichern und später starten. In beiden Fällen wird das Programm jedoch zuerst in die Sandbox gestellt und dort ausgeführt.
Die Markierung stellt zudem sicher, dass ein Umbenennen der Anwendungen keine Auswirkungen auf die Beobachtung hat. Wird die markierte Datei auf einem Rechner ohne das Sandboxprogramm ausgeführt, dann verhält sich der Markierungsvorspann unauffällig, und die Software funktioniert ganz normal. Problematisch sind Downloads von Archiven: Für umfassenden Schutz müsste eine Sandbox-Software alle Kompressionsformate (und auch "umgemünzte" Dateien, die mit einer flaschen Dateierweiterung versehen wurden) prüfen und ggf. deren Inhalt markieren - das wäre ein enormer Aufwand. SurfinShield prüft derzeit daher nur das Entpacken durch Winzip (Überwachung des Entpackers, nicht der Archivdownloads): Wahlweise werden alle EXE-Dateien aus ZIP-Archiven markiert oder ZIPs generell ignoriert.
Der Anwender kann eine ausführbare Datei auch manuell unter Beobachtung stellen. Dies setzt aber ein gewisses Verantwortungsbewusstsein und Know-how beim Endanwender voraus. Ohne dessen Mithilfe kommt SurfinShield zurzeit allerdings nicht aus, wenn Software über CD-ROM oder Diskette auf dem Rechner landet: Momentan gibt es keinen Weg, Mobile Code aus diesen Quellen automatisch überwachen zu lassen. Finjan arbeitet aber an einer entsprechenden Lösung.
Der sicherste Ansatz ist jedoch, dem Endanwender keinen Einfluß auf die Sicherheitsrichtlinien zu gewähren und diese durch einen Administrator zentral vorzugeben. Für spezielle Rechner kann er Ausnahmen definieren. Der Administrator selbst sollte die Sandbox jedoch umgehen können, um Patches und Treiber auf die jeweiligen Systeme zu befördern. Es gibt auch die Möglichkeit, bestimmte Anwendungen freizuschalten. Diese Anwendungen sind dann auf dem zentralen Management Server definiert und werden anhand eines MD5- oder ähnlichen Hashes identifiziert.
Das Markieren der EXE-Dateien basiert auf einem Mechanismus, der Internetanwendungen in der Prozessliste identifiziert. Wenn aus einem solchen Prozess etwas abgespeichert wird und es sich dabei um eine EXE handelt, wird diese markiert. Die zu überwachenden Internetanwendungen werden in einer Liste auf einem zentralen Server geführt. Diese Liste enthält alle gängigen Chat-, E-Mail-, Messenger-, FTP- und sonstigen Internet-Anwendungen, über die sich Dateien austauschen lassen. Der Administrator kann weitere Anwendungen ergänzen.
Die Sandbox an sich ist durch Gerätetreiber (VxD oder KmD) realisiert, die im Ring0 von Windows arbeiten. Die Anwendung kann dadurch erkennen, wenn registrierte Internetanwendungen versuchen, EXE-Dateien abzuspeichern. Genauer gesagt überwacht der Dateitreiber alle Schreiboperationen von registrierten Internetanwendungen. Wird das Schreiben einer EXE-Datei bemerkt, so ergänzt der Treiber diese um das Markierungsprogramm (Stub). Dazu verwendet er einen so genannten Asynchronous Procedure Call (APC). Dieser Stub sorgt dann später dafür, dass die EXE in der Sandbox landet. Das Ganze lässt sich mit der Erstellung eines selbstextrahierenden ZIP-Archives vergleichen, das dem komprimierten Code das Entpackprogramm voranstellt.
Die Sandbox-Software lenkt alle sicherheitsrelevanten
Systemzugriffe um und entscheidet anhand der Policy über deren
Ausführung.
Die eigentliche Sandbox funktioniert als ein so genannter Redirector, d.h. alle Funktionsaufrufe der Anwendung in der Sandbox werden während der Ausführung umgeleitet. Durch diese Umleitung von Systemaufrufen ist es möglich, verschiedene Systemressourcen während der Laufzeit vor der ausführbaren Datei zu verbergen. Dabei dient die Sandbox dann als Bindeglied zwischen den Da- tei-, Netzwerk-, Registry- und Betriebssystemdiensten, wobei die Berechtigungen durch die Systemrichtlinien gesteuert werden. Die Gerätetreiber der Sandbox fangen dann alle Versuche markierter Dateien, auf sicherheitsrelevante Betriebssystemfunktionen zuzugreifen, zunächst ab. Die Sandbox kann dann auf Grund der Policy diese Funktionsaufrufe weiterleiten oder unterdrücken. Sie enthält zudem einen speziellen Prozess, der 16-Bit-Anwendungen einen eigenen Speicherbereich zuordnet, um auch unter Windows NT deren Beobachtung zu ermöglichen.
Im Falle von Java und ActiveX muss sich die Sandboxing-Anwendung in den Browser integrieren oder den Browser an sich unter Beobachtung stellen. Dabei wird vor allem die Java Virtual Machine (JVM) und beim Internet Explorer zusätzlich die ActiveX-Einheit überwacht. Das Integrieren in den Browser hat den Vorteil, dass nur betroffene Java Applets oder ActiveX Controls im Fall einer Sicherheitsverletzung geschlossen werden. Der Browser-Prozess an sich bleibt davon unberührt und kann den Rest der Webseite ganz normal darstellen. Ferner lassen sich bestimmte Websites über eine URL-Liste vom Monitoring ausschließen. Falls beispielsweise ein Proxyserver im Netzwerk vorhanden ist, muss der Administrator diesen der Sandbox bekannt machen, da sonst jedes Applet oder Control wegen einer Netzwerkverletzung abgeblockt wird.
Zur Überwachung aktiver Inhalte integriert sich die
Sandbox-Software in den Webbrowser.
Der Aufwand, die Sandbox zu umgehen, ist relativ hoch. Es gibt natürlich auch hier keinen hundertprozentigen Schutz. Unter Win95/98/ME ist es bespielsweise denkbar, dass Programme durch direkte BIOS-Zugriffe die Sandbox unterlaufen. Dies ist aber sehr aufwändig und funktioniert nicht unter Windows NT, wo jedes Programm die Windows-API verwenden muss. Der Endanwender kommt nur durch eine vollständige Deinstallation an der Sandbox vorbei. Ein Beenden der Sandbox durch den Taskmanager genügt nicht, da sich diese durch die Integration ins Betriebssystem über Gerätetreiber selbstständig wieder startet. Der Gerätetreiber erkennt einen Zugriff einer registrierten Anwendung und startet den Rest der Sandboxanwendung neu. Erst ein Unterbinden des Neustarts per Sicherheitsrichtlinie schaltet die Sandbox ab.
Von der Performance her sind keine Einbußen zu verzeichnen, da lediglich eine zusätzliche Gerätetreiberschicht die Funktionsaufrufe filtert. Jeder Prozess läuft in einem separaten Speicherbereich ab, und Programme arbeiten mit oder ohne Sandbox gleich schnell. Die Programmgröße ist ebenfalls irrelevant und beeinflusst die Sandbox-Performance nicht.
Die Sandbox bleibt für den Endanwender solange unsichtbar, bis eine Sicherheitsverletzung auftritt. Da die Sandbox auf dem Clientrechner läuft, kann es in einigen Fällen zu Inkompatibilitäten mit vorhandener Software kommen, welche evtl. ein ähnliches Konzept hat oder teilweise dieselben Schnittstellen verwendet. Dies lässt sich durch die tiefe Integration ins Betriebssystem leider nie ganz vermeiden.
Alle Sandbox-Clients holen sich von Zeit zu Zeit die
aktualisierten Sicherheitsrichtlinien aus einer Datenbank.
Die Administration geschieht von einer Konsole aus, welche die Sicherheitsrichtlinien in eine Datenbank schreibt. Die Clients, auf denen die Sandbox installiert ist, holen sich im Polling-Verfahren von Zeit zu Zeit die Sicherheitsrichtlinien von einem Server, der die Datenbank beherbergt. Der Client speichert die Sicherheitsrichtlinien lokal ab. Sollte eine Polling-Anforderung fehlschlagen, dann ignoriert der Client dies und verwendet weiterhin die lokale, zuletzt gespeicherte Kopie der Sicherheitsrichtlinien. Dadurch produzieren auch Laptops ohne eine permanente Serveranbindung keine störenden Fehlermeldungen.
Dipl.-Ing. (BA) Peter Pendelin ist Technical Account Manager Europe bei Finjan Inc.
© SecuMedia-Verlags-GmbH, D-55205 Ingelheim,
KES 4/2000, Seite 70
