Gastbeitrag hakin9: Cross-Site Authentication Angriffe

• Home
• Magazin
• Know How
• Virus, Malware & Spamschutz

Im Internet sind Diskussionsforen von jeher ein beliebter Austauschspunkt von Meinungen zu den verschiedensten Themen im Leben. Im Zuge der Ausbreitung von Web 2.0 Applikationen haben sich auch Weblogs (Kurzform: Blog) über die Jahre stark etabliert.

Vor allem die zuerst genannten Foren-Systeme (wie zum Beispiel YaBB, phpBB oder vBulletin) sind für Cross-Site Authentication Angriffe (XSA bzw. CSA) besonders interessant, da Blogs dem Besucher nur äußerst selten einen HTTP Auth Login-Dialog anbieten (wie zum Beispiel Serendipity mit einem zusätzlichem Plugin).

Doch was sind eigentlich Cross-Site Authentication Angriffe?

XSA gehört zur Rubrik der Phishing-Angriffe und wurde erstmals von Joachim Breitner, einem Student der Mathematik an der Universität Karlsruhe, öffentlich erwähnt [1]. Bislang haben XSA-Angriffe allerdings keine große Beachtung im Feld der IT-Sicherheit gefunden, obwohl sie sicherlich zu den trivialsten Phishing-Angriffen überhaupt zählen. Mit dem XSA-Angriff wird dem Benutzer eines Forums (seltener auch Weblog) ein Login-Dialog versucht unter zuschieben, um an dessen Benutzerdaten für das Forum zu gelangen. Möglicherweise lässt sich das so gewonnene Passwort in Kombination mit der obligatorisch anzugebenden E-Mail-Adresse (zu finden im Profil des Benutzers) für die Kaperung des E-Mail-Accounts benutzen.

Je nach verfassten Diskussionsbeiträgen des in die Falle gelaufenen Benutzers lassen sich evtl. auch weitere Rückschlüsse auf andere Benutzerkonten bei E-Mail-Providern, eBay, Amazon, etc. ziehen, so dass mit einer Portion Glück der Login in eBay mit dem ausgespähten Passwort funktioniert. Auch würden sich so E-Mails unbefugt lesen oder Spam verschicken lassen. Ein Verkauf der erlangten Datensätze (Anschrift, Telefon, etc.) ist ebenso denkbar.

Aber wie funktioniert der Angriff im Detail?

Der Angreifer meldet sich bei einem beliebigen Diskussionsforum an und erstellt einen Beitrag, in den er ein Bild einbindet. Wichtig ist hierbei, dass das Bild eingebunden wird und nicht nur per Link verlinkt wird.

Zudem muss sich das Bild auf einem Server befinden, den der Angreifer kontrolliert. Das Verzeichnis, in dem das Bild liegt, wird mittels der Konfigurationsdatei namens .htaccess [2] mit einem Passwortschutz (HTTP Auth) geschützt.

Beim Aufruf des Threads, welcher den speziellen Beitrag enthält, passiert folgendes (siehe auch Abbildung 1):

• Der Webbrowser schickt eine HTTP/1.1 GET Anfrage an den Webserver (Foren-System), um den gewünschten Thread als Quellcode geschickt zu bekommen;
• Der Webserver liefert das Dokument an den Client aus;
• Der Webbrowser führt seinerseits weitere HTTP/1.1 GET Anfragen aus, um den restlichen Inhalt der Seite zu erfassen (Bilder, Iframes, Skripte, CSS-Stylesheets, etc.) Darunter befindet sich auch die Anfrage nach dem Bild des Angreifers;
• Nun antwortet der Webserver des Angreifers mit HTTP/1.1 401 Autorization required, da das Verzeichnis geschützt ist und vor der Übertragung der Daten (das Bild) eine Authentifizierung erfordert;
• Der Webbrowser des Clienten öffnet nun einen Login-Dialog für die Eingabe eines Benutzernamen und Passwort. Jetzt kommt es darauf an, ob der Besucher der Webseite ein bereits registrierter Benutzer ist und seine Login-Daten (erneut) eingibt oder er die Eingabe verweigert. Sollte der Besucher seine Login-Daten eingeben und abschicken, kann der Webserver des Angreifers diese Daten abspeichern;
• Im letzten Schritt liefert der Webserver des Angreifers das eingebundene Bild an den Webbrowser aus, damit der Benutzer nicht durch etwaige Fehlermeldung vielleicht noch Verdacht schöpft.

