Phishing-Angriffe durch Clickjacking-Schwachstelle in WhatsApp möglich

• Es wurde eine Phishing-Schwachstelle entdeckt, bei der in WhatsApp-Nachrichten ein Link und eine Vorschau wie von einer legitimen Website angezeigt werden, der eigentliche Klick jedoch auf eine Angreifer-Seite führt
• Die Ursache liegt darin, dass der Link im Nachrichtentext und die Vorschaudaten getrennt übertragen werden und sich durch das Entfernen von matchedText eine Vorschau-Diskrepanz erzeugen lässt
• Das Zeichen U+202E Right-To-Left Override kann die Anzeigerichtung einer URL umkehren, sodass die eigentliche Domain wie eine legitime Domain aussieht
• Angreifer können eine Mirror-Domain des Imitationsziels vorbereiten, dann die Vorschau der Originalseite beibehalten und nur den text-Wert ändern, um Opfer zu täuschen
• Meta erklärte, die Logik zur URL-Normalisierung dynamisch anpassen zu können; Nutzer sollten Links vor dem Anklicken kopieren und die tatsächliche Adresse prüfen

---

Stelle, an der sich WhatsApp-Linkvorschau und tatsächlicher Link trennen

• Der Forscher schickte einem Freund einen webhook.site-Link, um zu prüfen, ob beim Rendern der Linkvorschau durch den Empfänger einer WhatsApp-Nachricht ein HTTP-Request ausgelöst wird
• Der HTTP-Request trat nur einmal auf der Senderseite auf; damit wurde bestätigt, dass der Empfänger den Link nicht separat rendert
• Aufgrund dieses Verhaltens nahm der Forscher an, dass WhatsApp-Nachrichten Link und Vorschaudaten gemeinsam enthalten und übertragen, und testete, ob sich beide voneinander abweichend gestalten lassen

Issue #1: Abweichung der Linkvorschau

• Der Forscher versuchte zunächst, WhatsApp-Web-Nachrichten direkt per Proxy zu verändern, doch wegen WhatsApps E2EE war eine einfache Manipulation mit Tools wie Burp Suite nicht möglich
• Stattdessen setzte er unmittelbar vor der verschlüsselten Übertragung der Nachricht per WebSocket einen Breakpoint in JavaScript und prüfte das Nachrichtenobjekt
• Im Nachrichtenobjekt existieren Linktext und Vorschaudaten als getrennte Eigenschaften
  • text: Nachrichtentext
  • canonicalURL: die Domain, die unten in der Vorschau angezeigt wird
  • matchedText: ein Wert, der offenbar mit canonicalURL verglichen wird; es wurde getestet, ob dieser Wert auch in text vorkommt
• Wenn im Nachrichtenobjekt für instagram.com der text zu google.com geändert wird, verschwindet die Vorschau und es bleibt nur der Google-Link übrig
• Wird die Eigenschaft matchedText entfernt, lässt sich eine inkonsistente Nachricht erzeugen, bei der tatsächlicher Link und Vorschau voneinander abweichen

Issue #2: Tarnung der Linkanzeige mit U+202E

• Um zu verhindern, dass der eigentliche Linktext auffällt, wurde per Fuzzing geprüft, ob Unicode-Zeichen die Textdarstellung verändern können
• U+202E ist ein Right-To-Left Override-Zeichen, das Text für Nutzer in umgekehrter Reihenfolge anzeigen kann
• Mit U+202E allein sah der Link unnatürlich aus und wirkte wenig klickwürdig; deshalb musste eine umgedrehte Zeichenfolge konstruiert werden, die wie eine normale URL erscheint

Aufbau der Mirror-URL

• Ziel war es, eine URL zu erzeugen, die in umgekehrter Darstellung wie https://instagram.com aussieht
• Eine einfache Umkehrung ergäbe moc.margatsni//:sttph, doch eine TLD wie .margatsni lässt sich nicht registrieren
• Die Lösung war, eine tatsächlich registrierbare TLD so zu verwenden, dass sie wie eine Subdomain aussieht
  • Als Beispiel kann mit der niederländischen TLD .nl eine Zeichenfolge erzeugt werden, die wie ln.instagram.com aussieht
