A insegurança da pilha de telecom após o Salt Typhoon
(soatok.blog)- Após a invasão do Salt Typhoon, ao revisar software de telecom open source, foi descoberto um buffer overflow sem autenticação na biblioteca XMLRPC empacotada com o FreeSWITCH
- A vulnerabilidade ocorre em um código que grava a Request URI em uma variável de pilha de 4096 bytes usando
sprintf(), e, independentemente das limitações do navegador, pode ser possível enviar requisições com mais de 4096 caracteres - A SignalWire respondeu que três PRs de correção foram publicados no GitHub em fevereiro de 2025, mas informou que a nova release da FreeSWITCH Community não está planejada até o verão de 2025
- No Shodan, havia cerca de 8.300 resultados para FreeSWITCH, e operadores sem uma tag de release precisam reagir por conta própria, compilando a partir do código-fonte ou bloqueando via firewall
- Este caso mostra que o risco na segurança de telecom cresce não só pela vulnerabilidade em si, mas também pela gestão de vulnerabilidades e pela resposta de release, e mesmo após a atribuição do CVE-2025-44087 em 30 de abril de 2025, ainda não havia release do FreeSWITCH
O que levou a analisar o FreeSWITCH após o Salt Typhoon
- No fim de 2024, o ponto de partida foi a notícia de que o grupo Salt Typhoon, supostamente ligado ao governo chinês, havia comprometido a T-Mobile e outras operadoras
- Não era possível investigar diretamente redes de operadoras móveis, mas havia muitos projetos open source relacionados a telecom no GitHub
- Já havia experiência anterior trabalhando com empresas que usavam Asterisk e FreeSWITCH, mas sem uma análise profunda de PBX, SIP e codificação de áudio
- A expectativa era de que vulnerabilidades simples já tivessem sido encontradas, dada a tradição da área de telecom, com excelentes programadores em C, comunidades antigas de hackers e engenheiros vindos dos Bell Labs
- Ainda assim, a vulnerabilidade foi encontrada logo após abrir o código-fonte do FreeSWITCH
Buffer overflow no processador de requisições HTTP do XMLRPC
- O processador de requisições HTTP da biblioteca XMLRPC empacotada com o FreeSWITCH grava a URI em um buffer de pilha de tamanho fixo
z[4096] - O código problemático tem a forma
sprintf(z, "Index of %s" CRLF, uri);, e comourivem da parte path da Request URI, ele pode ser controlado por um atacante - Muitos navegadores não lidam bem com URLs maiores que 2048 caracteres, mas os RFCs relevantes geralmente permitem cerca de 8 KB, e a Cloudflare suporta até 32 KB
- Portanto, é razoável considerar que um atacante possa enviar uma Request URI com mais de 4096 caracteres, o que leva a um buffer overflow sem autenticação na biblioteca XMLRPC
- O processo de escalar isso para execução remota de código não é abordado
Forma de correção e patches publicados
- A direção da correção é usar
snprintf()no lugar desprintf() - Isso faz parte de práticas básicas de programação defensiva em C
- A SignalWire afirmou que o problema havia sido corrigido recentemente e indicou os seguintes PRs
- Como os patches já estavam publicados no GitHub, concluiu-se que era possível publicar o texto
Processo de divulgação da vulnerabilidade e lacuna de release
- Em 27 de janeiro de 2025, os detalhes da vulnerabilidade foram enviados para o endereço de e-mail indicado na política de segurança do FreeSWITCH
- Em 7 de fevereiro de 2025, foi enviado um e-mail de acompanhamento para confirmar o recebimento do relatório
- No mesmo dia, Andrey Volk respondeu que a vulnerabilidade havia sido corrigida recentemente e orientou a consultar os PRs relacionados
- Ao perguntar sobre o cronograma de uma release com as correções de segurança, veio a resposta de que a release da FreeSWITCH Community não está planejada até o verão de 2025
- Com isso, usuários que não pagam pelo FreeSWITCH Advantage podem permanecer vulneráveis até a próxima release regular
Escala da exposição e impacto para operadores
- Na época, havia cerca de 8.300 resultados para FreeSWITCH no Shodan
- Como é improvável que todas essas instâncias paguem por suporte enterprise, a avaliação é que milhares de pilhas de telecom no mundo inteiro podem permanecer vulneráveis até o verão
- Mesmo que os patches estejam públicos no GitHub, sem uma tag de release fica difícil para operadores comuns atualizarem com facilidade
- Em vez de esperar por uma release da SignalWire, operadores de FreeSWITCH deveriam considerar as seguintes medidas
- Recompilar diretamente a partir do código-fonte
- Bloquear o acesso HTTP público à pilha FreeSWITCH no nível do firewall
Problema estrutural da segurança em telecom
- Em conversas com pessoas da indústria de telecom, a reação foi de que até a velocidade de resposta do FreeSWITCH já seria considerada rápida
- Em dezembro de 2024, voltaram a surgir alertas sobre uma vulnerabilidade no SS7 presente havia 17 anos na rede telefônica
- Depois dessa experiência, não houve investigação adicional sobre Asterisk ou outros softwares
- Em conclusão, a avaliação é de que a segurança em telecom hoje está em más condições
- Um dos principais motivos parece ser a quase ausência de incentivos financeiros para tornar esses sistemas seguros
Situação posterior
- Na atualização de 30 de abril de 2025, foi atribuído o CVE-2025-44087 ao buffer overflow reportado
- Mesmo nesse momento, ainda não havia tag nem release do FreeSWITCH
1 comentários
Comentários do Hacker News
O autor admite que não tem nenhuma experiência com infraestrutura de nível operadora, mas a suspeita em si está em grande parte correta
Na prática, já fiz bastante teste de intrusão e pesquisa de segurança em 4G/5G com várias grandes operadoras, e embora haja diferenças entre operadoras e fornecedores de equipamentos, ainda é algo muito próximo de um verdadeiro show de horrores
Até bem recentemente, segurança era na prática apenas segurança por obscuridade, e os padrões 4G/5G começaram a tratar disso, mas ainda restam brechas grandes o bastante para causar séria preocupação
Não é exagero considerar que agentes de ameaça de nível intermediário ou superior consigam estabelecer uma cabeça de ponte em uma operadora, e eu mesmo já demonstrei isso profissionalmente várias vezes
Os fornecedores de equipamentos de um certo país do Leste Asiático têm uma qualidade de stack de software tão baixa que quase dá para classificá-los como uma APT, e a segurança é praticamente inexistente
Há razões legítimas para países ocidentais terem banido esses fornecedores, e o software dos fornecedores ocidentais é bem mais maduro, mas ainda assim está vários anos atrás do que consideraríamos práticas modernas de segurança
O GCHQ concluiu que a qualidade do código era tão ruim que era impossível revisá-lo adequadamente, e que não havia sequer garantia de que o código-fonte fornecido fosse o mesmo que rodava de fato nos equipamentos
Isso porque a Huawei podia atualizá-los diretamente, e pelo que sei esses equipamentos foram proibidos depois de 2020: https://www.washingtonpost.com/world/national-security/brita...
Queria comprar um no AliExpress e dar uma olhada; este link seria um bom ponto de partida?
https://vulners.com/search/types/huawei
Em 2025, realmente não consigo entender por que os padrões de telefonia móvel ainda usam chave pré-compartilhada
RSA e Diffie-Hellman[1] já existem há décadas, e a infraestrutura de autoridades certificadoras também é antiga, mas os cartões SIM ainda são emitidos com uma chave pré-compartilhada conhecida apenas pelo cartão e pela operadora, e depois toda a autenticação e criptografia se baseia nessa chave
Se a operadora for invadida e a chave vazar, não há nada que se possa fazer
Pior ainda, essa chave precisa ser enviada pelo fabricante do SIM à operadora, e como o fabricante pode estar em outro país e sujeito a exigências de um governo estrangeiro, há amplas oportunidades para invasão do fabricante ou interceptação durante a transmissão
Isso parece uma vulnerabilidade NOBUS, e se o fabricante do SIM ou o fornecedor de equipamentos do core da rede repassar as chaves à NSA em conluio, seria possível potencialmente espionar o tráfego móvel do mundo inteiro
[1] Sei que esses algoritmos já não são mais prática recomendada e que curvas elípticas são melhores, mas, comparado ao que temos hoje, até RSA seria melhor
[2] https://nickvsnetworking.com/hss-usim-authentication-in-lte-...
“Segundo documentos ultrassecretos da NSA fornecidos por Edward Snowden, espiões dos Estados Unidos e do Reino Unido invadiram a rede interna de computadores do maior fabricante de cartões SIM do mundo e roubaram as chaves de criptografia usadas para proteger a privacidade das comunicações de celulares no mundo inteiro”
https://theintercept.com/2015/02/19/great-sim-heist/
Não sei se isso ainda acontece hoje, mas antigamente era difícil considerar o celular um meio de comunicação seguro
Provavelmente o ideal seria conversar por comunicação de dados criptografada de ponta a ponta entre dispositivos
Algoritmos de chave simétrica também têm a vantagem de serem seguros contra computação quântica
Ainda assim, em 2025 eu esperaria pelo menos suporte a ECC, e hoje a maioria dos smart cards já deveria conseguir oferecer isso por padrão
Se você não pode confiar no fornecedor do cartão SIM, na prática não há solução
Mesmo com um esquema assimétrico, o vetor de ataque só muda um pouco; se você não pode confiar no software rodando no cartão, como saber que ele não está vazando texto plano por meio da escolha de números aleatórios em algoritmos não determinísticos?
A ideia de que colocar RSA em um sistema simétrico o torna mais seguro tem pouca base; na verdade, está mais para o contrário
A expressão “vulnerabilidade NOBUS” também é especialmente estranha, porque a raiz de confiança nesse tipo de sistema é a operadora
Nem faz sentido perguntar se operadoras americanas estariam “em conluio” com agências de inteligência dos EUA, porque é melhor partir do princípio de que já estão
Golpistas são grandes clientes das operadoras, e quando são pegos e bloqueados, voltam, pagam a taxa de ativação de uma nova linha e repetem o mesmo processo
Os golpistas também ajudam a vender recursos extras, então deixar de resolver o problema também gera mais receita
Como conclui o post do blog, não é nada surpreendente que o Freeswitch não mude o cronograma de lançamentos da comunidade
O Freeswitch de antigamente tinha um forte espírito comunitário, mas o clima mudou depois que ele foi comercializado de forma mais agressiva alguns anos atrás
Desde então, para acessar coisas que deveriam ser públicas, era preciso passar por um processo de “cadastro” e, se bem me lembro, coisas como o repositório APT ficaram escondidas atrás dessa barreira de registro
Não quero me cadastrar em uma empresa comercial para acessar conteúdo de uma comunidade de software livre
Todo mundo no setor de tecnologia sabe que, se você dá suas informações a uma empresa comercial, o pessoal de vendas vai encher o saco com upsell, cross-sell e ainda te colocar em listas de e-mail que você não pediu
Também vi outras partes da comunidade VoIP recalibrarem sua generosidade em relação ao open source e, sinceramente, é difícil culpá-las
A equipe da Matrix.org também falou de algo parecido em uma das apresentações da FOSDEM’25, sobre o problema de fornecedores comerciais pegando carona no desenvolvimento
Seria ótimo se eles também disponibilizassem atualizações gratuitas até para o repositório APT, mas isso seria exatamente isso: algo “bacana da parte deles”
Se você depende do código deles mas não quer pagar pelos custos de suporte, então pode compilar os pacotes APT por conta própria
Não sei bem que tipo de espírito comunitário se deve esperar de um projeto mantido por uma única empresa dessa forma
Considerando agentes de ameaça estrangeiros, alianças ocidentais como a Five Eyes e a pressão constante para fazer os números subirem, parece razoável assumir que não existe anonimato real online
Se eles quiserem você, também têm meios de te pegar
Na prática, isso não é tão diferente da era anterior à internet
Se você não quer ser interceptado, precisa criptografar de uma forma que grandes agências de segurança não consigam acessar eletronicamente com facilidade
Tipo bilhetes físicos, comunicação verbal, gestos com as mãos
Também é preciso estar preparado para arcar com as consequências do que você disse e fez online quando um ator estatal realmente alocar recursos para explorar esses dados
Só pelo artigo, eu não fico totalmente convencido da conclusão de que “a segurança de telecomunicações hoje é uma bagunça”
Parece mais um caso de escolher o Freeswitch arbitrariamente e encontrar um buffer overflow
A “stack de telecomunicações” pode ser vulnerável ou não, mas a evidência apresentada aqui é muito fraca
Foi divulgado que o ataque Salt Typhoon explorou uma vulnerabilidade da Cisco, mas analistas também levantaram a possibilidade de os atacantes terem usado credenciais legítimas: https://cyberscoop.com/cisco-talos-salt-typhoon-initial-acce...
Então isso não tem relação com o Freeswitch
O Oracle SBC frequentemente já é instável só no funcionamento básico, e certamente haverá algum bug de negação de serviço que nem consegue ser devidamente isolado no caos da implementação TRouter que o Teams lança esta semana
E nem vamos falar da confusão do MF Tandem ou do fato de quase toda operadora simplesmente deixar tráfego SIP UDP bruto e não criptografado exposto na internet
É possível construir sistemas seguros nessa área, mas a realidade é que a maioria das grandes operadoras roda uma pilha de dívida técnica pior do que equipamentos antigos e sem patch que compõem a rede, além de plataformas proprietárias e impossíveis de modificar de empresas ou projetos mortos há muito tempo, como Nortel e Metaswitch
A frase “está tudo uma bagunça e não há motivação para consertar” é só um resumo
Sinceramente, essas conversas são muito difíceis de acompanhar se você não conhece o jargão, e eu mesmo não entendo essa área o suficiente para tentar explicar de forma desajeitada, então escrevi só isso
Eu não esperava nem um pouco que meu blog aparecesse no Hacker News
É código que faz parsing de protocolos de rede complexos, carregando legado de várias gerações, muitas vezes escrito em segredo e quase sempre em C/C++
Claro que isso não teria vulnerabilidades. Claro
Protocolos como SS7 foram projetados sem qualquer noção de hackers ou agentes maliciosos
Dá para colocar firewalls por cima, mas isso entra em conflito com os recursos desejados e, mesmo quando não entra, ainda exige investimento extra
O DIAMETER é melhor, mas ainda tem muitos buracos
Nos últimos anos, a segurança em telecom se tornou prioridade e houve melhorias, mas ainda é preciso envolver décadas de hardware, software, firmware e design de rede legados
Duvido que haja lugares rodando Freeswitch padrão puro em redes de telecom, mas, como produto de telecom antigo em que a segurança não foi buscada tanto quanto deveria, os tipos de problema do Freeswitch estão espalhados por toda parte
É ótimo que o autor tenha olhado o código no tempo livre, encontrado bugs e reportado isso, e eu não quero desencorajar isso de forma alguma
Mas o fato de um único mantenedor de um único software não ter se curvado ao autor de acordo com as melhores práticas da indústria de segurança não basta para dizer que “a segurança de telecom hoje é uma bagunça”
Se alguém trouxer um bug no seu código sem afirmar que ele está sendo explorado de fato, e sem fornecer um PoC para confirmar a explorabilidade, existe algum motivo para não tratá-lo como um bug comum?
Corrija agora e coloque no próximo release
As pessoas conseguem ver as mudanças? Sim, como conseguem ver todas as outras mudanças
Se alguém conseguir encontrar um exploit, só resta desejar boa sorte, porque o autor do relatório não conseguiu
A mesma coisa acontece em distribuições Linux
Bugs de segurança são reportados e, às vezes, o autor upstream não está nem sendo teimoso — ele literalmente já morreu
Se você quiser mudar isso no seu próprio cronograma, então faça o release você mesmo
Uma área em que o Freeswitch provavelmente é usado com bastante frequência é em instalações do BigBlueButton em escolas e universidades
É um sistema de sala de aula virtual e muitas vezes deve ser usado sem contrato de suporte, então isso me preocupa mais do que operadoras
Fico me perguntando quantas pessoas realmente usam o módulo XML RPC
Ele não é carregado por padrão
Atualização: segundo o Shodan, são 468
Também fico me perguntando se
senddirectorydocumentno módulo XML RPC é realmente usadocurl --show-error --get --request GET --user freeswitch:works "http://localhost:8080/${SIXTEEN_THOUSAND_RANDOM_CHARACTERS}";Alguém tem alguma ideia de como acionar isso?
Se aparecer ao menos uma PoC que provoque um segfault, acho que a chance de sair um release de segurança fica bem maior
O hack realmente bom acontece com injeção de CAMEL MAP
Isso controla todo tipo de coisa boa: SMS, USSD e até a joia da coroa, os serviços de localização
Muitas empresas de “SMS em massa” em lugares como ilhas ricas do Caribe ou a Indonésia fazem muito mais do que só enviar spam
Então é antigo, e o 2G foi projetado nos anos 1990
Não sei bem o que as pessoas esperam
Sinceramente, já é lucro se funcionar
Grandes operadoras não rodam FreeSwitch ou Asterisk no core
É claro que a Motorola está descontinuando o produto, mas ele existe em campo
O que eu cuido está fortemente protegido por firewall, mas duvido que todos estejam
A maioria das empresas com PBX que quer fazer algo além de roteamento básico de chamadas e conexão com a PSTN provavelmente usa ferramentas de terceiros
E uma parte considerável dessas ferramentas é construída sobre FreeSWITCH, Asterisk ou similares
Recomendo fortemente a apresentação da P1 Security sobre segurança em telecom móvel: https://www.slideshare.net/slideshow/day1-hacking-telcoequip...
O material é antigo, mas não há motivo para acreditar que tenha melhorado
Porque não existe incentivo algum para melhorar
Além disso, vulnerabilidades de segurança de software são apenas parte do problema; a outra parte é que as operadoras terceirizam de bom grado o controle e o acesso central a quem oferecer o menor preço: https://berthub.eu/articles/posts/5g-elephant-in-the-room/