Zwanzig Jahre lang hieß Phishing zu schlagen, zu lernen, die Fälschung zu erkennen. Browser-in-the-Middle gibt Ihnen nichts zu erkennen. Es zeigt Ihnen die echte Anmeldeseite und stiehlt Ihre laufende Sitzung, während Sie zusehen. Was es stoppt, ist ein Zugangsnachweis, den Sie nicht abschreiben können.

Sie bekommen eine Nachricht über ein geteiltes Dokument, eine markierte Anmeldung, eine Rechnung. Sie klicken. Eine Microsoft-Anmeldeseite öffnet sich, und es ist die echte: die richtigen Schriftarten, das richtige Logo, die kleine Animation, wenn Sie mit Tab zwischen den Feldern wechseln, die echte Multi-Faktor-Abfrage, die Ihr Telefon vibrieren lässt. Sie bestätigen sie. Sie sind drin. Nichts fühlte sich falsch an, weil fast nichts falsch war. Die Seite, in die Sie getippt haben, war Microsofts Anmeldeseite. Nur waren nicht Sie es, der mit ihr sprach.

Ende Juni dokumentierte Harry Everett von Netcraft, wie ein Phishing-Baukasten namens Bluekit diesen Sprung vollzieht, und BleepingComputer berichtete in derselben Woche darüber. Bluekit verkauft sich als Service: ein gehosteter Phishing-Baukasten mit Vorlagen für Outlook, Gmail, iCloud, GitHub und die eine oder andere Krypto-Wallet, dazu ein eingebauter Assistent zum Verfassen der Köder-E-Mail. Sein neuer Trick trägt einen Namen, der kursiert, seit ihn ein Forscher namens mr.d0x 2022 beschrieben hat: Browser-in-the-Middle.

Die echte Seite, zu Ihnen gestreamt.

Phishing alter Schule baut eine Fälschung. Jemand klont die Anmeldeseite, hostet sie auf einer täuschend ähnlichen Domain und hofft, dass Sie die Adressleiste übergehen. Die Abwehr ist um genau das herum gewachsen: die Fälschung erkennen, den Tippfehler in der URL bemerken.

Als Nächstes kam ein Reverse-Proxy-Baukasten wie Evilginx. Er klont die Seite nicht. Er sitzt mitten in der Verbindung, ein „Adversary in the Middle“, und reicht Ihren Datenverkehr an die echte Seite weiter, während er im Vorbeifließen das Sitzungs-Cookie abschöpft. (Dieses Cookie ist das kleine Token, das eine Seite Ihrem Browser nach der Anmeldung übergibt, damit sie nicht bei jedem Klick erneut nach Ihrem Passwort fragt.) Es zu stehlen hebelt die meisten Multi-Faktor-Anmeldungen aus, weil der Angreifer den Nachweis einer abgeschlossenen Anmeldung mitnimmt, nicht das Passwort.

Browser-in-the-Middle ist seltsamer und in gewisser Weise einfacher. Der Angreifer betreibt einen echten Browser auf seinem eigenen Server und richtet ihn auf die echte Anmeldeseite. Eine Open-Source-Bibliothek namens rrweb, gebaut zum Wiedergeben von Nutzersitzungen, serialisiert diese laufende Seite und streamt sie über einen WebSocket zu Ihnen — einen dauerhaften, beidseitigen Kanal zwischen Ihrem Browser und seinem. Ihr Browser rendert die Struktur der echten Seite, als hätten Sie sie selbst geladen. Sie sehen keinen Screenshot und kein Video. Sie fernsteuern einen Browser, der im echten Geschäft sitzt, und Ihre Tastenanschläge, Ihre Maus und Ihre Multi-Faktor-Bestätigung werden an ihn zurückgereicht. Wenn die Anmeldung abgeschlossen wird, wird sie in seinem Browser abgeschlossen, und sein Server stellt das Sitzungs-Token aus. Ihm gehörte Ihre Sitzung von der ersten Sekunde an.

