Kontrolliertes Risiko

Sicherheitstool (nicht nur) für den Internet Explorer

Praxis & Tipps | Tipps & Tricks

Ein Dreh- und Angelpunkt der Sicherheitsbedenken gegen Windows ist der Internet Explorer. Sicher wird der Browser erst durch Sperren aller aktiven Inhalte, was einem aber schnell den Spaß am Surfen verdirbt, da viele Seiten nicht mehr korrekt angezeigt werden. Die neue Version 2.0 des c't-IEController hingegen bietet zusätzliche Sicherheit ohne Komfortverlust.

Das ist doch nicht zu fassen: Ich klicke auf einen harmlos aussehenden Link, kurze Zeit passiert nichts, dann öffnet sich die Dialogbox eines Programms und informiert mich, dass mein System verwundbar sei. Tatsächlich: Mein Browser hat über den Link ohne Rückfrage das Programm geladen und gestartet. Wie gut, dass es nur eine Demo war und kein Spionage-Tool oder Dialer.

Dieser Exploit [1] funktionierte mit dem Internet Explorer 5.x und 6.0 trotz aller Sicherheitsupdates, die bis Mitte September verfügbar waren. Der Browser bietet lediglich eine wirksame Gegenmaßnahme: das Abschalten von ActiveX. Doch dann funktioniert auch der Start von Plug-ins nicht mehr. Um sicher surfen zu können, muss man also auf den Acrobat Reader zur Anzeige von PDF-Dateien ebenso verzichten, wie etwa auf den Flash-Player.

Wesentlich praxisnaher fällt der Schutz aus, den unser Tool IEController [2] bietet. Damit kann man ActiveX generell abschalten und ist damit vor dem Exploit sicher, während der Start des Acrobat Reader und des Flash Player erlaubt bleibt. Daneben kann man weitere Plug-ins zulassen, ohne die prinzipielle Sicherheit des Systems aufzugeben. Vor einem halben Jahr erschien die erste Version von IEController, jetzt folgt die zweite, die nicht nur ActiveX-Controls und die Ausführung externer Programme durch den Browser überwacht, sondern auch Datei- und Internetzugriffe. Außerdem wurden einige kleine Fehler behoben.

Der beschriebene Exploit ist ein perfektes Beispiel dafür, wie IEController mehr Transparenz und Sicherheit für Windows bringt. Selbst wenn man ActiveX generell zulässt und das Demo-Programm geladen wird, darf der Browser es nicht, wie im Beispiel [1] vorgesehen, unter „C:\“ abspeichern. Allerdings benötigt er Schreibrechte auf bestimmte Verzeichnisse wie das Browser-Cache. Doch wenn ein Exploit dort ein Programm abspeichert, kann der IEController immer noch verhindern, dass es ungefragt ausgeführt wird.

Wer nun befürchtet, dass IEController tief ins Windows-System eingreift oder Dateien verändert, die zum Internet Explorer gehören, sei beruhigt: Das Tool wird nicht einmal installiert, sondern lediglich zusammen mit einer DLL in ein beliebiges Verzeichnis kopiert. Beim Start ruft es den Internet Explorer auf und klinkt sich zwischen den laufenden Prozess und das Betriebssystem ein. In dieser Position kann es überwachen, welche Module der Browser nachlädt, auf welche Dateien er zugreift, welche fremden Programme er startet und welche Webserver er kontaktiert. Version 2.0 ermöglicht zudem die Einsicht in alle Daten, die über das Netz gehen, sogar bei einer Verbindung via SSL.

Startet man den Browser hingegen direkt, bleibt alles beim Alten. IEController hat keinerlei Nebenwirkungen und kann auch jederzeit durch einfaches Löschen der .exe- und der .dll-Datei entfernt werden. Lediglich in der Registry verbleiben unter „HKEY_CURRENT_USER/Software/c't“ die Einstellungen, die das Tool abspeichert. Das hat aber keinerlei Auswirkungen auf das System; mit Regedit lassen sich auch die Schlüssel unter „c't“ problemlos entfernen.

