[BPF] Análise e Mitigação do Problema com Chips Realtek
Fernando Frediani
fhfrediani em gmail.com
Seg Set 29 15:21:39 -03 2025
Olá André
Obrigado por compartilhar essas informações com tanta riqueza de detalhes.
Queria fazer 2 observações à respeito de 2 pontos:
1 - Vejo muitos falaram sobre colocar regras de firewall na CPE na
tentativa de deter o ataque mas sinceramente não creio muito que esse
seja o fato principal de infecção por 2 razões principais: 1) a maioria
das CPEs já vem com firewall padrão para a WAN que não permite
praticamente nenhuma conexão entrante, muito menos para falar como o ALG
SIP que poderia receber algo ali. 2) a vasta maioria das CPEs hoje em
dia está em IPs de CGNAT, portanto não exploráveis de fora do ISP. Mesmo
que não houvesse firewall suficiente na WAN não faz muito sentido pra
mim pensar que a infecção chega por ali.
Fez sentido sim pensar que vem através de outros dispositivos conectados
diretamente à LAN essa sim que vai receber o que bater ali
2 - Algo que eu vim tentando entender até aqui era se esses problema
infecta o sistema de arquivos da CPE com alguma ferramenta que fica
instalada permanentemente e persiste à reboot ou se era algo nessa linha
que você falou que a infecção fica na memória e quando a CPE é rebootada
tudo volta ao normal até a infecção novamente.
Porque se existe algum tipo de infecção do sistema de arquivo e algo
instalado na CPE um upgrade de firmware por si só não resolveria sem
factory reset. Já se fica restrito à memória ai sim pois em teoria
corrige a vulnerabilidade do ALG SIP.
Fernando Frediani
On 9/26/2025 12:26 PM, Andre Bolzan wrote:
>
> OLA!!
>
> "previsão do que pretendemos" mandaremos no GTER, Guie (Polleto) quer
> polir melhor texto..
> Eu discordo, porque problema é "multidisciplinar e nem todo mundo
> entende de CPE, CVE, Linux, etcs)
>
> TEXTO:
>
> Gostaria de compartilhar uma análise sobre o recente problema de
> segurança envolvendo a vulnerabilidade CVE-2022-27255 em chips
> Realtek, que afetou provedores e serviços no Brasil e no mundo.
>
> A solução definitiva para esta vulnerabilidade é a atualização de
> firmware.Precisamos cobrar os fabricantes, integradores, e
> distribuidores!!! A CVE tem 3 anos, o patch da Realtek para SDK saiu
> logo em seguida. É vergonhoso que versões de firmware datadas de 2023,
> 2024, 2025 ! , tenham saído sem essa correção!Queria deixar
> registrado para os colegas que trabalham com Hosting, colocation, os
> famosos PC(provedor de conteúdo, outro lado da moeda ), que todo esse
> problema só aconteceu na parte antiga da internet. o ALG é
> “gambiarra” para IPv4.Invistam em infraestrutura IPv6.Fica a
> provocação: O impacto poderia ser bem menor, se pudéssemos desativar
> essas gambiarras, e entregar ao usuário uma experiência IPV6-Nativa
> completa.
>
> Os passos que sugerimos e tem se mostrado muito eficiente para mitigar
> a falha: 0. Atualizar o firmware, quando disponibilizado pelo
> fornecedor
>
> 1.
>
> Desativar a função ALG SIP no firewall da CPE: Esta funcionalidade
> contém o trecho de código vulnerável. Desativá-la remove o vetor
> de ataque primário.
>
> 2.
>
> Filtrar/bloquear o tráfego na porta 5060 UDP entre as CPEs: Esta
> porta é o principal meio de propagação da infecção entre os
> equipamentos. Bloquear este tráfego impede que a ameaça se
> prolifere lateralmente na rede. Não é possível usar filtro de lan
> na CPE, veremos adiante nessa jornada…
>
> 3.
>
> Remoção de equipamentos do parque (último recurso): Em casos onde
> as medidas anteriores falham, é provável que a CPE esteja com a
> infecção em um nível mais profundo.
>
> Análise Detalhada da vulnerabilidade… Ou tentativa.. demos(lá ele
> 100x) uma de “analistas de seguranças”, mas não é nossa área de
> atuação, foi a necessidade que fez o ladrão, aqueles que acharem as
> “simplificações” falhas, eu concordo, objetivo é “espalhar
> conhecimento” de maneira didática =) me esforcei ao máximo….Esse
> incidente me fez lembrar da primeira onda de ransomware(wannacry), a
> segurança corporativa passou anos fechando tudo de fora para dentro e
> os ataques evoluíram para ser executados de dentro para fora.Essa é a
> primeira vez que vejo explorarem vulnerabilidade **de dentro para
> fora** no setor de ISP, e, talvez por isso, nossa resposta
> “demorou”.Tivemos várias iniciativas no início dos ataques, fomos
> trabalhando primeiro mitigando na borda, etc.. E depois fomos para
> BRAS visando poupar os CGNATs que sofreram bastante…Num trabalho a
> muitas mãos, fomos atacar a parte “baixa da coisa” a CPEs, porque na
> nossa análise essa vulnerabilidade poderia inutilizar as porta UPlink
> das OLTs muito rápido… ia dar um “trabalhão” ficar mudando planos de
> dezenas, centenas até milhares de clientes “da noite para dia” com
> atendimento só podendo dizer
>
> “desculpa, estamos trabalhando para normalizar”...agora sim, vamos a
> vulnerabilidade…
>
> Esta falha de segurança permite que um atacante manipula a memória da CPE.
>
> O ponto de entrada é o ALG SIP, um "severino-da-portaria" que facilita
> a comunicação de voz (SIP), para equipamentos não-tolerantes a NAT em
> redes IPv4.A infecção é iniciada com o envio de pacotes contendo um
> payload mágico, forçando um estouro de buffer no ALG SIP. O ALG SIP
> joga os dados que chegam em qualquer interface diretamente na RAM,
> essa é a função real dele, atuar em camada baixa e fazer um “hardware
> offload” de camada 3.Por isso os ataques foram tão “danosos”, às
> medidas “tradicionais” de mitigação como firewall ou acl direto na CPE
> não funcionam nessa vulnerabilidade, tudo que chega nas interfaces da
> CPE vai para RAM diretamente e a CPE se torna vulnerável.Só podemos
> desativar ALG SIP da CPE e impedir que esse pacotes cheguem às
> interfaces(wan, lan,gerência,etcs), precisa tirar o que está
> infectando a CPE, normalmente são os dispostos cliente da casa do
> assinante como tv box(clássicos), PC, androids, etcs.Em casos em que
> não conseguimos convencer o cliente que o problema é equipamento dele,
> só resta trocar a CPE por uma sem a vulnerabilidade, cruzar dedos para
> esse Botnet não alcançar a outras CPEs.Esse processo inicial de
> estourar buffer é simples, muitooooo simples, mas por sorte o
> threadque executa o ALG SIP opera com recursos limitados de CPU e RAM,
> o que dificulta a vida dos atacantes.A infecção, na maioria dos casos,
> roda apenas na memória RAM (não tendo acesso ao sistema de arquivos -
> FS), o que permite que uma simples reinicialização da CPE elimine a
> infecção temporariamente. Vou deixar para explicar o mito de desativar
> IPv6 para final.Depois que CPE foi considerada vulnerável , seu buffer
> ALG SIP cheio, vem a próxima fase do ataque
>
> Fase 1: Ataque de Reflexão o "Upload Maldito"
>
> Com o buffer cheio, somente manipulando a memória da CPE, o atacante
> consegue fazer o clássico ataque de reflexão, ele faz com que a CPE
> pensar que “deve uma resposta” para alguém que não solicitou esse
> tráfego e manipulando o IP e porta de destino.Normalmente a CPE, faz
> o envio de 100 a 200 MB de upload, mesmo que a CPE tenha poder
> computacional para gerar maiores cargas de trabalho, nessa fase do
> ataque, o atacante não tem total controle da CPE, por sorte o PID que
> roda o ALG SIP tem limite de recursos da CPU e RAM. Algumas vezes
> esse PID ou a CPE trava durante o ataque, fazendo com que a memória
> seja limpa e o buffer esvaziado, por consequência a infecção é
> eliminada temporariamente.Essa etapa do ataque um simples reiniciar da
> CPE limpa a memória e elimina a infecção temporariamente.A CPE sera
> reinfectada caso o dispositivo que está explorando a vulnerabilidade
> não seja removido da casa da rede.
>
> Esse tipo de ataque por reflexão, embora simples, é extremamente
> eficiente, além de prejudicar o alvo remoto também degrada o
> desempenho de equipamentos internos como CGNATs, portas uplinks, etcs,
> devido à alta carga de trabalho.
>
> É importante falar que simplesmente desativar o ALG SIP no firewall
> pode não ser suficiente, se o atacante usar credenciais de acesso
> padrão (ex: admin/admin, root/admin), o ALG SIP pode ser reativado e o
> ataque vai ser reiniciado.Desativar ALG SIP , não exclui a
> vulnerabilidade, apenas adormece o problema, não deixando que o código
> ruim seja executado.Deixar trechos de código inativo(desativar a
> função) já virou uma bela dor de cabeça mundo afora, gerando milhões
> em prejuízo, um caso emblemático foi o da Sony que deixo trechos de
> código não usado(inativo) em um dos seus produtos da linha
> Playstations e isso permitiu o desbloqueio do console. (para alegria
> dos BRs).
>
> Fase 2: Execução de Código Remoto e Persistência
>
> O atacante manipula ainda mais a memória da CPE para obter acesso à
> CLI do chip Realtek. Com muito trabalho de engenharia reversa e um
> toque de “malandragem”, o atacante consegue executar scripts remotos
> (tipo um wget) e abrri backdoors. Caso tenha sucesso nessa fase, o céu
> é o limite para o atacante: ele terá acesso completo à CPE.
>
> Vale lembrar aqui a importância de boas práticas de segurança, como o
> uso de ACLs nas interfaces do BRAS e a eliminação de senhas padrão.
>
> Depois que o atacante tem acesso total à CPE, ele pode manipular o
> file system (FS) e a infecção se torna quase impossível de ser
> removida do equipamento.
>
> Tive acesso a dois casos de fabricantes diferentes, onde o pacote de
> atualização já previa esse tipo de ataque e reescrevia o FS; em um
> deles a infecção foi removida, no outro não.Fase 3: Persistência
> Extrema e a "Batalha Perdida"
>
> Quando o atacante tem acesso ao sistema de arquivos, a infecção se
> torna mais agressiva e difícil de remover. A única maneira de
> eliminá-la é apagando e reescrevendo completamente a flashda CPE. Aqui
> ainda é campo a ser explorado, me faltam dados e tempo para fazer
> laboratório para contribuir mais.
>
> Infelizmente, em alguns casos, a infecção demonstrou ser ainda mais
> persistente, sobrevivendo à reescrita do sistema de
> arquivos(atualização do firmware). Isso me leva a fazer um paralelo
> com vírus de computador que evoluíram para atacar a BIOS(UEFI). Os
> atacantes de CPE também evoluíram, e em certas situações, a única
> solução é a remoção física do equipamento e aguardar o fabricante
> lançar uma solução, pois ele é único que tem acesso total ao código.
>
> Considerações Finais
>
> Este incidente ressalta a importância de uma segurança proativa e
> contínua. É inadmissível que os fabricantes tenham negligenciado um
> CVE de 2022, mesmo com o patch disponibilizado pela Realtek na época.
> A falta de atualizações de firmware é um problema sistêmico que expõe
> a infraestrutura a riscos desnecessários.
>
> O mito de que a desativação do IPv6 resolvia o problema foi
> desmascarado; na verdade, a alterar a interface WAN a CPE reiniciar a
> memória, interrompendo o ataque temporariamente…
>
> Gostaria de agradecer a colaboração de Guilherme Poletto escrevemos
> esse “bla bla todo” todo juntos.Ao Octavio Gianatiempo e
> GallandOctavio, que descobriram o CVE e publicaram, cujo trabalho foi
> fundamental para a análise deste caso.
>
> Espero que esta análise contribua para a discussão e ajude a
> fortalecer a segurança de nossas redes.O problema de CPE de baixo
> qualidade vem batendo na trave a pelo menos 3 anos, como diz aquele
> velhoDeitado futiboLisTikU, quem não faz toma… tomamos CVE na cabeça
> rsrsrNosso objetivo anterior era basicamente sobre v6 e gerência, mas
> agora “inimigo é outro”, temos falha de segurança afetando todo mundo,
> provedor internet, provedor de conteúdo, etcs… precisamos lidar com
> essa falha.Sei que o tema é “chato” , mas “risco operacional” é grande
> para pais e para mercado...Problema tem várias camadas, Gerencial,
> Segurança e operacional de redes, etcs…Fico imaginando que uma corrida
> por CPE, vai parecer a época da pandemia, pode faltar equipamentos até
> para quem nem tem chip realtek em operação…
>
> Sem falar no custo operacional e a quantidade de defeitos que isso vai
> gerar, para atendimento e NOC…Impacto ambiental de milhares(milhões?)
> de CPEs jogadas fora, centes de barris de petróleo queimado,
> etc…Imagina impacto no caixa das empresas para fornecer milhões de
> litros de café que isso vai demandar =)Queria dividir problema em 2
> fase:1º o'que fazer com as milhares de CPE com chip Realtek, caso não
> encontremos solução serão milhões de reais jogado no lixo em todo
> país… mundo...Estamos trabalhando em adaptar um “robozinho em python”
> que fazia uma padronização em CPEs, ele empurrava XML e outras
> coisinhas… Ideia é ajudar quem não tem Tr069, pensamos em ler lista de
> IP WAN, logar, empurrar firmware, baixar xml, editar as config para
> desativar o ALG SIP e devolver XML.Como quase 90% do fabricante usou
> interface muito parecida acredito que tenha pouco trabalho de
> adaptação de “tplink” para “dlink”.Talvez fazermos um “catálogo
> nacional” de modelos e fabricantes afetados, BPF é esse lugar ?Fazer
> um forms para as pessoas cadastrarem de maneira anônima “os volumes”
> de equipamento afetado, pensei em coisa simples, tipo:Fabricante:
> ZeDaPadariaModelo: CPE_realtek_171firmware: v1.39quantidade: 2000Com
> ideia do volume de equipamento afetados, podemos tentar fazer
> “vampetaço” no fabricante por volume de equipamentos. pode não dar em
> nada…
>
> 2º Depois que terminamos o caso das Realtek, retomamos com “selo BPF
> de CPE” .Queria debater mais sobre “BCOPdCPE” (boas práticas operação
> de CPE), tr069, mas não acho que é a hora… CVE é o inimigo da vez.Mais
> uma vez obrigado aos amigos que aguentaram as lamúrias minhas durante
> o “desbravar” desse mostro…Sei que mandar fonte é muito 2019, mas daí
> que saiu esse texto:Link da CVE:
> https://github.com/infobyte/cve-2022-27255apresentação youtube:
> https://www.youtube.com/watch?v=veicfLvqcOs&t=633s
> <https://www.youtube.com/watch?v=veicfLvqcOs&t=633s>
>
> _______________________________________________
> bpf mailing list
> bpf em listas.brasilpeeringforum.org
> https://listas.brasilpeeringforum.org/mailman/listinfo/bpf
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.brasilpeeringforum.org/pipermail/bpf/attachments/20250929/23a76028/attachment-0001.htm>
Mais detalhes sobre a lista de discussão bpf