Phishing mit Unicode Domains

Phisher können sich gewisser Tricks bedienen, um die verlinkten URLs zu verschleiern. Unicode-Domains stellen eine solche Methode dar. Das Gefährliche: Nutzer können in gängigen Browsern diese Angriffe kaum erkennen.


Anzeige

Punycode-Domains für Phishing

Ich bin gestern bei hackernews.com wieder auf das Thema gestoßen. Deren Artikel bezieht sich auf den Beitrag des Chinesen Xudong Zheng vom April 2017. Dort geht Zheng auf Punycodes ein, über die man Domainnamen mit fremdsprachigen Zeichen registrieren kann. Das wären z.B. Umlaut-Domains für deutsche Nutzer.


(Quelle)

Problem ist, dass man bei diesen Punycode-Domains Zeichen verwenden kann, die im Browser nicht darstellbar sind. Man kann also eine Domain mit “xn--pple-43d.com” registrieren, die im Browser als “аpple.com” angezeigt wird. Der obige Screenshot zeigt vordergründig eine Apple-URL an. Aber der Browser verwendet intern die Domain “xn--pple-43d.com”. Durch die Unicode-Zeichen wird die URL verschleiert. Der Benutzer kann nicht erkennen, dass er nicht auf der aktuell angezeigten Domain unterwegs ist.

https hilft nicht

Selbst die https-Verschlüsselung ist kein Indiz, dass die Ziel-URL sauber ist. Man muss das Zertifikate überprüfen. Und das ist jetzt eine Sache, die mich persönlich kolossal ärgert. Denn die Browserentwickler scheinen die Nutzer für Dumpfbacken zu halten. Warum? Aktuell wird von Google und Konsorten ja mächtig Druck ausgeübt, damit alle Kommunikation mit Webservern künftig per https verschlüsselt wird. Andererseits werden essentielle Browserfunktionen als Flachschüsse angelegt, um den Benutzer nur ja nicht zu überfordern. Das Abrufen von https-Zertifikatsinformationen gerät mitunter zum Abenteuer.

  • Klickte man früher auf das Schloss vor der URL einer https-Adresse, wurden einem Zertifikatsinfos angezeigt und mit einem weiteren Mausklick ließen sich Details abrufen. Das konnte man selbst Interneteinsteigern noch halbwegs vermitteln – lediglich die Frage, ob der Zertifikatsaussteller vertrauenswürdig ist, steht auf einem anderen Blatt.
  • Im aktuellen Firefox-Browser bekommt man dagegen bei Anwahl des grünen Felds nur die in obigem Screenshot sichtbare Information eingeblendet, die einen fälschlich in Sicherheit wiegt. Man muss ein wenig herumklicken, um das Zertifikat der Webseite ansehen zu können (immerhin klappt das halbwegs komfortabel).
  • Ganz schlimm ist es in Google Chrome und dessen Ablegern. Dort bekommt man bei Anwahl des grünen Felds nur eine Palette mit Einstellungen zu sehen, die für den Nutzer wertlos sind.

Wer einmal im Google Chrome versucht hat, auf die Schnelle ein Zertifikat und dessen Details zu überprüfen, weiß, was ich im letzten Punkt meine. Man muss die Spalte mit den Entwicklertools über das Menü und den Befehl Tools öffnen, um dort unter ‘Security Overview’ irgendwo unter ‘Valid Certificate’ die grau abgeblendete Schaltfläche View certificate anzuwählen. Erst dann bekommt man das Zertifikat samt Details angezeigt. Nur im Zertifikat kann ich erkennen, für wen dieses ausgestellt wurde (und muss dem Aussteller vertrauen, was auch nicht mehr als Gott gegeben gelten darf).