Browser-in-the-Middle. Der eigene Browser des Angreifers ist an der echten Seite angemeldet. Eine Bibliothek namens rrweb streamt die laufende Struktur dieser echten Seite über einen WebSocket an Ihren Browser, und Ihre Tastenanschläge und Multi-Faktor-Bestätigung werden in die andere Richtung zurückgereicht. Sie authentifizieren die Sitzung des Angreifers, nicht Ihre eigene — also erzeugt seine Maschine das Sitzungs-Token. Multi-Faktor-Bestätigung ändert daran nichts. Quelle: Netcraft.

Warum der Aufwand? Weil es auf eine Weise überzeugt, wie es ein Klon nie tut. Es gibt keine gefälschte Seite, die man falsch machen kann. Und weil der Angreifer einen einzigen, konsistenten Browser nutzt, um mit der echten Seite zu sprechen, löst die Anmeldung nicht die Fingerprint-Mismatch-Alarme aus (die kleinen Unstimmigkeiten zwischen Ihrem Gerät und dem eines Proxys), die einen Reverse-Proxy-Baukasten manchmal verraten. Netcraft zählte in einer einzigen Woche rund siebzig frische Bluekit-Hostnamen. Das ist der Ausstoß eines Produkts.

Was es nicht stoppt.

Beginnen wir mit der schlechten Nachricht, denn davon gibt es reichlich.

Multi-Faktor-Authentifizierung stoppt das in ihren gängigen Formen nicht. Ein Einmalcode und eine Push-Bestätigung beweisen dasselbe — dass gerade jetzt eine Anmeldung stattfindet —, und der Angriff braucht genau diese Anmeldung, weil der Angreifer derjenige ist, der sich anmeldet. Sie liefern den Beweis. Er behält die Sitzung.

Neuere Verfahren zur Sitzungshärtung helfen weniger, als man hoffen würde. Netcraft merkt an, dass Device Bound Session Credentials — ein Verfahren, das ein Sitzungs-Cookie an das Gerät bindet, auf dem es ausgestellt wurde — „nicht vor Browser-in-the-Middle schützen können, während sie einen gewissen Schutz gegen Adversary-in-the-Middle bieten“. Die Sitzung beginnt ihr Leben auf dem Gerät des Angreifers, also schützt es den Angreifer, sie an dieses Gerät zu binden, nicht Sie. Alles, was nach der Anmeldung angeflanscht wird, kommt zu spät, denn dann hält der Angreifer die Sitzung von Rechts wegen.

Isolation stoppt es ebenso wenig, und das sollte man deutlich sagen. Ein Browser, der jeden Tab in einer wegwerfbaren virtuellen Maschine ausführt, so wie unserer, hält in Schach, was eine Seite Ihrem Computer antun kann. Browser-in-the-Middle tut Ihrem Computer nichts. Es leiht sich Ihre Hände für eine Anmeldung und behält das Ergebnis auf einem Server, den Sie nie zu Gesicht bekommen. Sie können Ihre eigene Sitzung in dem Moment wegwerfen, in dem Sie den Tab schließen. Die Kopie, auf die es ankommt, war nie auf Ihrer Seite, um sie wegzuwerfen. Wegwerfbarkeit verteidigt gegen eine lange Liste von Angriffen, und Browser-in-the-Middle steht nicht auf der Liste.

Was es stoppt.

Kein besserer Detektor für gefälschte Seiten hilft hier, weil es keine gefälschte Seite gibt. Die Lösung ist ein Zugangsnachweis, den der Angreifer nicht abschreiben kann.

Passwörter und Einmalcodes teilen eine fatale Eigenschaft: Sie sind Zeichenketten. Sie tippen eine Zeichenkette in eine gestreamte Seite, die Leitung trägt sie, und der Browser am anderen Ende spielt sie wieder ein. Das ist das gesamte Geschäftsmodell.

