Homograph-Angriff: Wie eine Lookalike-Domain dich täuscht

Ein Homograph-Angriff registriert eine Domain aus Zeichen, die identisch aussehen wie die einer echten Domain, es aber nicht sind - ein kyrillisches "a", das für ein lateinisches "a" steht, zum Beispiel -, sodass die Adresse, die ein Mensch liest, und die Adresse, die ein Browser auflöst, zwei verschiedene Dinge sind. Der Trick funktioniert, weil das Domain Name System nur ASCII versteht, sodass jede Nicht-ASCII-Domain in eine ASCII-Form namens Punycode übersetzt wird, markiert mit einem xn--Präfix, bevor sie überhaupt mit DNS in Berührung kommt. Browser dekodieren das für die Anzeige zurück in die lesbare Version, und genau in diesem Dekodierschritt steckt die Täuschung.

Moderne Browser fangen die offensichtlichen Fälle inzwischen ab und zeigen rohes Punycode, wenn ein Label Schriften auf verdächtige Weise mischt, wodurch die meisten der einfachen Angriffe wegfallen, die vor zehn Jahren noch funktionierten. Aber dieser Schutz verlässt die Adressleiste des Browsers nicht.

Ich beschäftige mich beruflich mit Fällen von Brand-Spoofing, und gute Fälschungen lassen mich immer noch für eine halbe Sekunde zögern, bevor mir der Verräter auffällt. Dieser Beitrag behandelt, wie ein Homograph-Angriff funktioniert, wo die Verteidigung des Browsers endet, und was dagegen zu tun ist - egal, ob du kurz davor bist zu klicken oder dir die gespoofte Domain gehört. Für die weiter gefasste Frage, ob Kurzlinks selbst vertrauenswürdig sind, deckt sind URL-Shortener sicher dieses Terrain ab; hier geht es um die Domain, die unter dem Link liegt.

Was Punycode ist und warum es das gibt

DNS wurde für ASCII gebaut, Punkt. Es hat keine native Möglichkeit, die akzentuierten Buchstaben, kyrillischen, arabischen oder chinesischen Zeichen zu speichern, aus denen der Großteil der Schriftsysteme der Welt besteht - ein echtes Problem in dem Moment, als die Domain-Registrierung sich außerhalb englischsprachiger Märkte öffnete.

Punycode ist die Lösung: eine umkehrbare Kodierung, standardisiert als RFC 3492, die ein Unicode-Label in ASCII-Buchstaben, -Ziffern und -Bindestriche umwandelt, die DNS ohne jede Änderung am Übertragungsprotokoll transportieren kann. Eine deutsche Bäckerei, die eine Domain mit Umlaut registriert, oder ein ukrainischer Händler, der eine in Kyrillisch registriert, bekommt einen funktionierenden internationalisierten Domainnamen, der genau wie jeder andere aufgelöst wird, weil darunter einfach ein weiteres ASCII-Label steckt. Die kodierte Form beginnt immer mit xn--, ein Signal: "Das hier ist Punycode, dekodiere es, bevor du es einem Menschen zeigst."

Nichts davon ist für sich genommen eine Schwachstelle - internationalisierte Domainnamen sind ein echtes, notwendiges Feature, kein Workaround, den irgendjemand deaktivieren sollte. Das Problem beginnt eine Ebene höher, in dem Moment, in dem ein Browser entscheidet, wie er dir diesen dekodierten Namen anzeigt.

Wie ein Homograph-Angriff funktioniert

Ein Homograph-Angriff nutzt die Lücke zwischen dem, was eine Domain enthält, und dem, wie sie nach dem Rendern aussieht. In der Praxis tauchen zwei Varianten auf, und sie sind nicht gleich verbreitet.

Die Ganzschrift-Variante registriert eine komplette Domain in einer nicht-lateinischen Schrift, deren Buchstabenformen zufällig der Zielmarke ähneln. Sie ist auffällig im Aufbau und für Verteidiger leichter zu erkennen, weil das gesamte Label fremd ist.

Die Mischschrift-Variante ist die, die tatsächlich zum Einsatz kommt, weil sie nur eine einzige Ersetzung braucht. Nimm eine Domain wie novacloud.com. Tausche das lateinische "o" gegen das optisch identische kyrillische "о" (U+043E), und du erhältst nоvacloud.com - gleiche Form, gleiche Länge, anderer Code-Point, und eine Domain, die zu xn--nvacloud-nbh.com kodiert. Alles andere im Label bleibt unangetastet, sodass das Auge fast nichts hat, worauf es reagieren könnte. Sicherheitsforscher nennen diese Art von Lookalike-Paar ein "Confusable," und eine Handvoll davon deckt den Großteil des lateinischen Alphabets ab.

