Durante uma reunião recente do gabinete, o então conselheiro de segurança nacional de Donald Trump, Mike Waltz, deve ter ficado entediado. Aparentemente, sem saber do fotógrafo atrás dele, foi flagrado clandestinamente verificando suas mensagens do Signal debaixo da mesa.
Na verdade, ele não estava usando o aplicativo oficial do Signal, que é amplamente considerado o padrão ouro dos aplicativos de mensagens criptografadas. Ele estava usando um clone do Signal chamado TeleMessage Signal, ou TM SGNL. Este aplicativo, feito pela TeleMessage (que foi recentemente adquirida pela Smarsh), funciona de maneira quase idêntica ao Signal, exceto que também arquiva cópias de todas as mensagens que passam por ele, destruindo todas as suas garantias de segurança.
Dois dias após a publicação da foto de Waltz, uma fonte anônima me disse que havia hackeado o TeleMessage. “Eu diria que todo o processo levou cerca de 15 a 20 minutos”, disse o hacker. “Não foi muito esforço.” Representantes da TeleMessage e da Smarsh não responderam a um pedido de comentário.
A exploração que o hacker usou foi incrivelmente simples. Na época, decidimos não publicar detalhes sobre isso porque seria muito fácil para outros replicarem. Desde então, a TeleMessage suspendeu temporariamente todos os serviços, que é agora por que a WIRED pode compartilhar exatamente como esse hack ocorreu sem arriscar os dados privados de ninguém.
“Primeiro, olhei para o painel de administração secure.telemessage.com e percebi que eles estavam hashando senhas para MD5 no lado do cliente, algo que anula os benefícios de segurança de hash de senhas, já que o hash efetivamente se torna a senha”, disse o hacker. (Hashing é uma forma de ofuscar criptograficamente uma senha armazenada em um sistema, e MD5 é uma versão inadequada dos algoritmos usados para fazê-lo.) O Drop Site News relatou desde então que parece que este painel de administração expôs endereços de e-mail, senhas, nomes de usuário e números de telefone ao público.
A fraca hash de senhas e o fato de que o site da TeleMessage foi programado com JSP—uma tecnologia da era dos anos 2000 para criar aplicativos web em Java—deu ao hacker “a impressão de que sua segurança deveria ser pobre”. Esperando encontrar arquivos JSP vulneráveis, o hacker então usou feroxbuster, uma ferramenta que pode rapidamente encontrar recursos disponíveis publicamente em um site, em secure.telemessage.com.
O hacker também usou feroxbuster em archive.telemessage.com, outro domínio usado pela TeleMessage, onde descobriu a URL vulnerável, que terminava em /heapdump.
Quando carregou esta URL, o servidor respondeu com um despejo de heap Java, que é um arquivo de cerca de 150 MB contendo uma captura da memória do servidor no momento em que a URL foi carregada.
O hacker disse que “sabia pela experiência passada que despejos de heap de servidores web” incluirão os “corpos” das solicitações http, disseram eles, “e isso pode incluir credenciais de usuários fazendo login.” E para o TM SGNL, eles fizeram. Ao baixar um despejo de heap e então procurar por “senha”, o hacker pôde ver nomes de usuários e senhas de usuários aleatórios.
Eles tentaram fazer login em secure.telemessage.com usando um par dessas credenciais e descobriram que haviam acabado de hackear um usuário com um endereço de e-mail associado ao Departamento de Segurança Interna dos EUA, uma das agências que implementa a draconiana política de imigração de Trump. O CBP confirmou desde então que era um cliente da TeleMessage.
Depois de passar mais alguns minutos explorando o despejo de heap, o hacker também descobriu logs de chat em texto simples. “Posso ler chats internos da Coinbase, isso é incrível”, disse o hacker. (A Coinbase não respondeu ao pedido de comentário da WIRED, mas disse à 404 Media que “não há evidências de que qualquer informação sensível de clientes da Coinbase foi acessada ou que contas de clientes estão em risco, uma vez que a Coinbase não usa essa ferramenta para compartilhar senhas, frases-semente ou outros dados necessários para acessar contas.”)
Neste ponto, o hacker disse que havia passado de 15 a 20 minutos mexendo nos servidores da TeleMessage e já havia comprometido um de seus clientes do governo federal, junto com uma das maiores exchanges de criptomoedas do mundo.
Como descobri ao analisar o código-fonte do TM SGNL, os aplicativos da TeleMessage—como o que está rodando no telefone de Mike Waltz—carregavam mensagens não criptografadas para archive.telemessage.com (eu chamo isso de servidor de arquivo), que então encaminha as mensagens para o destino final do cliente. Isso contradiz o material de marketing público da TeleMessage, onde afirmavam que o TM SNGL usa “criptografia de ponta a ponta do telefone móvel até o arquivo corporativo.”
O servidor de arquivo é programado em Java e é construído usando o Spring Boot, um framework de código aberto para criar aplicativos Java. O Spring Boot inclui um conjunto de recursos chamados Actuator que ajudam os desenvolvedores a monitorar e depurar seus aplicativos. Um desses recursos é o endpoint de despejo de heap, que é a URL que o hacker usou para baixar despejos de heap.
De acordo com a documentação do Spring Boot Actuator: “Como os Endpoints podem conter informações sensíveis, deve-se ter cuidado ao considerar quando expô-los.” No caso do servidor de arquivo da TeleMessage, os despejos de heap continham nomes de usuários, senhas, logs de chat não criptografados, chaves de criptografia e outras informações sensíveis.
Se alguém na internet tivesse carregado a URL do despejo de heap exatamente quando Mike Waltz estava enviando mensagens usando o aplicativo TM SGNL, o arquivo de despejo de heap teria contido suas mensagens não criptografadas do Signal também.
Uma postagem de 2024 no blog da empresa de segurança em nuvem Wiz lista “Arquivo HeapDump exposto” como a principal configuração incorreta comum no Spring Boot Actuator. “Até a versão 1.5 (lançada em 2017), o endpoint /heapdump foi configurado como publicamente exposto e acessível sem autenticação por padrão. Desde então, em versões posteriores, o Spring Boot Actuator mudou sua configuração padrão para expor apenas os endpoints /health e /info sem autenticação (estes são menos interessantes para atacantes)”, escreveu o autor. “Apesar dessa melhoria, os desenvolvedores muitas vezes desativam essas medidas de segurança para fins de diagnóstico ao implantar aplicativos em ambientes de teste, e essa aparentemente pequena mudança de configuração pode permanecer despercebida e, portanto, persistir quando um aplicativo é enviado para produção, permitindo inadvertidamente que atacantes obtenham acesso não autorizado a dados críticos.”
Em uma postagem de 2020 no blog da Walmart Global Tech, outro desenvolvedor deu um aviso semelhante. “Além de /health e /info, todos os endpoints do actuator são arriscados para abrir para usuários finais porque podem expor despejos de aplicativos, logs, dados de configuração e controles”, escreveu o autor. “Os endpoints do actuator têm implicações de segurança e NUNCA DEVEM ser expostos em ambiente de produção.”
A exploração rápida do hacker do TeleMessage indica que o servidor de arquivo estava mal configurado. Estava rodando uma versão do Spring Boot de oito anos ou alguém havia configurado manualmente para expor o endpoint de despejo de heap para a internet pública.
É por isso que levou a um hacker cerca de 20 minutos de tentativa antes que ele se abrisse, com dados sensíveis vazando.