- Wenn Cloudflare-Cache und Push-Benachrichtigungen kombiniert werden, wird ein 0-Click-Deanonymisierungsangriff möglich, der den Standort eines Nutzers auf einen Bereich von einigen Hundert Meilen eingrenzen kann – auf Smartphones mit einer anfälligen App oder auf Laptops mit einer App im Hintergrund
- Der Angreifer bringt das Zielgerät dazu, automatisch eine Ressource hinter Cloudflare zu laden, und untersucht anschließend, in welchem Cloudflare-Rechenzentrum sie gecacht wurde, um eine Region in der Nähe des Ziels abzuschätzen
- Bei Signal können Anhänge wegen des Caches für
cdn2.signal.orgund mobiler Push-Benachrichtigungen auch dann heruntergeladen werden, wenn der Chat nicht geöffnet wird; bei Discord ist derselbe Angriff über die Avatar-URL in einer Freundschaftsanfrage-Benachrichtigung möglich - Cloudflare hat einen Bug im Zusammenhang mit Cloudflare Teleport gepatcht, der Anfragen an bestimmte Rechenzentren erlaubte; dennoch soll es auch mit VPN-Servern wieder möglich gewesen sein, auf etwa 54 % aller Cloudflare-Rechenzentren zuzugreifen
- Signal und Discord verwiesen die Verantwortung jeweils auf Cloudflare bzw. die Nutzerseite, während Cloudflare erklärte, das Deaktivieren von Caching für schützenswerte Ressourcen liege in der Verantwortung der Kunden – damit bleibt ein Datenschutzrisiko durch das Zusammenspiel von App-, CDN- und Benachrichtigungsdesign bestehen
Wie der Cloudflare-Cache den Standort eingrenzen kann
- Dieser Angriff nutzt Cache-Statusinformationen von Cloudflare und geografisch verteilte Rechenzentren, um den ungefähren Standort eines Nutzers zu schätzen
- Cloudflare liefert bei Anfragen nach cachebaren Ressourcen Informationen in den Antwort-Headern
cf-cache-statuszeigtHIToderMISScf-rayenthält einen Flughafencode in der Nähe des Rechenzentrums, das die Anfrage verarbeitet hat
- Wenn ein Zielgerät eine Ressource einer Cloudflare-basierten Website lädt, kann diese Ressource in einem Rechenzentrum nahe beim Ziel gecacht werden
- Untersucht man anschließend mehrere Cloudflare-Rechenzentren und findet heraus, wo die Ressource gecacht wurde, lässt sich eine Region in der Nähe des Ziels abschätzen
- Cloudflare betreibt Hunderte Rechenzentren in mehr als 120 Ländern und 330 Städten und erklärt, dass der nächstgelegene Standort für Bewohner entwickelter Länder mit hoher Wahrscheinlichkeit innerhalb von 200 Meilen liegt
Cloudflare Teleport und das Durchlaufen von Rechenzentren
- Normalerweise funktionieren die IP-Bereiche von Cloudflare per Anycast, sodass Nutzer keine direkte TCP-Verbindung zu einem bestimmten Rechenzentrum anfordern können
- Auf Basis eines Community-Forum-Beitrags, dem zufolge Cloudflare Workers und interne IP-Bereiche von Cloudflare WARP eine Umgehung ermöglichten, um HTTP-Anfragen an ein bestimmtes Rechenzentrum zu senden, entstand Cloudflare Teleport
- Cloudflare Teleport war ein auf Cloudflare Workers basierender Proxy, mit dem sich durch Angabe eines bestimmten
colo-Werts Anfragen an ein gewünschtes Rechenzentrum senden ließen- Als Beispiel wurde ein Code wie
SEAfür das Rechenzentrum Seattle verwendet - Die Zuordnung bestimmter IP-Bereiche zu Rechenzentren wurde in Form von
colos.jsonerfasst
- Als Beispiel wurde ein Code wie
- Cloudflare hat diesen Bug später vollständig gepatcht; das Teleport-Tool funktioniert mit dieser Methode nicht mehr
Proof of Concept mit dem Namecheap-Favicon
- Für die erste Verifikation wurde
favicon.icovon Namecheap verwendet - Diese Ressource war ein einfaches statisches Bild mit aktiviertem Cloudflare-Caching, und der Bot-Schutz war nicht streng, weshalb sie als Testziel gewählt wurde
- Das CLI-Tool listet für eine angegebene URL auf, welche Rechenzentren die Ressource gecacht haben und wie alt der Cache ist
- Namecheap hatte das Cache-Alter mit 5 Minuten sehr niedrig gesetzt, dennoch ließen sich Rechenzentren ermitteln, die das Favicon innerhalb der letzten 5 Minuten gecacht hatten
- Da Browser beim Öffnen einer Website automatisch das Favicon herunterladen, diente dieses Ergebnis als Proof of Concept dafür, dass Nutzer aus mehreren Regionen Namecheap.com innerhalb der letzten 5 Minuten besucht hatten
Anwendung bei Signal
- Signal verwendet zwei CDNs für die Bereitstellung von Inhalten
cdn.signal.org: auf CloudFront basierend, für Profil-Avatarecdn2.signal.org: auf Cloudflare basierend, für Nachrichtenanhänge
- Für den Pfad
https://cdn2.signal.org/attachments/*ist Cloudflare-Caching konfiguriert; wenn ein Gerät, das einen Anhang erhalten hat, ihn herunterlädt, kann er in einem nahegelegenen Rechenzentrum gecacht werden -
1-Click-Methode
- Wenn ein Nutzer in Signal einen Anhang sendet, wird die Datei zu
cdn2.signal.orghochgeladen - Öffnet der Empfänger die Unterhaltung, lädt sein Gerät den Anhang automatisch herunter; mit der geografischen Schätzung über Cloudflare-Caches lässt sich der Standort des Empfängers eingrenzen
- Im Test wurde das SSL-Pinning der Signal-Desktop-App entfernt und mit Burp wurden Anfragen und Antworten geprüft
- Wenn das Gerät des Angreifers den Anhang zuerst herunterlädt, kann in einem Rechenzentrum in der Nähe des Angreifers ein Cache entstehen und das Ergebnis verfälschen; deshalb wurden in der Signal-App auf Angreiferseite GET-Anfragen an
cdn2.signal.org/attachments/*blockiert - In einem Test in New York gegen sich selbst wurde das Rechenzentrum
EWRin Newark, NJ, gefunden; es lag etwa 150 Meilen von den tatsächlichen Koordinaten entfernt
- Wenn ein Nutzer in Signal einen Anhang sendet, wird die Datei zu
-
0-Click-Methode
- Die mobile Signal-App enthält standardmäßig Absender und Nachricht in Push-Benachrichtigungen
- Bei Nachrichten mit angehängtem Bild lädt das Gerät ein Bild vom Signal-CDN herunter, um es rechts in der Benachrichtigung anzuzeigen
- Auch wenn das Ziel die Signal-Unterhaltung nicht öffnet, kann bei Eingang einer Push-Benachrichtigung das angehängte Bild heruntergeladen werden; dabei entsteht ein Cache in einem Cloudflare-Rechenzentrum nahe beim Ziel
- Diese Methode führt zu einem 0-Click-Angriff, der den aktuellen Standort ohne Nutzerinteraktion schätzt
- Da Signal von Journalisten, Aktivisten und Whistleblowern genutzt wird, bestehen Missbrauchsrisiken wie Account-Tracking, Korrelation von Identitäten oder die Standortabschätzung von Mitarbeitern, die sich mit Journalisten treffen
Anwendung bei Discord
- Auch Discord wurde wegen CDN-Ressourcen mit aktiviertem Cloudflare-Cache als für denselben Angriffstyp anfällige App identifiziert
- Bei der 1-Click-Methode werden Custom Emojis genutzt, die Nitro-Abonnenten verwenden können
- Custom Emojis werden vom Discord-CDN geladen
- Sie können in Nachrichten, Nutzerstatus, Channels und an weiteren Stellen angezeigt werden
- Ein Angreifer kann ein Custom Emoji im Nutzerstatus anzeigen und warten, bis das Ziel das Profil öffnet
- Der vollständige an Discord eingereichte HackerOne-Bericht ist als separates Gist veröffentlicht
-
0-Click über Freundschaftsanfrage-Benachrichtigung
- Mobile Push-Benachrichtigungen von Discord werden nicht nur für Nachrichten, sondern auch für verschiedene andere Ereignisse gesendet
- Sendet man eine Freundschaftsanfrage, wird auf dem Mobilgerät des Ziels eine Push-Benachrichtigung ausgelöst
- Selbst wenn das Ziel Discord gerade nutzt, wird eine Freundschaftsanfrage-Benachrichtigung immer an das Mobilgerät gesendet
- Die Freundschaftsanfrage-Benachrichtigung enthält die Avatar-URL des anfragenden Nutzers, und das Smartphone lädt diesen Avatar ohne Nutzerinteraktion herunter, um ihn in der Benachrichtigung anzuzeigen
- Das Format der Avatar-URL von Discord unterscheidet sich je nach Kontext
- Push-Benachrichtigung:
https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash} - Anzeige auf der Website:
https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash}.png - Beide URLs verweisen auf dasselbe Bild, haben aber unterschiedliche Pfade und werden daher separat gecacht; so lässt sich der Cache, der durch die Push-Benachrichtigung geladen wurde, vom Cache unterscheiden, der durch die Anzeige im App-Profil entstanden ist
-
GeoGuesser-Automatisierung
- Der Discord-0-Click-Angriffsablauf wurde mit dem privaten Discord-Bot GeoGuesser automatisiert
- Der Bot nimmt mit einem einzigen Befehl einen Nutzernamen entgegen und führt dann folgende Schritte aus
- Er verwendet die Discord User API mit Account-Zugangsdaten
- Er ersetzt den Nutzer-Avatar durch ein zufälliges Bild, um einen neuen Avatar-Hash zu erzeugen
- Er sendet dem angegebenen Nutzer eine Freundschaftsanfrage
- Er führt über eine private API auf Basis der Cloudflare Teleport CLI den Angriff zur Cache-Aufzählung aus
- Er zeigt die Ergebnisse in Discord in weniger als 30 Sekunden an
- In einer Demonstration gegen Discord-CTO Stanislav Vishnevskiy zeigte sich, dass zwei Cloudflare-Rechenzentren den Avatar gecacht hatten
- Der Grund für zwei gefundene Rechenzentren könnte sein, dass mehrere Geräte die Benachrichtigung erhalten haben oder dass Anfragen desselben Geräts per Load Balancing auf unterschiedliche Rechenzentren verteilt wurden
- GeoGuesser berechnet mit der Google Maps API den Mittelpunkt der beiden Rechenzentren und zeigt einen Kreisradius an
- Auf der Demo-Karte lag der Discord-Hauptsitz in San Francisco, CA, innerhalb des äußeren Kreises; der tatsächliche Standort wurde nahe am Rand des inneren Kreises in einem Bereich von etwa 300 Meilen vermutet
- Der gesamte Ablauf dauerte weniger als 1 Minute, und der Angriff ist nahezu schwer zu erkennen
Bug-Bounties und Reaktionen der Organisationen
- Signal wies den Bericht sofort zurück und erklärte, nie versucht zu haben, Anonymitätsfunktionen auf Netzwerkebene wie WireGuard, Tor oder Open-Source-VPN-Software vollständig nachzubilden
- Die Gegenargumentation zu Signal stützt sich darauf, dass Signal als Privacy-First-Kommunikationsplattform vermarktet wird und Nutzer erwarten, dass Datenschutzrisiken über Ende-zu-Ende-Verschlüsselung hinaus minimiert werden
- Telegram wird als Beispiel genannt, das für diesen Angriff nicht anfällig ist
- Es verwendet ein eigenes Protokoll, das nicht auf HTTP angewiesen ist
- Es ist nicht auf das Caching von Cloud-Anbietern wie Cloudflare angewiesen
- Das Sicherheitsteam von Discord erklärte zunächst, Änderungen zum Schutz der Nutzer prüfen zu wollen, wechselte später jedoch zur Position, dass es sich um ein Cloudflare-Problem handle, das auch andere Cloudflare-Kunden betreffe
- Cloudflare patchte den Bug, den Cloudflare Teleport zum Durchlaufen von Rechenzentren verwendet hatte
- Dieser Bug war ein Jahr zuvor von einem anderen Melder bei HackerOne gemeldet worden, damals jedoch als ohne Auswirkung eingestuft worden
- Nach Weitergabe dieser Forschung öffnete Cloudflare den bestehenden Bericht erneut und behob das Problem; sowohl der ursprüngliche Melder als auch diese Meldung erhielten jeweils 200 US-Dollar Bug Bounty
Auch nach dem Patch verbleibende Probleme
- Gepatcht hat Cloudflare den Bug, der das Durchlaufen von Rechenzentren aus dem internen Netzwerk heraus ermöglichte; die Grundvoraussetzungen der cachebasierten Standortschätzung selbst verschwinden dadurch nicht
- Es wurde angegeben, dass die im Beitrag beschriebenen Angriffe auch innerhalb der letzten 24 Stunden nach dem Patch ausgeführt wurden
- Cloudflare Teleport wurde 24 Stunden nach dem Patch mit einer VPN-basierten Methode erneut implementiert
- Der ausgewählte VPN-Anbieter verfügt über mehr als 3.000 Server in 31 Ländern
- Mit dieser Methode konnte wieder auf etwa 54 % aller Cloudflare-Rechenzentren zugegriffen werden; sie decke die meisten bevölkerungsreichen Regionen ab
- Cloudflares endgültige Position ist, dass dieser Deanonymisierungsangriff nicht als Schwachstelle in den eigenen Systemen betrachtet wird und dass das Deaktivieren von Caching für schützenswerte Ressourcen in der Verantwortung der Kunden liegt
- Kunden wie Discord sehen Cloudflare in der Verantwortung, während Cloudflare der Ansicht ist, Kunden müssten ihr Caching anpassen; damit klafft die Verantwortungsgrenze auseinander
Schutzmaßnahmen und praktische Implikationen
- Dieser Angriff zeigt, dass Leistungs- und Usability-Funktionen wie Caching und Push-Benachrichtigungen in Kombination als Tracking-Mittel missbraucht werden können
- Der Cloudflare-Teleport-Bug wurde gepatcht, und manche Apps wie Signal und Discord könnten nach der Veröffentlichung Gegenmaßnahmen umgesetzt haben; das grundlegende Risiko bleibt jedoch bestehen
- Apps, die Inhalte über ein CDN bereitstellen und Caching verwenden, können ohne angemessene Vorsicht für denselben Angriffstyp anfällig sein
- Für schützenswerte Ressourcen müssen CDN-Caching-Richtlinien, automatisch in Push-Benachrichtigungen geladene Bilder und das Cache-Verhalten nutzerspezifischer eindeutiger URLs gemeinsam betrachtet werden
- Journalisten, Aktivisten, Hacker und Nutzer mit hohem Datenschutzbedarf sollten sich bewusst sein, dass App-Benachrichtigungen und das automatische Laden externer Ressourcen zur Offenlegung ihres Standorts führen können
1 Kommentare
Meinungen auf Hacker News
Wenn man einem Signal-Nutzer ein Foto sendet, wird es über Cloudflare abgerufen und in einem Rechenzentrum in der Nähe dieses Nutzers gecacht. Anschließend lässt sich über den Cache-Status herausfinden, welches Rechenzentrum verwendet wurde.
Solange sich der Nutzer nicht in einer abgelegenen Gegend befindet, scheint es übertrieben, das Deanonymisierung zu nennen, aber interessant ist der Artikel trotzdem.
Trotzdem wird Cloudflare den Cache kaum in Seattle, Manchester oder Tokio bedienen; schon das Eingrenzen eines unbekannten Signal-Nutzers auf eine grobe geografische Position ist daher wichtige Metadaten, die sich mit anderen Informationen kombinieren lassen, um eine Person offenzulegen. Ein eleganter Angriff.
Cloudflare kann in privaten und Gruppen-Chats enorme Mengen an Metadaten sehen und anhand der Dateigröße nachverfolgen, wer die ursprünglichen Medien gesendet hat, wer sie gelesen hat, wann sie gelesen wurden, wer sie weitergeleitet hat und an wen. Auch wenn Cloudflare die Bilder oder Videos nicht direkt sehen kann, reicht es aus, wenn die Größe vorab bekannt ist oder später etwa durch eine Anfrage von Strafverfolgungsbehörden bekannt wird.
Diese Information allein reicht immer noch nicht aus, aber wenn es einen konkreten Verdächtigen gibt, kann sie bei der Bestätigung helfen. Wenn man direkt an die verdächtige Person herankommt und sich auch mit deren „sauberem“ Profil anfreunden kann, ließen sich mit derselben Technik zwei Standortprofile abgleichen. Deanonymisierung ist keine einzelne Information, sondern ein Prozess, bei dem alle Informationen zu einem Profil beitragen, das Verdächtige eingrenzt oder einen Verdacht bestätigt.
Mit „Ermittler“ ist hier keine AI-Agent oder Strafverfolgungsbehörde gemeint, sondern eine normale Person. Strafverfolgungsbehörden könnten Informationen vermutlich direkter von Cloudflare erhalten.
Ob genau dieses Maß und diese Art der Deanonymisierung für den eigenen Anwendungsfall problematisch ist, ist eine andere Frage. Ich persönlich hätte kein großes Problem damit, wenn gegenseitige Kontakte meine IP-Adresse direkt sehen würden, aber das gilt nicht für alle Nutzer.
Auch bei den Ermittlungen zu Silk Road waren Informationen auf dieser Ebene tatsächlich wichtig. Ulbricht hatte anfangs versehentlich seine Zeitzone preisgegeben, wodurch US-Behörden ihn auf eine Person in den USA eingrenzen konnten. Ohne diese Information hätte er überall auf der Welt sein können.
Ein guter Artikel mit interessanter Technik und Herangehensweise.
Allerdings sind Formulierungen wie „Deanonymisierung“ oder „Nutzerstandort erlangen“ etwas übertrieben. Von einem präzisen Standort ist das weit entfernt; 150 Meilen entsprechen ungefähr zwei Stunden Fahrt auf dem Highway von Atlanta, GA, nach Augusta, GA. In diesem Radius leben wahrscheinlich mehr als 700.000 Menschen.
Signals Funktion zum automatischen Abrufen von Anhängen ist etwas besorgniserregend. Bei einem privaten Messenger hätte ich erwartet, dass es wie beim Deaktivieren von JavaScript in Tor eine Option zum Abschalten gibt; vielleicht habe ich nicht tief genug gesucht, aber ich konnte so eine Funktion nicht finden.
Signal scheint für die breite Akzeptanz einen „standardmäßig nützlichen“ Ansatz zu wählen, der Datenschutz und Benutzbarkeit ausbalanciert. Nutzer, die sich wirklich Sorgen machen, werden Signal wahrscheinlich mithilfe von Leitfäden wie https://www.privacyguides.org/articles/2022/07/07/signal-con... härten. Für Hochrisiko-Szenarien wurden VPN/Proxy und geänderte Einstellungen schon immer empfohlen.
Caching wird nicht verschwinden, CloudFlare auch nicht. Die DDoS-Gefahr in alten P2P-Multiplayer-Lobbys, in denen IPs offengelegt wurden, wirkte größer als das hier, und unter den Dritten scheint CloudFlare am besten zu reagieren. Grundsätzlich sollten sensible Informationen nicht gecacht werden, und die Verantwortung, einem CDN oder Zwischendienst mitzuteilen, bestimmte Objekte nicht zu cachen, liegt bei der kommunizierenden Anwendung.
Cool. Anders als bei manch anderem kann man das hier eindeutig als Deanonymisierung sehen, oder zumindest als etwas, das dem sehr nahekommt. Wie anonym wäre Satoshi heute noch geblieben, wenn man seinen Standort auf 250 Meilen genau hätte eingrenzen können?
Wenn man diesen Angriff wiederholt anwendet, auf irgendeine Weise getarnt, kann man Bewegungen über die Zeit verfolgen. Meist reichen schon 4–5 Standorte in der Größenordnung einer Postleitzahl aus, um eine Person eindeutig zu identifizieren.
Auch der Ansatz, den Apple und Cloudflare in ihrer Datenschutzsoftware verwenden, basiert auf der Idee, dass die Region keine identifizierende Information ist. Das gilt für Apples iCloud Private Relay ebenso wie für Cloudflares WARP: Ist Apple Private Relay aktiviert, wird die ursprüngliche IP verborgen, aber die IP, über die der Traffic geroutet wird, liegt im selben Land.
https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overv...
Dieser Angriff ist akademisch interessant und neu, aber keine „Deanonymisierung“.
Natürlich könnte es auch nicht er gewesen sein, sondern ein zufälliger früher Nutzer. Trotzdem halte ich es für einigermaßen möglich, dass er es war.
Details: https://news.ycombinator.com/item?id=29728339
Ich unterstütze keine Versuche, seinen Namen und seine Adresse herauszufinden und öffentlich zu machen, weil das sein Leben erschweren könnte. Aber abstrakt betrachtet ist es äußerst spannend, dass es trotz der vielen Augen, die über Jahre darauf gerichtet waren, ein ungelöstes Rätsel geblieben ist.
Ich verstehe nicht, warum so viele Top-Kommentare die Schwere herunterspielen. Das ist genau die Art von Angriff, mit der Strafverfolgungsbehörden oder böswillige Akteure Standortbelege aufbauen können.
Ein Standortnachweis ist keine Deanonymisierung, besonders nicht, wenn dieser „Standort“ so großflächig ist.
Man versucht es erst einmal zu ignorieren und schaut, ob das Problem am Morgen noch da ist. Bis dahin hofft man, dass jemand einen Grund findet, warum es kein Problem ist.
Warum hat Signal für diese URLs Caching aktiviert? Der häufigste Fall dürfte sein, dass ein Anhang einmal heruntergeladen wird und das war’s.
Ich hätte eher erwartet, dass man mehr als einen Download verhindert und die Datei nach dem ersten erfolgreichen Download sofort löscht. Natürlich kann der Client zwischendurch scheitern, daher könnte es eine Schonfrist für erneute Downloads geben. Trotzdem scheint mir das nicht der Normalfall zu sein; wenn man CDN-Caching deaktiviert, ließe sich dieses Problem beheben, und hoffentlich würden die Kosten nicht stark steigen.
Jedenfalls ist „Deanonymisierung“ hier etwas clickbaitig. Den Standort einer Person auf etwa 250 Meilen einzugrenzen, ist nicht gut, aber es deanonymisiert sie nicht.
Edit: Ich hatte nicht daran gedacht, dass Anhänge in Gruppenchats gesendet und dann von mehreren Personen heruntergeladen werden. Aber selbst dann werden Anhänge nicht für jede Person in der Gruppe einzeln verschlüsselt? Ich weiß natürlich nicht genau, wie es tatsächlich funktioniert.
Die genannten Dinge können Menschen, die ein derart extremes Maß an Datenschutz und Sicherheit wollen, praktisch konfigurieren. Nachrichten lassen sich 30 Sekunden nach dem Ansehen automatisch löschen, sämtlicher Traffic kann über einen Proxy geroutet werden, und vieles mehr kann nach Geschmack angepasst werden.
Der Grund für das Caching sind vermutlich Übertragungskosten. Dateianhänge, Sprachnachrichten, Videos usw. summieren sich.
Das ist derselbe 15-Jährige, der vor ein paar Monaten die Zendesk-Slack-Übernahme-Schwachstelle gefunden hat [1]
[1]: https://news.ycombinator.com/item?id=41818459
Den Bug-Report an Adobe hätte er dann mit fünf Jahren geschrieben: https://hackerone.com/daniel?type=user
Es ist zwar eindeutig ein „Angriff“, aber nicht die Art, an die man normalerweise bei Zero-Click denkt. Es gibt keine Codeausführung; stattdessen wird mit ein paar Tricks ermittelt, welches Cloudflare-Rechenzentrum das Bild gecacht hat, um so die sehr grobe Region des Nutzers zu erhalten.
Trotzdem beeindruckend und aufschlussreich.
Solche Akteure können mit lokalen Ressourcen zusammenarbeiten und weiter ermitteln. Allein zu wissen, welche Ressourcen in welcher Region eingesetzt werden müssen, kann viel Geld sparen.
Wie gesagt: beeindruckend und aufschlussreich. Das Dokument wirkt stellenweise ein wenig, als sei ChatGPT zur Hilfe genommen worden, mit vielen sehr klaren und spezifischen Formulierungen. Für diesen Zweck ist das ein guter Anwendungsfall, daher ist das kein Vorwurf. Guter Text.
Wenn ich nichts übersehe, wirkt das wie eine sehr umständliche Methode, den IP-Standort eines Nutzers zu ermitteln.
Wenn ich mich zum Beispiel mit einem VPN verbinde und https://cloudflare.com/cdn-cgi/trace aufrufe, bekomme ich
colo:CPH(Copenhagen). Das ist geografisch weit von meinem nächstgelegenen CF-Rechenzentrum entfernt und näher am IP-Standort des VPN-Anbieters in Oslo, aber trotzdem nicht wirklich nah.Ohne VPN bekomme ich nicht einmal die Hauptstadt des Landes, in dem ich gerade bin, sondern ein Rechenzentrum etwa 250 Meilen nördlich. Daher fällt es mir schwer zuzustimmen, dass Cloudflare immer das „nächstgelegene verfügbare Rechenzentrum“ zurückgibt.
Der Artikel selbst ist gut und definitiv interessant, aber von der praktischen Nutzbarkeit bin ich nicht überzeugt.
Die praktische Nutzbarkeit und das potenzielle Risiko entstehen, wenn diese Daten mit anderen Daten kombiniert werden. Deanonymisierungstechniken mit spärlichen Datensätzen sind seit mindestens 15 Jahren ein aktives Forschungsfeld, und Menschen sind oft überrascht, wie viel sich aus ein paar scheinbar unzusammenhängenden Datenpunkten ableiten lässt.
Es gibt einen Grund, warum Anwendungen großen Aufwand betreiben, um Anfragen nach Ressourcen wie Bildern zu proxyn. Das ist nicht kostenlos.
Welchen Vorteil hat es bei Signal, Bilder in einem CDN zu cachen?
Wenn man lokales Client-Caching annimmt, sollte die Gesamtzahl der Anfragen für diese Ressource sehr klein sein, in den meisten Fällen wahrscheinlich nur eine.
Separat davon könnte CloudFront dieses Problem wohl sehr einfach beheben, indem es den
cf-ray-Header nicht zurückgibt oder Kunden eine Option bietet, ihn zu entfernen. Allerdings könnte man es über Timing-Informationen vielleicht trotzdem herausfinden.„Nähe“ ist hier eine ungefähre Heuristik und eine Eigenschaft der Anycast-Routingtabellen der BGP-Router, über die die Anfrage läuft. In der Praxis entspricht es eher dem „optimalen Pfad“.
cf-ray-Header entfernt, kann man einfach die Antwortzeit betrachten. Wenn die Ressource von einem anderen Kontinent geholt werden muss, lässt sich das wahrscheinlich zuverlässig messen.Ähnlich ist es bei Websites, die verbergen wollen, ob ein bestimmter Nutzer existiert. Wenn man einen Login-Versuch mit einem existierenden Nutzernamen macht, wird Passwort-Hashing durchgeführt, wodurch die Antwortzeit in der Regel um mindestens 50 ms steigt; bei einem nicht existierenden Nutzernamen wird früh abgebrochen. Die Lösung ist, immer denselben Code auszuführen und also auch immer zu hashen, aber sehr wenige Websites tun das. Oder man sagt, wenn es zum Threat Model passt, direkt, dass der Nutzername nicht existiert.
Zurück zum Cloudflare-Fall: Solange die Antwort nicht verzögert wird, hilft das nicht. Antwortverzögerung ist aber das Gegenteil dessen, was Cloudflare leisten soll.
Ist der „Angriff“ hier nicht, dass jeder Nutzer einem anderen Nutzer eine Nachricht mit einem Link zu einer im CDN gecachten Ressource schicken kann? Vielleicht habe ich das auch missverstanden.
Ich verstehe das nicht so ganz. Hat jemals jemand Signal für anonym gehalten? Bei Discord genauso. Falls ja, gibt es schlechte Nachrichten: Beide sind nicht anonym, überhaupt nicht, nicht im Geringsten anonym.
Sie haben das auch nie behauptet. Signal behauptet nur, Nachrichten nicht lesen zu können. Bei Discord weiß ich es nicht genau, und ich bin skeptisch. Auch diese Behauptung hat Schwachstellen. Selbst wenn die Kryptografie solide ist: Hast du die aktuell verwendete Version gründlich geprüft und selbst kompiliert?
Bestenfalls ist es eine schwache Pseudonymität. Dass Anwendungen, die zugunsten der Benutzerfreundlichkeit etwas Sicherheit opfern, standardmäßig Medien laden, war schon immer üblich, und im normalen Threat Model ist das eine vertretbare Entscheidung. Medien in Nachrichten einzubetten war ebenfalls schon immer ein Klassiker unter den Deanonymisierungsangriffen.
Am Ende zeigt es nur, dass Tracking-Pixel auch heute noch eine wirksame Technik sind; gut, aber nicht überraschend.
Wer anonym bleiben will, sollte weder Discord noch Signal nutzen, und ich würde auch nicht empfehlen, auf HN zu posten. Vielleicht hätte man eine Chance, wenn man über Whonix mit einem Wegwerf-Account, ohne JavaScript, zu zufälligen Zeiten automatisch Nachrichten einfügen lässt, die zuvor von einem lokalen LLM umgeschrieben wurden. Trotzdem sollte man sich darauf nicht verlassen.
Anonymität gibt es nicht mehr.