Dipl.-Inform. Carsten Eilers

Unicode unterstützt alle Sprachen - egal ob sie von links nach rechts oder von rechts nach links geschrieben werden. Dementsprechend muss es möglich sein, ggf. die Schreibrichtung umzukehren. Um von der üblichen Schreibrichtung "von links nach rechts" auf die in Sprachen wie Arabisch oder Hebräisch verwendete Schreibrichtung "von rechts nach links" umzuschalten, wird das Unicode-Kontrollzeichen "RIGHT TO LEFT OVERRIDE" (RLO, U+202E) verwendet.

Nun ist es eigentlich ziemlich dumm, mitten im Text die Schreibrichtung zu ändern, wenn man nicht auch die Sprache wechselt. I.A. macht das also niemand. Es sei denn, er möchte sich einen Spass erlauben oder die Funktion des RLO demonstrieren. So wie ich jetzt:

Dieser Block ist anfangs von links nach rechts geschrieben, dann kommt das RLO-Zeichen ‮ und dann geht es von rechts nach links weiter.

Das Beispiel funktioniert natürlich nur, wenn Ihr Browser Unicode unterstützt. Nach "RLO-Zeichen" lesen Sie dann dort ".retiew sknil hcan sthcer nov se theg nnad dun" (oder so ähnlich, der Zeilenumbruch sorgt dafür, dass der "." am Anfang der zweiten Zeile landet). Ohne Unicode geht der Satz einfach mit "und dann geht es von rechts nach links weiter." weiter.

Wenn Ihr Browser Unicode unterstützt, können Sie auch die späteren Beispiele "live" erleben, ansonsten müssen Sie mir entweder glauben, dass die Behauptungen stimmen, oder einen Browser verwenden, der Unicode unterstützt, z.B. Mozillas Firefox.

Bis jetzt war das alles nur Spass, nun wird es ernst.

RLO in Dateinamen

Die Cyberkriminellen haben schon vor einiger Zeit gemerkt, dass sich das RLO-Zeichen missbrauchen lässt, um z.B. Dateinamen zu tarnen. Das ist z.B. nützlich, wenn dem potentiellen Opfer per E-Mail eine .exe-Datei untergeschoben werden soll. Öffnet der Mail-Empfänger die getarnte Datei, wird das sich tatsächlich dahinter verbergende Programm ausgeführt. Das ist doch viel praktischer, als über eine präparierte Datei eine Schwachstelle in irgend einer Anwendung auszunutzen: Der RLO-Trick funktioniert immer, ein Exploit für eine Schwachstelle nur, wenn die präparierte Datei mit einer von der Schwachstelle betroffenen Version der Anwendung geöffnet wird.

Aber kommen wir zum "praktischen Teil", der Vorführung des RLO-Tricks. Konkret wurden z.B. die folgenden Dateinamen eingesetzt:

Costing Cap[U+202E]slx.exe

und

Calenda[U+202E]cod.scr

Das RLO-Kontrollzeichen sorgt dafür, dass die jeweils darauf folgenden Zeichen in umgekehrte Reihenfolge ausgegeben werden: Aus slx.exe wird exe.xls und aus cod.scr wird rcs.doc. Das sind doch ganz eindeutig eine Excel- und eine Word-Datei, oder?

Insgesamt werden die Dateinamen zu

Costing Cap‮slx.exe

und

Calenda‮cod.scr

Wer würde diesen Dateien schon misstrauen? Noch dazu, wenn die E-Mail, in der sie ankommen, entsprechend formuliert ist?

Im Gegensatz zum Benutzer lässt sich Windows vom RLO-Trick nicht beeindrucken und erkennt eine ausführbare .exe- bzw. .scr-Datei, die daher beim Aufruf auch ausgeführt werden.

Das ganze geht natürlich auch noch kürzer. Vor dem RLO-Zeichen muss gar nichts stehen - was halten Sie z.B. von der Datei mit dem Namen ‮?txt.exe

Sie denken, das ist eine harmlose Textdatei? Leider nicht, denn vor dem exe.txt steht ein RLO-Zeichen. Mit anderen Worten: Eigentlich heißt die Datei gar nicht exe.txt, sondern [U+202E]txt.exe und ist eine waschechte Programmdatei. Was Windows auch wieder ganz korrekt erkennt.

RLO in Archiven

Einen Schritt weiter gehen die aktuellen Angriffe: Bei denen steckt die ausführbare Datei samt RLO-Trick im Dateinamen in einem ZIP-Archiv. Das enthält (scheinbar) eine Datei mit dem Namen
CORP_INVOICE_08.14.2011_Pr.phylexe.doc,
und wahrscheinlich haben Sie schon erraten, wo darin das RLO-Zeichen steckt, oder? Richtig, vor dem exe.doc! Tatsächlich hat die Datei den Namen

CORP_INVOICE_08.14.2011_Pr.phyl[U+202E]cod.exe

oder als Demo

CORP_INVOICE_08.14.2011_Pr.phyl‮cod.exe

Und wie schon oben gilt: Wer seinen Augen traut und die .doc-Datei mit einem Doppelklick öffnet, wird zum Opfer der Cyberkriminellen.

