Une messagerie se disant « super sécurisée » a divulgué le numéro de téléphone de tous ses utilisateurs

• Une faille critique a été découverte dans Freedom Chat, une application de messagerie sur le thème MAGA (droite conservatrice américaine), exposant les numéros de téléphone et codes PIN de ses utilisateurs
• L’application est la suite d’un projet antérieur appelé Converso, qui avait déjà connu par le passé des problèmes d’erreur d’implémentation du chiffrement et d’exposition de données
• L’analyse montre que, via la fonction de canaux, les codes PIN de tous les membres étaient transmis à d’autres utilisateurs, et que l’API de synchronisation des contacts permettait un appairage numéro de téléphone-UID
• Le chercheur a confirmé qu’il n’y avait aucune limitation de débit (rate limiting), ce qui lui a permis de collecter en une seule journée les numéros de téléphone de tous les utilisateurs de Freedom Chat
• L’affaire est présentée comme un cas où une application « axée sur la sécurité » a en réalité échoué même à assurer la protection élémentaire des données personnelles

---

De Converso à Freedom Chat

• Lancé en 2023, Converso affirmait proposer une « architecture décentralisée sans serveur » et un « E2EE de pointe », mais l’analyse du chercheur crnković a montré que toutes ces affirmations étaient fausses
  • En réalité, l’application utilisait un serveur central et un service de chiffrement tiers (Seald), et les clés de chiffrement pouvaient être dérivées à partir d’informations publiques
  • Tous les messages étaient téléversés dans un bucket Firebase public, consultable par n’importe qui
• Par la suite, le PDG Tanner Haas a retiré l’application puis l’a rebaptisée Freedom Chat, invoquant les « préoccupations en matière de confidentialité du camp conservateur »
  • Il avait évoqué la leçon consistant à « accepter les critiques et s’améliorer », mais les problèmes de sécurité se sont répétés

Architecture et fonctions de Freedom Chat

• L’application utilise une inscription basée sur le numéro de téléphone et une vérification par code 2FA, tandis que la définition d’un PIN est facultative
• Les fonctions principales sont les discussions 1:1 et les canaux (Channels), dans une structure similaire à Telegram
• L’application mettait en avant une fonction de blocage des captures d’écran et la présentait comme une « fonction de sécurité », sans rapport avec la sécurité réelle

Fuite des codes PIN

• Le résultat d’une requête API /channel incluait, dans les objets utilisateur (user object) de 1 519 membres du canal, un champ PIN
  • Le code PIN à 6 chiffres apparaissait en clair, avec l’UID de chaque utilisateur, sa clé Seald, sa date de création, etc.
• Après avoir créé un nouveau compte, le chercheur a constaté que son propre PIN figurait tel quel dans les données de réponse
• Autrement dit, les PIN de tous les utilisateurs restés dans le canal par défaut étaient exposés aux autres utilisateurs

Vulnérabilité d’appairage des numéros de téléphone

• L’API /user/numbers vérifie la présence d’un contact selon une méthode identique à WhatsApp
  • Si un numéro inclus dans la requête appartenait à un utilisateur de Freedom Chat, l’API renvoyait l’UID et la clé Seald
• Le chercheur a confirmé que cette API n’avait aucune limitation de débit, rendant possible le test séquentiel de tous les numéros de téléphone américains
  • Il devenait ainsi possible d’effectuer un appairage numéro de téléphone-UID et, en le combinant avec les données UID-PIN déjà exposées, de reconstituer une correspondance numéro de téléphone-PIN

Expérience de fuite des données de l’ensemble des utilisateurs

• Le chercheur a écrit un script Python pour envoyer automatiquement des requêtes sur tous les numéros de téléphone nord-américains (combinaisons à 7 chiffres × indicatifs régionaux)
  • Chaque requête envoyait 40 000 numéros, avec un temps de réponse moyen d’environ 1,5 seconde
  • En 27 heures, toutes les requêtes ont été traitées avec succès, permettant de collecter tous les numéros de téléphone des utilisateurs de Freedom Chat
