Vor noch relativ kurzer Zeit hat Google begonnen, die Registrierung mit den neuen Top-Level-Domänen .zip und .mov zu erlauben. Schon immer war bei den Top-Level-Domänen die Verwechslung von TLD und Dateiendung ein Thema. Und es gab auch darauf basierende Angriffe.

Wie kann das genutzt werden?

Wie URL-Spoofing genauer funktioniert erklärt dieser Artikel ganz gut, wie ich finde.

In kurz geht das darum, dass ein Nutzer einen Link anklickt, der durch die Ausnutzung von Homographen so aussieht, als würde der Nutzer von einer Domain ein Zip-Archiv herunterladen. Tatsächlich wird er jedoch auf eine Domain geleitet, die so heißt, wie der vermeintliche Download. Das kann z.B. genutzt werden, um eine Authentifizierung zu verlangen oder einen tatsächlich schädlichen Download unterzujubeln.

Hier ist wieder einmal wichtig, Anwendern beizubringen, dass sie sich vor dem Klick auf einen Link genau ansehen, was das Ziel des Links tatsächlich ist.

Die Punycode-Darstellung die auch von manchen Browsern vorgenommen wird, könnte ebenfalls helfen, wenn man die Adresszeile auch nach dem Klick noch im Auge hat. Der folgende Screenshot zeigt, wie die URL auch in der Browser-Adresszeile bei einigen Browsern aussehen würde.

Auch treten einige Browser an dieser Stelle erst einmal auf die Bremse und fragen nach, ob der Nutzer jetzt wirklich vorhatte, sich auf diesem Host anzumelden. Auch das könnte Anwender alarmieren und aufhalten. Aber der geneigte Leser weiß sicher auch, dass es Anwender gibt, die einfach jeden Klick tun, um an "ihr" Dokument zu kommen. Allerdings würde diese Meldung auch nur auftreten, wenn tatsächlich keine Authentifizierung erforderlich ist, was wiederum von jedem Angreifer implementiert würde.

Vielfältige Empfehlungen laufen außerdem darauf hinaus, schlicht die genannten TLDs in Firewalls und Proxies zu sperren. Ich weiß nicht, ob das nicht vielleicht etwas zu restriktiv ist. Die Zeit wird es vermutlich zeigen.

In normalen Texten von z.B. E-Mails können auch Dateinamen Erwähnung finden.

Verschiedene Benutzeroberflächen, wie zum Beispiel auch der Notes Client, erkennen aber auch URLs in Texten und ersetzen sie automatisch durch klickbare Links. In Notes muss dafür ein Schema (http://) oder wenigstens "www." im Text enthalten sein, so dass "archiv.zip" nicht automatisch zu einem Link wird. Das kann bei anderen Anwendungen bzw. Rich-Text-Editoren grundsätzlich anders aussehen.

Interessant ist es aber in der umgekehrten Richtung, denn auch wenn ich selber darauf achte, dass keine Links in meinen E-Mails sind bzw. aus meinen Dateinamen keine Links werden, habe ich keine Kontrolle darüber, was daraus auf der anderen Seite wird. Denn auch bei eingehenden E-Mails oder anderen Texten, die im Browser dargestellt werden (Twitter) werden Texte nachträglich "linkifiziert". Das funktioniert teilweise auch für Texte mit dem Aufbau "domainname.tld". Eine Testmail mit dem Inhalt:

an meinen google-Account hatte zur Folge, dass "assono.de" (ohne "www" oder Schema) als Link dargestellt wird. Die anderen beiden (noch?) nicht. Offenbar funktioniert die Erkennung über eine Liste von Top Level Domains, in die .zip & .mov eventuell noch nicht aufgenommen wurde.

Das konnte ich bei hotmail (Microsoft) bzw. Exchange/Outlook/OWA nicht beobachten. Da allerdings bei der Linkifizierung nicht der Mail-Inhalt verändert wird, sondern sie eine Funktion des "Readers"/der Benutzeroberfläche ist, kann dieses Feature zu jeder Zeit nachgereicht werden. Auch jahrealte Mails oder Tweets könnten (bei Twitter indikativ) dementsprechend "plötzlich" zu klickbaren Links werden.

Warum ist es relevant, wenn Dateinamen zu klickbaren Links werden?

Unsere Anwender sind darauf trainiert, Links zu klicken. Wird ein Dateiname erwähnt, der aussieht, wie ein Link, gibt es guten Grund anzunehmen, dass der Link zu einer Download-Seite führt, die mir die erwähnte Datei zur Verfügung stellt.

Wenn nun der Link betätigt wird, können drei Dinge passieren:

• Die Domäne gibt es nicht. Der Browser öffnet sich mit "Server nicht gefunden"
• Es gibt die Domäne, aber sie ist harmlos
• Es gibt die Domäne und sie ist schädlich. Im guten Fall wird die Site direkt geblockt, im schlechtesten Fall resultiert eine Kompromittierung aus dem Link
  

Die ersten beiden Dinge erzeugen "nur" Verwirrung. Der letzte Fall verursacht ggf. Schaden, der abhängig vom Empfänger dem Sender zur Last gelegt wird.

ich fürchte, rein technisch gibt es eher wenig zu tun.

Wir können auf unserer Seite die automatische Linkifizierung deaktivieren, um zu verhindern, dass auch normale Texte zu potentiell klickbaren Links werden. Das beträfe jedoch jede URL, die in Plain Text geschrieben wurde und - mal ehrlich - es ist halt doch bequem, einfach klicken zu können. Das dürfte selbst unter IT-affinen Personen nicht nur auf Gegenliebe stoßen, aber außerhalb unserer "Blase" dürfte es offenen Widerstand treffen.

Andererseits könnten wir Texte, die potentiell linkifizierbar sind, für die Linkifizierung unbrauchbar machen, indem:

• Ein Leerzeichen oder Zero-width space eingefügt wird
• der Punkt durch einen Unterstrich ersetzt wird
• bereits ein eigener Link hinterlegt wird,
  
  • wo die Datei in der Tat als Download hinterlegt ist
  • der auf eine eigene Website leitet, die das Problem erläutert
    

Darüber hinaus immer wieder schulen: Links sind potentiell gefährlich, weil auch irreführend. Woran erkennt man einen korrekten Link?

Disclaimer: als ein Kollege einen Link zum Testen der Problematik/Awareness verschickte, habe ich es nicht am Link selber erkannt, sondern daran, dass beim Öffnen im Firefox selbiger zu meckern anfing (siehe das obige, erste Bild). Ich war "wach" und habe es dennoch nicht erkannt... Was muten wir unseren Anwendern dann erst zu?

Anwender selber können beim Schreiben darauf achten, dass sie die Dateinamen "maskieren" und Dateien nicht generisch benennen.

Generell ist das Thema aber vielleicht auch etwas hoch gehängt. Nichts davon führt unmittelbar zur Kompromittierung. Immer noch können Anwender das grundsätzlich bei der Betrachtung des Links bzw. der Adresszeile erkennen. Noch immer wird alles durch Firewalls und Proxies geprüft und ggf. geblockt. Noch immer wird Malware durch Virenscanner erkannt. Noch immer müssen Anwender schädliche Dateien ausführen bevor sie tatsächlich Schaden anrichten. Noch immer gilt, dass man nicht einfach irgendwo sein Kennwort eingibt.

Don't panic and know where your towel is.