Ein zusätzlicher Hinweis: Auch dem Icon einer Datei darf man nicht vertrauen, das kann vom Angreifer ebenfalls manipuliert werden. So wird der Angreifer beim Einsatz des RLO-Tricks in einem Dateinamen natürlich dafür sorgen, dass die Datei ein zum vorgetäuschten Typ passendes Icon zeigt. Lediglich die Type-Anzeige des Windows Explorers und der Archivprogramme (sofern sie ihn den anzeigen) lässt sich nicht beeinflussen. So eine Manipulation wäre sowieso nicht im Interesse des Angreifers: Wenn Windows die Datei für z.B. eine .doc-Datei hielte, würde es das Programm ja nicht starten.

Was die "Bug oder Feature"-Frage betrifft: In Unicode ist RLO ein gewolltes Feature, aber muss ein Dateiname wirklich Steuerzeichen enthalten? Ist das nicht doch eher ein Bug als ein Feature?

Aber nicht nur Dateinamen lassen sich mit dem RLO-Trick tarnen:

RLO in E-Mail-Adressen

Die Überschrift ist natürlich de Facto falsch: Die Zeichen, die in einer E-Mail-Adresse vorkommen dürfen, sind genau festgelegt, und der aktuelle Standard RFC 5322 sieht kein RLO-Steuerzeichen darin vor. Aber es gibt ja noch den "Display Name", der i.A. den Realnamen des Empfängers enthält. Und darin kann ein RLO-Zeichen durchaus vorkommen.

Nehmen wir mal an, Sie bekommen eine E-Mail, in der ein Mitarbeiter eines Geschäftspartners einige wichtige Dateien anfordert. Sie klicken auf "Antworten", schreiben ein "Hier kommen die Files!" in die erzeugte Antwort-Mail und hängen die Dateien an. Dann werden sie misstrauisch - ist die E-Mail wirklich von einem Mitarbeiter des Geschäftspartners? Absender-Adressen kann man schließlich beliebig fälschen. Sicherheitshalber sehen sie nach, an wen die E-Mail denn gesendet wird:
"Max Mustermann <elpmaxe.refiergna@partner.example>"

Na, dann ist ja alles klar, die E-Mail geht an die Domain partner.example, dann wird schon alles seine Richtigkeit haben. Und schon geht die Mail auf die Reise - an elpmaxe.rentrap@angreifer.example, denn zwischen Realname und E-Mail-Adresse steht ein RLO-Zeichen:

Max Mustermann [U+202E] <elpmaxe.rentrap@angreifer.example>

bzw.

Max Mustermann ‮ <elpmaxe.rentrap@angreifer.example>

Einige E-Mail-Clients und -Anbieter haben auf diese Bedrohung reagiert und Gegenmaßnahmen entwickelt, andere sind über den RLO-Trick angreifbar.

Die Cyberkriminellen können keine beliebigen E-Mail-Adressen vortäuschen, da ihre Domain ja als angeblicher Local-Part erhalten bleibt. Lediglich den angeblichen Domain-Part können sie frei wählen. Sie müssen nur dafür sorgen, dass E-Mails an den entsprechenden Benutzer ihrer Domain zugestellt werden können. Und dafür kann man ja einen Catch-All-Account einrichten, der alle E-Mails entgegen nimmt, für die kein spezieller Account zuständig ist.

RLO in Links

Auch ein Link lässt sich mit dem RLO-Trick verfälschen: Führt der folgende Link Sie wirklich zu Google - oder etwa nach Bing?

‮http://www.bing.com/search?q=google+gnib=q?/moc.elgoog.www//:ptth

Zum Glück lässt sich die Statuszeile nicht täuschen. Aber da könnte man ja mit JavaScript eine schöne Laufschrift einblenden (wenn ich den erwische, der den Blödsinn mal erfunden hat...).

Weitere Unicode-Tricks

Domainnamen, die kyrillische Zeichen an Stelle ähnlich aussehender englischer Zeichen enthalten, sind ein alter Trick der Phisher und Spammer. Aber auch in Dateinamen lässt sich damit Schaden anrichten - wenn es z.B. im Verzeichnis %SystemRoot%\system32\drivers\etc außer der Datei hosts noch eine zweite Datei hosts gibt.

Nun ist es natürlich unmöglich, dass in einem Verzeichnis zwei Dateien mit gleichem Namen gespeichert sind. Des Rätsels Lösung: Das "o" im zweiten Dateinamen ist gar kein "o", sondern ein Unicode-Zeichen: [U+006F] - und das entspricht einem dem kleinen "o" sehr ähnlichem kyrillischen Zeichen. Vergleichen Sie selbst: oooooo - Oje... Ach ja: Das jeweils zweite Zeichen ist das kyrillische.

Mit dem gleichen Trick kann man auch z.B. Oracle aus Googles Such-Index verschwinden lassen. Suchten Sie oracle oder oracle?

Sie sehen also: Sie sollten Ihren Augen nicht unbedingt trauen. Manches sieht in Wirklichkeit ganz anders aus, als es auf den ersten Blick scheint. Trauen dürfen sie aber der folgenden Ankündigung: In der nächsten Folge geht es um einen neuen Angriff auf eine altbekannte Schwachstelle in SSL und TLS 1.0.

Carsten Eilers