IDN-Sicherheitslücke in fast allen Browsern

In allen bekannten Web-Browsern außer dem Internet Explorer, der internationale Domain-Namen schlicht nicht unterstützt, wurde eine Sicherheitslücke gefunden, die es erlaubt in der Adresszeile eine andere Domain auszugeben als die tatsächlich angezeigte. Der ganze Trick besteht darin, Zeichen zu kodieren, die eigentlich nicht kodiert werden müssten.

Das Kodierungsverfahren Punycode legt fest, wie man „Zeichenketten mit einem großen Zeichensatz in eine Zeichenkette mit einem kleineren Zeichensatz“ umwandeln kann. Da die zahlreichen in seit März 2004 auch in bei der deutschen Top-Level-Domain .de verfügbaren internationalen Domain-Namen vorkommenden Zeichen nicht mit Hilfe des ASCII-Zeichensatz mit 128 Zeichen dargestellt werden können, werden diese im Unicode-Standard definierten Zeichen durch Punycode kodiert. Wie die englischsprachige Wikipedia als Beispiel anführt, wird die Zeichenkette „bücher.ch“ kodiert in „bcher-kva.ch“, woraufhin ihr noch das Prefix „xn--“ zur einfacheren Erkennung vorangestellt wird und somit die dann vom Browser letztendlich bei der Eingabe von „bücher.ch“ angeforderte Domain „xn--bcher-kva.ch“ lautet.

Nun ist es aber nunmal auch möglich diejenigen Zeichen mit Punycode zu kodieren, die im ASCII-Zeichensatz enthalten sind und bei denen dies rein technisch betrachtet eigentlich gar nicht notwendig wäre. So kann man z.B. das „a“ in der Domain „paypal.com“ mit Punycode in „xn--pypal-4ve.com“ kodieren, woraufhin der Browser, und darin liegt der Knackpunkt, die Anfrage zwar an die Domain „xn--pypal-4ve.com“ sendet, unter anderem in der Adresszeile jedoch die dekodierte Domain „paypal.com“ anzeigt!

Betroffen von dieser Sicherheitslücke sind alle namhaften Browser mit Ausnahme des eingangs erwähnten Internet Explorer, der nur durch Plugins überhaupt Fit für „Umlaut-Domains“ gemacht werden kann. Ob diese Plugins ebenfalls betroffen sind, ist derzeit noch unklar, man sollte jedoch angesichts der Tatsache, dass mindestens drei unabhängig entwickelte Implementierungen verwundbar sind, davon ausgehen.

In dem Advisory wird interessanterweise auch aufgeführt, wie die Browser-Hersteller, die bereits am 19. Januar angeschrieben wurden, auf die Hinweise reagiert haben. So hat Apple anscheinend gar nicht reagiert, und Opera hält die eigene IDN-Implementierung für sicher - vom Gegenteil kann sich jeder Opera-Anwender direkt anhand des Demo-Exploits überzeugen. Die Mozilla-Entwickler hingegen scheinen die Sache nicht ganz auf die leichte Schulter zu nehmen und arbeiten momentan angeblich daran, eine auf lange Zeit hinaus sichere Lösung zu finden und weisen darauf hin, dass man IDN-Unterstützung in den Einstellungen deaktivieren könne. Zwar ist eine Version 1.0.1 von Firefox geplant, jedoch gibt es zum jetzigen Zeitpunkt noch keine Hinweise dahingehend, ob diese eventuell wegen der nun öffentlichen IDN-Sicherheitslücke vorgezogen wird. Als Workaround könnte geprüft werden, ob ein dekodiertes Zeichen tatsächlich nicht im ASCII-Zeichensatz vorhanden ist.

Kurioserweise zeigt das Deaktivieren der Einstellung „network.enableIDN“ (Dazu einfach in die Adresszeile „about:config“ eingeben, in der erscheinenden Liste die genannte Einstellung suchen und per Doppelklick deren Wert auf „false“ ändern) in unseren Tests nur so lange Wirkung, wie man den Browser nicht schließt. Aufgrund eines Bugs in Mozilla/Firefox wird diese Einstellung nämlich bei jedem Start des Browsers wieder zurück auf „true“ gesetzt, obwohl sie in den Einstellungen weiterhin als deaktiviert gekennzeichnet ist!

Folge dieser Entdeckung könnte eine Zunahme an Phising-Versuchen sein. Dabei wird versucht den Anwender zur Eingabe sensibler Daten auf einer gefälschten Website zu bewegen, wobei die in der Adresszeile des Browsers angezeigte Domain bei Verwendung von aktuellen Browser-Versionen bisher als sicheres Erkennungsmerkmal offizieller Websites gelten konnte. Der bereits weiter oben verlinkte Demo-Exploit veranschaulicht das Ausmaß dieser Sicherheitslücke.