Bei E-Mail ist sowieso alles fake

Die letzten Wochen waren für Apple in mehrfacher Hinsicht sehr hart: Neben dem Problem der passwortlosen Logins im macOS und den Problemen mit dem 13. Kalendermonat ist die Anzahl der Updates im iOS seit der Veröffentlichung von Release 11 immer noch sehr hoch.

Im Rahmen der Entdeckung der Behandlung der IDN-Domains im Browser Safari (CVE-2017-7106) und deren problematischer Darstellung ist vor allem auch der E-Mail-Client und die Darstellung der Kontakte eine zentrale Ursache dafür, dass diese Tricks funktionieren.

Denn zu einem erfolgreichen Phishing-Versuch gehört eine erfolgreiche Kontaktaufnahme. Die von mir verwendeten und beschriebenen IDN-Domains sind in der Regel für Spearphishing interessant, weniger für eine breite Streuung in der Masse. Und der prinzipiell erste Versuch unseren Awareness-Experten aufs Kreuz zu legen hat nur geklappt, weil ich wußte, er ist unterwegs und wird die Mail auf dem iPhone lesen.

Was hat Apple unternommen?

Nach unseren Bug-Reports hat Apple mit der Veröffentlichung von iOS 11 nur die Komponente WebKit im Safari, den aber auf allen Plattformen, im Umgang mit den betroffenen Zeichenklassen korrigiert.

Zur Erinnerung, um diese Zeichen und Domains geht es im Speziellen:

Bezüglich der Kontakte und E-Mail-Adressen schloss sich eine Diskussion an, in der es darum ging, was in einer Welt der E-Mails überhaupt vertrauenswürdig ist: fast nichts.

Und wie Apple die Anzeige im Mail-Client und in den Kontakten bisher behandelt hat, ist allerdings auf den ersten Blick gar nicht sichtbar.

Die Absender-Adresse einer E-Mail wird normalerweise in folgendem Format angegeben:

"Name zur Anzeige" <Vorname.name@to.com>

Das E-Mail-Programm im iOS zeigt in der E-Mail-Anzeige üblicherweise nur den Anzeigenamen an, die E-Mail-Adresse ist an dieser Stelle egal. Mit dieser Art der Darstellung sind sie nicht alleine. So kann man schon mal in einer sehr einfachen Art und Weise eine andere Identität vortäuschen. Teilweise helfen Siri und die interne Suche sogar, die vermeintlich neue, aber in Wirklichkeit gefälschte Adresse, dem echten Kontakt hinzuzufügen in dem sie genau das vorschlagen. Bei solchen Vorschlägen sollte man aufmerksam werden, denn bestehende Kontakte mit neuer Adresse sind seltsam.

Wir wollen uns aber mit den Adressen selbst beschäftigen, denn auch hier wird oft vernachlässigt, was im Browser in der Adresszeile mittlerweile umgesetzt ist: eigentlich gibt es keinen Grund, warum sich die Domain-Darstellung in E-Mail-Programmen von der Adressezeile im Browser unterscheiden sollte:

Denn für alle meine to, live und gmx-Adressen muss die Anzeige im xn-Format erfolgen, um dem Benutzer die Chance zu geben, die Domains zu unterscheiden. Hier die Beispiele in den Darstellungen der echten xn—t26l.com Domain in iOS 11.1.2 und ios 11.2:

Die xn-Domains, mit denen wir testen, sind im Hintergrund komplett valide aufgesetzt: Es gibt Zertifikate, es gibt gültige SPF-Records, der Mail-Server hat eine gute Reputation und ist auf keiner Blacklist enthalten. Und damit gibt es auf technischer Ebene der Mail-Server keine Möglichkeit, diese E-Mails auf formaler Ebene auszuschließen. Außer man entscheidet auf organisatorischer Ebene, dass keine geschäftliche Kommunikation mit Partnern exitiert, die IDN-Domains im E-Mail-Verkehr benutzen, und dass alle xn-Domains in einer Quarantäne landen und nur nach manueller Prüfung freigegeben werden. Bei TO ist es außerhalb unserer IDN-Forschungen noch nicht vorgekommen, dass gültige E-Mails mit IDN-Domain in der Quarantäne gelandet sind.

Fazit

Wer eine solche Infrastruktur nicht hat, dem ist mit iOS 11.2 jetzt zumindest die Möglichkeit gegeben, solche Absender zu erkennen. Und die Regeln scheinen die gleichen wie im Browser Safari zu sein: normale deutsche Umlaute werden weiterhin in der “schönen” Anzeige als Umlaute angezeigt, nur die Hochrisiko-Zeichen werden in der xn-Notation dargestellt.

In den offizielle Releasenotes zu iOS 11.2 ist zu diesem Thema nichts vermerkt, allerdings sind die Screenshots eindeutig.