Ein Passkey ist ein privater Schlüssel, der auf Ihrem Gerät lebt und es nie verlässt. Sich anzumelden bedeutet, dass Ihr Mac eine einmalige Challenge signiert, nachdem Sie sie mit Touch ID bestätigt haben, und die Signatur, die er zurückgibt, ist an genau die Website gebunden, für die Sie den Passkey erstellt haben. Daraus folgen zwei Konsequenzen, und beide brechen Browser-in-the-Middle.

Erstens gibt es nichts zu tippen, also gibt es nichts weiterzureichen. Das Geheimnis erscheint nie auf der Seite, überquert nie den WebSocket und sitzt nie in einem Formularfeld, das rrweb zurückstreamen könnte. Der Browser des Angreifers kann fragen, so viel er will; die Signierung geschieht auf einem Chip in Ihrem Mac, den der Server des Angreifers nicht erreichen kann.

Zweitens ist der Passkey für Ihre echte Bank auf die Domain Ihrer echten Bank registriert. Wenn der Host des Angreifers die Seite vor Ihnen ausliefert, sucht Ihr Mac nach einem Passkey, der dort nicht existiert, und bietet nichts an. Die Anmeldung, die einen Fingertipp dauern sollte, findet nicht statt. Diese Stille — das Autofill, das nie auslöst, und der Passkey, der nicht auf der Liste steht — ist die Warnung, die Ihnen die gefälschte Adressleiste früher gab und nun nicht mehr geben kann.

Warum ein Passkey den Angriff bricht. Links: Ein Passwort (und der Einmalcode danach) ist eine Zeichenkette. Sie tippen es in die gestreamte echte Seite, es überquert die Leitung, und der Angreifer spielt es wieder ein, um eine Sitzung zu erzeugen. Rechts: Ein Passkey ist ein Schlüssel. Ihr Mac signiert ihn hinter Touch ID, bindet ihn an die Domain der echten Seite und lässt ihn nie das Gerät verlassen — auf dem Host des Angreifers gibt es also nichts zu tippen und nichts anzubieten, und die Anmeldung kann nicht abgeschlossen werden.

Zwei Wege, die Zugangsdaten Ihres Macs zu verleihen.

Das Design des Browsers ist hier entscheidend, denn ein Passkey verteidigt Sie nur, wenn er dorthin gelangt, wo Sie sich anmelden.

Bromure führt jede Browsing-Sitzung in einer wegwerfbaren virtuellen Linux-Maschine auf Ihrem Mac aus — einem separaten kleinen Computer, den es löscht, wenn Sie das Fenster schließen. Das hält feindselige Seiten gut in Schach, wirft aber eine naheliegende Frage auf: Wenn der Browser in einer Wegwerf-Maschine lebt, woher kommen dann Ihre gespeicherten Anmeldungen? Bromure lässt Sie pro Profil wählen und teilt die Wahl bewusst in zwei Schalter.

macOS-Passwörter verwenden

Die breite Komfort-Option. Die Sitzung füllt Benutzernamen und Passwörter aus den gespeicherten Passwörtern Ihres Macs und dem iCloud-Schlüsselbund automatisch aus, und Chromiums eigener Passwortspeicher wird abgeschaltet. Sie bleibt domaingebunden, füllt also nicht in den Host des Angreifers ein. Aber ein Passwort ist eine Zeichenkette, und ein entschlossener Mensch kann eines von Hand eintippen. Komfort, mit einer weichen Kante.

macOS-Passkeys verwenden

Die enge, phishing-resistente Option. Die Sitzung meldet sich mit Passkeys an, die auf Ihrem Mac liegen, und Touch ID oder Ihr Passwort schützt jede Anfrage. Sie können dies aktivieren und das vollständige Teilen von Passwörtern dabei ausgeschaltet lassen: nur Passkeys. Nichts zu tippen, nichts weiterzureichen, nichts, was auf der falschen Domain angeboten würde. Dieser Schalter nimmt Browser-in-the-Middle vom Tisch.

