Fire Spoofing – als Firefox-Dialoge noch täuschbar waren

Der Begriff Firespoofing taucht heute nur noch selten auf. Meist findet man ihn in alten Forenbeiträgen, Bugtrackern oder in Backlinks früher IT-Security-Seiten. Dahinter steckt eine Sicherheitslücke aus den Jahren 2004/2005, die zeigt, wie anders Browser damals aufgebaut waren und wie stark sich Websicherheit seitdem verändert hat.

Firespoofing war eine Sicherheitslücke in frühen Firefox-Versionen. Dabei konnten Webseiten echte Sicherheits- oder Download-Fenster so überdecken, dass sie für Nutzer anders aussahen, als sie wirklich waren. Technisch wurde nichts verändert, aber der Bildschirm wurde so geschickt „überlagert“, dass viele Menschen nicht merkten, dass sie gerade einem echten Sicherheitsdialog zustimmten.

Was genau war Fire Spoofing?

Im Kern handelte es sich um einen Angriff auf die Benutzeroberfläche. Browser-Dialoge waren damals noch Teil derselben grafischen Ebene wie normale Webseitenfenster. JavaScript durfte neue Fenster ohne Rahmen öffnen und frei auf dem Bildschirm positionieren.

Ein Angreifer konnte dadurch:

Der Entdecker der Lücke, Michael Krax aka mikx, beschrieb das 2005 so:

Using javascript it is possible to spoof the content of security and download dialogs by partly covering them with a popup window.

Mit JavaScript ist es möglich, den Inhalt von Sicherheits- und Download-Dialogen zu verfälschen, indem man sie teilweise mit einem Popup-Fenster überdeckt.

Damit wurde erstmals klar dokumentiert, dass nicht der Dialog selbst verändert wurde, sondern dessen Wahrnehmung beim Nutzer.

Wie der Angriff praktisch funktionierte

Die Angriffsmethode war technisch simpel, aber wirkungsvoll.

Eine Webseite öffnete gezielt ein kleines, rahmenloses Popup-Fenster exakt über den sensiblen Bereich eines echten Firefox-Dialogs, zum Beispiel über den „Öffnen“- oder „OK“-Button. Der Nutzer glaubte, einer harmlosen Aktion zuzustimmen, klickte tatsächlich aber den echten Button darunter an.

Da viele Dateitypen unter Windows XP automatisch ausgeführt wurden, konnte dies im schlimmsten Fall direkt zum Start einer Schadsoftware führen.

Welche Systeme waren betroffen?

Besonders problematisch war zudem eine damals verfügbare Sonderfunktion namens codebase principals, die lokalen Dateizugriff erlaubte und von einigen XUL-Webseiten (XML User Interface Language) empfohlen wurde.

Dokumentiert wurden unter anderem:

• Firefox 1.0 (Preview und Release)
• Mozilla Suite 1.7.x
• Netscape 7.x
• Windows XP

Andere Betriebssysteme spielten kaum eine Rolle, da die meisten Exploits auf das Windows-Dialogverhalten abzielten.

Warum die Lücke als kritisch galt

Schon kurz nach ihrer Entdeckung wurde klar, dass Firespoofing kein theoretisches Problem war. Der Angriff ließ sich zuverlässig reproduzieren und nutzte ausschließlich Funktionen, die in Firefox standardmäßig vorhanden waren.

Besonders problematisch war, dass Nutzer den Betrug praktisch nicht erkennen konnten. Die manipulierten Dialoge wirkten echt, trugen das gewohnte Browser-Design und erschienen in einer Situation, in der viele Menschen ohnehin mit Sicherheitsabfragen rechneten.

Der Entdecker der Lücke, mikx, ging zunächst davon aus, dass das Problem noch vor der finalen Veröffentlichung von Firefox 1.0 behoben würde. Später schrieb er jedoch:

At that time I expected the issue to be fixed with the final Firefox 1.0 release … but more than 3 months after reporting the bug is still unfixed.

Damals ging ich davon aus, dass das Problem bis zur finalen Veröffentlichung von Firefox 1.0 behoben sein würde – doch mehr als drei Monate nach der Meldung war die Sicherheitslücke immer noch nicht geschlossen.

Aus heutiger Sicht wirkt der Angriff vergleichsweise einfach. 2005 war er jedoch realistisch, zuverlässig reproduzierbar und für Nutzer kaum erkennbar.

Warum Firespoofing heute kein praktisches Risiko mehr ist

Dass Firespoofing heute keine Rolle mehr spielt, liegt nicht an einem einzelnen Patch, sondern an einem grundlegenden Wandel im Sicherheitsdesign moderner Browser.

In den frühen 2000er-Jahren wurden Webseiten, Browseroberfläche und Sicherheitsdialoge noch weitgehend innerhalb derselben grafischen Umgebung dargestellt. Fenster konnten frei positioniert, überlagert und optisch manipuliert werden. Genau das machte Firespoofing möglich.

Der ursprüngliche Angriff basierte darauf, dass Dialoge nicht zuverlässig geschützt waren:

Modal dialogs should always be on top and it should not be possible to obfuscate their appearance.

Modale Dialoge sollten immer im Vordergrund liegen und es sollte nicht möglich sein, ihr Erscheinungsbild zu verschleiern.

Dieses Prinzip ist heute fest in der Architektur aller großen Browser verankert.

Strikte Trennung von Webseite und Browser-Oberfläche

Moderne Browser trennen technisch sauber zwischen:

Webseiten laufen in isolierten Prozessen und haben keinerlei Kontrolle mehr über Position, Darstellung oder Fokus von Sicherheitsabfragen.

Native Systemdialoge statt Browserfenster

Während frühe Firefox-Versionen ihre Dialoge selbst zeichneten, werden heute in sicherheitsrelevanten Situationen native Betriebssystem-Dialoge oder technisch gleichwertige geschützte UI-Schichten verwendet.

Diese liegen immer im Vordergrund, lassen sich nicht überdecken und ignorieren vollständig CSS oder JavaScript.

Entfernte Risikofunktionen

Zusätzlich wurden Funktionen abgeschafft, die den Schaden früher massiv vergrößerten:

• codebase principals
• automatisches Ausführen bestimmter Dateitypen
• ungeschützte Downloadmechanismen

Der ursprüngliche Proof of Concept zielte genau auf diese Kombination ab:

This can fool a user to download and automatically execute a file … or to grant a script local data access.

Dadurch konnte ein Nutzer dazu gebracht werden, eine Datei herunterzuladen und automatisch auszuführen oder einem Skript lokalen Datenzugriff zu erlauben.

Beides ist heute in dieser Form nicht mehr möglich.

Weitere Schutzmechanismen

Hinzu kommen:

Firespoofing wurde damit nicht nur behoben, sondern architektonisch unmöglich gemacht.

Welche Gefahren bestehen heute trotzdem noch?

Auch wenn Firespoofing technisch nicht mehr möglich ist, ist die Täuschung von Nutzern über die Benutzeroberfläche weiterhin ein zentrales Sicherheitsproblem.

Heute geschieht dies vor allem durch:

• gefälschte Login-Seiten (Phishing)
• manipulierte Download-Buttons
• irreführende Browser-Benachrichtigungen
• versteckte oder überlagerte Klickflächen (Clickjacking)
• gezieltes Social Engineering

Die Methoden haben sich geändert – das Ziel ist gleich geblieben: Nutzer zu riskanten Aktionen zu verleiten.