Die Einstellungen werden für jeden Benutzer getrennt verwaltet; jeder kann eine oder mehrere Konfigurationen abspeichern. Dazu sind keine Administratorrechte erforderlich. Für jede Konfiguration erzeugt IEController auf dem Desktop des jeweiligen Benutzers eine eigene Verknüpfung, über die sich der Internet Explorer mit den entsprechenden Einstellungen starten lässt. So kann man etwa fürs Homebanking eine Konfiguration anlegen, in der Java zugelassen wird, während es sonst beim Surfen ausgeschaltet bleibt.

Als Sicherheitstool in administrierten Umgebungen lässt sich IEController allerdings nur eingeschränkt nutzen. Zwar kann der Administrator eine Konfiguration vorgeben und für die einzelnen Benutzer in die Registry kopieren. Die Aufrufoption „-ROConfig“ verhindert, dass Benutzer die Konfiguration ändern. Ein besserer Schutz wäre es, die entsprechenden Einträge in der Registry mit Schreibschutz zu versehen. Doch eine derart vorgegebene, einheitliche Sicherheits-Policy funktioniert nur, sofern die Benutzer kooperieren. Denn sie können ja den Internet Explorer auch ohne IEController starten.

Standardmäßig ruft IEController den Internet Explorer auf, doch er funktioniert vom Prinzip her auch mit jedem anderen Win32-Programm. Man könnte damit also auch etwa einen anderen Browser sicher machen, doch die individuelle Anpassung wäre recht aufwendig. Wenn man im Internet Explorer eine Seite mit JavaScript lädt, dann öffnet er die Datei „jscript.dll“ und erzeugt ein COM-Objekt (Component Object Model), das den Code ausführt. Hat man in der Konfiguration des IEController das Ausführen von JScript (Microsofts erweiterte Version von JavaScript) verboten, wird die Erzeugung des entsprechenden COM-Objektes verhindert. Dazu muss man lediglich im Konfigurationsmenü ein Häkchen löschen. Andere Browser nutzen aber nicht die „jscript.dll“, sondern erzeugen andere COM-Objekte, um JavaScript anzuzeigen. Diese muss man dann in die Konfiguration je nach Wunsch als erlaubt oder verboten eintragen.

Nun erzeugt der Internet Explorer beim Programmstart und Laden einer einfachen HTML-Datei aber bereits 23 COM-Objekte. Das lässt ahnen, wie aufwendig es ist, den Überwachungsmechanismus an ein gänzlich anderes Programm anzupassen. Außerdem ist das nicht ungefährlich. Es kann durchaus zu Abstürzen und Datenverlusten kommen, wenn IEController die Erzeugung eines COM-Objekts verhindert und das kontrollierte Programm dies nicht abfängt. Der Internet Explorer zeigt sich hier sehr tolerant, das muss aber nicht für jede Software gelten.

Bei Programmen, die eng mit dem Microsoft Browser zusammenarbeiten oder ihn als Anzeigemodul nutzen, kann die Überwachung durch IEController aber durchaus sinnvoll sein. Ein Beispiel ist Outlook Express: Es genügt, die Standardobjekte des Internet Explorer durch Setzen eines Häkchens und rund zehn weitere durch einmaliges Bestätigen zuzulassen, um mit dem Mailer arbeiten zu können. Alles andere, insbesondere JScript und VBScript, bleibt aber verboten, was die Anzeige von HTML-Mails recht sicher macht. Ein generelles Verbot von Zugriffen auf Internetadressen verhindert zusätzlich, dass das Lesen einer Spam-Mail dem Absender durch Nachladen von dessen Webserver signalisiert wird. Außerdem kann man den Start externer Programme verhindern beziehungsweise etwa auf einen JPG-Viewer und das Notepad beschränken, um gefährliche Attachment-Typen zu entschärfen.

