[BPF] Análise e Mitigação do Problema com Chips Realtek

[Andre Bolzan]

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 thread que 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 flash da 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 rsrsr

Nosso 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: ZeDaPadaria
Modelo: CPE_realtek_171
firmware: v1.39
quantidade: 2000

Com 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-27255
apresentação youtube: https://www.youtube.com/watch?v=veicfLvqcOs&t=633s
-------------- Próxima Parte ----------
Um anexo em HTML foi limpo...
URL: <http://listas.brasilpeeringforum.org/pipermail/bpf/attachments/20250926/9a226c73/attachment-0001.htm>