Descoberta vulnerabilidade de RCE com um clique em software de driver pré-instalado da ASUS

• Foi descoberta uma vulnerabilidade de execução remota de código (RCE) com um clique no software DriverHub da ASUS
• Devido a uma validação fraca de origin no ambiente local, um site malicioso pode usar RPC para executar ações com privilégios de administrador
• Ao abusar do endpoint UpdateApp, é possível executar código malicioso combinando um executável assinado pela ASUS com um arquivo ini manipulado
• A vulnerabilidade foi divulgada como CVE-2025-3462, CVE-2025-3463, e a ASUS distribuiu rapidamente um patch
• Foi confirmado que não havia casos reais de exploração no momento do reporte, e a ASUS recompensou o pesquisador com inclusão no hall da fama em vez de bug bounty

---

Introduction

• Tudo começou com uma história sobre a compra de novas peças de PC
• Ao comprar uma placa-mãe ASUS, a opção de instalação automática de software via BIOS vinha ativada por padrão
• Por não desativar a opção a tempo, após fazer login no Windows apareceu um pedido de permissão para instalar o DriverHub
• Como precisava do driver de WiFi, ele instalou o DriverHub por curiosidade

DriverHub

• O DriverHub é um processo em segundo plano que roda sem GUI
• Ele se comunica com driverhub.asus.com para informar a lista de drivers que precisam ser instalados ou atualizados
• Localmente, ele expõe uma API HTTP (porta 53000) via RPC
• O site pode enviar requisições de API para esse serviço local e gerenciar drivers diretamente
• Isso levou à percepção de que um invasor poderia enviar requisições arbitrárias se a segurança fosse insuficiente

Finding the Vulnerability

• Foi testado se um site poderia enviar requisições RPC arbitrárias ao backend do DriverHub
• O sistema foi projetado para responder apenas quando o Origin fosse “driverhub.asus.com”
• Foi verificado se a checagem de Origin era feita com um match curinga no estilo origin.includes("driverhub.asus.com")
• Ao alterar o Origin para “driverhub.asus.com.mrbruh.com”, foi descoberto que a requisição era aceita
• Isso confirmou um risco grave, no qual um invasor poderia fazer chamadas RPC a partir de um site malicioso

The Extent of the Damage

• Com reversing e análise de JavaScript, foi identificado o conjunto de endpoints de API disponíveis em segundo plano
• Principais endpoints:
  • Initialize: retorna estado de instalação e informações
  • DeviceInfo: retorna software ASUS instalado, drivers, hardware e endereço MAC
  • Reboot: executa reboot imediato
  • Log: retorna conjunto de arquivos de log
  • InstallApp: instala um app ou driver do ID especificado
  • UpdateApp: baixa e executa um executável da URL especificada (execução automática se tiver assinatura da ASUS)
• Em especial, foi destacado que o UpdateApp poderia ser explorado

Achieving RCE

• O endpoint UpdateApp foi analisado em detalhes
• O parâmetro “Url” tinha uma condição exigindo a presença de .asus.com, mas havia possibilidade de bypass, e o nome do arquivo seguia o final da URL
• Apenas executáveis assinados pela ASUS eram executados automaticamente, mas arquivos não assinados também eram baixados e não eram apagados depois
• Foi considerada a possibilidade de um ataque de timing que trocasse o arquivo logo antes da execução após passar na verificação de assinatura, mas isso não era prático
• Ao analisar a estrutura do pacote de driver WiFi da ASUS, foi identificado que a propriedade SilentInstallRun em AsusSetup.ini podia ser usada para executar comandos arbitrários
• Cadeia final de ataque:
  1. O invasor induz o acesso a um site no subdomínio driverhub.asus.com. *
  2. O site solicita um calc.exe malicioso via UpdateApp (apenas download, sem execução)
  3. Solicita um AsusSetup.ini customizado (SilentInstallRun=calc.exe, também sem execução)
  4. Solicita o AsusSetup.exe assinado (executado automaticamente com privilégios de administrador; com a flag “-s”, ele lê o ini e executa calc.exe)
• Como resultado, ocorre execução remota de código arbitrário com privilégios de administrador e um clique (RCE)

Reporting Timeline (DD/MM/YYYY)

• 07/04/2025: vulnerabilidade descoberta inicialmente
• 08/04/2025: PoC de RCE concluída e vulnerabilidade reportada
• 09/04/2025: resposta automática da ASUS recebida
• 17/04/2025: patch distribuído e build corrigida recebida
• 18/04/2025: confirmação de que o patch estava ao vivo
• 09/05/2025: divulgação de CVE-2025-3462 (8,4), CVE-2025-3463 (9,4)

Assessing the Damage

