Exploit crítico em chipsets Wi‑Fi da MediaTek: vulnerabilidade zero-click

 (blog.sonicwall.com)
1 pontos por GN⁺ 2024-09-22 | 1 comentários | Compartilhar no WhatsApp

Vulnerabilidade grave em chipsets Wi‑Fi da MediaTek: vulnerabilidade zero-click (CVE-2024-20017) ameaça roteadores e smartphones

Visão geral
  • A equipe de pesquisa de ameaças SonicWall Capture Labs identificou a vulnerabilidade CVE-2024-20017, avaliou seu impacto e desenvolveu medidas de mitigação
  • A CVE-2024-20017 é uma vulnerabilidade zero-click crítica com pontuação CVSS 3.0 de 9,8, que afeta os chipsets Wi‑Fi MediaTek MT7622/MT7915 e os bundles de driver RTxxxx SoftAP
  • São afetadas a versão 7.4.0.1 e anteriores do SDK da MediaTek, usadas em produtos de diversos fabricantes como Ubiquiti, Xiaomi e Netgear, além do OpenWrt 19.07 e 21.02
  • A vulnerabilidade permite execução remota de código sem interação do usuário, e a MediaTek distribuiu patches para mitigá-la
  • A vulnerabilidade foi divulgada e corrigida em março, mas um PoC publicado recentemente aumenta a probabilidade de exploração
Visão técnica
  • A vulnerabilidade existe no wappd, um daemon de rede incluído no SDK MediaTek MT7622/MT7915 e nos bundles de driver RTxxxx SoftAP
  • O wappd é responsável por configurar e gerenciar interfaces sem fio e pontos de acesso, especialmente em relação à tecnologia Hotspot 2.0
  • A arquitetura do wappd é composta pelo próprio serviço de rede, por um conjunto de serviços locais que interagem com as interfaces sem fio do dispositivo e por um canal de comunicação entre componentes via sockets de domínio Unix
  • A vulnerabilidade é causada por um buffer overflow, em que um valor de comprimento obtido diretamente de dados de pacote controlados pelo atacante é usado em uma cópia de memória
Gatilho da vulnerabilidade
  • A vulnerabilidade ocorre na função IAPP_RcvHandlerSSB, em que um valor de comprimento controlado pelo atacante é passado para a macro IAPP_MEM_MOVE
  • Não há verificação de limites além de confirmar que o tamanho máximo do pacote não ultrapassa 1600 bytes
  • O atacante precisa enviar o pacote anexando a estrutura esperada antes da carga maliciosa
  • O comprimento da struct RT_IAPP_HEADER deve ser pequeno, e o campo RT_IAPP_HEADER.Command deve ser 50
Exploração
  • O código de exploit publicado usa uma cadeia ROP para obter execução remota de código por meio da técnica de sobrescrita da Global Offset Table
  • Ele aproveita uma chamada a system() para executar um comando que envia um shell reverso ao atacante
  • O shell reverso é configurado com as ferramentas Bash e Netcat
Proteção da SonicWall
  • As seguintes assinaturas foram distribuídas para ajudar clientes da SonicWall a se protegerem contra a exploração dessa vulnerabilidade
    • IPS: 20322 MediaTek MT7915 wlan Service OOB Write 1
    • IPS: 20323 MediaTek MT7915 wlan Service OOB Write 2
Recomendações de mitigação
  • Como o código de exploit foi publicado, é fortemente recomendado que os usuários atualizem para a versão mais recente de firmware compatível com esses chipsets
Links relacionados

Resumo do GN⁺

  • Este artigo trata de uma vulnerabilidade zero-click grave em chipsets Wi‑Fi da MediaTek, que permite execução remota de código sem interação do usuário
  • A equipe de pesquisa da SonicWall identificou a vulnerabilidade e desenvolveu medidas de mitigação, além de recomendar que os usuários atualizem para o firmware mais recente
  • A vulnerabilidade afeta roteadores e smartphones de diversos fabricantes, e a divulgação recente de um PoC aumenta a chance de exploração
  • Um produto com funcionalidade semelhante são os chipsets Wi‑Fi da Qualcomm, e é importante verificar regularmente as atualizações de segurança