Die Aufteilung ist genau der Punkt. Ihren gesamten Schlüsselbund in eine Sitzung zu teilen, ist die bequeme Voreinstellung; nur Passkeys zu teilen, ist die Option, die gegen den Angriff in diesem Artikel immun ist. Passkey-only bekommt einen eigenen Schalter, sodass die phishing-resistente Wahl Sie einen einzigen Umschalter kostet statt eines Sicherheitsprojekts. Sie können ein Profil mit genau einer Art der Authentifizierung betreiben — der Art, die sich nicht von Ihrem Bildschirm streamen lässt.

Was das nicht löst.

Ein Umschalter ist kein Kraftfeld, und die Grenzen sind wichtig.

Die große sei wiederholt. Wenn Sie sich über eine Browser-in-the-Middle-Seite mit einem Passwort anmelden, selbst mit einem Einmalcode oder einer Push-Bestätigung dahinter, bekommt der Angreifer eine funktionierende Sitzung, und weder eine wegwerfbare VM noch ein cleverer Browser holt sie zurück. Passkey-only-Teilen schützt die Anmeldungen, bei denen Sie einen Passkey verwenden, und keine anderen. Viele Seiten bieten sie noch immer nicht an, und für die ist der alte Rat der einzige Rat: Folgen Sie keinen Anmeldelinks aus Nachrichten, rufen Sie die Seite selbst auf.

Erkennung hilft, und Bromure nutzt sie: gefiltertes DNS, das bekannte bösartige Domains blockiert, und eine KI-Phishing-Prüfung, die URL und Formularstruktur einer Seite bewertet, bevor Sie handeln. Beide verbessern die Chancen. Keine ist eine Garantie, und Browser-in-the-Middle ist darauf ausgelegt, die Erkennung zu erschweren. Siebzig frische Hostnamen pro Woche hängen die meisten Blocklisten ab, und ein Inhaltsscanner findet keine gefälschte Seite zum Markieren. Erkennung fängt den nachlässigen Angreifer. Phishing-resistente Zugangsnachweise fangen den sorgfältigen.

Und die allergewöhnlichste Grenze: Einen Menschen kann man zu vielem überreden. Wenn eine überzeugende Nachricht Sie zu einer Seite ohne Passkey führt und Sie ein Passwort eintippen, das Sie anderswo wiederverwendet haben, war keine Browser-Einstellung je Teil dieser Schleife. Passkey-only-Teilen macht Sie nicht unbesiegbar. Für die Anmeldungen, die am meisten zählen — Ihre Mail, Ihr Code-Host, Ihr Identity-Provider —, entfernt es die Zeichenkette, für die der Angreifer gekommen ist, und lässt einen Schlüssel zurück, den er nicht erreichen kann.

Die gefälschte Adressleiste geht in Rente.

Der Rat, den wir zwei Jahrzehnte lang wiederholten (die URL prüfen, nach dem Schloss-Symbol suchen, der Seite misstrauen), setzte voraus, dass der Angreifer etwas fälschen musste. Browser-in-the-Middle fälscht nichts. Es reicht Ihnen das echte Stück und steht mit offenem Sack dahinter.

Das ehrliche Fazit: Ein Security-First-Browser macht Sie hiergegen nicht immun, und das sagen wir lieber, als so zu tun. Die Antwort ist von Ihren Augen zu Ihren Zugangsnachweisen gewandert. Gegen eine Seite, die Sie nicht von der echten unterscheiden können, ist die dauerhafte Verteidigung, sich mit etwas anzumelden, das Sie nicht abschreiben können: ein Passkey, signiert auf Ihrem Mac, gebunden an die echte Domain, dem Host des Angreifers nie angeboten. Bromures Anteil ist klein und konkret. Es macht das zur einfachen Voreinstellung, indem es ein Profil Passkeys teilen lässt und sonst nichts. Installieren Sie ihn, schalten Sie Passkey-only für die Konten ein, die Sie sich nicht zu verlieren leisten können, und lassen Sie die nächste perfekt aussehende Anmeldeseite Sie nach einem Geheimnis fragen, das Sie ihr nicht mehr geben müssen.