Ist die Domain erst registriert, ist der Rest des Angriffs gewöhnliches Phishing: eine Pixel für Pixel kopierte Login-Seite, eine dringliche Nachricht, die auf den gespooften Link verweist, und ein Ziel, das keinen Grund hat, an einer Adresse zu zweifeln, die exakt richtig aussieht.

Was Browser heute dagegen tun

Browser-Hersteller haben die einfache Version dieses Angriffs vor Jahren größtenteils mit einer Regel geschlossen, welche Schriften sich in einem Label mischen dürfen. Chromes Richtlinie, dokumentiert in seinem IDN-Handling-Guide, prüft, ob jedes Zeichen in einem Label plausibel zu einer einzigen Schrift gehört oder zu einer kleinen Gruppe von Schriftkombinationen, die legitim zusammen auftreten, wie japanisches Kanji mit Hiragana. Werden Schriften außerhalb dieser erlaubten Gruppe gemischt, zeigt der Browser die rohe xn--Form statt sie zu dekodieren - das größte Kapital des Angriffs, eine völlig normal aussehende Domain, verwandelt sich zurück in eine offensichtlich kodierte Zeichenfolge. Firefox führt eine vergleichbare Prüfung durch, beschrieben in Mozillas IDN-Display-Algorithmus, und Safari wendet seine eigene Version an.

Vollständigen Schutz bietet das nicht. Ein Mischschrift-Label, das nur aus Zeichen innerhalb einer erlaubten Kombination besteht, kann trotzdem als lesbarer, täuschender Name durchschlüpfen, und die Regel wird browserweise durchgesetzt, ohne eine gemeinsame Instanz, die entscheidet, was als sicher gilt.

Wo dieser Schutz endet

Die Prüfung auf Schriftmischung steckt im Rendering-Code der Adressleiste des Browsers. Sie reist nicht mit der URL an andere Orte mit, und genau in dieser Lücke richtet eine gespoofte Domain noch echten Schaden an.

E-Mail-Clients sind die größte Angriffsfläche: Eine Nachricht kann beliebigen Ankertext über einem Link anzeigen, unabhängig vom Ziel, und die meisten Mail-Apps führen überhaupt keine Confusable-Prüfung durch. Chat-Apps entfalten einen geteilten Link zu einer Vorschaukarte aus Seiten-Metadaten, nicht mit einem Punycode-bewussten Renderer. QR-Codes entfernen den Textschritt vollständig, eine Lücke, die wir in sind QR-Codes sicher behandeln, und gedrucktes Material hat gar keine Software-Schicht zwischen Auge und Täuschung.

Wenn dein Team Links unter einer Domain verschickt, die deine Kunden bereits wiedererkennen, hat eine gespoofte Lookalike-Domain deutlich weniger Spielraum, dich über all diese Kanäle hinweg gleichzeitig überzeugend nachzuahmen. Sieh dir an, wie eine benutzerdefinierte Markendomain bei Elido funktioniert, falls du deine Links noch von einer geteilten oder generischen Domain aus verschickst.

Warum eine Markendomain deine beste Verteidigung ist

Ein Homograph-Angriff funktioniert, indem er Wiedererkennbarkeit ausnutzt - er braucht eine erkennbare Marke, um sie zu fälschen. Das klingt wie ein Argument gegen den Aufbau einer eigenen, erkennbaren Domain, ist aber das Gegenteil. Ein unverwechselbarer Branded Short Link, den dein Publikum bereits mit dir verbindet, ist etwas, womit es eine verdächtige Nachricht vergleichen kann; eine generische oder geliehene Shortener-Domain gibt einem Angreifer ohnehin eine Vorlage, die Kunden nicht vom echten Anbieter unterscheiden können, weil keine von beiden aussieht wie "du".

Eine benutzerdefinierte Domain für Kurzlinks einzurichten bedeutet, dass jeder Link, den du verschickst, einen Namen trägt, den Empfänger wiedererkennen, was die Hürde für jeden erhöht, der ihn fälschen will. Das lohnt sich von Link-Cloaking und URL-Masking abzugrenzen, einer bewussten, offengelegten Entscheidung, Links über die eigene Domain zu leiten. Ein Homograph-Angriff ist der gegenteilige Schachzug - er verschleiert die Identität des Angreifers, während er deine imitiert -, und die Verteidigung ist Transparenz darüber, welche Domain wirklich dir gehört.

Die Registrar-Kontrollen, auf die es wirklich ankommt

Zwei Kontrollen leisten den Großteil der eigentlichen Arbeit, sobald du eine schützenswerte Domain besitzt, und sie greifen auf unterschiedlichen Ebenen des Stacks.