Lange Rede kurzer Sinn: Mit den Punycode-Domainnamen ließen sich sogenannte IDN homograph attack durchführen. Der Benutzer wiegt sich in Sicherheit, weil die Anzeigen ja scheinbar stimmen. Der Bug wurde von Zengh bereits am 20. Januar 2017 an Google und die Mozilla-Entwickler gemeldet. In Chrome wurde das Problem in der Version 58 behoben (dort bekommt man die gesamte URL angezeigt). In Firefox 53 wird auch die gesamte URL angezeigt – aber der Slimjet-Browser zeigt die URL noch fehlerhaft an – und Nutzer, die älter Browserversionen verwenden, haben das Problem ebenfalls. Man kann diese Testseite aufrufen. Wird dort apple.com in der Adresszeile angezeigt, ist der Browser anfällig für solche Angriffe.

Das Ganze ist übrigens nichts neues, das Thema köchelt seit Jahren. Ich hatte das Thema bereits im November 2016 im Blog-Beitrag Spammer-Trick mit Google.com zeigt neues Risiko behandelt. Dort wurden zwei Sicherheitsprobleme, die Punycode-URLs und die Möglichkeit zur Registrierung von Domains, die sich an bekannte Domainnamen wie Google anlehnen, kombiniert.


Anzeige
Dieser Beitrag wurde unter Internet, Sicherheit abgelegt und mit , , , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

