CVE-2025-48927

O serviço TeleMessage (TM SGNL, um clone do Signal usado por funcionários do governo dos EUA e empresas como a Coinbase) expunha publicamente o endpoint /heapdump do Spring Boot Actuator em seu servidor de arquivamento (archive.telemessage.com), sem autenticação. Qualquer pessoa que acessasse essa URL baixava um dump de memória de ~150 MB contendo credenciais, chaves de criptografia e mensagens em texto claro. O CVSS de 5,3 (apenas confidencialidade baixa) subestima grosseiramente o impacto real: nesse caso específico, o vazamento incluiu senhas de clientes governamentais e corporativos e conversas supostamente 'criptografadas de ponta a ponta'.

A falha é classificada como CWE-1188 (Initialization of a Resource with an Insecure Default). O Spring Boot Actuator é um conjunto de endpoints de monitoramento e debug que o framework expõe opcionalmente. Até a versão 1.5 do Actuator (2017), o endpoint /heapdump vinha habilitado e acessível sem autenticação por padrão; versões posteriores mudaram o padrão para expor apenas /health e /info sem autenticação. O problema não está em um bug de código, mas em configuração: alguém deixou o /heapdump ativo e público no servidor de arquivamento da TeleMessage, provavelmente um resquício de ambiente de teste/diagnóstico que migrou para produção sem revisão.

O endpoint retorna um heap dump — uma fotografia completa da memória da aplicação Java no momento da requisição. Como o servidor de arquivamento processa e repassa mensagens do TM SGNL para o destino final do cliente, essa memória continha os corpos das requisições HTTP em trânsito: nomes de usuário, senhas, chaves de criptografia e o conteúdo de mensagens de chat não criptografadas. Isso contradiz o material de marketing da TeleMessage, que afirmava criptografia de ponta a ponta do celular até o arquivo corporativo — a análise do código-fonte mostrou que as mensagens chegavam sem criptografia ao servidor de arquivamento antes de serem repassadas.

Agravantes reportados no mesmo incidente (não fazem parte desta CVE, mas compõem o cenário): o painel administrativo em secure.telemessage.com fazia hash MD5 das senhas no lado do cliente, o que anula o propósito do hashing, e a aplicação usava JSP, tecnologia datada, sinalizando maturidade de segurança baixa no stack como um todo.

O vetor é trivial: uma requisição GET não autenticada à URL /heapdump em um host acessível pela internet. Não há necessidade de autenticação, engenharia social, ou condição de rede especial — basta o endpoint estar exposto publicamente, o que caracteriza uma falha de configuração, não de lógica de aplicação. Complexidade de ataque: baixa. O pesquisador que relatou o caso à WIRED usou feroxbuster (ferramenta de descoberta de caminhos web) contra os domínios da TeleMessage e localizou o endpoint em archive.telemessage.com em poucos minutos.

Após baixar o dump (~150 MB), o atacante buscou a string 'password' no arquivo binário e extraiu credenciais de usuários em texto claro. Com um par de credenciais, conseguiu autenticar em secure.telemessage.com e acessar a conta de um cliente associado ao U.S. Customs and Border Protection (CBP), além de localizar logs de chat internos da Coinbase. Todo o processo, do reconhecimento inicial ao comprometimento de contas reais, levou entre 15 e 20 minutos segundo o próprio autor do ataque.

A exploração está confirmada como ativa (catálogo KEV da CISA, adicionada em 2025-07-01) e documentada publicamente por WIRED/404 Media em maio de 2025. Não há indício de que a exploração exigisse qualquer conhecimento privilegiado além de reconhecimento de URLs — o único 'segredo' era saber que o endpoint existia, algo que ferramentas de enumeração de diretórios revelam rapidamente.

Não há advisory oficial do fornecedor disponível nas fontes consultadas — TeleMessage e sua controladora Smarsh não responderam a pedidos de comentário da imprensa, e a empresa suspendeu temporariamente todos os serviços após o incidente. Não é possível apurar aqui uma versão corrigida específica publicada pelo fornecedor; a CISA orienta aplicar mitigações conforme instrução do fornecedor ou, na ausência delas, descontinuar o uso do produto.

Como controle geral para qualquer aplicação Spring Boot: os endpoints do Actuator (heapdump, env, mappings, etc.) nunca devem ser expostos sem autenticação em produção — apenas /health e /info são considerados de baixo risco para exposição pública. A mitigação correta é desabilitar o endpoint (management.endpoint.heapdump.enabled=false) ou restringi-lo a interfaces de gerenciamento internas, com autenticação e controle de rede (management.endpoints.web.exposure.include limitado, ou porta de management separada da porta da aplicação). Isso é configuração de framework, não patch de CVE — não existe 'versão corrigida' para o comportamento padrão do Actuator, exposição incorreta é responsabilidade de quem faz o deploy.

O que não funciona: assumir que a criptografia de ponta a ponta anunciada pelo fornecedor protege o conteúdo das mensagens é um mito específico deste caso — a análise de código mostrou que as mensagens passavam em texto claro pelo servidor de arquivamento antes de qualquer processamento. Nenhum WAF resolve isso se o endpoint sensível continuar habilitado; a única mitigação real é configuração correta do Actuator ou remoção do serviço, como recomendou a própria CISA.

Em logs de servidor web, procure por requisições GET a caminhos terminados em /heapdump ou /actuator/heapdump, especialmente vindas de IPs não corporativos ou ferramentas de enumeração (user-agents de feroxbuster, dirb, gobuster, ou varreduras sequenciais de caminhos). Uma resposta bem-sucedida a essa URL gera uma transferência de dados atipicamente grande (dezenas a centenas de MB) em uma única requisição, o que deve destacar-se em métricas de volume de tráfego de saída.

Não há assinatura confiável para diferenciar reconhecimento malicioso de tráfego legítimo de monitoramento interno além da origem da requisição e da ausência de autenticação — se o endpoint estava exposto sem controle de acesso, qualquer acesso ao /heapdump por origem externa à rede de gerenciamento deve ser tratado como incidente, já que não há uso legítimo desse endpoint por usuários finais ou clientes.