Neben Windows 2000, XP und 2003 Server unterstützt die neue Version von IEController jetzt auch Windows NT4SP6. Unter Windows 95/98 läuft das Tool nicht; es kann sich dort prinzipbedingt nicht zwischen einzelne Prozesse und das Betriebssystem einhängen. Daher müsste es für die Kontrolle des Internet Explorer systemweite Änderungen durchführen, was eventuell Nebenwirkungen auf andere Programme hätte. Wer sich daran versuchen möchte, kann die Quelltexte des Tools über den Soft-Link am Ende des Artikels herunterladen.

Die Dialoge von Version 2.0 erscheinen abhängig von der Windows-Version in Deutsch, Englisch oder Niederländisch. Über die Verknüpfung auf dem Desktop lässt sich sowohl der Internet Explorer direkt starten als auch das Konfigurationsmenü von IEController öffnen. Letzteres erreicht man durch Festhalten der Maustaste nach dem Doppelklick. Eine kurze Pause vor der Abfrage sorgt dafür, dass dies im Unterschied zu Version 1.0 nun auch auf schnellen Systemen funktioniert. Außerdem klappt es jetzt auch bei Linkshändern, die mit vertauscht belegten Maustasten arbeiten. Wer mit diesem Aufrufmechanismus nicht zurechtkommt, kann ihn mit der Option „-NoMouseCfg“ ausschalten und das Konfigurationsmenü über eine Kopie der Verknüpfung mit der Option „-Config“ starten.

Außerdem kann man nach dem Start des Browsers das Konfigurationsmenü mit der Tastenkombination „Alt+Caps“ (etwas länger drücken) öffnen. So lässt sich etwa während des Surfens JScript einschalten, das der Browser zum Durchsuchen und Drucken der dargestellten Webseite benötigt. Doch Vorsicht: Diese Änderung wird abgespeichert und gilt auch für weitere Browserfenster, die man mit „Strg+N“ geöffnet hat. Man sollte daher nicht vergessen, sie wieder rückgängig zu machen.

Bei begrenztem Hauptspeicher verwaltet der Internet Explorer übrigens mehrere Fenster in einem Prozess. Einmal am Werk, kontrolliert der IEController dann auch Fenster, die durch direkten Start des Browsers geöffnet wurden. Der Registry-Eintrag „BrowseNewProcess=yes“ unter „HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\
CurrentVersion\Explorer\BrowseNewProcess“ sorgt dafür, dass man gleichzeitig mit und ohne IEController surfen kann.

Das Konfigurationsmenü umfasst fünf Sektionen: die Filter für COM-Objekte (unter dem Reiter ActiveX), für Aufrufe externer Programme (unter Programme), für Dateizugriffe (unter Dateien) und für Zugriffe auf Server (unter Internet) sowie die Grundeinstellungen (unter Konfiguration). Über die Grundeinstellungen legt man die Desktop-Verknüpfung für eine neue Konfiguration an, kann aus Textfiles Einstellungen importieren und greift auf unsere Online-Hilfe zu, in der auch Files mit Einstellungen zum Download angeboten werden.

Die Konfiguration der vier Filter ist in jeweils zwei Bereiche aufgeteilt: Im Hauptdialog nimmt man die Grundeinstellungen vor, kann also beispielsweise JScript oder Zugriffe auf das Cookies-Verzeichnis ein- beziehungsweise ausschalten. Daneben gibt es die Experten-Konfiguration mit einer Black- und einer Whitelist, in denen verbotene und erlaubte Elemente (COM-Objekte, Programme, Dateien oder Server) eingetragen werden. Darunter stellt man schließlich noch ein, wie IEController mit Elementen verfährt, die weder von der Grundeinstellung noch von den Listen erfasst werden. So kann das Tool unbekannte COM-Objekte generell sperren (sicher), zulassen (unsicher) oder vor dem Start nachfragen.