26 Antworten zu Phishing mit Unicode Domains

  1. User sagt:

    Hallo,

    How to fix this in Firefox:
    In your firefox location bar, type ‘about:config’ without quotes.
    Do a search for ‘punycode’ without quotes.
    You should see a parameter titled: network.IDN_show_punycode
    Change the value from false to true.

    Quelle: https://www.wordfence.com/blog/2017/04/chrome-firefox-unicode-phishing/

  2. Peter sagt:

    Vorschlag meinerseits:
    Die Browser könnten die Unicode-Zeichen in der Adresszeile doch in einer anderen Farbe (rot?) darstellen.
    Dann sieht man auch dort schon, dass etwas ‘anders’ ist als normalerweise.

    Alternativ könnten Sie die ganze Adresszeile z.B. in rotem Text darstellen, sobald mindestens ein Unicode-Zeichen enthalten ist.

    Das kann doch nicht so schwer sein @Microsoft @Google @Apple @All … ;-)

  3. Werbung

  4. Markus sagt:

    »In Firefox 53 wird auch die gesamte URL angezeigt« Nicht bei mir (Firefox 53.0.3 32-bit, laut eigenen Angaben “Firefox ist aktuell”, unter Windows 7/64HP, stets nach den Empfehlungen von Günther Born upgedatet). Was tun?

    • Günter Born sagt:

      Merkwürdig, ich habe es gerade nochmals mit Firefox 53.0.3 portable unter Windows 7 SP1 getestet. Die Testseite wird nicht als apple.com sondern als www[.]xn--80ak6aa92e[.]com angezeigt.

      Nachtrag: Das betreffende Flag wurde ja in den nachfolgenden Kommentaren genannt. Scheinbar stellt der FF portable dieses Flag auf true, während es bei der FF installierbaren Version auf false steht.

      • Kim O. Fee sagt:

        Der FF Portable Apps enthält zwar den 32-bit und den 64-bit Kern mit entsprechender Anpassung auf das System, aber dass die Punycode-Einstellung automatisch erfolgt, ist mir neu – zumindest hier stand im w7-SP1-x64-Betrieb “false” …

        • Günter Born sagt:

          Muss ich mal zur Kenntnis nehmen. Da ich die alternativen Browser generell als portable-Version unter W7 nutze und an den FF-Einstellungen wissentlich nichts geändert habe, bleibt es aber mysteriös.

          • Kim O. Fee sagt:

            Ich vergleiche öfters mal die beiden FF-Kernvezeichnisse (x32 und x64) des jeweils entpackten Installers mit denen von Portable Apps bzw. deren appinfo.ini und installer.ini (man kann ja nie wissen …), aber da ist grundsätzlich alles sauber. Somit bleiben eigentlich nur noch irgendwelche AddOns übrig, die solche Umschaltungen vornehmen …

    • Remo sagt:

      Seltsam. Bei mir auf Win 10 64 Creators (mit allen aktuellen Fixes) und dem Firefox 53.0.3 in der 64 Bit Variante klappt es ebenfalls nicht.
      Was ist hier falsch ?

      • S.H. sagt:

        …steht weiter unten im Artikel von “the hacker News”..
        Das Anzeigen von Punycode aktivieren. Zumindest ein “Workaround”, zu mehr hat’s bei Mozilla wohl noch nicht gereicht…….
        a.a.O.: “Firefox users can follow below-mentioned steps to manually apply temporarily mitigation:
        Type about:config in address bar and press enter.
        Type Punycode in the search bar.
        Browser settings will show parameter titled: network.IDN_show_punycode, double-click or right-click and select Toggle to change the value from false to True.”

    • Michael sagt:

      Sieh mal in der ‘about:config’ nach, ob der Schlüssel ‘network.IDN_show_punycode’ auf ‘false’ steht. Wenn ja, ist das das Problem. Einfach auf ‘true’ setzen.

      Das funktioniert sogar unter den alten 20er Versionen von Firefox und PaleMoon, die ich hier in Sandboxie laufen habe.

    • Martin sagt:

      Sieh mal in der ‘about:config’ nach, ob der Schlüssel ‘network.IDN_show_punycode’ auf ‘false’ steht. Wenn ja, ist das das Problem. Einfach auf ‘true’ setzen.

      Das funktioniert sogar unter den alten 20er Versionen von Firefox und PaleMoon, die ich hier in Sandboxie laufen habe.

  5. Stefan sagt:

    Lösung: in Firefox (about:config) die Einstellung “network.IDN_show_punycode” auf true setzen

  6. Dekre sagt:

    Sehr merkwürdig – in Firefox 53 wird die Testseite mit https und dann www[.]аррӏе[.]com angezeigt. Mit IE 11 passiert gar nichts, wenn ich auf den Link in der Blogseite klicke. Die wird auch nicht angezeigt, wenn ich mit den Mauscursor darauf gehe. Kopiere ich dann die url-Seite von Firefox hinein, so kommt der Hinweis:
    “Die Datei ‘https://www.apple.com/’wurde nicht gefunden. Überprüfen Sie die Schreibweise, und versuchen Sie es erneut.”
    Sehr komisch. Das verstehe ich nicht.

    • Dekre sagt:

      @Lieber Günter,
      Ich habe bei IE 11 jetzt die Blogseite mit F12 (Entwicklertool) mir angeschaut. Wenn ich es richtig verstehe, schreibt Du:
      “Man kann diese Testseite aufrufen (… ist verlinkt = “https://www.xn--80ak6aa92e.com/” ) . Wird dort apple.com in der Adresszeile angezeigt, ist der Browser anfällig für solche Angriffe.”

      Schaue ich mir dann die Auswirkung bei IE11 und Firefox 53.0.3 an, so interpretiere ich es jetzt so, dass IE 11 sicher ist und und Firefox 53.0.3 dann nicht. Weil bei IE 11 die Seite nicht angezeigt wind und bei Firefox die Seite mit apple.com und dann auch so aufgerufen wird. Ist diese Aussage so richtig?

      • Günter Born sagt:

        Der IE11 kann wohl nur unter Win10 die Seiten anzeigen – auf Windows 7 tut sich nichts. Ist auch hier erwähnt. Ob man den IE 11 als sicher bezeichnen mag? Muss jeder selbst entscheiden. Beim FF haben andere Poster ja auf die betreffenden Flags hingewiesen. Ich habe es gerade geprüft, bei mir stand das Flag dn_show_punycode auf true.

        PS: Heute hat wohl der Spam-Filter für Kommentare hier im Blog heftig zugeschlagen. Einige Kommentare sind, wohl auf Grund des immer gleich lautenden Flag-Namens dn_show_punycode, hier im Papierkorb gelandet. Hatte plötzlich 13 Papierkorbeinträge, wovon nur wenige Dubletten waren. Ich habe die Kommentare händisch restauriert und freigegeben. Erklärt die vielen Kommentare zum Thema.

        • Dekre sagt:

          Danke Günter, auch dann heute andere Kommentatoren sagen, dass was in Firefox umgestellt werden muss. Das mache ich. Bei Chrome kommt das richtig und wird angezeigt mit “https://www.xn--80ak6aa92e.com/“.

  7. Herr IngoW sagt:

    Bei mir kann “Firefox 53.0.3” in Win10Pro es auch nicht.
    Der Link wird auch falsch am unteren Rand angezeigt wenn der Mauszeiger drauf ist.

    Beim EDGE wird die richtige URL erst nach dem drücken der “Enter-Taste” angezeigt.
    Der Link wird aber richtig am unteren Rand angezeigt wenn der Mauszeiger drauf ist.

    Beim IE kommt unten ein Hinweis auf nicht lesbare Zeichen (ändern/Download der Spracheinstellungen) der Link wird aber richtig am unteren Rand angezeigt wenn der Mauszeiger drauf ist.

    Also ist schon schwer zu erkennen. Es ist auch beim Surfen immer Vorsicht geboten so weit es möglich ist.

  8. Werbung

  9. Herr IngoW sagt:

    Für “Firefox” wurde die Lösung des Problems in deinem Beitrag: https://www.borncity.com/blog/2016/11/21/spammer-trick-mit-google-com-zeigt-neues-risiko/
    in einem Kommentar von “Ralph” beschrieben:
    Zitat:
    “Ralph sagt:
    22. November 2016 um 12:49

    Und das ist gut so, denn sonst hätte ich meine Domain nicht!
    Beim Firefox gibt es übrigens eine ganz einfache Möglichkeit, als dummer „ich klicke jeden Link an“-Nutzer zumindest mit einem Blick auf den URL doch noch eventuell mitzubekommen, dass man nicht da ist, wo man zu sein glaubt:
    about:config eingeben
    idn_show_punycode suchen
    von false auf true umstellen
    fertig”
    Zitat ende.

  10. Nobody sagt:

    Windows 7 SP 1, 32-Bit, Firefox 53.0 und 53.0.3, Anzeige: https.//www.аррӏе. com

  11. Ralph sagt:

    Im Firefox unter about:config einfach den Schlüssel “network.IDN_show_punycode” auf true setzen. Sollte der Schlüssel nicht existieren, dann als Typ boolean anlegen und auf true stellen. Und schon würde aus schlüter[.]de in der Adressleiste xn--schlter-q2a[.]de (und: nein, die Domain gehört mir nicht, ich weiss nicht einmal, ob es die gibt). Funktioniert bei mir im FF 50 ganz hervorragend und hat früher auch funktioniert.

  12. gs sagt:

    Firefox users can limit their exposure to this bug by going to
    about:config
    and setting
    network.IDN_show_punycode
    to true.
    This will force Firefox to always display IDN domains in its Punycode form, making it possible to identify malicious domains.
    https://www.xudongz.com/blog/2017/idn-phishing/

  13. Pixelkrieger sagt:

    Lösung: Im FF über about:config nach “puny” suchen. Bei show_ponycode den Eintrag von false auf true setzen. Jetzt müsste erkannt werden, dass es sich nicht um die original Webseite von Apple handelt.

  14. PunyCoder sagt:

    Bei wem es im Firefox nicht klappt, einfach in der about:config

    “network.IDN_show_punycode” auf “TRUE” setzen.

    Dann klappt es auch sofort, ohne Neustart des FF.

    Cheers

  15. Andreas B. sagt:

    Puuu-haaaa! – Und wozu zum […] braucht die Welt diesen blöden Nonsense mit Unicode überhaupt??? (Ja, sogar der Normalchinese kann seinen Kram amtlich korrekt transkribieren!) – Den Beispiel-Schlüter kann man einfach “schlueter” schreiben, und gut is. Weiß man seit Anno Toback, dass man für all so’n Zeugs mit ascii arbeitet, und reicht doch.
    Mögen die meinetwegen ihre Klicki-bunti-Oberflächen aufhübschen, wie sie wollen, aber vom Maschinen-Bereich sollen die Marketing- und “User-Experience”-Fuzzies gefälligst ihre Flossen weg lassen.

  16. ein-leser sagt:

    Pale Moon hat einen integrierten “Schutz” gegen Punnycode

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.