- O grupo de hackers DDoSecrets divulgou 410 GB de heap dumps obtidos em um ataque contra a empresa israelense TeleMessage
- A TeleMessage desenvolve versões modificadas de Signal, WhatsApp, Telegram e WeChat para oferecer serviços de arquivamento de mensagens
- Os dados incluem mensagens em texto puro, metadados e informações pessoais, por isso estão sendo distribuídos de forma limitada apenas para jornalistas e pesquisadores
- Embora os produtos da TeleMessage alegassem oferecer criptografia de ponta a ponta, foi revelado que sua estrutura na prática contornava essa proteção
- Também surgiram indícios de que o governo dos EUA e autoridades compartilharam informações sensíveis por meio de canais vulneráveis do ponto de vista de segurança
Visão geral
- Em maio de 2025, o grupo de hackers DDoSecrets divulgou 410 GB de heap dumps obtidos da empresa israelense TeleMessage
- A TeleMessage é uma fornecedora de soluções de armazenamento centralizado (arquivamento) para mensageiros populares como Signal, WhatsApp, Telegram e WeChat
- Como esses dados incluem muitas informações sensíveis e informações de identificação pessoal (PII), sua distribuição está limitada a jornalistas e pesquisadores
Linha do tempo resumida do caso
- Março: durante o governo Trump, o conselheiro de segurança nacional Mike Waltz convidou por engano um jornalista para um grupo no Signal em que se discutiam conversas relacionadas a crimes de guerra. Após a cobertura do caso, houve uma audiência no Congresso
- 1º de maio: no dia em que Waltz foi rebaixado de cargo, ele foi visto usando TM SGNL, uma versão modificada do Signal criada pela TeleMessage. Entre seus interlocutores estavam Tulsi Gabbard, JD Vance e Marco Rubio, entre outras autoridades de alto escalão
- 3 de maio: o código-fonte do TM SGNL foi divulgado via GitHub
- 4 de maio: ocorreu o ataque à TeleMessage, e o fato foi noticiado pela imprensa
- 5 de maio: outro hacker invadiu a TeleMessage novamente, causando a interrupção do serviço
- 6 de maio: a análise do código-fonte do TM SGNL comprovou que a criptografia de ponta a ponta alegada pela TeleMessage não estava de fato em uso. Parte dos dados obtidos no ataque confirmou a presença de logs de chat em texto puro
- 18 de maio: análises adicionais revelaram uma vulnerabilidade no servidor de arquivamento da TeleMessage. Qualquer pessoa podia acessar uma URL específica (
archive.telemessage.com/management/heapdump) e baixar heap dumps Java
Detalhes deste vazamento
- Os heap dumps divulgados foram obtidos em 4 de maio de 2025 e tiveram origem em uma vulnerabilidade na solução de mensagens seguras oferecida pela TeleMessage
- Foi confirmado que o produto vinha sendo usado por várias instituições, incluindo o governo dos EUA, desde 2023
- Os dados incluem mensagens em texto puro, informações de remetente/destinatário, timestamps, nomes de grupos e outros metadados ricos
- A DDoSecrets está fornecendo informações extraídas e tratadas conforme necessário para fins de pesquisa
Impacto e implicações
- O incidente trouxe à tona a falta de confiabilidade das soluções de mensageria e a fragilidade operacional
- Foi confirmada a incompatibilidade entre o nível de segurança anunciado pela TeleMessage e seu funcionamento real
- Veio à tona que altos funcionários do governo dos EUA trocaram informações sigilosas por meio de apps-clone de mensageria vulneráveis, destacando um grave problema de segurança
- O caso, chamado de SignalGate, ainda está em andamento, e a expectativa é de que análises adicionais e respostas da comunidade de segurança continuem
1 comentários
Comentários do Hacker News
Foi mencionado que havia um endpoint
/heapdumpem um dos servidores, que publicamente fornecia o heap dump do servidor; dá a sensação de que este incidente saiu completamente do controle. Também apontam que esse grupo na verdade não “publicou” os dados, já que jornalistas precisam enviar uma solicitação para ter acesso. O fato de não revelarem quanto conteúdo de mensagens realmente existe, destacando apenas o número de 410GB de dump, fez o caso ganhar ainda mais atenção.Imagine pegar um software pouco confiável, torná-lo ainda pior e, além disso, cobrar por isso. Parece vergonhoso tanto do ponto de vista da empresa quanto do usuário.
Acho importante o ponto de que mencionam apenas o número de 410GB sem dizer quanto disso são dados reais. Recentemente examinei um dump grande parecido e, no fim, era basicamente cache de atualização de pacotes do sistema operacional e logs. Não havia nenhum dado importante. O tamanho do heap dump pode ser reduzido facilmente, então simplesmente despejar tudo parece suspeito. Claro, também é possível que já tenham filtrado os dados importantes de um dump de 512GB.
Muita gente costuma achar que a maioria das empresas de software israelenses é formada por ex-Mossad brilhantes, mas acho que, na prática, não é bem assim. Espero que haja bastante conteúdo interessante nesse dump de mensagens.
Parece uma situação em que alguém usou uma aplicação Java e, por engano, expôs todos os endpoints JMX via HTTP. Isso não é a configuração padrão, então me parece um simples caso de descuido.
Fico curioso se isso é um heap dump do servidor ou um heap dump voltado para o cliente. Se for do cliente, talvez tenha sido algo intencional para registrar logs quando o aplicativo trava.
A descrição no LinkedIn do CEO da TeleMessage parece um texto mal gerado automaticamente por IA, cheio apenas de expressões batidas como inovação estratégica, valores éticos, SaaS, fusões e aquisições e liderança setorial.
Parece mesmo uma redação horrorosa no estilo LinkedIn.
Em resumo, a sensação é: "Eu sou CEO. Nossa empresa é SaaS. Eu sou CEO."
Já se passaram algumas semanas desde que o caso TeleMessage veio a público, e fico me perguntando se a Signal Foundation já soltou algum posicionamento oficial. Parece um duplo padrão ameaçar processar por marca registrada quando surge um cliente open source de terceiros usando o nome Signal, mas ficar em silêncio quando uma empresa do setor de defesa usa o mesmo nome.
Há quem diga que o motivo de várias organizações estarem quietas nos EUA hoje é o medo de retaliação do governo. Por outro lado, também acho que, desde que Moxie, que era central na Signal Foundation, saiu e perdeu protagonismo, ficou menos claro o que a organização busca atualmente.
Acho que a Signal não tem culpa nenhuma nesta situação. O problema é da TeleMessage e dos responsáveis que escolheram e usaram isso. Mesmo que a Signal diga alguma coisa, só vai receber críticas e não vai adiantar muito.
Como um antigo fork FOSS da Signal recebeu uma notificação legal, fico curioso se o Molly ainda está ativo, ou se em geral existem servidores que possam ser hospedados diretamente.
Tenho minhas críticas à briga entre moxie e fdroid, mas este caso envolve questões de poder estatal e corrupção que vão além disso; é algo importante demais para ser reduzido a um problema de uma pessoa ou empresa. Pense se, caso o governo de outro país estivesse usando como ferramenta nacional de comunicação um software estrangeiro obscuro de que ninguém nunca ouviu falar, ele não seria ridicularizado por incompetência.
Concordo com a necessidade de proteger nomes e marcas. Mesmo que você faça um fork de um projeto open source, não é natural poder usar livremente a marca e o nome do autor original. Se você fizer fork de uma versão open source do Firefox ou do VSCode, por exemplo, não pode dar ao clone o nome original por causa de marca registrada.
Mesmo que o fork do Signal fosse ruim, ainda assim era legal. O realmente chocante é que essa empresa também vendia um WhatsApp crackeado. É difícil acreditar que os clientes reais desse tipo de produto sejam instituições e governos. Também anexaram um link.
Fico curioso sobre por que isso seria ilegal. Ao contrário do caso Beeper, o Departamento de Justiça dos EUA às vezes até vê com maus olhos a proibição de clientes privados; então por que o WhatsApp seria diferente? O WhatsApp archiver aparentemente instala um patch no WhatsApp do próprio usuário, o que pode trazer problemas de segurança, mas não seria necessariamente ilegal.
Na prática, no mercado financeiro global, Global Relay e TeleMessage são grandes fornecedores de soluções de comunicação para fins de compliance.
Minha empresa lida com coisas muito menos importantes, mas mesmo assim recebe testes de invasão externos duas vezes por ano. Fico me perguntando como um erro irresponsável desse nível pode ser legalmente possível.
Acho que isso acontece porque engenharia de software não é tratada seriamente como engenharia de verdade. Por exemplo, a responsabilidade decorrente quando algo dá errado é limitada.
Na verdade, parece que nem era legal. Ouvi dizer que também há indícios de que o SOC2 foi falsificado.
Heapdumpé um termo que conheci há uns 15 anos ao debugar apps Android. É um snapshot da memória de um processo Java, então é inevitável que haja texto puro lá dentro. O ponto importante é por que esses heaps estavam expostos em um endpoint HTTP aberto. Imagino que isso estivesse hardcoded no código cliente ou que tenham descoberto observando o padrão das requisições. Não é fácil inferir a arquitetura de backend ou o modo de armazenamento de mensagens só com essa informação, então fico me perguntando se estou deixando passar algo.Expor um endpoint
/heapdumpsem autenticação em produção parece erro de iniciante. É ainda mais grave num serviço que lida com comunicações sensíveis do governo. O uso de tecnologias antigas como hash MD5 e JSP também revela falta de entendimento de segurança. Este caso é um exemplo clássico de por que segurança defensiva e auditorias regulares são indispensáveis.next.js, por exemplo), também dá para criar endpoints vulneráveis sem autenticação.Acho que, quando parlamentares tentam proibir criptografia e2e ou exigir backdoors, este caso pode ser citado como um bom exemplo real.
Como os dados são sensíveis e contêm muita PII, a DDoSecrets diz que vai compartilhar apenas com jornalistas e pesquisadores. Em geral, sou a favor de divulgação responsável, mas neste caso acho que talvez fosse necessário um vazamento mais doloroso e impactante. Ditadores e oligarcas não ligam muito se forem hackeados e continuarão usando ferramentas parecidas; só quando a população prejudicada se indignar é que pode haver mudança. A inteligência do povo ficou menos protegida por causa dessa falha de segurança. Mesmo que imprensa ou pesquisadores tentem noticiar isso, em sociedades autoritárias eles podem ser facilmente silenciados, criando uma situação em que ninguém conhece a realidade. Os detentores do poder podem continuar justificando a repressão sem resistência nem consequências. Se fosse apenas um incidente comum de segurança corporativa, eu preferiria divulgação responsável, mas para impedir a ditadura acho que o critério precisa ser outro.
Hoje em dia nem é necessário silenciar jornalistas. Muita gente já acredita mais em contas anônimas de redes sociais ou influenciadores políticos como fonte de informação, então mesmo que algo seja exposto, basta chamar de “fake news” e seguir em frente. Se eleitores suficientes forem enganados, no fim não faz muita diferença.
Acho perigosa a ideia de que é preciso aceitar danos para despertar a população para uma má governança. Se esse raciocínio for levado ao extremo, pode acabar justificando violência e sofrimento ainda maiores. É perigoso pensar, de modo geral, que as pessoas só acordam quando são mais feridas.
Se isso for realmente divulgado, o dano pode não atingir os líderes, mas sim colocar informantes internos em risco. Por exemplo, se houver nos logs informações sensíveis sobre agentes de inteligência, vidas podem ficar ameaçadas.
Mencionam o antigo vazamento do Cabinet australiano e explicam que a emissora ajudou a encobrir o caso ao devolver a maior parte das informações ao governo. Esse tipo de atitude pode acabar escondendo fatos importantes que a população deveria conhecer e ter grande impacto político. Acham que o Signalgate atual é parecido. Independentemente de partido, enfatizam que o direito da população de saber mais é importante.
Acho irônico ver políticos fazerem lobby para transformar software de comunicação em algo com backdoor e depois eles mesmos acabarem sendo hackeados do mesmo jeito. Infelizmente, não parecem ter capacidade de compreensão nem empatia suficientes para entender o significado dessa sequência de acontecimentos.