FTP-Funktion des Internet Explorer als Passwort-Schleuder

Username und Passwort werden unbemerkt in lokalen Dateien gespeichert

Unter recht alltäglichen Umständen speichert der Internet Explorer 6 in Webseiten, die per FTP herunter geladen wurden, den Benutzernamen und das Passwort des Benutzers. Dieses Verhalten kann fatal sein, wenn man das Programm zur Verwaltung seiner Internet-Präsenz verwendet.

Neben seinem Hauptzweck als Web-Browser kann der Internet Explorer 6 (IE6) auch als FTP-Client dienen. Das ist vor allem auf öffentlichen Rechnern, die meist mit dem IE ausgestattet sind, recht praktisch, wenn man an der eigenen Webseite kleine Aktualisierungen vornehmen will - ein vollwertiger FTP-Client ist dann nicht nötig.

Die Behandlung von HTML-Dateien durch den Internet Explorer weist jedoch ein mehr als merkwürdiges Verhalten auf, das zu fatalen Sicherheitslücken führen kann. Ist man auf einem Server per FTP eingeloggt, und klickt in der Verzeichnisstruktur eine HTML-Datei doppelt an, so öffnet sie sich wie bei einem gewöhnlichen Browser. Klickt man dann jedoch auf "Datei / Speichern unter", so landet die Webseite mitsamt der vollständigen FTP-URL auf der lokalen Festplatte. In der HTML-Datei findet sich dann eine Zeile der Art:



Lädt man diese Datei anschließend wieder per FTP auf den Server, so stehen in der HTML-Datei stets der Benutzername und das Passwort des Servers. Die Informationen sind, für normale Web-Surfer unsichtbar, im Quelltext der HTML-Seite eingebettet. Ein Blick in den Seiten-Quelltext zeigt aber die Daten an. Auch Webserver durch Skripte automatisiert nach FTP-Daten durchsuchen zu lassen ist denkbar.

In der Praxis erscheint das folgende Szenario durchaus als realistisch: Man hat auf dem heimischen FTP-Server, der nur als Zugriff auf die eigenen Arbeiten dient, eine HTML-Datei gespeichert, die beispielsweise eine selbst geschriebene Web-Anwendung enthält. Diese Datei öffnet man bei einem Bekannten oder einem Kunden per IE6, um sie auf Funktion zu prüfen, und speichert sie dann lokal. Unbesehen lädt man sie auf den Webserver des Kunden oder seines Freundes - und dort stehen dann die Zugangsdaten für den eigenen FTP-Server, bis jemand den Fehler bemerkt.

In der Redaktion von Golem.de ließ sich dieses Verhalten mit einem aktuell gepatchten IE6 unter Windows XP nachvollziehen. Das Problem tritt jedoch nicht auf, wenn man die Datei noch in der FTP-Ansicht nach einem Rechtsklick mit "In Ordner kopieren" auf die lokale Festplatte überträgt. Die Datei muss, damit die URL eingebettet wird, per Doppelklick geöffnet, und erst dann gespeichert werden. Der Effekt scheint also aufzutreten, wenn der IE6 von der FTP- zur Browser-Ansicht wechselt.

Auf die Sicherheitslücke wies zuerst Brian Krebs von der Washington Post in seinem Blog hin. Getreu dem Motto "It's not a bug, it's a feature" erklärte dem Kolumnisten der einflussreichen US-Tageszeitung gegenüber Microsoft, dieses Verhalten des Browsers sei durchaus so gewünscht. Der FTP-Zugang werde gespeichert, weil er Teil der URL der herunter geladenen Datei sei. Damit diese später in der selben Sicherheitszone des Browsers geöffnet würde, sei dies notwendig. Außerdem, so Microsoft weiter, sei der Internet Explorer nicht als vollwertiger FTP-Client gedacht, die Funktion sei nur "zur Bequemlichkeit" vorhanden.

Wie Brian Krebs berichtet, erhielt er am Rande der Sicherheitskonferenz "Def Con" einen Tipp zu der Lücke. Die Quelle des Journalisten hat Krebs zufolge bereits 2004 Microsoft auf das Problem hingewiesen. Damals erhielt der Mann die Antwort, man müsse den Browser komplett umschreiben, um das Verhalten abzustellen. Das Problem ist aber auch noch im Internet Explorer 7 zu finden. Offenbar besteht seitens Microsoft keine Absicht, dieses Verhalten des Browsers zu ändern, sodass man beim Speichern von HTML-Dokumenten via FTP gründlich aufpassen muss - und am besten gleich die eigenen Webseiten überprüft, wenn man den IE für FTP-Operationen benutzt hat. Auch das Sicherheitsunternehmen Secunia stuft in einem Bulletin das Verhalten des IE als "Schwachstelle" ein. (nie)

Quelle:
http://www.golem.de/0708/54113.html