Einfaches Passwort-Phishing durch eingebettete Bilder: Cross-Site-Authentication-Attacken

Phishing-E-Mails scheinen von einer Bank oder von E-Bay zu kommen und fordern den Empfänger dazu auf, seine Zugangsdaten in eine gefälschte Login-Seite zu tippen. Darüber definiert sich Phishing: Benutzerdaten durch Täuschung ausspionieren. Das klappt auch mit Cross-Site-Skripting (XSS), dieser Angriff platziert aktiven Code auf einer fremden Seite. Der Browser führt den Code gutgläubig aus und sendet die Login-Daten an den Angreifer (siehe auch den Artikel zum sicheren Programmieren für Admins in diesem Heft).

Schotten dicht?

Um XSS zu verhindern, entfernen viele Webanwendungen aktive Inhalte aus allen Eingaben, die sie später einem Benutzer präsentieren - etwa aus Forumseinträgen, Auktionsbeschreibungen oder E-Mails. Oft akzeptieren sie aber reinen, als ungefährlich angesehenen HTML-Code. Insbesondere gestatten es viele Webanwendungen, Bilder per »<img>«-Tag einzubetten. Hier setzt die XSA-Attacke an (Cross Site Authentication). Der Angreifer muss lediglich einen beliebigen Server kontrollieren, auf dem er das Bild und etwas zusätzlichen Code ablegt. In den angegriffene Dienst fügt er das unverfängliche HTML-Tag »<img src="http://Angreifer/bild.png">« ein (Abbildung 1).

Das Bild liegt in einem per HTTP AUTH geschützten Bereich des Angreifer-Servers (Listing 1). Der verlangt vom Browser einen Benutzernamen und ein Passwort, bevor er die Datei ausliefert. Optional liefert er einen beschreibenden Text mit, den der Browser anzeigt, während er den Benutzer zur Passworteingabe auffordert. Im Normalfall vergleicht der Server dann die (unverschlüsselt) übermittelten Zugangsdaten mit den Einträgen seiner Benutzerdatenbank und gewährt oder verweigert den Zugriff. Bei einer XSA-Attacke speichert der Server die Daten jedoch und gestattet, um kein Misstrauen zu erwecken, den Zugriff in jedem Fall. Das ist mit ein paar Zeilen Perl-Code und Apaches Mod_perl schnell implementiert (Listing 2).

Für den Anwender ist dies kaum erkennbar: Er sieht in der Adressleiste seine Webanwendung und eventuell die teilweise aufgebaute Webseite. Dass die Passwortabfrage nicht auch von dieser Seite stammt, bemerkt er nur bei sehr genauem Hinsehen - ein argloser oder eiliger User wird wie gewohnt seine Daten eintippen und weiterarbeiten. Das Eingabefenster ist in keiner Weise gefälscht, es ist Teil des Browsers und passt daher zum Look&Feel des Systems.

Betroffen sind alle Webanwendungen, die fremdes HTML ausliefern oder auf fremden Servern gespeicherte Bilder einbetten, etwa Webforen, Webmail, Auktionshäuser, Wikis und Ähnliches. Verlangt die Anwendung selbst HTTP-Authentifizierung, stehen die Chancen für den Angreifer am besten. Wenn er Glück hat, verwechselt der Anwender den Dialog sogar mit einem lokalen Login und tippt seine Linux-Benutzerkennung ein.

Bildersturm

Eine vor XSA geschützte Webanwendung darf in den eigenen Seiten auf keine fremde Bilder verweisen. Im einfachsten Fall meidet sie fremde Bilder und fremden HTML-Code. Wo das nicht möglich ist, könnte der Anbieter die Bilder auf den eigenen Server kopieren. Das hat jedoch rechtliche Folgen und gestattet Crackern zudem das Ressourcen-schonende Verteilen raubkopierter Dateien. Auch ist es technisch nicht trivial, fremden HTML-Code auf Bilder zu überprüfen und passend zu ändern.

Eine Variante wäre, die Verknüpfungen auf fremde Bilder so umzuschreiben, dass die Anfrage an den eigenen Server geht und dieser als Proxy agiert. Beides ist bei kleinen Anwendungen wie privaten Webforen problematisch, wenn dadurch die zu bezahlenden Datenmengen übermäßig steigen.

Abbildung 1: Dass der Browser mit mehreren Servern spricht, bleibt vielen Anwendern verborgen. Das nutzt der XSA-Angriff und verlangt eine Authentifizierung für ein extern eingebundenes Bild. Username und Passwort gehen zum zweiten Server.

Sinnvoller ist es, die Webbrowser anzupassen. Sie lassen bisher recht unterschiedlich erkennen, dass der Benutzer sich auf digitalen Abwegen befindet. Zwar zeigen alle Browser neben der vom Server frei wählbaren und damit gefährlichen Beschreibung auch den Servernamen, allerdings verstecken sie die Information teils sehr gut.

Am schlechtesten schneidet der Internet Explorer ab (Abbildung 2a): Der Domainname steht praktisch unbeachtet in der Titelleiste des Dialogs. Wenig besser bei Mozilla (Abbildung 2b), Firefox und Galeon, die den Domainnamen auf eine Zeile hinter der Beschreibung setzen. Bevor Benutzer aber so weit lesen, haben die meisten bereits in die Tasten gegriffen und ihre Daten abgeschickt. Zudem kann der Beschreibungstext sie gezielt in die Irre führen.

Abbildung 2a: Beim Internet Explorer ist der Angriff kaum erkennbar. Nur die Titelleiste nennt den Server.

Abbildung 2b: Mozilla (und seine Abkömmlinge) machen es kaum besser. Wer in Eile ist, übersieht den Domainnamen am Ende des Erklärungstextes leicht.