Chromiums IDN-Spoofing-Schutz übersieht überzeugende Lookalike-Domains
Chromiums Schutzmechanismen gegen IDN-Spoofing übersahen 20 registrierte Lookalike-Domains – trotz jahrelanger Schutzvorkehrungen, die täuschende Unicode-Adressen sichtbar machen sollen. Eine Proof-of-Concept-Domain ähnelte apple.com stark, erschien jedoch als lesbares Unicode statt im auffälligen Punycode-Format, das mit xn-- beginnt.
Der Fund bedeutet nicht, dass Angreifer Apples Domain registriert oder dessen Infrastruktur kompromittiert hätten. Forschende von Have I Been Squatted, kurz HIBS, registrierten eine andere Domain, deren kyrillische Zeichen den lateinischen Buchstaben in „apple“ ähneln. Ihre Tests zeigen, wie sorgfältig ausgewählte Zeichen die Anzeigeregeln von Chromium sowie dessen separate Schutzmechanismen beim Navigieren passieren können.
Das Ergebnis belebt einen Konflikt neu, den Browser bewältigen müssen, seit internationalisierte Domainnamen breite Verwendung fanden. Das Web benötigt Adressen in den Sprachen, die Menschen tatsächlich nutzen. Dieselbe Zeichenvielfalt eröffnet Angreifern jedoch mehr Möglichkeiten, vertrauenswürdige Marken, Identitätsanbieter und Zahlungsdienste nachzuahmen.
Chromium setzt bereits eines der detailliertesten Schutzsysteme der Branche ein. Es prüft Schriftsysteme, verdächtige Zeichenkombinationen, bekannte Domains und den Browserverlauf. Die neuen Beispiele heben diese Schutzmaßnahmen nicht auf. Sie zeigen, wie einige wenige Zeichen zwischen Ebenen hindurchfallen können, die jeweils leicht unterschiedliche Entscheidungen treffen.
Forschende entdeckten einen neuen Grenzfall bei Chromium-IDN-Spoofing
Die entscheidende Veränderung ist nicht die Rückkehr eines vergessenen Angriffs, sondern der Nachweis, dass die aktuellen Chromium-Prüfungen weiterhin überzeugende neue Varianten zulassen.
Die HIBS-Forschenden Ian Muscat und Leanne Briffa veröffentlichten ihre Analyse am 3. Oktober 2026. Sie untersuchten, ob eine internationalisierte Domain einer bekannten Adresse in lateinischer Schrift ähneln und in Chromium-basierten Browsern dennoch als Unicode erscheinen könnte.
Ein internationalisierter Domainname, kurz IDN, enthält Zeichen außerhalb des grundlegenden englischen Alphabets. Anwendungen übersetzen diese Zeichen vor einer DNS-Anfrage in eine ASCII-kompatible Darstellung namens Punycode. Eine mit xn-- beginnende Domain ist daher nicht automatisch gefährlich. Es handelt sich um eine codierte Form, die vom bestehenden Domain Name System benötigt wird.
Browser wandeln diese codierte Form zur Anzeige häufig wieder in lesbares Unicode um. Das unterstützt legitime Adressen auf Arabisch, Kyrillisch, Chinesisch und in vielen weiteren Schriftsystemen. Das Sicherheitsproblem entsteht, wenn unterschiedliche Zeichen nahezu identische Formen haben.
Die Forschenden konzentrierten sich auf аррӏө.com, eine Domain, die in gängigen Schriftarten apple.com ähneln kann. Ihre Buchstaben sind kyrillisch, darunter Zeichen in der Form eines lateinischen „a“, zweier „p“ und eines „l“. Das abschließende kyrillische Zeichen ө ähnelt bei der Darstellung in der Größe einer Adressleiste einem gerundeten „e“.
Die Adresse ist nicht apple.com. Ihre codierte Form lautet xn--80a6aa68c8d.com, und DNS behandelt sie als eigenständigen Namen. Dennoch kann die lesbare Version den visuellen Eindruck erzeugen, dass ein Besucher Apples Domain erreicht hat.
HIBS registrierte diese Domain und 19 weitere Lookalikes als Proof of Concept. Die Liste ahmte Namen nach, die mit OpenAI, Skype, SharePoint, SpaceX, Shell, Xerox, Kaspersky, Okta, Nike und anderen bekannten Organisationen verbunden sind.
Die ursprüngliche IDN-Forschung besagt, dass Chrome 154 den Apple-Lookalike mit einem gültigen Zertifikat als Unicode anzeigte. Er bestand zudem die von den Forschenden geprüften Navigationskontrollen, ohne eine Lookalike-Warnung auszulösen.
Ein gültiges Zertifikat beweist nicht, dass eine Domain zu der Marke gehört, der sie ähnelt. Es bestätigt, dass der Browser eine verschlüsselte Verbindung zu der im Zertifikat genannten Domain aufgebaut hat. Angreifer können Zertifikate für Domains erhalten, die sie rechtmäßig kontrollieren – auch für täuschende.
Bei den Beispielen handelte es sich um kontrollierte Registrierungen, nicht um Belege für eine Kampagne gegen Kunden jedes genannten Unternehmens. Diese Unterscheidung ist wichtig, da ein technisch möglicher Spoof nicht automatisch eine aktive Phishing-Operation darstellt.
Dennoch ist die technische Machbarkeit der entscheidende Befund. Eine täuschende Domain kann eine echte Website, HTTPS, E-Mail, Weiterleitungen und andere gewöhnliche Internetdienste unterstützen. Angreifer könnten die visuelle Ähnlichkeit dann mit einer Suchanzeige, betrügerischen E-Mails, einem QR-Code, verkürzten Links oder einer kopierten Anmeldeseite kombinieren.
Die Forschung erschien am 18. Oktober in einer breiteren Berichterstattung, als eine Untersuchung zu Typosquatting detaillierte, wie die kyrillischen Ersetzungen die Regeln von Chromium überstanden. Das Timing lenkt erneut Aufmerksamkeit auf Schutzmechanismen, die viele Nutzer nie zu sehen bekommen, sofern der Browser nichts Verdächtiges erkennt.
Daraus ergibt sich die zentrale Spannung des Artikels. Chromium muss täuschende visuelle Ersetzungen von legitimen Wörtern unterscheiden, die Millionen Menschen verwenden. Eine Regel, die weit genug gefasst wäre, um jede Ähnlichkeit zu erfassen, würde zugleich gewöhnliche internationale Adressen schwerer lesbar und vertrauenswürdig machen.
Wie Chromium-Unicode-Lookalikes mehrere Prüfungen passieren
Der Apple-Lookalike bleibt bestehen, weil keine einzelne Chromium-Regel den vollständigen visuellen Eindruck bewertet, der den Nutzer erreicht.
Chromium fragt nicht einfach, ob eine Domain Unicode enthält. Es verarbeitet IDNs durch mehrere Prüfungen, bevor entschieden wird, ob lesbare Zeichen oder das zugrunde liegende Punycode-Label angezeigt werden.
Die erste wichtige Ebene nutzt den Spoof-Checker der International Components for Unicode. Chromium konfiguriert ihn auf die Stufe „Highly Restrictive“, die verdächtige Kombinationen von Schriftsystemen begrenzt.
Ein gemischtes Label mit einem kyrillischen Zeichen zwischen lateinischen Buchstaben besteht diesen Test normalerweise nicht. Wird beispielsweise nur das erste „a“ in apple.com ersetzt, zeigt Chromium xn--pple-43d.com an. Die codierte Adresse wird wesentlich seltener mit dem Original verwechselt.
Der neue Apple-Lookalike umgeht dieses Ergebnis, weil jeder Buchstabe vor .com kyrillisch ist. Es handelt sich um ein Label in nur einer Schrift und nicht um eine offensichtliche Mischung aus lateinischen und kyrillischen Zeichen.
Chromium pflegt zudem einen Satz zulässiger Zeichen. Es entfernt verschiedene Unicode-Blöcke und einzelne Codepunkte, die mit riskanten oder verwirrenden Darstellungen verbunden sind. Die Zeichen in аррӏө.com bleiben zulässig, unter anderem weil sie legitime Buchstaben sind, die in realen Sprachen verwendet werden.
Es folgen mehrere gezielte Prüfungen. Chromium beschränkt das isländische Thorn und Eth außerhalb relevanter Länderdomains. Es begrenzt das aserbaidschanische Schwa und wendet eine spezielle Regel auf den katalanischen Mittelpunkt an. Keine dieser Einschränkungen betrifft die kyrillische Zeichenfolge im Proof of Concept.
Die relevanteste Abwehr ist Chromiums Prüfung auf skriptweite Verwechselbarkeit. Sie sucht nach Labels, die vollständig in kyrillischen Zeichen geschrieben sind und allesamt lateinischen Buchstaben ähneln.
Chromium führte diesen Schutz nach einer viel diskutierten Demonstration aus dem Jahr 2017 ein. Der Sicherheitsforscher Xudong Zheng registrierte eine vollständig kyrillische Version von apple.com, die Browser als nahezu identische visuelle Kopie der echten Adresse anzeigten.
Chromium reagierte in Chrome 58. Seine skriptweite Prüfung identifiziert einen Satz von 29 kyrillischen Zeichen, die lateinischen Zeichen ähneln. Wenn jeder Buchstabe eines einsprachigen Labels zu diesem Satz gehört, kann Chromium die Domain als Punycode anzeigen.
Diese Abwehr erkennt die Version von 2017. Die neue Variante erkennt sie nicht, weil ө nicht zu den 29 aufgeführten Zeichen gehört. Ein einziges Zeichen außerhalb dieses Satzes führt dazu, dass die skriptweite Bedingung nicht mehr greift, obwohl das vollständige Label weiterhin „apple“ ähnelt.
Der Browser muss dieses Zeichen irgendwo zulassen, da es kein erfundenes Symbol ist. Kyrillisches ө wird im Kasachischen, Mongolischen, Tatarischen und weiteren Sprachen verwendet. Es überall zu blockieren, würde legitimen Sprechern die Nutzung erschweren.
Anschließend nutzt Chromium einen Skeleton-Vergleich für geschützte Domains. Ein Skeleton reduziert visuell verwandte Zeichen auf eine normalisierte Darstellung, die Software mit bekannten Namen vergleichen kann.
Der Prozess ist nützlich, kann menschliches Sehen jedoch nicht perfekt nachbilden. In diesem Fall bleibt der Balken über ө bei der Normalisierung erhalten. Das resultierende Skeleton endet mit einer Form auf Basis von „o“ plus einer kombinierenden Markierung statt mit dem erwarteten lateinischen „e“.
Dieser Unterschied verhindert eine exakte Übereinstimmung mit dem Skeleton von apple.com. Eine kleine Markierung genügt, um das rechnerische Ergebnis zu verändern, selbst wenn sie in einer kompakten Browseroberfläche kaum sichtbar ist.
Beispiele in lateinischer Schrift offenbaren eine verwandte Schwäche. Die Forschenden nutzten Zeichen wie ƙ, einen lateinischen Buchstaben mit Haken, um das „k“ in Namen wie Okta und Nike nachzuahmen. Chromium kann keine umfassende skriptweite Warnung für lateinische Zeichen anwenden, da Domains mit lateinischen Akzenten verbreitet und legitim sind.
Stattdessen gewährt Chromium einer gebündelten Liste prominenter Domains stärkeren Skeleton-Schutz. HIBS fand 8.462 Namen in dieser Liste, darunter 836 in einer höher priorisierten Gruppe. Ein Zeichen, das eine zusätzliche Markierung bewahrt, kann jedoch eine exakte Skeleton-Übereinstimmung verhindern.
Die Chromium-Anzeigerichtlinien erkennen den zugrunde liegenden Ausgleich an. Chrome zeigt Punycode an, wenn seine IDN-Anzeigeregeln ein Homograph-Risiko erkennen, vermeidet jedoch, jede Nicht-ASCII-Adresse als feindselig zu behandeln.
Dieser Ausgleich macht Chromium-IDN-Spoofing zu einem Klassifikationsproblem statt zu einem einfachen Blacklist-Problem. Jede neue Regel muss böswillige Ähnlichkeit erfassen, ohne legitime internationale Namen in unlesbare codierte Zeichenfolgen zu verwandeln.
Browserwarnungen bieten eine zweite Abwehr – mit Grenzen
Eine Domain, die als Unicode erscheint, wird weiterhin bei der Navigation geprüft, doch diese Prüfungen hängen von exakten Vergleichen, der Namenslänge und dem Verlauf des Besuchers ab.
Chromium trennt die Darstellung der Adresse vom Schutz zur Navigationszeit. Das erste System bestimmt, wie ein Hostname in der Adressleiste aussieht. Das zweite kann einen Besuch unterbrechen oder nach dem Navigieren mit einem Hinweis versehen.
Die Lookalike-Navigationskomponente von Chromium vergleicht eine besuchte Adresse mit populären Domains und Websites, die der Nutzer regelmäßig aufruft. Je nach Übereinstimmung kann Chrome eine ganzseitige Zwischenseite oder einen weniger aufdringlichen Safety Tip anzeigen.
Das Design der Lookalike-Warnungen beschreibt diese Prüfungen als zusätzliche Ebene neben Google Safe Browsing. Popularität und die bisherige Interaktion eines Nutzers geben dem Browser Bezugspunkte, um verdächtige Alternativen zu identifizieren.
HIBS berichtet, dass eine exakte Skeleton-Übereinstimmung mit einer der 836 Domains höchster Priorität eine Zwischenseite erzeugt. Eine exakte Übereinstimmung mit einer anderen gebündelten Domain kann einen Safety Tip auslösen.
Der Browser berücksichtigt auch Websites, die ein Nutzer mit ausreichender Häufigkeit besucht. Wenn eine neue Adresse einer dieser häufig besuchten Websites exakt ähnelt, kann Chromium die Navigation blockieren und fragen, ob der Besucher die bekannte Domain öffnen wollte.
Ähnliche Treffer werden enger behandelt. Chromium kann ein Skeleton erkennen, das sich durch ein eingefügtes, entferntes oder ersetztes Zeichen unterscheidet. Es kann zudem einen Tausch benachbarter Zeichen erkennen.
Diese Vergleiche gelten nicht einheitlich. Laut der Forschung überspringt der Test auf ähnliche Treffer Ziel-Labels mit weniger als fünf Zeichen vor der Top-Level-Domain. Das ist für Marken mit kurzen Namen relevant.
Der Okta-Lookalike mit ƙ ist nur eine Änderung vom echten Namen entfernt, aber „okta“ besteht aus vier Zeichen. Nach Angaben der Forschenden ist er damit für die betreffende Prüfung auf ähnliche Treffer zu kurz.
Das Apple-Beispiel scheitert aus einem anderen Grund. Sein Skeleton liegt zwei Änderungen von apple.com entfernt, weil ө zu einem „o“ plus einem beibehaltenen Balken normalisiert wird. Der Vergleich auf Ähnlichkeit erlaubt jedoch nur eine Änderung.
Infolgedessen wurde die getestete Domain als Unicode angezeigt und ohne Warnung vor einer Verwechslungsgefahr geladen. Laut HIBS galt dies selbst für jemanden, der die authentische Apple-Website regelmäßig besuchte.
Diese Ergebnisse sollten nicht als vollständige Prüfung aller Schutzmechanismen rund um einen Websitebesuch verstanden werden. Safe Browsing, Threat-Intelligence-Feeds, Endpunktsoftware, DNS-Filter, E-Mail-Gateways und Reputationsdienste können eine bösartige Domain weiterhin kennzeichnen.
HIBS schloss zudem einige Variablen aus seiner Bewertung aus, darunter Remote-Allowlisten, Reputationsprüfungen und bestimmte Weiterleitungsverhalten. Eine als Waffe eingesetzte Website könnte daher auf weitere Abwehrmaßnahmen treffen, die der Proof of Concept nicht getestet hat.
Auch das Gegenteil trifft zu. Eine neu erstellte Phishing-Domain verfügt anfangs möglicherweise nur über wenige Reputationsdaten. Angreifer nutzen oft dieses Zeitfenster aus, bevor automatisierte Systeme die Infrastruktur klassifizieren oder Verteidiger eine Abschaltung veranlassen.
Das erklärt, warum dieser Sonderfall selbst bei mehreren Schutzvorkehrungen relevant ist. Mehrschichtige Sicherheit funktioniert am besten, wenn Fehler unabhängig voneinander auftreten. Hier stützen sich mehrere Prüfungen auf eng verwandte Skeleton-Darstellungen und Domainlisten, sodass ein sorgfältig gewähltes Zeichen mehr als eine Entscheidung beeinflussen kann.
Historienbasierter Schutz bedeutet außerdem, dass zwei Nutzer unterschiedlich behandelt werden können. Ein regelmäßiger Besucher eines geschützten Dienstes liefert dem Browser eine bekannte Domain zum Vergleich. Ein Erstbesucher verfügt möglicherweise nur über die integrierte Popularitätsliste.
Dieser Unterschied ist besonders für Recruiting-Websites, regionale Banken, Unternehmenssoftware und Lieferantenportale relevant. Mitarbeitende erhalten möglicherweise einen Link zu einem Dienst, den sie noch nie besucht haben, sodass der Browser über weniger persönliche Historie zum Vergleich verfügt.
Die sicherste Schlussfolgerung ist nicht, dass Chromium keinen Schutz bietet. Seine Regeln stoppen viele gängige Ersetzungen, bevor sie Nutzer erreichen. Die Lehre lautet, dass das Erscheinungsbild der Adressleiste und das Ausbleiben einer Warnung für sich genommen keine Authentizität belegen können.
IDN-Homograph-Angriffe reichen über die Adressleiste hinaus
Der Browser ist nur eine Anzeigeoberfläche, während täuschende Domains Nutzer über E-Mail, Messaging-Anwendungen, Dokumente und Suchergebnisse erreichen können.
Ein IDN-Homograph-Angriff verwendet unterschiedlichartige, aber ähnlich aussehende Zeichen, um einen anderen Bezeichner nachzuahmen. Typosquatting ist die umfassendere Praxis, verwirrend ähnliche Alternativen zu einer legitimen Domain zu registrieren, einschließlich einfacher Tippfehler und visuell täuschender Zeichen.
Die neue Forschung liegt an der Schnittstelle dieser Kategorien. Die Domains sind keine herkömmlichen Tastaturfehler, doch ihre visuelle Ähnlichkeit kann schnelles Lesen, kleine Bildschirme und vertraute Markenformen ausnutzen.
E-Mail schafft eine besonders schwierige Übergabe. Die Adressregeln von Chromium schützen Hostnamen, die über die Browseroberfläche dargestellt werden. Sie regeln nicht automatisch Unicode-Text, den eine Webmail-Anwendung in einer Nachrichtenkopfzeile platziert.
HIBS testete 20 internationalisierte Absenderdomains in Gmail und Outlook im Web. Den Forschern zufolge zeigte Gmail alle 20 in Unicode an, einschließlich Domains, die Chromiums Adressleiste als Punycode dargestellt hätte.
Laut Test behielt Gmail die codierte Form in einem separaten Feld mailed-by bei. Die meisten Empfänger prüfen eher die hervorgehobene Absenderzeile, als technische Zustellinformationen aufzuklappen.
Outlook im Web verfolgte im Test der Forscher den entgegengesetzten Ansatz. Es zeigte alle 20 Absenderdomains als ihre ASCII-kompatiblen Labels an, einschließlich gewöhnlicher internationaler Namen wie café.com und zürich.com.
Keiner der beiden Ansätze löst den zugrunde liegenden Zielkonflikt vollständig. Alles zu dekodieren verschafft Nutzern lesbare internationale Adressen, bewahrt aber visuelle Mehrdeutigkeit. Alles zu kodieren macht Unterschiede sichtbar, während legitime mehrsprachige Adressen ungewohnt und schwer interpretierbar werden.
Messaging-Anwendungen und Dokumente können dieselbe Lücke erzeugen. Eine Plattform kann einen Unicode-Link als normalen Text darstellen, bevor der Browser das ausgewählte Ziel erhält. Der Nutzer beurteilt eine Anzeige und navigiert dann durch ein anderes Sicherheitssystem.
Suchergebnisse und Anzeigen eröffnen einen weiteren Weg. Eine täuschende Domain kann neben vertrautem Branding und kopierten Seitentiteln erscheinen. Selbst wenn die Adresse leicht abweicht, kann der umgebende Kontext Nutzer dazu verleiten, das visuelle Muster zu vervollständigen.
QR-Codes entfernen das sichtbare Ziel fast vollständig, bis ein Scan erfolgt. Mobile Browser haben zudem weniger Platz für Hostnamen, und Oberflächen können einen Seitentitel gegenüber der vollständigen Adresse hervorheben.
Das Unicode-Konsortium empfiehlt mehrere Schutzmaßnahmen gegen verwechselbare IDNs. Dazu zählen die Begrenzung zulässiger Zeichenrepertoires, das Verhindern riskanter Schriftsystem-Mischungen, die Anwendung kontextbezogener Sprachbeschränkungen und das Blockieren von Registrierungen, die bestehenden Labels ähneln.
Seine IDN-Sicherheitshinweise betonen außerdem eine wichtige Einschränkung. Unicode-Verwechselungen machen nur einen kleinen Teil des Phishings aus. Einfache Domains wie secure-brand-login.com sind weiterhin verbreiteter und benötigen keine ungewöhnlichen Zeichen.
Dieser Kontext verhindert, dass die neuen Erkenntnisse zu der Behauptung werden, Unicode verursache den Großteil des Online-Betrugs. Angreifer wählen meist die günstigste funktionierende Methode. Ein vertrautes Wort, eine irreführende Subdomain, ein gestohlenes Konto oder eine kompromittierte legitime Website kann einfacher sein als der Aufbau einer ausgefeilten IDN.
Eine geringere Verbreitung beseitigt jedoch nicht das Risiko für hochwertige Ziele. Identitätsplattformen, Finanzdienstleister, Cloud-Konsolen und Mitarbeiterportale bieten Angreifern wertvolle Zugangsdaten. Eine visuell überzeugende Imitation kann den zusätzlichen Aufwand wert sein.
Die Internationalisierung selbst ist nicht der Fehler. Das Internet muss Namen unterstützen, die außerhalb des grundlegenden lateinischen Alphabets geschrieben werden. Jede solche Adresse als feindselig zu behandeln, würde die Last auf legitime Nutzer und Unternehmen verlagern.
Die ungelöste Frage ist, wo jede Abwehrmaßnahme greifen sollte. Browser steuern Anzeige- und Navigationswarnungen. Registries bestimmen, welche Labels registriert werden können. E-Mail-Dienste steuern die Absenderdarstellung. Markeninhaber überwachen verdächtige Registrierungen, während Sicherheitsteams sie filtern und untersuchen.
Kein Beteiligter sieht den vollständigen Angriffspfad. Diese Fragmentierung ermöglicht es, dass eine von einer Oberfläche abgelehnte Domain in einer anderen überzeugend erscheinen kann.
Registries können Chromium-IDN-Spoofing nicht Browsern überlassen
Die dauerhafteste Abwehr beginnt vor der Navigation, doch Registry-Richtlinien bleiben über Sprachen und Top-Level-Domains hinweg fragmentiert.
Eine Domain kann keine unabhängige Website oder Mailbox unterstützen, wenn eine Registry ihre Registrierung nicht zulässt. Registry-Kontrollen können daher täuschende Namen blockieren, bevor Browser entscheiden müssen, wie sie angezeigt werden.
Richtlinien für internationalisierte Domains verwenden häufig IDN-Tabellen. Diese Tabellen legen fest, welche Unicode-Zeichen eine Top-Level-Domain akzeptiert und welche Kombinationen oder Varianten besonders behandelt werden müssen.
Das Unicode-Konsortium empfiehlt, verwechselbare Labels zu bündeln oder zu blockieren. Beim Bündeln werden verwandte Varianten demselben Registranten zugewiesen. Beim Blockieren darf ein Label existieren, während die Registrierung verwirrender Alternativen verhindert wird.
Die IDN-Implementierungsrichtlinien von ICANN formulieren allgemeine Erwartungen, die Cybersquatting und Verbraucherverwirrung reduzieren sollen. Die tatsächlichen Richtlinien unterscheiden sich weiterhin, weil verschiedene Registries unterschiedliche Sprachen, Schriftsysteme und lokale Anforderungen unterstützen.
Die .com-Registry erlaubte die Proof-of-Concept-Registrierungen von HIBS. Das bedeutet nicht, dass .com jede Unicode-Sequenz akzeptiert. Es bedeutet, dass die getesteten Zeichen und Kombinationen den geltenden Registrierungsregeln entsprachen.
HIBS analysierte außerdem die im Oktober 2026 über ICANNs Centralized Zone Data Service bezogene .com-Zonendatei. Die Forscher zählten 167.226.216 delegierte .com-Namen, darunter 733.509 in IDN-Form dargestellte Namen.
Ihre Methodik ordnete IDNs delegierten ASCII-Domains zu, denen sie visuell ähnelten. Daraus ergaben sich 161.894 Lookalike-Paare, die 133.953 unterschiedliche ASCII-Namen abdeckten.
Diese Zahlen sind keine Zählung bösartiger Domains. Die Forscher weisen ausdrücklich darauf hin, dass ein visuelles Paar eine defensive Registrierung, eine mehrsprachige Website oder eine unabhängige Organisation darstellen kann.
Diese Unterscheidung ist entscheidend. Eine Domain mit einem akzentuierten Zeichen kann einer ASCII-Adresse zufällig ähneln. Eigentümerschaft, Inhalte, DNS-Verhalten, Zertifikate, E-Mail-Konfiguration und Weiterleitungen liefern stärkere Hinweise auf böswillige Absicht.
Dennoch zeigt der Umfang, warum Browserlisten nicht jedes relevante Ziel aufführen können. Chromiums integrierte Schutzmechanismen decken Tausende prominente Namen ab, während die .com-Zone Millionen von Unternehmen und Organisationen enthält, die Ziel von Imitationen werden könnten.
Kleine Unternehmen könnten besonders gefährdet sein. Ihre Domains erscheinen mit geringerer Wahrscheinlichkeit auf globalen Popularitätslisten, doch ihre Kunden vertrauen möglicherweise Rechnungen, Lieferantenportalen und Passwort-Zurücksetzungsnachrichten mit dem Unternehmensnamen.
Eine Registry könnte reagieren, indem sie ein neu identifiziertes Zeichen in bestimmten Kontexten verbietet. Dieser Ansatz kann einen Sonderfall schließen, aber auch gültige Wörter und Gemeinschaften ausschließen, die auf dieses Zeichen angewiesen sind.
Eine präzisere Richtlinie kann Varianten anhand sprachspezifischer Beziehungen definieren. Visuelle Ähnlichkeit hängt jedoch von Schriftarten, Größe, benachbarten Buchstaben und der Vertrautheit der Lesenden ab. Eine für Englischsprachige offensichtliche Sequenz kann in einer anderen Sprache ein legitimes Wort sein.
Defensive Registrierung bietet eine weitere Option. Eine Marke kann wahrscheinliche Varianten registrieren und auf die authentische Domain weiterleiten. Chromiums Navigationscode erkennt einige sichere Weiterleitungen, was dazu beiträgt, Warnungen bei Varianten zu vermeiden, die von der tatsächlichen Organisation kontrolliert werden.
Diese Strategie lässt sich nicht perfekt skalieren. Unicode enthält viele mögliche Ersetzungen, und Registrierungsrichtlinien unterscheiden sich zwischen Top-Level-Domains. Jede denkbare Lookalike-Domain zu kaufen, würde fortlaufende Kosten verursachen und dennoch Lücken lassen.
Monitoring bietet eine breitere Abdeckung. Sicherheitsteams können neue Registrierungen, Zertifikatsausstellungen, DNS-Änderungen und Hosting-Verhalten bei Namen beobachten, die wichtigen Domains ähneln. Früherkennung unterstützt Abschaltanfragen und Sperren, bevor ein Angriff viele Nutzer erreicht.
Organisationen sollten zudem risikoreiche Abläufe außerhalb des Browsers schützen. Passwortmanager gleichen Zugangsdaten mit exakten Ursprüngen ab und füllen sie daher mit geringerer Wahrscheinlichkeit auf einer Lookalike-Domain automatisch aus. Passkeys binden die Authentifizierung an die Domain der legitimen Website und widerstehen herkömmlichem Zugangsdaten-Phishing.
Mitarbeitende, die Zahlungen oder Kontowiederherstellungen bearbeiten, benötigen Prüfwege, die nicht vom Erscheinungsbild eines Links abhängen. Bekannte Lesezeichen, verwaltete Anwendungsportale und unabhängig bestätigte Kontaktkanäle reduzieren die Abhängigkeit von visueller Domain-Erkennung.
Diese Maßnahmen betreffen mehr als Unicode-Lookalikes in Chromium. Sie helfen auch gegen gewöhnliche Tippfehler, irreführende Subdomains, kompromittierte Mailboxen und geklonte Login-Seiten.
Der Druck liegt daher gleichzeitig bei mehreren Beteiligten. Chromium muss seine Heuristiken verfeinern. Registries benötigen stärkere Variantenrichtlinien. Mail-Anbieter benötigen klarere Absenderanzeigen. Organisationen benötigen Kontrollen, die davon ausgehen, dass Nutzer eine Adresse gelegentlich falsch lesen.
Was als Nächstes geschieht, wird zeigen, ob sich die Lücke wirklich schließt
Drei Signale werden bestimmen, ob diese Forschung zu einer dauerhaften Abwehr führt oder nur zu einem weiteren Eintrag in der Geschichte gepatchter Lookalikes.
Das erste Signal ist eine Regeländerung in Chromium. Die klarste Reaktion würde kyrillisches ө, lateinisches ƙ oder die Verzweigungslogik betreffen, die es einem nicht gelisteten Zeichen ermöglicht, eine vollständige Schriftsystemprüfung zu umgehen.
Allein zwei Zeichen hinzuzufügen würde die veröffentlichten Beispiele stoppen. Es würde das strukturelle Problem jedoch nicht zwangsläufig lösen. Ein anderes Zeichen mit einer sichtbaren Markierung oder einer ungewöhnlichen Skeleton-Zuordnung könnte dasselbe Ergebnis erneut erzeugen.
Ein umfassenderer Fix könnte den gerenderten Eindruck anhand zusätzlicher Skeletttransformationen vergleichen. Lockerere Vergleiche erhöhen jedoch die Zahl der Fehlalarme, insbesondere bei legitimen internationalen Namen.
Der öffentliche Code und die Tests von Chromium machen diesen Prozess nachvollziehbar. Sicherheitsforscher können prüfen, ob ein Patch die registrierten Proofs blockiert und gleichzeitig gewöhnliche Domains in den betroffenen Sprachen erhält.
Das zweite Signal sind Maßnahmen der Registrierungsstellen. Aktualisierte IDN-Tabellen könnten diese Zeichen in bestimmten Kontexten als Varianten klassifizieren oder Registrierungen verhindern, die etablierte ASCII-Bezeichnungen nachahmen.
Maßnahmen der Registrierungsstellen würden die zentrale Bewertung des Artikels stärken, weil sie täuschende Namen stoppen, bevor Darstellungsunterschiede entstehen. Ein reiner Browser-Patch ließe die Domains für E-Mail-Clients und andere Anwendungen mit abweichenden Darstellungsregeln verfügbar.
Das dritte Signal ist eine Änderung bei der Darstellung von E-Mails. HIBS stellte fest, dass Gmail alle getesteten Absenderdomains dekodierte, während Outlook die kodierten Bezeichnungen anzeigte. Künftige Änderungen an den Oberflächen könnten beide Formen offenlegen, gemischte visuelle Identitäten markieren oder warnen, wenn ein Absender einer bekannten Domain ähnelt.
Dieses Signal ist wichtig, weil E-Mails weiterhin ein naheliegender Übermittlungsweg für den Diebstahl von Zugangsdaten und Zahlungsbetrug sind. Ein Chromium-Patch kann nicht vor einem täuschenden Absendernamen schützen, der als Text innerhalb einer Webanwendung dargestellt wird.
Forscher werden die Ergebnisse nach Updates zudem erneut testen müssen. Die ursprüngliche Arbeit untersuchte zu einem bestimmten Zeitpunkt konkretes Browserverhalten, registrierte Namen und Testpostfächer. Sie belegte nicht, dass jeder Chromium-Build, jedes Betriebssystem, jede Schriftart oder jede E-Mail-Anwendung die Zeichen identisch darstellen wird.
Unterschiedliche Schriftarten können die Illusion abschwächen oder verstärken. Bei größeren Größen ist der Balken über ө leichter zu erkennen. In einer kompakten Adressleiste oder einem Absenderfeld kann dieser Unterschied weniger auffällig sein.
Die gemeldeten Registrierungen belegen außerdem die Möglichkeit, nicht eine breite Ausnutzung. Öffentliche Hinweise auf Phishing-Kampagnen mit genau diesen Zeichen würden die Dringlichkeit erhöhen. Das Ausbleiben solcher Berichte würde nicht zeigen, dass die Lücke harmlos ist, hätte aber Einfluss auf die Risikopriorisierung.
Für Nutzer ist die unmittelbare Lehre enger gefasst als „Unicode niemals vertrauen“. Prüfen Sie unerwartete Anfragen über einen bekannten Kanal, insbesondere wenn sie Zugangsdaten, Zahlungen oder die Wiederherstellung eines Kontos betreffen. Ein Lesezeichen oder Passwortmanager bietet eine bessere Referenz als die bloße visuelle Prüfung.
Administratoren sollten die wichtigsten Domains erfassen und Registrierungen überwachen, die ihnen ähneln. Setzen Sie phishing-resistente Authentifizierung für sensible Systeme voraus. Behandeln Sie neue Lieferanten- oder Zahlungsdaten als Anlass zur Überprüfung, nicht als routinemäßige E-Mail-Aufgabe.
Produktteams sollten testen, wie Anwendungen internationalisierte Absenderadressen und Links darstellen. Die Anzeige eines benutzerfreundlichen Unicode-Namens ohne Zugriff auf die kodierte Form kann nützliche Hinweise verbergen. Nur Punycode anzuzeigen, kann legitime internationale Identitäten unnötig abschreckend wirken lassen.
Die IDN-Spoofing-Abwehr von Chromium bleibt umfangreich, doch diese Forschung zeigt, dass umfangreich nicht vollständig bedeutet. Der Browser blockiert offensichtliche skriptübergreifende Ersetzungen und bekannte Tricks mit vollständigen Schriftsystemen und prüft bei der Navigation anschließend beliebte und vertraute Ziele.
Ein sorgfältig ausgewähltes Zeichen kann den maschinellen Vergleich dennoch verändern, ohne den Eindruck für einen eiligen Menschen zu verändern. Diese Lücke ist im Code klein, aber überall bedeutsam, wo Vertrauen davon abhängt, einen Namen wiederzuerkennen.
In den kommenden Monaten dürfte sich zeigen, ob Chromium, Registrierungsstellen und E-Mail-Anbieter die Beispiele als isolierte Ergänzungen einer Liste behandeln oder als Hinweis darauf, dass die Schichten andere Annahmen benötigen. Bis dahin sollten Organisationen ihre eigenen Domains testen, ursprungsgebundene Authentifizierung stärken und aufhören, Nutzer Sicherheitsentscheidungen allein anhand von Typografie treffen zu lassen.
