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.
Anzeige
- 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
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/
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 … ;-)
»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?
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.
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" …
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.
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 …
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 ?
…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."
Autsch !
Das war es. Dank an alle Wegweiser. Hat prima geklappt.
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.
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.
Lösung: in Firefox (about:config) die Einstellung "network.IDN_show_punycode" auf true setzen
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.
@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?
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.
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/".
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.
Für "Firefox" wurde die Lösung des Problems in deinem Beitrag: http://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.
Windows 7 SP 1, 32-Bit, Firefox 53.0 und 53.0.3, Anzeige: https.//www.аррӏе. com
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.
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/
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.
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
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.
Pale Moon hat einen integrierten "Schutz" gegen Punnycode