Leituras relacionadas

1 comentários

 
GN⁺ 2024-09-22
Opiniões no Hacker News

  • Para quem já comparou o código-fonte do driver do SDK do fornecedor da MediaTek com o mt76, isso não é tão surpreendente. Para dizer o mínimo, é bem bagunçado.
    Infelizmente, por oferecer um pouco mais de throughput que o mt76, ainda existem alguns builds de firmware de terceiros circulando com o driver do fornecedor.
    Felizmente, a MediaTek e a divisão WiSoC têm alguns engenheiros que interagem ativamente com a comunidade de software livre e de código aberto, e eles mesmos mantêm um pequeno fork do OpenWrt baseado no mt76: https://git01.mediatek.com/plugins/gitiles/openwrt/feeds/mtk...

    • Não sei por que esse tipo de hardware/firmware dá tanto a impressão de ser código de prova de conceito implantado em produção. Não dá para contratar gente que realmente saiba o que está fazendo?
    • Fico curioso se há algum release ou informação sobre o objetivo desse programa, ou quanto desse feed foi mesclado ao projeto upstream

  • O título é um pouco enganoso. Tenho alguns roteadores em casa com mt76 Wi-Fi, então cliquei no link achando que fosse um bug de firmware ou de silício, mas fiquei aliviado ao ver que era um bug no código bagunçado do SDK do fornecedor.
    Mesmo o suporte a mt76 no kernel mainline e no hostapd sendo bastante bom, não entendo por que alguém tentaria usar aquilo.

    • Para dizer que ficou “aliviado por ser um bug no código bagunçado do SDK do fornecedor”, há vários fornecedores com os quais se preocupar.
      O texto diz que é um “pacote de drivers usado em produtos de vários fabricantes, incluindo Ubiquiti, Xiaomi, Netgear etc.”
      Dito isso, alguns fornecedores, como a Ubiquiti, afirmam que não usam isso em produtos reais: https://community.ui.com/questions/CVE-2024-20017/b3f1a425-d...
    • A série OpenWRT 21.02.x é baseada no kernel mainline 5.4, mas mesmo assim consta como afetada. Esse pessoal entende bem de redes sem fio no Linux e, pelo que sei, o driver mt76 do kernel mainline é mantido por desenvolvedores do OpenWRT.

  • Blog original: https://blog.coffinsec.com/0day/2024/08/30/exploiting-CVE-20...

    • O serviço wappd é usado principalmente para configurar e coordenar o comportamento de interfaces sem fio e pontos de acesso usando Hotspot 2.0 e tecnologias relacionadas.
      A estrutura da aplicação é um tanto complexa, mas, essencialmente, consiste em um serviço de rede, serviços locais que interagem com as interfaces sem fio do dispositivo e canais de comunicação entre componentes que usam soquetes de domínio Unix.
      O lado menos ruim é que isso parece ser um problema em um serviço de “valor agregado” que não é estritamente necessário para a operação da própria placa de rede sem fio, e não um bug no firmware de banda base.
      Isso lembra alguns pacotes de drivers de dispositivos em que o driver de verdade é pequeno e silencioso, mas instala junto um bundleware várias ordens de grandeza maior para funcionalidades que 99% dos usuários não precisam nem querem. Impressoras e GPUs são especialmente ruins nisso.

  • Fico me perguntando se há alguma lógica na convenção de nomes da MediaTek, ou se todos os dispositivos são simplesmente MTxxxx e o x é um valor incremental ou aleatório.
    Tenho um aparelho com chip Wi-Fi mt6631 e, embora eu possa presumir que está tudo bem por ele não aparecer na lista dos afetados, é difícil saber em que ponto da linha de produtos ele se encaixa.

  • Dizem que o OpenWrt 19.07 e 21.02 são afetados, mas, pelo que parece, os builds oficiais do OpenWrt usam apenas o driver mt76, não o SDK da Mediatek.

  • Não sei por que notebooks com CPU AMD sempre vêm com uma placa Wi-Fi MediaTek RZ616.
    Troquei todas por placas Wi-Fi Intel, e agora tenho uma pilha de placas RZ616 que virarão os microplásticos do futuro.

    • A Intel vende dois tipos de placas Wi-Fi. Os modelos terminados em 1 usam o protocolo CNVI, funcionam apenas com chips Intel e são vendidos muito baratos para OEMs.
      Os modelos terminados em 0 usam PCIe padrão e custam cerca de 10 dólares a mais para os OEMs.
      A AMD renomeou os MediaTek MT7921 e MT7922 como RZ608 e RZ616, respectivamente, para oferecer aos OEMs algo na mesma faixa de preço dos chips xx1 da Intel.
    • A Lenovo também ficou insatisfeita com a MediaTek e começou a soldar chips Qualcomm para WLAN em plataformas AMD, mas acabou se dando mal de novo por causa de bugs de interação entre firmware e driver no Linux. Isso mesmo a Lenovo vendendo e dando suporte oficial ao Linux.
      Quando a geração do chipset deixa de ser recente, a capacidade da Qualcomm de dar suporte ao kernel mainline fica bem limitada. Hoje em dia é preciso uma pressão enorme dos fornecedores para fazer a Qualcomm se mexer.
    • O iwlwifi também tem seus próprios problemas, e o maior deles é a falta de modo AP em 5 GHz. A licença do firmware da Intel também é mais restritiva que a da MediaTek, e, por ser fullmac, o firmware assume muito mais trabalho.
      Pessoalmente, prefiro softmac. Hoje em dia não há muitas boas opções, e a era de ouro do ath9k já passou.
    • Fico curioso se você realmente usou, além de simplesmente “não confiar na MediaTek”.
      Usei em sequência um ThinkPad Intel e um ThinkPad AMD para trabalho, e o Wi-Fi com chipset MediaTek no AMD foi muito melhor que o chipset Intel no Intel.
      No Intel, a conexão de rede caía várias vezes por hora e a latência era horrível, a ponto de ser imediatamente perceptível ao usar ssh, mesmo em 5 GHz. O dispositivo MT7921 que uso agora tem sido muito estável no Linux nos últimos 2 ou 3 anos.
      No fim, parece variar bastante conforme a combinação de chipset e notebook.

  • Pelo que lembro, meu celular também usa chipset MediaTek. E tenho uma vaga lembrança de que o motivo de o fabricante depois ter deixado a MediaTek foi a, digamos, qualidade desses produtos.
    Não sei como o Wi-Fi é configurado em celulares. Há alguma forma de verificar se este celular é afetado? Tenho dados móveis ilimitados e boa cobertura, então quase não uso Wi-Fi, mas ainda assim seria bom saber.

    • No termux, execute "sudo su" e depois ls /sys/module.
      A saída será parecida com a do lsmod.

  • Mesmo numa época como a atual, em que as pessoas compram qualquer silício que consigam encontrar, ainda não entendo por que esses fornecedores de terceira linha não seguem a estratégia do PC, abrem completamente o firmware e deixam a comunidade open source cuidar disso.

    • Normalmente, são as regras da FCC que exigem dificultar a transmissão fora das faixas autorizadas que levam a esse tipo de situação.

  • O texto diz que “as versões afetadas incluem o MediaTek SDK 7.4.0.1 e anteriores, além do OpenWrt 19.07 e 21.02” e que “a vulnerabilidade está no daemon de rede wappd, incluído nos pacotes de driver MediaTek MT7622/MT7915 SDK e RTxxxx SoftAP”, mas, na prática, parece que o OpenWRT não usa wappd.

    • Como contribuidor do OpenWrt, me pergunto por que as pessoas não distinguem OpenWrt de SDKs proprietários de fornecedores. Se houvesse um bug no Nobara, ninguém mencionaria o Fedora.
    • Também fiquei com essa dúvida, já que uso OpenWRT em vários APs Netgear na minha rede doméstica. Se essa explicação estiver certa, então estou tranquilo?

  • É por isso que precisamos de firmware livre. Já cansei de Broadcom e Ralink.