Die Nachfrage-Option bietet die Möglichkeit, die Schutzfunktionen an eigene Bedürfnisse anzupassen. Beantwortet man eine Nachfrage mit der Option „Diese Wahl soll immer gelten“, so wird das Element in die jeweilige Black- oder Whitelist übernommen. Außerdem kann man in den Listen über einen Klick mit der rechten Maustaste in den Anzeigebereich direkt Einträge vornehmen, ändern oder löschen.

IEController arbeitet die Filterlisten in einer festen Reihenfolge ab: Die höchste Priorität hat die Blacklist; was dort eingetragen ist, wird unabhängig von anderen Einstellungen immer gesperrt. Danach kommen die Grundeinstellungen. Ist dort etwa JScript ausgeschaltet, lässt es sich über die Whitelist nicht aktivieren.

Bei der Filterung von COM-Objekten ist gegenüber Version 1.0 lediglich die Grundeinstellung für die Anzeige von PNG-Grafiken hinzugekommen. Diese Option ist per Default inaktiv, da PNG-Grafiken nicht so häufig vorkommen. Außerdem enthält das Anzeigemodul des Internet Explorer bis Version 6 einen Buffer-Overflow-Fehler [3].

Unter „Standard-Objekte“ sind die notwendigsten Module zusammengefasst, ohne die der Internet Explorer nicht auskommt. Diese Liste ist bewusst knapp gefasst. Denn die meisten Objekte sind optional. Zum Beispiel die Favoriten: Wenn sie nicht funktionieren, kann man mit dem Browser trotzdem gut arbeiten. Aber schon morgen könnte eine Sicherheitslücke in genau diesem Objekt bekannt werden. Daher haben wir es nicht in die Liste aufgenommen. Wer die Favoriten nutzen möchte, muss sie in seine Whitelist aufnehmen.

Der IEController erlaubt also in der Standardeinstellung so wenig wie möglich, ermöglicht aber die Anpassung an persönliche Vorlieben. Dabei muss man sich im Klaren sein, dass jedes weitere zugelassene Objekt ein Sicherheitsproblem enthalten kann.

Leider gibt es keine vollständige Liste der COM-Objekte und ihrer Bedeutung. So ist es schwierig festzustellen, welche Funktionen und Risiken sich hinter einer Objektkennung (CLSID) verbirgt, wenn IEController nachfragt, ob er die Ausführung zulassen soll. Man kann allenfalls versuchen, zur CLSID den Bezeichner zu ermitteln und dafür die Interface-Dokumentation im MSDN-Bereich bei Microsoft [4] zu suchen. Beispielsweise:

CLS: {0x00021401L,0x0000,0x0000,{0xC0,0x00,0x00,0x00,0x00,0x00,0x00,0x46}}
Bezeichner: CLSID_ShellLink
Interface: IShellLink, von MS dokumentiert.

Recht einfach ist es dagegen, den Start externer Programme zu kontrollieren. Dies kommt eher selten vor, da häufig benötigte Applikationen wie der Acrobat Reader als Plug-ins installiert werden. Daher stört es wenig, wenn man den IEController vor jedem Start einer Anwendung nachfragen lässt. Dadurch geht man sicher, dass eine vermeintliche Textdatei, die direkt vom Server geöffnet wird, sich nicht als ausführbarer Code entpuppt. Als Erweiterung wäre noch denkbar, dass externe Programme unter der Kontrolle des IEController gestartet werden, um den Schutz quasi weiterzuvererben.

Da prinzipiell jede Funktion des Internet Explorer unsicher sein könnte, überwacht IEController in Version 2.0 zusätzlich die Dateizugriffe. Prinzipiell ließen sich damit alle Risiken kontrollieren, doch in der Praxis sieht das anders aus: Der Internet Explorer tobt ständig lesend und schreibend über die Platte, sodass man nur mit einer sehr lockeren Kontrolle arbeiten kann. Daher sind die Freigaben schon in der Grundeinstellung sehr umfangreich; immerhin erlauben sie aber nur lesenden Zugriff auf das Systemverzeichnis. Daneben sollte man wichtige Dateien, die etwa Kennwörter, PGP-Schlüssel oder die Homebanking-Datenbank enthalten, in die Blacklist eintragen.

