Une attaque de désanonymisation en 0-click visant des plateformes comme Signal et Discord

 (gist.github.com/hackermondev)
1 points par GN⁺ 2025-01-22 | 1 commentaires | Partager sur WhatsApp
  • La combinaison du cache Cloudflare et des notifications push permet une attaque de désanonymisation en 0-click capable de réduire la localisation d’un utilisateur à une zone de quelques centaines de miles, sur un téléphone avec une app vulnérable installée ou sur un ordinateur portable avec une app en arrière-plan
  • L’attaquant force l’appareil ciblé à charger automatiquement une ressource derrière Cloudflare, puis détermine dans quel datacenter Cloudflare elle a été mise en cache afin d’estimer la région proche de la cible
  • Dans Signal, à cause du cache des pièces jointes de cdn2.signal.org et des notifications push mobiles, une image jointe peut être téléchargée même sans ouvrir la conversation ; dans Discord, la même attaque est possible via l’URL d’avatar d’une notification de demande d’ami
  • Cloudflare a corrigé un bug lié à Cloudflare Teleport qui permettait d’envoyer des requêtes vers des datacenters précis, mais même en passant par des serveurs VPN, il aurait encore été possible de réaccéder à environ 54 % de l’ensemble des datacenters Cloudflare
  • Signal et Discord ont renvoyé la responsabilité vers Cloudflare ou vers l’utilisateur, tandis que Cloudflare affirme qu’il revient au client de désactiver le cache sur les ressources à protéger, ce qui laisse subsister un risque pour la vie privée lié à la conception des apps, du CDN et des notifications

Principe du resserrement de localisation via le cache Cloudflare

  • Cette attaque exploite les informations d’état du cache de Cloudflare et ses datacenters géographiquement distribués pour estimer la localisation approximative d’un utilisateur
  • Cloudflare fournit des informations dans les en-têtes de réponse pour les requêtes sur des ressources mises en cache
    • cf-cache-status indique HIT ou MISS
    • cf-ray contient le datacenter qui a traité la requête ainsi qu’un code d’aéroport proche
  • Quand l’appareil ciblé charge une ressource d’un site reposant sur Cloudflare, cette ressource peut être mise en cache dans un datacenter proche de la cible
  • En interrogeant ensuite plusieurs datacenters Cloudflare pour voir où la ressource est présente dans le cache, il devient possible d’estimer la zone proche de la cible
  • Cloudflare explique exploiter plusieurs centaines de datacenters dans plus de 120 pays et 330 villes, et qu’un habitant d’un pays développé a de fortes chances d’avoir un datacenter à moins de 200 miles

Cloudflare Teleport et le parcours des datacenters

  • En temps normal, les plages d’IP Cloudflare fonctionnent en anycast, ce qui empêche de demander directement une connexion TCP à un datacenter précis
  • Sur la base d’un message de forum communautaire expliquant qu’il était possible de contourner cela avec Cloudflare Workers et les plages IP internes de Cloudflare WARP pour envoyer des requêtes HTTP vers un datacenter spécifique, Cloudflare Teleport a été créé
  • Cloudflare Teleport était un proxy basé sur Cloudflare Workers permettant d’envoyer des requêtes vers le datacenter voulu en indiquant une valeur colo
    • Par exemple, le code SEA correspondait au datacenter de Seattle
    • Les correspondances entre certaines plages d’IP et les datacenters étaient organisées sous la forme d’un colos.json
  • Cloudflare a depuis entièrement corrigé ce bug, et l’outil Teleport ne fonctionne plus de cette manière

Preuve de concept vérifiée avec le favicon de Namecheap

  • Pour la première validation, le favicon.ico de Namecheap a été utilisé
  • Cette ressource était une simple image statique avec le cache Cloudflare activé, et la protection anti-bot n’y était pas trop stricte, ce qui en faisait un bon sujet de test
  • L’outil CLI listait, pour une URL donnée, les datacenters ayant mis la ressource en cache ainsi que l’âge du cache
  • Namecheap avait réglé l’âge du cache à seulement 5 minutes, mais il était malgré tout possible d’identifier les datacenters ayant mis en cache le favicon dans les 5 dernières minutes
  • Comme le navigateur télécharge automatiquement le favicon lors de l’ouverture d’un site, ce résultat servait de preuve de concept montrant que des utilisateurs situés dans plusieurs régions avaient visité Namecheap.com dans les 5 minutes précédentes