Learning by Doing

Learning by Doing ist meistens die beste Lernmethode, aber wir können diesen Angriff nicht einfach in einem beliebigen Forum im Internet ausprobieren, da das Ausspähen von Daten in Deutschland gemäß dem Paragraph 202a StGB unter Strafe steht. Daher werden wir eine eigene Apache-MySQL-PHP-Umgebung (WAMP) unter dem Betriebssystem Windows XP von Microsoft installieren und anschließend ein Diskussionsforum aufsetzen und unsere nötigen Vorbereitungen aus Sicht des Angreifers treffen. Und dies alles lokal auf unserem eigenen PC.

Einrichtung der Umgebung XAMPP

Ich habe mich auf Grund seiner Einfachheit und guten Funktionalität für den Einsatz des XAMPP Pakets [3] und dem optional dazu erhältlichen Perl-Pakets für die Windows-Plattform entschieden.

Das XAMPP-Paket ist nicht für den Einsatz als Produktivsystem gedacht und ist unsicher, aber unsere Anforderungen erfüllt es voll und ganz. Bevor wir jedoch mit der Installation des XAMPP-Pakets beginnen, empfehle ich das Anlegen und Einrichten einer virtuellen Maschine (VM) mit einer Virtualisierungslösung von Microsoft, VMware oder einem anderen Anbieter. Nach dem Download des Installer-Pakets von XAMPP für Windows (momentan aktuelle Version 1.6.2 vom 29. Mai 2007) mit den Eckdaten:

• Apache HTTPD 2.2.4;
• MySQL 5.0.41;
• PHP 4.4.7 und 5.2.2;
• PHPMyAdmin 2.10.1.

brauchen wir noch das optional dazu erhältliche Perl-Paket 5.8.8 wegen des mod_perl Moduls 2.0.3, welches wir ebenfalls als Installer-Paket herunterladen.

Das Modul mod_perl brauchen wir für ein kleines Skript, welches wir uns noch schreiben müssen, da der Apache nicht die kompletten Login-Daten in den Logfiles speichert, so dass wir nur den Benutzernamen erfahren würden. Dazu später mehr.

Als Foren-System (englisch: Bulletin Board) habe ich mir phpBB in der Version 2.0.22 ausgesucht, welches unter [4] heruntergeladen werden kann. Zunächst installieren wir XAMPP für Windows in den Pfad, der uns standardmässig vorgeschlagen wird: c:\xampp. Wer den Pfad hier ändern möchte, muss diesen im folgenden Verlauf dieses Artikels substituieren. Bei der Frage nach der Dienst-Installation von Apache HTTPD und MySQL würde ich beide bejahen, da man sonst bei jedem Neustart gezwungen ist, die Dienste von Hand über das XAMPP Control Panel zu aktivieren. Als nächstes wird das Perl-Paket installiert.

Hiernach erstellen wir das Verzeichnis namens test unter dem Pfad c:\xampp\htdocs.

Im eben erstellten Verzeichnis erstellen wir nun eine Datei .htaccess, welche wir mit dem Inhalt aus Listing 1 füllen.

Wer Probleme mit dem Anlegen der Datei unter Windows hat, der kann die Eingabeaufforderung zur Erstellung der Datei benutzen. Der Befehl echo. > .htaccess erstellt die Datei. Jetzt kann man sie in einem beliebigen Text-Editor zum Editieren öffnen.

Im gleichen Verzeichnis können wir noch das einzubindende Bild platzieren. Dieser Schritt ist optional für unseren Test, da wir am Schluss der Demonstration der Lücke nicht zwingend das Bild sehen müssen. Aber aus Sicht des Angreifers ist es besser ein Bild, welches am besten noch zum Kontext des Threads passt, zu platzieren, damit kein (weiterer) Verdacht erregt wird. Als nächstes müssen wir das Perl-Skript aus Listing 2 an der richtigen Stelle im Dateisystem ablegen, damit es über mod_perl [5] geladen werden kann. Dazu legen wir die Datei UserPwLog.pm mit einem Editor unserer Wahl in dem Verzeichnis c:\xampp\perl\site\lib\Apache2 an. Jetzt empfiehlt sich ein Neustart des PCs beziehungsweise der VM. (Ein einfacher Restart des Apache-Servers führt ab und zu zu Problemen.)

