- Le collectif de hackers DDoSecrets a publié 410 Go de heap dumps piratés chez l’entreprise israélienne TeleMessage
- TeleMessage développe des versions modifiées de Signal, WhatsApp, Telegram et WeChat afin de fournir un service d’archivage des messages
- Ces données contiennent des messages en clair, des métadonnées et des informations personnelles ; leur diffusion est donc limitée aux journalistes et aux chercheurs
- TeleMessage affirmait que ses produits prenaient en charge le chiffrement de bout en bout, mais il est apparu que leur architecture le contournait en réalité
- Des éléments montrent aussi que des responsables américains ont partagé des informations sensibles via des canaux vulnérables sur le plan de la sécurité
Aperçu
- En mai 2025, le collectif de hackers DDoSecrets a publié 410 Go de heap dumps obtenus auprès de l’entreprise israélienne TeleMessage
- TeleMessage est un fournisseur de solutions de stockage centralisé (archivage) pour de grandes messageries comme Signal, WhatsApp, Telegram et WeChat
- Comme ces données contiennent de nombreuses informations sensibles et des données personnelles identifiables (PII), elles sont diffusées uniquement aux journalistes et aux chercheurs
Chronologie résumée de l’affaire
- Mars : sous l’administration Trump, le conseiller à la sécurité nationale Mike Waltz menait sur un groupe Signal une conversation liée à des crimes de guerre lorsqu’il a invité par erreur un journaliste. Après la révélation de l’affaire, une audition au Congrès a eu lieu
- 1er mai : le jour où Waltz a été rétrogradé, il a été vu en train d’utiliser TM SGNL, une version modifiée de Signal créée par TeleMessage. Ses interlocuteurs comprenaient Tulsi Gabbard, JD Vance et Marco Rubio, entre autres hauts responsables
- 3 mai : le code source de TM SGNL a été publié sur GitHub
- 4 mai : le piratage de TeleMessage a eu lieu, et les faits ont été rapportés dans la presse
- 5 mai : un autre hacker a de nouveau piraté TeleMessage, provoquant une interruption du service
- 6 mai : l’analyse du code source de TM SGNL a démontré que le chiffrement de bout en bout revendiqué par TeleMessage n’était en réalité pas appliqué. Une partie des données piratées a confirmé la présence de journaux de discussion en clair
- 18 mai : une analyse supplémentaire a révélé une vulnérabilité sur le serveur d’archivage de TeleMessage. N’importe qui pouvait accéder à une URL spécifique (
archive.telemessage.com/management/heapdump) pour télécharger un heap dump Java
Détails de cette fuite
- Les heap dumps publiés ont été récupérés le 4 mai 2025 et proviennent d’une faille dans la solution de messagerie sécurisée fournie par TeleMessage
- Il a été confirmé que ces produits étaient utilisés depuis 2023 par plusieurs organisations, y compris le gouvernement américain
- Les données incluent des messages en clair, des informations sur les expéditeurs et destinataires, des horodatages et des noms de groupe, soit un ensemble riche de métadonnées
- DDoSecrets fournit les informations nécessaires à la recherche après les avoir extraites et nettoyées
Impact et enseignements
- Cette affaire met en lumière le manque de fiabilité des solutions de messagerie et la négligence opérationnelle
- Elle confirme le décalage entre le niveau de sécurité annoncé par TeleMessage et le fonctionnement réel de ses produits
- Le fait que de hauts responsables du gouvernement américain aient échangé des informations confidentielles via des applications de messagerie clones vulnérables souligne un grave problème de sécurité
- Cette affaire, surnommée SignalGate, est toujours en cours, et de nouvelles analyses ainsi que des réponses de la communauté sécurité sont attendues
1 commentaires
Commentaires sur Hacker News
Il est mentionné qu’un serveur exposait un endpoint
/heapdumpet rendait publiquement disponible son heap dump ; l’affaire semble avoir pris des proportions incontrôlables. Ce groupe n’a pas réellement « publié » les données : les journalistes doivent soumettre une demande pour y accéder. Le fait de ne pas préciser quelle quantité de messages réels s’y trouve, tout en mettant seulement en avant le chiffre de 410 Go de dump, a encore amplifié le sujet.Imaginez prendre un logiciel déjà peu fiable, le rendre encore pire, puis le faire payer en plus. C’est embarrassant, aussi bien du point de vue de l’entreprise que de celui des utilisateurs.
Le point important, c’est justement qu’on parle de 410 Go sans préciser la quantité réelle de données utiles dans le heap dump. J’ai récemment vérifié un dump massif du même genre : en pratique, il ne contenait guère que du cache de mises à jour de paquets OS et des logs. Aucune donnée importante. On peut facilement réduire la taille d’un heap dump, donc le fait d’avoir tout livré tel quel paraît suspect. Bien sûr, il est aussi possible que les données sensibles aient déjà été filtrées dans ces 512 Go de dump.
On a souvent l’image que la plupart des entreprises logicielles israéliennes sont remplies d’anciens du Mossad exceptionnellement compétents, mais en réalité, ce n’est pas forcément à la hauteur des attentes. J’espère qu’il y aura du contenu intéressant dans ce dump de messages.
On dirait que quelqu’un utilisait une application Java et a accidentellement exposé tous les endpoints JMX en HTTP. Ce n’est pas la configuration par défaut, donc j’y vois une simple erreur d’inattention.
Je me demande s’il s’agit d’un heap dump du serveur ou d’un heap dump côté client. Si c’est le client, c’était peut-être intentionnel pour conserver des logs lors d’un crash.
En lisant la présentation LinkedIn du CEO de TeleMessage, on a l’impression d’un texte auto-généré à la va-vite par une IA, rempli uniquement de formules creuses comme innovation stratégique, valeurs éthiques, SaaS, fusions-acquisitions ou leadership sectoriel.
On dirait vraiment une écriture LinkedIn de très bas niveau.
En résumé, ça donne l’impression de répéter : « Je suis CEO. Notre entreprise fait du SaaS. Je suis CEO. »
Quelques semaines ont passé depuis la révélation de l’affaire TeleMessage, et je me demande si la Signal Foundation a publié une position officielle. J’ai du mal avec ce double standard : menacer d’actions en justice pour la marque quand un client open source tiers utilise le nom Signal, mais rester silencieux quand un sous-traitant de la défense emploie ce même nom.
Certains estiment que si tant d’organisations restent discrètes aux États-Unis aujourd’hui, c’est parce qu’elles craignent les représailles du gouvernement. D’un autre côté, depuis que Moxie, figure centrale de la Signal Foundation, s’est effacé puis a quitté l’organisation, il est devenu moins clair de savoir ce qu’elle cherche à défendre.
À mon avis, Signal n’a aucune faute dans cette affaire. Le problème vient plutôt de TeleMessage et des responsables qui ont choisi de l’utiliser. Même si Signal faisait une déclaration, cela n’apporterait rien d’utile et ne ferait qu’attirer des critiques.
Puisque de précédents forks FOSS de Signal avaient reçu des avertissements juridiques, je me demande si Molly fonctionne toujours aujourd’hui, ou s’il existe encore des serveurs généralement auto-hébergeables.
Même si j’ai des reproches sur le conflit entre moxie et fdroid, cette affaire dépasse largement ce cadre : il s’agit de pouvoir d’État et de corruption, pas simplement d’un problème lié à une personne ou une entreprise. Si le gouvernement d’un autre pays utilisait comme outil national de communication un logiciel étranger obscur dont personne n’a jamais entendu parler, on le traiterait sûrement d’incompétent.
Je comprends la nécessité de protéger un nom et une marque. Même si on fork un projet open source, on ne peut pas librement réutiliser la marque et le nom de l’auteur original. Si vous forkiez les versions open source de Firefox ou VSCode, vous ne pourriez pas appeler votre copie du nom d’origine à cause du droit des marques.
Même si le fork de Signal était médiocre, il restait malgré tout légal. En revanche, découvrir que cette entreprise vendait aussi des versions crackées de WhatsApp est franchement sidérant. J’ai du mal à croire que des institutions et des gouvernements aient réellement acheté ce type de produit. Un lien est aussi joint.
Je me demande pourquoi ce serait illégal. Contrairement au cas Beeper, le département de la Justice américain ne voit pas toujours d’un bon œil l’interdiction des clients tiers ; est-ce que WhatsApp est différent ? WhatsApp archiver semble en fait installer un patch sur le WhatsApp de l’utilisateur ; cela pose sans doute des problèmes de sécurité, mais pas forcément d’illégalité.
Dans les faits, sur les marchés financiers mondiaux, Global Relay et TeleMessage sont des fournisseurs majeurs de solutions de communication destinées à la conformité réglementaire.
Mon entreprise traite des sujets bien moins critiques, mais elle fait quand même réaliser deux tests d’intrusion externes par an. Je me demande comment un tel niveau d’irresponsabilité peut être légalement possible.
À mon avis, c’est parce que l’ingénierie logicielle n’est pas prise au sérieux comme une vraie ingénierie. Par exemple, en cas d’accident, la responsabilité qui s’ensuit reste limitée.
En réalité, je ne pense pas que ce soit légal. J’ai entendu dire qu’il y avait aussi des indices montrant que leur SOC2 aurait été falsifié.
« Heapdump » est un terme que j’avais découvert il y a 15 ans en déboguant des applications Android. C’est un instantané mémoire d’un processus Java, donc il est inévitable qu’on y trouve du texte en clair. La vraie question est : pourquoi ces heaps étaient-ils exposés via un endpoint HTTP ouvert ? Je suppose que l’adresse était soit codée en dur dans le client, soit déduite à partir des schémas de requêtes. Avec ces seules informations, il n’est pas simple de comprendre l’architecture backend ou la manière dont les messages sont stockés ; peut-être que j’ai raté quelque chose.
Exposer en production un endpoint
/heapdumpsans authentification est une erreur de débutant. C’est encore plus grave pour un service qui traite des communications gouvernementales sensibles. Le recours à des technologies vieillissantes comme les hash MD5 et JSP montre aussi une compréhension insuffisante de la sécurité. Cette affaire est un exemple typique de la nécessité d’une sécurité défensive et d’audits réguliers.Quand des élus proposent d’interdire le chiffrement e2e ou d’imposer des backdoors, je pense que cette affaire constitue un très bon exemple concret à leur opposer.
Les données sont sensibles et contiennent beaucoup de PII, et DDoSecrets ne les partage donc qu’avec des journalistes et des chercheurs. D’ordinaire, je suis favorable à une divulgation responsable, mais dans ce cas précis, je pense qu’il faudrait peut-être une fuite plus douloureuse et plus dévastatrice. Les dictateurs et les oligarques se moquent souvent d’être piratés, continueront à utiliser des outils similaires, et seul l’électorat lésé pourrait provoquer un changement. L’échec sécuritaire a réduit la protection de l’intelligence collective de la population. Même si des journalistes ou des chercheurs essaient d’en parler, dans une société autoritaire, ils peuvent facilement être réduits au silence, et l’on aboutit à une situation où personne ne sait vraiment ce qui se passe. Les détenteurs du pouvoir peuvent alors continuer à justifier la répression sans résistance ni conséquences. S’il s’agissait d’un simple incident de sécurité d’entreprise, je préférerais une divulgation responsable, mais pour empêcher la dérive autoritaire, je pense que c’est différent.
Aujourd’hui, il n’est même plus nécessaire de faire taire les journalistes : beaucoup de gens font déjà davantage confiance à des comptes anonymes sur les réseaux sociaux ou à des influenceurs politiques comme sources d’information. Du coup, même en cas de révélation, il suffit de balayer cela d’un « fake news », et si assez d’électeurs y croient, cela ne change plus grand-chose.
Je trouve dangereux de penser qu’il faudrait accepter des dommages pour réveiller la population face à une mauvaise gouvernance. Poussée à l’extrême, cette idée peut finir par justifier davantage de violence ou de souffrance. En général, raisonner comme si les gens devaient être blessés encore plus pour prendre conscience de la situation est préoccupant.
Si ces données étaient réellement publiées, les dégâts ne toucheraient pas forcément les dirigeants, mais pourraient mettre en danger des sources internes. Par exemple, si les logs contiennent des informations sensibles sur des agents de renseignement ou d’autres personnes, des vies pourraient être menacées.
En mentionnant l’ancienne fuite du Cabinet australien, quelqu’un explique qu’un média a contribué à étouffer l’affaire en restituant au gouvernement l’essentiel des informations. Une telle approche aurait au contraire permis de dissimuler des faits importants que le public devait connaître, avec un fort impact politique. Selon lui, cette affaire Signalgate est similaire. Indépendamment de toute affiliation partisane, il insiste sur l’importance du droit du public à en savoir davantage.
Je trouve ironique de voir des responsables politiques faire pression pour transformer les logiciels de communication en backdoors, puis se faire eux-mêmes pirater exactement de la même manière. Malheureusement, ils ne semblent pas avoir la capacité de comprendre vraiment ce que cette série d’événements signifie, ni l’empathie nécessaire.