• Logo após reportar a vulnerabilidade, foi escrito um script para rastrear certificate transparency
• Foi monitorado o histórico de emissão de certificados para subdomínios driverhub.asus.com.*
• Após um mês de monitoramento, não foi encontrado nenhum site filtrado além dos próprios testes
• Foi confirmado que não havia sinais de exploração prévia

Bug Bounty

• Foi perguntado à ASUS se haveria pagamento de bug bounty, mas o pedido foi recusado
• Em vez disso, a recompensa veio na forma de inclusão no hall da fama
• Também foi acrescentada uma explicação de que, apesar de a ASUS ser uma grande empresa, sua política de bounty é insuficiente

Fun Notes

• Ao enviar o formulário de Security Advisory da ASUS, a PoC foi bloqueada pelo Amazon CloudFront como requisição maliciosa
• Ao clicar em “Install All” no DriverHub, outros softwares (Norton360, WinRAR etc.) também eram instalados à força
• A descrição do CVE é vaga e incorreta nos fatos, podendo levar ao mal-entendido de que 'desktops/laptops não são afetados' (na prática, qualquer dispositivo com DriverHub instalado é afetado)
• O WiFi ainda não funciona, exigindo a compra de um adaptador USB WiFi externo
• Contato: Signal: paul19.84, e-mail contact [at] mrbruh.com

[GN⁺]

Comentários no Hacker News

• O resultado do Responsible Disclosure parece um desastre para a humanidade; para que as empresas levem a segurança dos clientes a sério, elas precisariam sofrer dores maiores com mais frequência. Se você encontra um problema, diz como corrigir e dá um mês para resolver, para a empresa isso vira só mais um ticket no backlog. Mas, se a situação vai parar nas notícias online e até o CEO precisa se manifestar, em poucas horas eles encontram uma solução. Claro que, no fim, quem mais sofre é o usuário, mas, de qualquer forma, só de comprar ASUS ele já está sofrendo.
  • A reação da ASUS desta vez foi relativamente rápida: não negou o problema, não processou quem fez a engenharia reversa e aplicou um patch imediatamente. Antigamente, esse tipo de questão podia levar meses ou até envolver a polícia. O público em geral nem liga para vulnerabilidades; afinal, vivemos num mundo em que pessoas fazem transações financeiras em celulares sem atualização há 3 anos. Cobrir a imprensa com notícias de CVE só faria todo mundo ficar anestesiado. Na Europa, novas regras proíbem a venda de produtos com vulnerabilidades conhecidas. Então, se a ASUS continuar assim, placas-mãe vão acabar encalhadas em estoque e distribuidores não vão querer vender. Isso também vale para eletrodomésticos; por exemplo, se uma lava-louças tiver uma vulnerabilidade, esse setor também pode sofrer grandes prejuízos.
  • O nome “Responsible” Disclosure é, ironicamente, um comportamento totalmente irresponsável. A maioria das empresas não corrige em uma semana, não dá crédito, não avisa os usuários e nem aprende com os erros. Divulgação lenta e limitada acaba incentivando esse comportamento. A atitude realmente responsável é divulgar de forma imediata, completa e pública. E, se houver confiança de que a empresa responde direito, talvez dê para considerar um aviso prévio de uns 5 dias úteis. Chamar divulgação lenta e parcial de "responsible disclosure" é só um jogo de palavras.
  • A raiz do problema é a ausência de legislação sobre responsabilidade por produto. Montadoras têm obrigação de fazer recall, mas empresas de software/hardware sofrem pouca pressão. Acho que o cliente deveria poder receber reembolso integral por produtos com vulnerabilidades (CVE) que não foram corrigidas.
  • Para citar CGPGrey, a primeira solução que vem à cabeça normalmente é ruim e ineficaz. Uma boa cultura de segurança deveria incentivar que problemas internos não sejam escondidos. As empresas são gananciosas e escondem todos os problemas de segurança. Se divulgar imediatamente após descobrir, até um problema que poderia ser corrigido em um mês ficaria exposto a todos e com probabilidade muito maior de exploração.
  • Tenho uma ideia de negócio, que talvez já exista: uma plataforma de divulgação/intermediação que proteja a privacidade de quem reporta, valide a possibilidade real de exploração da vulnerabilidade, faça anúncios públicos em datas definidas e permita que empresas paguem para assinar um feed antecipado do que as afeta, usando esse dinheiro para recompensar os pesquisadores, cobrir custos operacionais e distribuir lucro. É parecido com um marketplace de bug bounty, mas um pouco mais hostil do ponto de vista das empresas. Fico curioso se isso seria legal ou se seria considerado extorsão.
  • Continuo insistindo que, como em outros setores, deveria existir responsabilidade legal por defeitos do produto. A maioria das pessoas só tolera produto defeituoso quando ele é barato; não há motivo para software ser exceção.
  • Simplesmente divulgar a vulnerabilidade no dia seguinte já seria a verdadeira motivação. Passar vergonha também ajuda na próxima questão de segurança.
  • Esse tipo de exagero de dizer “um desastre para a humanidade” é um exemplo clássico de como estragar o argumento.