Eine Besonderheit von Windows macht es schwierig, Zugriffe auf bestimmte Dateien über den Namen zu erkennen: Diese können nämlich in Kurz- und Langform angegeben werden (z. B. „iecontroller.exe“ und „iecont~1.exe“). Jeder Pfadbestandteil lässt sich über beide Varianten ansprechen, sodass viele Kombinationen möglich sind.

Ebenfalls neu in Version 2.0 ist die Überwachung von Internetzugriffen. Sie setzt an den WinINet-Funktionen an, sodass sie auch mit Escape-Zeichen verschleierte URLs korrekt erkennt. Allerdings müssen Adressen mit IP-Nummern zusätzlich zu den Klartext-URLs eingetragen werden. Außerdem ist es möglich, etwa mit „connect“ aus Winsock von IEController unbemerkt Verbindungen aufzubauen.

In der Grundeinstellung kann man den Zugriff auf den Alexa-Suchdienst und auf eine Sammlung von Adressen sperren, über die häufig Werbung geladen wird. Das ist zwar kein perfekter Werbeblocker, erspart aber in vielen Fällen das Laden von Bannern. Außerdem besteht die Möglichkeit, die vom und zum Webserver übertragenen Daten sichtbar zu machen. Das funktioniert auch, wenn sie über SSL verschlüsselt werden.

IEContoller schreibt die Daten auf die Debugkonsole von Windows, sodass sie mit einem Tool wie Debugview (s. Soft-Link) sichtbar werden. Für eine brauchbare Anzeige aktiviert man in Debugview unter „Capture“ nur die Punkte „Capture Win32“ und „Capture Events“ und zieht das Fenster so weit auf, dass die Ausgaben unter „Debug Print“ sichtbar werden.

Damit lässt sich beispielsweise prüfen, welche Daten der Browser beim Windows-Update an Microsoft überträgt. Das räumt Bedenken gegen diesen Mechanismus aus, die den Datenschutz betreffen. Ganz allgemein ist IEController übrigens ein nützliches Werkzeug, mit dem man hinter die Kulissen der Software schauen kann und teilweise interessante Phänomene entdeckt. So stellten wir beim Testen erstaunt fest, dass Outlook Express beim Start auf die DOS-Startda-tei „Autoexec.bat“ zugreift. Da hat ein Microsoft-Programmierer wohl mal etwas ausprobiert und vergessen, die Routine wieder zu entfernen. Das steigert nicht unbedingt das Vertrauen in die Software aus Redmond. (ad)

[1] Exploit zum Laden und Ausführen von Programmen (http://www.heise.de/security/dienste/browsercheck/demos/ie/e5_15.shtml)

[2] Matthias Withopf, Axel Kossel, Internet Explorer an die Kette gelegt, Echte Kontroller über aktive Inhalte, c't 1/03, S. 86

[3] Sicherheitslücke bei PNG

[4] Microsoft MSDN

[5] Gary Nebbett, Windows NT/2000 Native API Reference, Expert insight for Windows NT/2000 software developers, ISBN 1-57870-199-6

Über Einträge in die Black- und Whitelist kann man den IEController an eigene Bedürfnisse anpassen. Natürlich macht die Pflege der Listen Arbeit. Doch die Idee ist, dass uns Leser ihre Listen - mit einem Kommentar für jedes Objekt versehen - zusenden (an iec@ct.heise.de), die wir als Sammlung zum Download anbieten, aus der jeder das Gewünschte importieren kann.

Weitere Artikel zum Schwerpunktthema finden Sie in der c't 21/2003:

  • Bekannte Sicherheitslücken in Windows, S. 100
  • Eingeschränkte Windows-Benutzerkonten fürs Netz, S. 104
  • Virenblocker für Outlook Express, S. 112
  • Eigener Windows-Update-Server im LAN, S. 118

Kommentare

Kommentare lesen (67 Beiträge)

Anzeige
Anzeige