• Le serveur répondait sans limitation de débit ni blocage, rendant possible une consultation complète des données

Réponse et suite

• 2025-11-23 : découverte de la faille
• 2025-12-04 : le journaliste de TechCrunch Zack Whittaker révèle la vulnérabilité à Freedom Chat
• 2025-12-05 : Freedom Chat affirme que « le PIN ne sert pas à restaurer les messages » et indique qu’un audit est déjà en cours
• 2025-12-09 : notification de correction du problème
• 2025-12-11 : publication simultanée de ce rapport et de l’article de TechCrunch

Enseignement principal

• Freedom Chat affichait une ambition de « super sécurité », mais ne disposait pas des bases en matière d’authentification, de limitation de débit et de protection des données
• En conséquence, les numéros de téléphone et PIN de tous les utilisateurs ont été exposés, neutralisant de fait les fonctions de sécurité
• Le cas est considéré comme un exemple représentatif du décalage entre le marketing de la sécurité et l’implémentation réelle

[GN⁺]

Avis sur Hacker News

• Le système de recherche de numéros de téléphone chiffré de Signal est intéressant
  Le serveur recherche les numéros en utilisant une opération XOR au niveau du bit dans une RAM chiffrée matériellement, donc même en inspectant le système au niveau le plus bas, il est impossible de savoir si le numéro demandé existe
  Bien sûr, le rate limiting reste un autre problème important. Quand on conçoit un système de sécurité, il y a énormément d’edge cases à couvrir

  • Je ne trouve pas cette approche si géniale. Un messenger sécurisé ne devrait pas exiger un numéro de téléphone, qui est un identifiant personnel, dès le départ
  • Je me demande si Signal pourrait empêcher un gouvernement d’envoyer des requêtes de recherche pour tous les numéros de téléphone
    Sur des plateformes non commerciales centrées sur la vie privée comme Matrix, ce type de correspondance devrait être impossible par conception
    Par exemple, on pourrait proposer que chaque paire d’utilisateurs téléverse une valeur de hachage des numéros de téléphone, afin qu’un utilisateur ne puisse être trouvé que par les personnes présentes dans sa propre liste de contacts
    L’avantage, c’est que l’espace de hachage est vaste, donc difficile à remonter, et que l’utilisateur peut définir lui-même la portée de découvrabilité
    L’inconvénient, c’est qu’un attaquant peut générer toutes les combinaisons de numéros pour extraire les relations de contact, et qu’un gouvernement pourrait aussi détourner l’authentification par SMS pour en abuser
  • La partie sur le fait que le serveur utilise XOR dans une RAM chiffrée matériellement est intéressante. Je me demande s’il existe des ressources complémentaires à ce sujet
  • C’est toujours regrettable qu’un numéro de téléphone soit encore requis. Ce n’est que récemment que la fonction username a été ajoutée pour éviter d’exposer son numéro, mais le fait que le compte reste lié à la SIM me dérange toujours
  • Mais comme nous ne pouvons pas compiler et exploiter nous-mêmes les serveurs Signal, nous ne pouvons pas être sûrs que le serveur traite réellement les choses de cette manière

• Le champ pin de l’objet utilisateur paraît suspect
  Il est probable que le problème vienne de l’usage d’une bibliothèque de sérialisation en opt-out. Comme elle sérialise tout l’objet par défaut, si le développeur oublie d’exclure un champ précis, il se retrouve exposé tel quel
  Ou alors le serveur utilisait simplement un dictionnaire JS et n’a pas supprimé le champ avant d’envoyer la réponse
  Cette vulnérabilité est un ancien problème mentionné dans un article d’une équipe de recherche de l’université de Vienne ; elle avait déjà été exploitée de la même manière sur Telegram en 2016, ce qui avait permis au gouvernement iranien de collecter les numéros de téléphone de 15 millions d’utilisateurs
  Lien connexe : blog Telegram

  • Lors d’audits de code dans mon ancien travail, j’ai trouvé ce type de vulnérabilités de sérialisation un peu partout. Les développeurs devraient vraiment arrêter d’utiliser ces bibliothèques
  • Ce genre de problème est extrêmement courant. Des champs sensibles sont envoyés au client, mais comme ils ne sont pas visibles dans l’interface, personne ne s’en aperçoit
  • Le fait que le PIN ait été exposé est déjà un problème, mais le fait qu’il soit stocké en clair est encore plus grave. Il aurait dû être traité avec un algorithme de hachage robuste, comme un mot de passe