Registrar Lock ist die alltägliche Kontrolle - ein Statusflag, oft als clientTransferProhibited angezeigt, das routinemäßige automatisierte Transferanfragen innerhalb des eigenen Registrar-Dashboards blockiert. Jede Domain, die du aktiv nutzt, sollte das aktiviert haben; es kostet nichts. Registry Lock sitzt eine Ebene höher und schaltet den Registry-Betreiber direkt ein, sodass jede Änderung, Übertragung oder Löschung eine manuelle Verifizierung außerhalb des üblichen Kanals braucht - einen Anruf oder eine sichere Passphrase -, bevor sie wirksam wird. Diese Reibung gehört auf die eine oder zwei Domains, bei denen eine unautorisierte Änderung wirklich teuer würde, was für die meisten Unternehmen mindestens die primäre Markendomain bedeutet.

Keines der beiden Locks hindert jemanden daran, eine Lookalike-Domain neben deiner zu registrieren. Dafür braucht es aktives Monitoring: das Beobachten neuer Domain-Registrierungen und öffentlicher Certificate-Transparency-Logs nach Namen, die optisch nah an deiner Marke liegen, damit du es dem Registrar melden oder Kunden warnen kannst, bevor eine Kampagne damit irgendjemanden erreicht.

Was in eine Brand-Protection-Richtlinie gehört

Wenn du eine Domain besitzt, die sich zu spoofen lohnt, sollte der Sicherheitsabschnitt deiner Brand-Protection-Richtlinie konkret genug sein, dass jemand, der neu im Team ist, ihn umsetzen könnte, ohne dich vorher zu fragen.

• Registrar Transfer Lock auf jeder Domain, die dem Unternehmen gehört, mit zusätzlichem Registry Lock auf der primären Markendomain und allem, was Zahlungen oder Logins abwickelt.
• Ein wiederkehrender Rhythmus für das Scannen neuer Domain-Registrierungen und Certificate-Transparency-Logs nach Namen, die optisch nah an deiner Marke liegen, keine einmalige Prüfung.
• Defensive Registrierung der risikoreichsten Lookalike-Labels und verwechselbaren Top-Level-Domains, die du rechtfertigen kannst, priorisiert danach, wie nah sie an deine primäre Domain herankommen.
• Ein benannter Verantwortlicher und ein Eskalationspfad, um eine entdeckte Lookalike-Domain ihrem Registrar zu melden, plus interne Anleitung, damit Support-Mitarbeiter das Muster erkennen, wenn ein Kunde eine meldet. Die Sicherheits-Checkliste für die Wahl eines Link-Anbieters behandelt die angrenzenden Anbieter-Kontrollen.

Ein Verifizierungsrezept, dem jeder folgen kann

Du musst Punycode nicht verstehen, um einen Link sicher zu prüfen. Vier Schritte, in dieser Reihenfolge ausgeführt, fangen fast alles ab, worauf sich ein Homograph-Angriff verlässt.

1. Klappe den Link zuerst auf, statt direkt draufzuklicken. Wie du siehst, wohin eine Kurz-URL führt geht die Tools dafür durch, und Elidos eigener Link-Checker macht dasselbe, ohne dass du dem Ziel erst vertrauen musst.
2. Lies die registrierbare Domain - den Teil unmittelbar vor der Top-Level-Domain - statt irgendetwas, das davor erscheint. Das ist der Teil, den ein Angreifer vollständig kontrollieren muss.
3. Achte auf ein xn--Präfix, entweder in der rohen aufgeklappten URL oder in der Adressleiste deines Browsers. Siehst du eines, wo du einen einfachen Markennamen erwartet hast, halte inne und behandle es bis zum Beweis des Gegenteils als Lookalike.
4. Bestätige den Zertifikatsnamen auf der Zielseite. Ein Zertifikat spiegelt wider, was einem Domain-Inhaber tatsächlich ausgestellt wurde, was sich deutlich schwerer überzeugend fälschen lässt als ein gerendertes Label.

Keiner dieser Schritte dauert mehr als ein paar Sekunden, sobald sie zur Gewohnheit geworden sind, und du kannst alle vier einem nicht-technischen Kollegen in der Zeit beibringen, die es braucht, diesen Abschnitt einmal zu lesen.

Ein Homograph-Angriff ist ein Anzeigeproblem im Sicherheitskostüm. Punycode tut genau das, wofür es entwickelt wurde; die Täuschung passiert in der Lücke zwischen dem, was eine Domain ist, und dem, was ein Stück Software dir stattdessen zeigt. Browser haben den Großteil dieser Lücke für die Adressleiste geschlossen. Überall sonst ist die Lücke noch offen, weshalb das Aufklappen eines Links und das Lesen der registrierbaren Domain die Gewohnheit bleibt, die funktioniert, egal welcher Kanal den Link vor dich gebracht hat.

Verwandt im Blog

• Sind URL-Shortener sicher? Wie du einen Kurzlink prüfst
• Sind QR-Codes sicher? Quishing und wie du dich schützt
• Die Sicherheits-Checkliste für URL-Shortener
• Benutzerdefinierte Domains für deine Kurzlinks einrichten
• Wie du siehst, wohin eine Kurz-URL führt, bevor du klickst