• Damit die URL wie mit https:// beginnend erscheint, wurde hinten der gültige Pfad //:sptth angehängt
• So kann https://moc.margatsni.nl//:sptth in Kombination mit U+202E wie https://ln.instagram.com//:sptth aussehen
• Der Forscher nennt diese Methode 2K2E

Angriffsablauf

• Der Angreifer kauft eine Mirror-Domain der Seite, die er imitieren will
  • Beispiel: Damit es wie ln.instagram.com aussieht, wird moc.margatsni.nl registriert
• Zunächst wird eine Nachricht mit einem Link zur Originaldomain erstellt, um die Vorschau dieser Website zu übernehmen
  • Im Beispielobjekt enthalten text, matchedText und canonicalUrl alle https://instagram.com/
  • Ebenfalls enthalten sind vorschaubezogene Werte wie description, title, jpegThumbnail und thumbnailDirectPath
• Danach wird matchedText entfernt und der text-Wert auf die Form \u202ehttps://moc.margatsni.nl//:sptth geändert
• Die endgültige Nachricht zeigt dann eine Instagram-Vorschau, führt beim Anklicken aber auf die vom Angreifer vorbereitete Domain

Reaktion von Meta und Vergleich mit anderen Plattformen

• Meta antwortete, dass wegen der Unterstützung verschiedener Plattformen und Umgebungen die URL-Normalisierung je Plattform von der serverseitigen Logik abweichen könne
• Zudem gebe es ein System, mit dem sich die Logik zur URL-Normalisierung dynamisch anpassen lasse, falls tatsächlicher Spam oder Missbrauch auftritt
• Der Forscher bewertet dies so, dass Meta das Sicherheitsproblem nicht aktiv lösen wolle, sondern nur reagiere, wenn das System den Fall als Spam erkennt
• X, TikTok und Pinterest bereinigen das Zeichen U+202E und unterscheiden sich damit von WhatsApp

Mögliche Schutzmaßnahme für Nutzer

• Bei WhatsApp-Links ist es schwierig, allein anhand der Darstellung zu vertrauen
• Um 2K2E-Phishing zu vermeiden, sollte der Link vor dem Anklicken kopiert und die tatsächliche Adresse in der Zwischenablagen-Vorschau geprüft werden
• Die Zwischenablagen-Vorschau kann die Linkadresse in bereinigter Form ohne U+202E anzeigen
• Der Forscher fand später weitere Dienste, die wegen fehlender geeigneter Bereinigung ebenfalls für 2K2E anfällig sind

[GN⁺]

Hacker-News-Kommentare

• Eine ziemlich clevere Kombination aus missbräuchlich genutzten Funktionen, aber die gesamte Sicherheitsauswirkung würde ich eher als gering einschätzen
  Selbst im besten Fall bringt man den Empfänger nur dazu, einen Link im Browser zu öffnen; sofern es sich nicht um Angreifer wie Polizei oder Geheimdienste handelt, wäre danach normalerweise ein Folgeangriff nötig, der ungepatchte Software auf dem Gerät ausnutzt
  Technisch gesehen ist es nicht ganz korrekt, das Clickjacking zu nennen. Clickjacking bezeichnet normalerweise eine sehr spezifische Technik, bei der unsichtbare HTML-Frames über andere Inhalte gelegt werden
  https://owasp.org/www-community/attacks/Clickjacking
  https://portswigger.net/web-security/clickjacking

  • Ich würde das auch nicht Clickjacking nennen. Echtes Clickjacking bringt das Opfer dazu, unbemerkt kontobezogene Aktionen auszuführen, und nur einen unbeabsichtigten Link zu öffnen ist nicht annähernd so schwerwiegend
  • Wenn dieser Link einen Login-Bildschirm zeigt, der exakt wie Instagram aussieht, wie viel Prozent der Nutzer würden nach der einen irreführenden Bestätigung in der WhatsApp-Vorschau wohl noch einmal die URL prüfen?