Installation des Diskussionsforums

Wir entpacken den Inhalt des heruntergeladenen Archivs nach c:\xampp\htdocs, so dass wir über den Pfad c:\xampp\htdocs\phpbb2 unser Forum erreichen können. Nun öffnen wir einen beliebigen Webbrowser und laden in ihm die Adresse http://localhost/phpbb2. Sodann werden wir zur Installation des phpBB-Forums aufgefordert (siehe auch Abbildung 2).

Wir verwenden die folgenden Daten für die Installation von phpBB:

• Database Type: MySQL 4.x/5.x;
• Database Server Hostname: localhost;
• Your Database Name: test;
• Database Username: root;
• Administrator Username: admin;
• Administrator Password: admin.

Das Passwort-Feld für den Datenbank-Benutzer lassen wir frei, da der Benutzer root standardmässig kein Passwort gesetzt hat. Die Datenbank namens test existiert seit der Installation des XAMPP-Pakets für Windows automatisch und muss daher nicht vor der Installation noch mit phpMyAdmin angelegt werden. Nach der Installation von phpBB müssen noch die zwei Unterverzeichnisse install und contrib aus c:\xampp\htdocs\phpbb2 entfernt werden, da wir sonst von phpBB am Fortsetzen gehindert werden. Jetzt loggen wir uns als Benutzer admin ein und erstellen einen neuen Thread. Unser Beitrag wird mit dem Text

gefüllt.

Dies entspricht dem HTML-Tag "img src=“http://127.0.0.1/test/test.jpg“" und nennt sich BBcode [6], welcher für Foren-Systeme aus sicherheitstechnischen Erwägungen heraus entworfen wurde. Wie anfangs erwähnt, muss das Bild (hier test.jpg genannt) nicht im Verzeichnis test platziert werden, aber der Vollständigkeit halber ist es in diesem Artikel mit Bild gehalten.

Wenn wir unseren Beitrag aufrufen, bekommen wir den Login-Dialog (HTTP Auth) des verwendeten Webbrowsers zu sehen. In Abbildung 3 von Mozilla Firefox 2.0.0.4.

Wenn ein Forumsbenutzer nun das Detail der Adresse übersieht, welche aufzeigt, von woher die Anforderung des Login-Dialogs kommt, und seine Zugangsdaten eingibt, dann speichert unser Perl-Skript in der Datei c:\xampp\htdocs\test\log.txt Benutzername sowie das dazugehörige Passwort ab. Sofern der Benutzer nicht auf Abbrechen klickt wird das Bild test.jpg geladen und dargestellt. Anderenfalls bleibt das Laden des Bildes aus.

In Abbildung 5 ist der Login-Dialog des Webbrowsers Opera 9.21 dargestellt und in Abbildung 6 die Eingabemaske des Microsoft Internet Explorer 7.0.

Abwehrmaßnahmen

Leider sind die Möglichkeiten der Abwehrmaßnahmen deutlich beschränkt. Jeder Webbrowser zeigt an, woher die Aufforderung zur Eingabe von Benutzername und Passwort kommt. Wer hierauf achtet, läuft eigentlich nicht in eine Falle. (In unserem Beispiel ist der Hostname, localhost, natürlich gleich.)

Besonders wichtig ist hierbei aber die Tatsache, dass man die Domain genau überprüft, damit man nicht einem absichtlichen (und offensichtlichen) Schreibfehler unterliegt. Leider gibt es aber auch noch je nach verwendetem Browser weitere Möglichkeiten, um aus einem XSA-Angriff einen echten Phishing-Angriff zu machen, der nicht auf offensichtliche Schreibfehler setzt.

Browser haben auch mit Bugs im HTTP Auth Dialog zu kämpfen, wie zum Beispiel Opera und Internet Explorer 7. Der Opera-Browser in der aktuell neusten Version (Version 9.21) schneidet ab dem 34. Zeichen den Domainanmen ab und kennzeichnet dies mit ... am Ende der Zeile. Wer die drei Punkte am Ende übersieht, der kann Opfer eines Phishingangriffs werden. Der Internet Explorer 7 von Microsoft hat ebenfalls ein Problem mit der richtigen Darstellung des Domainnamens, sofern es ein IDN [7] ist.