• Perguntei à ASUS se dariam bug bounty, e responderam que, em vez disso, colocariam meu nome no Hall of Fame. Fica um gosto amargo, como se a piada fosse que a ASUS é só uma pequena startup sem capital para pagar bounty.
  • Empresas pequenas como a Cisco fazem algo parecido, só colocam o nome e não dão recompensa. A Cisco ainda esquece da página de avisos de segurança, então desaparece até a chance de reconhecimento.
  • Sem bug bounty, a escolha acaba sendo vender o exploit no mercado negro ou fazer divulgação total.
  • Situações assim fazem eu não querer nunca mais comprar produtos da ASUS.
• A qualidade do software da ASUS também é ruim, e a empresa continua criando problemas de segurança. Já houve antes caso de malware em UEFI de placa-mãe, e vem um monte de software desnecessário pré-instalado que dá trabalho até para remover. Há muitos relatos de reclamação, então vale consultar.
  • Também não foi a primeira vez que isso aconteceu. Já houve casos parecidos antes, e até deixei o registro no meu blog antigo.
• Disseram que não houve exploração porque só o próprio domínio de teste deles (driverhub.asus.com.*) atendia à condição, mas isso só vale se ninguém tiver registrado separadamente um subdomínio de driverhub. Com wildcard, isso pode não aparecer nos logs de transparência de certificados e ainda ser explorável.
  • Certificados wildcard cobrem apenas subdomínios de um nível. Por exemplo, *.example.com cobre test.example.com, mas não test.test.example.com. Se alguém usasse um wildcard *.asus.com.example.com, então driverhub.asus.com.example.com seria válido.
  • Disseram que a ideia era boa e foram verificar na hora; no momento, não há nada suspeito com certificados wildcard.
  • A observação sobre o ponto cego dos certificados wildcard é correta. Se um atacante tivesse um certificado wildcard .example.com, isso realmente poderia permitir exploração fora do verdadeiro driverhub.asus.com. Por isso, monitorar apenas logs de CT não é suficiente para detectar perfeitamente esse tipo de vulnerabilidade de takeover de subdomínio.
• Chamou atenção a parte em que, ao perguntarem à ASUS sobre bug bounty, responderam: "somos uma pequena startup, então não temos bounty, mas podemos colocar seu nome no Hall of Fame". Na prática, é uma gigante com valor de mercado acima de 15 bilhões.
  • Como piada sarcástica, recomendaram sarcasm.com.
• O Wi‑Fi onboard não funcionava, então usei um adaptador Wi‑Fi USB externo, mas graças ao DriverHub isso não serviu de nada. Chamam isso de solução, mas é decepcionante.
  • O post do blog em si foi uma leitura divertida.
  • O driver de Wi‑Fi mais recente não funcionava, então tive que usar uma versão antiga.
• A ASUS é uma grande empresa com valor de mercado de 15 bilhões de dólares, mas mesmo assim não recompensa direito e ainda ignora o esforço de clientes e pesquisadores. Vendo esse tratamento, dá para entender como os pesquisadores devem se sentir injustiçados. A conclusão é que o melhor é não comprar produtos da ASUS.
• Ao enviar o relatório do bug, o arquivo de PoC foi identificado pelo Amazon CloudFront como uma requisição maliciosa e o envio foi bloqueado. Esse tipo de WAF (Web Application Firewall) é, na verdade, um padrão ruim e um péssimo exemplo.
• Concordo com a reclamação sobre o problema do Wi‑Fi onboard. Na prática, basta verificar o modelo do chipset e baixar separadamente em sites como station-drivers, o que leva só alguns segundos. Não gosto da ASUS por esse tipo de incômodo; especialmente odeio opções de BIOS que interagem diretamente com o sistema operacional.
• Gosto dos produtos da ASUS, mas sempre desativo os apps de suporte pré-instalados na UEFI. Antigamente, a versão completa do ROG Armory Crate era instalada e era chata de remover. Mesmo depois que a ASUS assumiu o negócio de NUC da Intel, as atualizações de BIOS continuaram, mas apps de instalação como MyASUS passaram a vir por padrão. Felizmente há opção para desativar, e, quando atualizado a partir de um BIOS Intel NUC, parece vir desativado por padrão.