• Alle konzentrieren sich nur auf UTF-Rechts-nach-links-Zeichen, aber Meta hätte zumindest anerkennen müssen, dass die Vorschau-URL von der URL in der Nachricht abweichen kann
  Ich verstehe, dass das zum Auflösen verkürzter URLs dient, aber es scheint mir, dass Meta und WhatsApp durchaus eine clevere Umgehungslösung implementieren könnten

  • Nein. Bei Ende-zu-Ende-Verschlüsselung muss die Vorschau auf Sender- oder Empfängerseite erzeugt werden. Wenn der Empfänger die Vorschau erstellt, wird seine IP offengelegt. Am Ende müsste man die Vorschaufunktion entfernen

• Bei Clickjacking glaubt man, auf ein Element zu klicken, tatsächlich fängt aber meist ein anderes, transparent darüberliegendes Element das Klick-Event ab
  Wenn man der sichtbaren unteren Ebene den Fokus gibt und das Auslösen eines onblur-Events erkennt, kann der Angreifer den Klick feststellen, auch wenn der Nutzer das Event nicht bekommt
  Was OP gefunden hat, ist cool, aber kein Clickjacking. Ich habe früher selbst schon mit RTL-Zeichen Screensaver-Dateien, also normale ausführbare Dateien mit anderer Endung unter Windows, wie Word-Dokumente aussehen lassen. Vermutlich wollte ich Freunden oder Lehrern einen Streich spielen, aber ich erinnere mich nicht mehr genau an den Grund
  OP ist noch einen Schritt weiter gegangen und hat eine Methode gefunden, bei der sich die Darstellung auf anderen Systemen verändert. Es geht also nicht darum, dass der Nutzer sich irrt, welches Element er anklickt, sondern wohin der Link führt; daher ist es kein Clickjacking, und die zu Beginn des Artikels verlinkte Wikipedia-Seite bestätigt das ebenfalls
  Ich habe Clickjacking selbst noch nie praktisch ausgenutzt gesehen, aber die von OP gefundene Methode könnte meiner Meinung nach missbraucht werden
  Ehrlich gesagt habe ich längst aufgegeben zu erwarten, dass Nutzer beim Klicken auf Links die endgültige Domain unterscheiden können. Die meisten verstehen das Konzept an sich nicht, und für den Rest ist es ebenfalls schwer
  Sogar diejenigen, die glauben, es unterscheiden zu können, verzweifeln, wenn alle Links zu so etwas wie sendgrid.tld/j3ovi3bfogobbledypoop93jnri2o führen. Wir trainieren Menschen jeden Tag darauf, verdächtige, zum Tracking verschleierte Müll-Links anzuklicken, und niemanden scheint es zu kümmern

• Cooler Hack. Das eigentliche Problem ist weder WhatsApp noch Unicode-Rückwärtszeichen, sondern dass URLs schwierig sind
  Schon an einfachen Beispielen wie visa.securesite.com fallen viele Leute darauf herein. Für die nahe Zukunft sehe ich keine gute Lösung

  • In diesem konkreten Fall wird der Nutzer aber aktiv in die Irre geführt, wenn er versucht zu verstehen, worauf er klickt; das ist eher mangelhafte Bereinigung
    Die allgemeine Verwirrung rund um Hostnamen und Domains ist ein schwierigeres Problem, aber Browser versuchen immerhin, das durch Hervorheben des Domain-Teils etwas abzumildern. Wie bei den meisten Phishing-Techniken werden Passkeys dem am Ende vermutlich ein Ende setzen

• RTL war schon immer eine Quelle enormer Sicherheitsprobleme. Ich verstehe nicht, warum es im Betriebssystem keine Einstellung gibt, mit der sich sämtliches RTL deaktivieren lässt, damit Menschen, die solche Sprachen nicht kennen, nicht ohne jeden Nutzen diesem Risiko ausgesetzt sind

  • Unabhängig vom Betriebssystem sollte es so eine Option in allen OS-Widgets geben, die Text anzeigen, einschließlich Android-TextView
    Standardmäßig sollten alle bidirektionalen Text-Bypässe deaktiviert sein, es sei denn, ein Entwickler hat einen bestimmten Textbereich ausdrücklich geprüft und erlaubt
    Es ergibt keinen Sinn, den gesamten Text-Rendering-Stack standardmäßig verwundbar zu machen, angeblich um weniger als 1 % der Weltbevölkerung entgegenzukommen