• Aujourd’hui, la plupart des failles de sécurité viennent simplement du fait d’appeler des endpoints HTTP d’une manière inattendue
  Quand on parle de hacking en 2025, on imagine des techniques complexes, mais en réalité on déploie encore des API sans même de rate limiting. C’est le genre de problème qu’une seule ligne de configuration Nginx pourrait résoudre

  • Quand j’entends “une seule ligne de configuration Nginx suffit”, j’imagine la réponse : “ce n’était pas dans le tutoriel Docker, donc je ne sais pas ce que c’est”
  • Le développement logiciel a progressé, mais les principes de développement sécurisé ont très peu évolué
    La plupart des objectifs consistent à réduire la friction utilisateur et à améliorer l’efficacité commerciale. Beaucoup de développeurs implémentent des fonctionnalités sans même connaître des vulnérabilités de base comme XSS ou SSRF
  • Même pour appliquer une configuration simple, encore faut-il savoir qu’elle existe
  • Autrefois je pensais que les scans de sécurité internes automatisés n’étaient pas très utiles, mais après avoir vu en pratique à quel point on oublie facilement des configurations de base, j’ai fini par les considérer comme indispensables
    Des erreurs de sécurité élémentaires comme une mauvaise configuration du port mapping Docker ou l’absence de CSP sont bien trop fréquentes
  • Mais le rate limiting ne suffit pas à lui seul. Un attaquant peut répartir ses IP et envoyer des requêtes en parallèle

• En lisant la phrase “nous voulons offrir à nos lecteurs uniquement les meilleurs billets de blog”, j’ai eu l’impression de tomber sur quelqu’un qui avait une sensibilité proche de la mienne

• Je me demande si Freedom Chat® a une fonction qui empêche les journalistes de rejoindre une conversation de groupe. Je demande à moitié pour plaisanter, à moitié sérieusement, pour un ami au DoD

• Rien que cette année, il y a déjà eu plusieurs cas où des “applications de sécurité” ont fuité les données de leurs utilisateurs en les manipulant
  De mémoire, j’en ai déjà pour vingt cents (=4 cas), mais il y en a probablement davantage
  Cas connexes : 1, 2, 3

  • Je pense que cet incident montre à quel point il est important de sortir de Facebook Messenger
  • Et ce que nous savons ne représente qu’une partie du problème

• L’an dernier, je suis tombé par hasard sur un site d’offres d’emploi du GOP, et les candidatures étaient stockées dans le même index de recherche que les annonces
  En cherchant “bob”, j’ai été choqué de voir apparaître directement les CV et réponses des candidats

  • Je me demande de quel site il s’agissait

• Depuis l’affaire Anom, il nous faut un mot plus approprié que honeypot
  Un vrai messenger sûr ne verra pas le jour de cette façon. Mais le marketing continue, et de nouveaux utilisateurs se laissent attirer à chaque fois

  • On vit désormais dans un monde où l’échec devient une fonctionnalité
    Les fuites de données arrivent si souvent que les gens y sont devenus insensibles. Même les indemnisations issues des class actions finissent par devenir un processus où il faut fournir encore plus de données personnelles
    Les marchés prédictifs, les cryptomonnaies, etc., donnent eux aussi l’impression de présenter comme une “réussite” des échecs structurels qui finissent par nuire aux participants
  • Une nouvelle expression est proposée : “Petepot”

• Freedom Chat a annoncé que le “problème était corrigé”, mais je doute que ce soit vraiment le cas

• Si la phrase “je n’avais pas d’expérience en développement mobile, mais je pensais que ce ne serait pas difficile parce que je suis intelligent” est une citation réelle, on dirait presque une réplique de stand-up