Application à Signal

  • Signal utilise deux CDN pour la diffusion de contenu
    • cdn.signal.org : basé sur CloudFront, pour les avatars de profil
    • cdn2.signal.org : basé sur Cloudflare, pour les pièces jointes des messages
  • Le chemin https://cdn2.signal.org/attachments/* est mis en cache par Cloudflare ; lorsqu’un appareil recevant une pièce jointe la télécharge, elle peut être mise en cache dans un datacenter proche

  • Méthode en 1-click

    • Lorsqu’un utilisateur envoie une pièce jointe dans Signal, le fichier est téléversé sur cdn2.signal.org
    • Quand le destinataire ouvre la conversation, son appareil télécharge automatiquement la pièce jointe, ce qui permet de resserrer sa localisation grâce à l’estimation géographique basée sur le cache Cloudflare
    • Lors des tests, le SSL pinning de l’app Signal Desktop a été retiré et les requêtes/réponses ont été inspectées avec Burp
    • Si l’appareil de l’attaquant téléchargeait d’abord la pièce jointe, cela pouvait polluer le résultat en créant un cache près de l’attaquant ; les requêtes GET vers cdn2.signal.org/attachments/* ont donc été bloquées dans l’app Signal côté attaquant
    • Lors d’un test d’auto-ciblage depuis New York, le datacenter EWR de Newark, New Jersey, a été observé, à environ 150 miles de la position réelle

  • Méthode en 0-click

    • Par défaut, l’app mobile Signal inclut l’expéditeur et le message dans les notifications push
    • Lorsqu’un message contient une image en pièce jointe, l’appareil télécharge l’image depuis le CDN de Signal pour l’afficher à droite de la notification
    • Même si la cible n’ouvre pas la conversation, l’arrivée d’une notification push peut suffire à déclencher le téléchargement de l’image jointe, créant ainsi une entrée de cache dans un datacenter Cloudflare proche
    • Cette méthode aboutit à une attaque en 0-click permettant d’estimer la position actuelle sans interaction de l’utilisateur
    • Comme Signal est utilisé par des journalistes, des militants et des lanceurs d’alerte, les risques d’abus incluent le suivi de compte, la corrélation d’identité ou l’estimation de la position d’un employé rencontrant un journaliste

Application à Discord

  • Discord a lui aussi été identifié comme vulnérable au même type d’attaque à cause de ressources CDN mises en cache par Cloudflare
  • Dans la méthode en 1-click, on exploite des émojis personnalisés disponibles pour les abonnés Nitro
    • Les émojis personnalisés sont chargés depuis le CDN de Discord
    • Ils peuvent s’afficher à plusieurs endroits, comme dans les messages, le statut utilisateur ou les salons
    • Un attaquant peut afficher un émoji personnalisé dans son statut et attendre que la cible ouvre son profil
  • Le rapport HackerOne complet soumis à Discord est publié dans un Gist séparé

  • 0-click via les notifications de demande d’ami

    • Les notifications push mobiles de Discord ne sont pas envoyées seulement pour les messages, mais aussi pour divers autres événements
    • L’envoi d’une demande d’ami déclenche une notification push sur l’appareil mobile de la cible
    • Même si la cible utilise déjà Discord, la notification de demande d’ami est toujours envoyée sur l’appareil mobile
    • Cette notification inclut l’URL d’avatar de l’utilisateur ayant envoyé la demande, et le téléphone télécharge cet avatar sans interaction de l’utilisateur afin de l’afficher dans la notification
    • Le format des URL d’avatar de Discord varie selon le contexte
    • Notification push : https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash}
    • Affichage sur le site web : https://cdn.discordapp.com/avatars/{user_id}/{avatar_hash}.png
    • Les deux URL pointent vers la même image, mais comme leurs chemins diffèrent, elles sont mises en cache séparément, ce qui permet de distinguer un cache créé par une notification push d’un cache créé lors de l’affichage du profil dans l’app

  • Automatisation GeoGuesser

    • La procédure d’attaque 0-click contre Discord a été automatisée dans un bot Discord privé appelé GeoGuesser
    • Avec une seule commande, le bot prend un nom d’utilisateur et exécute les opérations suivantes
      • Utilise les identifiants du compte via l’API utilisateur de Discord
      • Remplace l’avatar de l’utilisateur par une image aléatoire afin de générer un nouveau hash d’avatar
      • Envoie une demande d’ami à l’utilisateur ciblé
      • Lance l’attaque d’énumération du cache via une API privée basée sur la CLI Cloudflare Teleport
      • Affiche le résultat dans Discord en moins de 30 secondes
    • Lors d’une démonstration visant le CTO de Discord, Stanislav Vishnevskiy, deux datacenters Cloudflare se sont révélés avoir mis l’avatar en cache
    • La présence de deux datacenters peut s’expliquer soit par la réception de la notification sur plusieurs appareils, soit par un équilibrage de charge envoyant les requêtes d’un même appareil vers différents datacenters
    • GeoGuesser utilise l’API Google Maps pour calculer le point médian entre les deux datacenters et afficher un cercle de rayon
    • Sur la carte de démonstration, le siège de Discord à San Francisco, Californie, se trouvait dans le grand cercle, et la position réelle était estimée près du bord du cercle intérieur, dans une zone d’environ 300 miles
    • L’ensemble du processus prenait moins d’une minute et l’attaque était presque impossible à détecter

Bug bounty et réponses des organisations

  • Signal a immédiatement rejeté le signalement, affirmant n’avoir jamais cherché à reproduire entièrement des fonctions d’anonymat au niveau réseau comme celles de WireGuard, Tor ou des logiciels VPN open source
  • La réponse opposée à Signal repose sur le fait que Signal est présenté comme une plateforme de communication axée sur la vie privée, et que les utilisateurs s’attendent à une réduction des risques dépassant le seul chiffrement de bout en bout
  • Telegram est cité comme exemple non vulnérable à cette attaque
    • Il utilise son propre protocole, qui ne dépend pas de HTTP
    • Il ne s’appuie pas sur le cache d’un fournisseur cloud comme Cloudflare
  • L’équipe sécurité de Discord a d’abord indiqué qu’elle examinerait des changements pour protéger les utilisateurs, avant d’adopter ensuite la position selon laquelle il s’agissait d’un problème Cloudflare touchant aussi d’autres clients
  • Cloudflare a corrigé le bug utilisé par Cloudflare Teleport pour parcourir les datacenters
    • Ce bug avait déjà été signalé un an plus tôt sur HackerOne par un autre chercheur, mais son impact avait alors été jugé nul
    • Après le partage de cette nouvelle recherche, Cloudflare a rouvert le rapport existant et l’a corrigé, versant une prime de 200 dollars à l’auteur initial et 200 dollars pour ce nouveau signalement

Le problème persiste après le correctif

  • Ce que Cloudflare a corrigé, c’est le bug qui permettait de parcourir les datacenters depuis son réseau interne ; les conditions fondamentales de l’estimation de localisation fondée sur le cache n’ont pas disparu
  • Il est indiqué que les attaques décrites dans l’article ont encore été exécutées dans les 24 heures suivant le correctif
  • Cloudflare Teleport a été réimplémenté 24 heures après le correctif en s’appuyant sur une méthode basée sur un VPN
  • Le fournisseur VPN retenu disposait de plus de 3 000 serveurs dans 31 pays
  • Cette méthode permettait de réaccéder à environ 54 % de l’ensemble des datacenters Cloudflare, couvrant selon l’auteur la plupart des zones fortement peuplées
  • La position finale de Cloudflare est qu’il ne considère pas cette attaque de désanonymisation comme une vulnérabilité de ses systèmes, et que la désactivation du cache pour les ressources nécessitant une protection relève de la responsabilité du client
  • Des clients comme Discord estiment que cela relève de Cloudflare, tandis que Cloudflare considère que le client doit ajuster sa politique de cache, ce qui révèle une frontière de responsabilité floue

Protection et implications pratiques

  • Cette attaque montre que des fonctions de performance et d’ergonomie comme la mise en cache et les notifications push peuvent être détournées en outil de traçage lorsqu’elles sont combinées
  • Le bug de Cloudflare Teleport a été corrigé et certaines apps comme Signal ou Discord ont peut-être mis en place des mesures d’atténuation après la divulgation, mais le risque de fond demeure
  • Les apps qui diffusent du contenu via un CDN et utilisent le cache peuvent être vulnérables au même type d’attaque en l’absence de précautions appropriées
  • Pour les ressources à protéger, il faut considérer ensemble la politique de cache du CDN, les images chargées automatiquement dans les notifications push et le comportement du cache sur des URL uniques par utilisateur
  • Les journalistes, militants, hackers et utilisateurs sensibles à la vie privée doivent être conscients que les notifications d’app et le chargement automatique de ressources externes peuvent entraîner une fuite de leur localisation

À lire aussi

1 commentaires

 
GN⁺ 2025-01-22
Avis de Hacker News

  • Si vous envoyez une photo à un utilisateur de Signal, elle est récupérée via Cloudflare et mise en cache dans un datacenter proche de cet utilisateur. On peut ensuite interroger l’état du cache pour savoir quel datacenter a été utilisé.
    À moins que l’utilisateur ne se trouve dans une région isolée, parler de désanonymisation semble exagéré, mais l’article reste intéressant.

    • Même l’idée de « proche de l’utilisateur » repose sur une grosse hypothèse. Dans mon cas, je suis à environ 200 miles d’ORD et 500 miles d’IAD, mais à cause du peering de mon FAI et de la configuration de ses réseaux amont, Cloudflare traite mon trafic depuis DFW, à 700 miles de là.
      Cela dit, Cloudflare ne va pas servir le cache depuis Seattle, Manchester ou Tokyo, donc le simple fait de réduire la localisation géographique approximative d’un utilisateur Signal inconnu constitue déjà une métadonnée importante pouvant être recoupée pour identifier une personne. Belle attaque.
    • Si l’on pense à l’impact sur les groupes, ça devient encore plus intéressant. Rien qu’en envoyant une image à un groupe, tous les appareils de ce groupe deviennent identifiables côté Cloudflare, qui voit aussi de gros volumes de trafic non chiffré envoyés par les mêmes adresses clientes vers d’autres sites web.
      Cloudflare peut voir une quantité énorme de métadonnées dans les conversations privées et de groupe, et suivre, via la taille des fichiers, qui a envoyé le média d’origine, qui l’a lu, quand il l’a lu, qui l’a transféré et à qui. Même sans voir directement les images ou vidéos, il suffit d’en connaître la taille à l’avance, ou de l’apprendre plus tard via une demande des forces de l’ordre, par exemple.
    • Cela peut être utile pour de l’analyse de corrélation. Par exemple, supposons qu’un enquêteur soit en contact régulier avec quelqu’un : un point de données isolé ne signifie rien, mais un historique quotidien de téléchargements d’images peut suggérer que cette personne passe 90 % de son temps dans l’État de Washington et 10 % ailleurs.
      Même si cette information reste insuffisante à elle seule, elle peut aider à confirmer une piste lorsqu’il existe un suspect précis. Si l’on peut entrer directement en contact avec la personne soupçonnée et devenir aussi ami avec son profil « propre », on pourrait utiliser la même technique pour faire correspondre les deux profils de localisation. La désanonymisation n’est pas une information unique, mais un processus où chaque élément s’ajoute à un profil qui permet de réduire la liste des suspects ou de confirmer un soupçon.
      Ici, par « enquêteur », il faut comprendre une personne ordinaire, pas un agent IA ni les forces de l’ordre. Les forces de l’ordre pourraient probablement obtenir des informations bien plus directement auprès de Cloudflare.
    • Ce n’est pas exagéré. Quand on reçoit un message sur Signal, on s’attend à ce que les aspects observables de l’adresse IP ou de la localisation ne soient pas révélés.
      La question de savoir si ce niveau et ce type précis de désanonymisation posent problème pour son propre usage est distincte. Personnellement, cela ne me dérangerait pas vraiment qu’un contact mutuel voie directement mon adresse IP, mais ce n’est pas le cas de tous les utilisateurs.
    • La « désanonymisation » ne signifie pas forcément obtenir l’adresse exacte du domicile. Certaines personnes veulent cacher le pays ou la région où elles vivent, et cette attaque affaiblit cette protection.
      Dans l’enquête Silk Road, ce type d’information a réellement compté. Ulbricht avait révélé son fuseau horaire par erreur au début, ce qui a permis aux autorités américaines de réduire le champ aux personnes se trouvant aux États-Unis. Sans cette information, il aurait pu être n’importe où dans le monde.

  • Bon article, avec une technique et une approche intéressantes.
    Cela dit, les expressions « désanonymisation » ou « obtention de la position de l’utilisateur » sont quelque peu exagérées. On est loin d’une localisation précise, et 150 miles représentent environ 2 heures de route sur autoroute entre Atlanta, GA, et Augusta, GA. Il y a probablement plus de 700 000 personnes dans ce rayon.
    La fonctionnalité de récupération automatique des pièces jointes de Signal est un peu préoccupante. Pour une messagerie privée, je m’attendais à une option pour la désactiver, comme on désactive JavaScript dans Tor ; peut-être que je n’ai pas cherché assez profondément, mais je n’ai pas vu une telle fonction.
    Signal semble avoir choisi une approche « utile par défaut », qui équilibre confidentialité et utilisabilité afin de favoriser l’adoption par le grand public. Les utilisateurs vraiment inquiets renforceront probablement Signal avec des guides comme https://www.privacyguides.org/articles/2022/07/07/signal-con.... Pour les scénarios à haut risque, on a toujours recommandé un VPN/proxy et des changements de configuration.
    La mise en cache ne disparaîtra pas, pas plus que CloudFlare. Les menaces de DDoS dans les anciens lobbys multijoueurs P2P, où l’IP était exposée, me semblaient plus graves que cela, et parmi les tiers, la réponse de CloudFlare paraît être la meilleure. Le principe devrait être de ne pas mettre en cache les informations sensibles, et c’est à l’application qui communique qu’incombe la responsabilité d’indiquer au CDN ou au service intermédiaire de ne pas mettre certains éléments en cache.

    • Il est facile de penser ainsi, mais ces données se combinent rapidement avec les petites informations que les gens partagent. Des détails anodins comme « j’ai conduit 15 minutes jusqu’au Starbucks » s’accumulent avec le temps et peuvent mener à une localisation précise.
    • Le téléchargement automatique peut être désactivé. Dans Settings > Data and storage > Media auto-download, on peut choisir ce qui est téléchargé automatiquement selon les données mobiles, le Wi‑Fi et l’itinérance.
    • Point séparé et mineur : dans un cercle de 100 km de rayon entre Atlanta et Augusta, il y a environ 2 millions de personnes. Calculé avec https://www.tomforth.co.uk/circlepopulations/.

  • Impressionnant. Contrairement à certains autres cas, on peut clairement considérer cela comme une désanonymisation, ou au moins quelque chose d’assez proche. Si l’on avait pu connaître la position de Satoshi à 250 miles près, à quel point serait-il encore resté anonyme aujourd’hui ?
    En appliquant cette attaque de façon répétée, en la dissimulant d’une manière ou d’une autre, on peut suivre les déplacements au fil du temps. En général, 4 ou 5 localisations de la taille d’un code postal suffisent à identifier une personne de manière unique.

    • Le contre-argument, c’est que quelqu’un qui se soucie de son anonymat cache son identité d’une manière que cette attaque ne casse pas, par exemple avec un VPN. En plus, il existe des attaques beaucoup plus efficaces, comme envoyer un lien vers un endpoint que l’on contrôle directement. Si la relation est assez fiable pour envoyer une notification, il n’est pas difficile d’inciter la personne à cliquer sur un lien. Il existe aussi des méthodes moins techniques, comme faire correspondre les moments où l’utilisateur est en ligne ou hors ligne avec les fuseaux horaires du monde entier.
      Les méthodes utilisées par Apple et Cloudflare dans leurs logiciels de protection de la vie privée reposent aussi sur l’idée que la région n’est pas une information identifiante. C’est le cas d’iCloud Private Relay d’Apple ou de WARP de Cloudflare ; avec Apple Private Relay activé, l’IP d’origine est masquée, mais l’IP par laquelle le trafic est routé se trouve dans le même pays.
      https://www.apple.com/icloud/docs/iCloud_Private_Relay_Overv...
      Cette attaque est intéressante et nouvelle sur le plan académique, mais ce n’est pas de la « désanonymisation ».
    • Une adresse IP domestique semblant être celle de Satoshi a bien fuité peu après le lancement de Bitcoin, mais elle n’a été reconnue que plusieurs années plus tard.
      Bien sûr, ce n’était peut-être pas lui, mais simplement un utilisateur précoce au hasard. Je pense tout de même qu’il y a une certaine probabilité que ce soit lui.
      Plus de détails : https://news.ycombinator.com/item?id=29728339
      Je ne soutiens pas les tentatives visant à retrouver et publier son nom et son adresse, car cela pourrait lui compliquer la vie. Mais, abstraitement, le fait que cela reste un mystère malgré tant d’attention pendant des années est très intéressant.
    • Combien de personnes vivent dans un cercle de 250 miles autour de New York ?
    • Dans presque toutes ces applications, on peut déjà faire la même chose avec l’identifiant publicitaire.
    • Il reste assez anonyme. Il a presque certainement utilisé un VPN, et même si ce n’était pas le cas, il vivait probablement dans une grande ville comptant des milliers, voire des centaines de milliers d’ingénieurs compétents. Savoir qu’il était à SF au moment d’un message ne dit littéralement rien.

  • Je ne comprends pas pourquoi autant de commentaires en tête minimisent la gravité. C’est exactement le type d’attaque qui permet aux forces de l’ordre ou à des acteurs malveillants d’établir une preuve de localisation.

    • Certains semblent jaloux de son âge, et d’autres pensent que parler de désanonymisation est exagéré, car, sauf cas très particulier, cela ne donne pas assez d’informations pour retrouver quelqu’un. Cette « attaque » est facilement neutralisée si l’on utilise un VPN ou si l’on vit dans une grande ville.
    • Je pense que beaucoup minimisent parce que le niveau de gravité présenté dans l’article original semble survendu. Beaucoup de réactions équilibrées ressemblent à : « excellente découverte, mais pas aussi dévastatrice que ce qui est affirmé », et la classification de la gravité du problème doit être exacte.
      Une preuve de localisation n’est pas une désanonymisation, surtout quand cette « localisation » est aussi large.
    • Rien que connaître le pays grâce à cela serait déjà une grande première étape.
    • On l’ignore pour la même raison que les gens ignorent les nouvelles technologies destructrices : parce que c’est inconfortable. C’est le signe que la menace est très réelle.
      On commence par l’ignorer pour voir si le problème est encore là le matin. D’ici là, on espère que quelqu’un trouvera une raison pour laquelle ce n’est pas un problème.

  • Pourquoi Signal a-t-il activé le cache sur ces URL ? Le cas le plus courant doit être qu’une pièce jointe est téléchargée une fois, puis terminé.
    J’aurais plutôt supposé qu’ils empêcheraient plus d’un téléchargement et supprimeraient immédiatement le fichier après le premier téléchargement réussi. Bien sûr, le client peut échouer en cours de route, donc on peut prévoir un délai de grâce pour permettre un nouveau téléchargement. Mais cela ne semble pas être le cas le plus fréquent, et j’espère que désactiver le cache CDN permettrait de corriger ce problème sans augmenter fortement les coûts.
    Quoi qu’il en soit, ici, « désanonymisation » est une expression un peu accrocheuse. Réduire la localisation de quelqu’un à environ 250 miles près n’est pas une bonne chose, mais cela ne désanonymise pas cette personne.
    Édit : je n’avais pas pensé au cas où une pièce jointe est envoyée dans une discussion de groupe et téléchargée par plusieurs personnes. Mais même dans ce cas, les pièces jointes ne sont-elles pas chiffrées séparément pour chaque membre du groupe ? Bien sûr, je ne sais pas vraiment comment cela fonctionne en pratique.

    • Les paramètres par défaut de Signal privilégient davantage l’utilisabilité tout en prenant en charge le chiffrement de bout en bout, et se concentrent moins sur un modèle de menace excessif consistant à cacher jusqu’au fait que l’on existe sur un continent dont on a la citoyenneté.
      Les éléments mentionnés peuvent en pratique être configurés par quelqu’un qui veut ce niveau délirant de confidentialité et de sécurité. On peut faire en sorte que les messages soient supprimés automatiquement 30 secondes après leur lecture, configurer tout le trafic pour qu’il passe par un proxy, et ajuster beaucoup d’autres choses selon les préférences de l’utilisateur.
      La raison du cache est probablement le coût de bande passante sortante. Les pièces jointes, messages vocaux, vidéos, etc. finissent par peser lourd.
    • C’est peut-être aussi à cause des discussions de groupe et des utilisateurs multi-appareils.

  • C’est le même ado de 15 ans qui a trouvé il y a quelques mois la vulnérabilité de prise de contrôle Slack de Zendesk [1].
    [1]: https://news.ycombinator.com/item?id=41818459

  • C’est bien une « attaque », certes, mais ce n’est pas le type auquel on pense généralement quand on parle de zéro clic. Il n’y a pas d’exécution de code ; la méthode consiste à obtenir la localisation très approximative d’un utilisateur grâce à quelques astuces permettant de savoir quel datacenter Cloudflare a mis l’image en cache.
    Cela reste impressionnant et éclairant.

    • Selon le contexte, une localisation même approximative peut être utile aux adversaires d’une personne cachée. Je ne pense pas que des criminels, par exemple, risquent gros avec ça, et 300 miles restent un grand rayon. Mais si l’on veut savoir, par exemple, si « cette personne est encore dans le pays », cela peut être utile à des forces de l’ordre.
      Elles peuvent ensuite coopérer avec des ressources locales pour poursuivre l’enquête. Le simple fait de savoir quelles ressources mobiliser, et dans quelle région, peut faire économiser beaucoup d’argent.
      Comme dit plus haut, c’est impressionnant et instructif. Le document donne aussi un peu l’impression d’avoir été aidé par ChatGPT, avec beaucoup de phrases très claires et précises. Pour ce type d’usage, c’est un excellent cas d’utilisation, donc ce n’est pas une critique. C’était un bon article.

  • Sauf si j’ai raté quelque chose, cela ressemble à une façon très verbeuse de déterminer la localisation de l’IP de l’utilisateur.
    Par exemple, si je me connecte à un VPN puis que je consulte https://cloudflare.com/cdn-cgi/trace, j’obtiens colo:CPH (Copenhague), ce qui est loin du datacenter CF géographiquement le plus proche de moi, et plus proche de la localisation IP du fournisseur VPN, à Oslo, sans pour autant être vraiment proche.
    Sans VPN, je n’obtiens même pas la capitale du pays où je me trouve actuellement, mais un datacenter situé à environ 250 miles au nord. J’ai donc aussi du mal à accepter l’idée que Cloudflare renverrait toujours le « datacenter disponible le plus proche ».
    L’article lui-même est chouette et clairement intéressant, mais je ne suis pas convaincu de son utilité pratique.

    • C’est moins précis que de déterminer la localisation de l’IP de l’utilisateur. La géolocalisation IP peut souvent descendre jusqu’au niveau de la ville. Ici, au mieux, on obtient seulement le datacenter Cloudflare le plus proche.
    • Avec une seule donnée, le résultat n’a probablement pas beaucoup de sens.
      L’utilité réelle et le risque potentiel apparaissent quand cette donnée est combinée avec d’autres. Les techniques de désanonymisation fondées sur des jeux de données clairsemés sont un domaine de recherche actif depuis au moins 15 ans, et les gens sont souvent surpris de tout ce que l’on peut déduire à partir de quelques fragments de données qui semblent sans rapport.
    • Tu ne crois pas qu’il soit nécessaire de protéger la localisation de l’IP des utilisateurs ?
      Il y a une raison pour laquelle les applications font beaucoup d’efforts pour proxifier les requêtes de ressources comme les images. Et ce n’est pas gratuit.
    • Que les personnes pouvant envoyer des messages sur Signal ne voient pas leur adresse IP est une attente assez raisonnable en matière de confidentialité.
    • Cela peut être utile pour traquer des dissidents politiques en fuite, des terroristes, etc. Pouvoir réduire une localisation à 250 miles est déjà une information très utile, et cela n’éveille aucun soupçon.

  • Quel est l’intérêt, pour Signal, de mettre des images en cache sur un CDN ?
    En supposant qu’il existe un cache côté client local, le nombre total de requêtes pour cette ressource devrait être très faible, et dans la plupart des cas probablement égal à une seule.
    À part ça, CloudFront pourrait corriger ce problème très facilement en ne renvoyant pas l’en-tête cf-ray, ou en donnant aux clients une option pour le supprimer. Cela dit, il serait peut-être toujours possible de le déduire à partir des informations de timing.

    • Il s’agit moins de cache que d’utilisation d’un CDN. Le fait qu’un CDN se comporte comme un cache du contenu d’origine est un effet secondaire du CDN : pour améliorer le temps de réponse de distribution, il met en cache sur le serveur le plus proche du point de vue de la réponse.
      Ici, la « proximité » est une heuristique approximative, et une propriété des tables de routage anycast des routeurs BGP par lesquels passe la requête. En pratique, cela ressemble plutôt au « meilleur chemin ».
    • Même sans l’en-tête cf-ray, il suffit de regarder le temps de réponse. Si la ressource doit être récupérée depuis un autre continent, cela peut probablement se mesurer de manière fiable.
      C’est similaire pour les sites web qui tentent de masquer l’existence d’un utilisateur. Si l’on tente de se connecter avec un nom d’utilisateur existant, le hachage du mot de passe est effectué, ce qui ajoute généralement au moins 50 ms au temps de réponse ; avec un nom d’utilisateur inexistant, la requête se termine plus tôt. La solution consiste à toujours exécuter le même code et donc à toujours faire le hachage, mais très peu de sites le font. Ou bien, si le modèle de menace le permet, on peut simplement indiquer tout de suite que le nom d’utilisateur n’existe pas.
      Pour revenir au cas Cloudflare, cela n’aide pas tant que l’on ne retarde pas la réponse. Or retarder les réponses est l’inverse de ce que Cloudflare est censé faire.
    • Je ne pense pas que l’application Signal ou son réseau choisisse de mettre les images en cache sur un CDN.
      L’« attaque » ici, n’est-ce pas qu’un utilisateur quelconque peut envoyer à un autre utilisateur un message contenant un lien vers une ressource mise en cache sur un CDN ? Je me trompe peut-être.
    • Cloudflare devrait permettre aux clients de désactiver cet en-tête, et Signal ne devrait pas mettre en cache les images envoyées à une seule personne, ni celles envoyées à des groupes de moins de quelques centaines de personnes.
    • À propos du faible nombre total de requêtes pour cette ressource, un autre chiffre à prendre en compte est le nombre de requêtes « vers ce serveur ».

  • Je ne comprends pas trop. Quelqu’un a-t-il déjà considéré Signal comme anonyme ? Même chose pour Discord. Si c’est le cas, mauvaise nouvelle : aucun des deux n’est anonyme, absolument pas, pas le moins du monde
    Ils n’ont jamais prétendu l’être. Signal affirme seulement ne pas pouvoir lire les messages. Pour Discord, je ne sais pas trop, et j’ai des doutes. Même cette affirmation a ses failles. La cryptographie peut être solide, mais avez-vous audité en détail la version que vous utilisez et l’avez-vous compilée vous-même ?
    Au mieux, c’est une faible pseudonymité. Il a toujours été courant que des applications sacrifient une partie de la sécurité au profit du confort d’utilisation en chargeant les médias par défaut, et c’est un choix acceptable dans un modèle de menace ordinaire. Mettre des médias dans les messages a aussi toujours été un grand classique des attaques de désanonymisation
    Au fond, cela montre surtout que les pixels de suivi restent une technique efficace aujourd’hui, ce qui est bien, mais pas surprenant
    Si vous voulez rester anonyme, il ne faut pas utiliser Discord ni Signal, et je ne vous recommanderais pas non plus de poster sur HN. Peut-être qu’en passant par Whonix avec un compte jetable, sans JavaScript, en collant automatiquement à des heures aléatoires un message réécrit par un LLM local, vous auriez une chance. Mais même là, il ne faudrait pas le garantir
    L’anonymat n’existe plus

    • Je suis actuellement banni du subreddit Signal pour avoir souligné qu’affirmer que Signal ne collecte pas de métadonnées revient à croire Signal sur parole. Donc oui, les gens considèrent bel et bien Signal comme anonyme
    • Les gens utilisent Signal et Telegram* dans des contextes où l’anonymat est important. Bien sûr, ce ne sont pas des outils conçus pour cela, mais il n’existe pas d’autre solution largement comprise, et dans la plupart des cas c’est suffisant pour eux
      • Fait intéressant, cette fois Telegram n’est pas vulnérable parce qu’il utilise son propre protocole, ce qui est peut-être encore pire
    • Les gens oublient sans cesse que anonymat et protection de la vie privée sont deux choses différentes