• Es ist enttäuschend, dass Meta dieses Problem nicht behebt und diesem Forscher auch keine Bug-Bounty auszahlen will

  • Ich habe Google Anfang dieses Jahres ein ähnliches Problem gemeldet, aber es wurde mit der Begründung abgelehnt, es sei „nur durch Social Engineering ausnutzbar“ und eine Behebung würde Nutzer „nicht sinnvoll weniger verwundbar machen“
    Ich werde hier nicht ins Detail gehen, aber Angreifer können wegen der Art, wie Google Search gelegentlich URLs umschreibt, die tatsächliche URL verschleiern
    Es ist generell besser, URLs, die auf Websites und in Apps angezeigt werden, niemals zu vertrauen
  • Vermutlich sind sie zu sehr damit beschäftigt, OSS-Projekten juristische Drohungen zu schicken
  • Wahrscheinlich wurde nicht klar genug formuliert, was überhaupt behoben werden soll, etwa ein Verbot von RTL-Zeichen, und Meta hat es womöglich so verstanden, als solle jede irreführende URL verhindert werden. Das ist praktisch unmöglich
  • Sie werden es wahrscheinlich beheben. Sie werden nur den Bounty Hunter nicht dafür bezahlen

• Dass „wie zu erwarten Link und Vorschau getrennt übertragen wurden!“, ist das größere UI-Design-Problem. Warum sollte ein normaler Nutzer zu seiner Sicherheit Link und Vorschau miteinander vergleichen müssen?

  • Das ist ein Sicherheitskompromiss. Um die nützliche Funktion einer Linkvorschau anzubieten, gibt es ein paar Möglichkeiten
    1. Sie wird auf Senderseite erzeugt. Nachteil: Sie kann gefälscht werden
    2. Sie wird auf Empfängerseite erzeugt. Nachteil: Die IP des Empfängers wird offengelegt
    3. Sie wird von einem Dritten erzeugt. Nachteil: Informationen fließen an den Dritten ab
       Insgesamt halte ich Option 1 für die beste. Der Sender kann seine gesamten Nachrichten ohnehin „fälschen“, und die Vorschau als Teil der Nachricht einzubetten ist kein großer Unterschied
       Das Problem hier ist, dass nicht klar ersichtlich ist, dass dieser Inhalt vom Sender stammt. Da er wie eine separate Sprechblase angezeigt wird, würden wohl 99 % der Nutzer nicht erkennen, dass der Inhalt vom Sender bereitgestellt wurde
       Außerdem ist die URL ohnehin der entscheidende Punkt. Wenn ein Angreifer kontrollierte URLs anklickbar macht, kann er in der Vorschau ohnehin anzeigen, was immer er will. Daher ist der Nutzen, eine „echte“ Vorschau erzwingen zu wollen, sehr gering
       Option 3 könnte ebenfalls funktionieren. Insbesondere mit etwas wie einem Double-Blind-Verfahren könnte man es so umsetzen, dass eine Partei die Verbindung annimmt und an eine zweite weiterleitet. Dann sieht die erste zwar die IP und die zweite das Ziel, aber solange sie nicht zusammenarbeiten, sieht keine von beiden beides gleichzeitig
       Der Nutzen wäre allerdings relativ klein gemessen daran, wie viel Infrastruktur man dafür aufbauen und betreiben müsste

• Mir gefällt, dass das ganz unten im Artikel als Reverse Engineering kategorisiert wurde

• Das ist kein Clickjacking. Bei Clickjacking kapert der Angreifer den Klick, sodass der Nutzer tatsächlich etwas anderes anklickt, als er beabsichtigt oder bemerkt
  RTL-Codepoints, die Text von rechts nach links fließen lassen, sind eine Internationalisierungsfunktion, und Menschen damit zu verwirren ist keine neue Schwachstelle