Im Login-Dialog wird der Domainname nicht konvertiert und bleibt daher beispielsweise foo.âbcdéf.bar anstatt zu foo.xn--bcdf-9na9b.bar nach dem Nameprep- [8] und Punycode-Verfahren [9] umgewandelt zu werden. Somit lässt sich zum Beispiel microsoft.com auch mit einem kleinen, kyrillischen o registrieren, ohne dass dies dem Auge auffällt.

Hier hilft nur der Blick in die Statuszeile des Browsers während der Login-Dialog angezeigt wird, da hier die Domain entsprechend nach dem Nameprep- und Punycode-Verfahren dargestellt wird.

Die Statuszeile des IE 7 ist standardmässig aktiviert und lässt sich mittels einer Skriptsprache auch nicht mehr ausblenden. Umschreiben lässt sich der Inhalt der Statuszeile jedoch immer noch, was aber keine Auswirkung auf die Anzeige hat, da der Internet Explorer einen anderen Statuszeilen-Text bei der Anzeige eines HTTP Auth Login-Dialogs ignoriert. Auch der Browser aus dem Hause Apple, Safari, hat in der neusten Version Probleme mit dem HTTP Auth Dialog (Windows-Version). Jedoch muss man hier erwähnen, dass der Browser sich erst im Beta-Stadium befindet und diese Fehler bis zur Final hoffentlich behoben worden sind.

Auch ist es sehr unüblich, dass Diskussionsforen den Login per HTTP Auth abwickeln, so dass beim Erscheinen des Login-Dialogs generell die Alarmglocken läuten sollten und man daraufhin den Vorgang abbrechen sollte. Zudem sollte man noch den Webmaster der betroffenen Webseite darüber unterrichtet und gegebenenfalls noch die anwesenden Moderatoren, damit sich diese sofort um die Löschung beziehungsweise Editierung des Phishing-Beitrags kümmern können.

Wie man sieht, ist dies ein sehr trivial durchzuführender Angriff mit einem üblen Nachgeschmack, sofern man dem auftauchenden Dialog wenig Beachtung schenkt und seine Login-Daten leichtfertig eintippt. Je nach verwendetem Webbrowser ist die Darstellung der Adresse (Domainname oder IP-Adresse) besser oder schlechter gelöst worden. Wie immer gilt auch hier die Devise Vorsicht ist besser als Nachsicht. Gesundes Misstrauen gegenüber einem plötzlich auftauchenden HTTP Auth Login-Dialog ist also definitiv nicht verkehrt!

Im Internet

• www.joachim-breitner.de/blog/archives/...
• de.wikipedia.org/wiki/Htaccess
• www.apachefriends.org/de/xampp-windows.html
• www.phpbb.com
• perl.apache.org
• de.wikipedia.org/wiki/BBcode
• de.wikipedia.org/wiki/Internationalized_Domain_Name
• de.wikipedia.org/wiki/Nameprep
• de.wikipedia.org/wiki/Punycode
• de.wikipedia.org/wiki/Cascading_Style_Sheets

Anmerkung

Die in diesem Artikel verwendeten Domainnamen sind frei erfunden und dienen ausschließlich als Beispiel. Dank gebührt auch Eric Johanson, der mir für Testzwecke seinen IDN kurzfristig zur Verfügung gestellt hat.

Wissenswertes

XSA steht für Cross-Site Authentication. Statt dem X kann auch ein C am Anfang stehen. Dies resultiert aus der Verwechslungsgefahr bei XSS mit CSS (Cascading Style Sheets, [10]). Da Cascading Style Sheets in Verbindung mit XSS-Angriffen auch sehr gebräuchlich sind, sollte deshalb eine deutlichere Unterscheidung getroffen werden.

Die Schreibweise mit X hat sich auch bei allen anderen Cross-Site Angriffen eingebürgert, obwohl diese bislang keiner Verwechslungsgefahr mit anderen Abkürzungen im IT-Sektor unterliegen.

Kommentare

Bitte beachten Sie unsere Informationen zum Datenschutz.

blog comments powered by Disqus