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

 (mrbruh.com)
2 pontos por GN⁺ 2025-05-12 | 1 comentários | Compartilhar no WhatsApp
  • O ASUS DriverHub, que pode ser instalado logo após o login no Windows, podia levar à execução de código com privilégios de administrador apenas pelo usuário visitar um site específico, por causa da forma como conectava um site a um serviço local
  • O DriverHub roda em segundo plano, sem GUI, e tinha uma arquitetura em que driverhub.asus.com enviava requisições ao serviço local HTTP/WebSocket em 127.0.0.1:53000; a verificação de Origin aceitava domínios no formato driverhub.asus.com.*
  • O endpoint UpdateApp baixava arquivos se a URL apenas contivesse a string .asus.com, e executáveis assinados pela ASUS eram executados com privilégios de administrador, enquanto arquivos que falhavam na validação de assinatura não eram apagados
  • O exploit final fazia o download, em sequência, de calc.exe sem assinatura, AsusSetup.ini manipulado e AsusSetup.exe assinado, e então alcançava RCE com privilégios de administrador com SilentInstallRun=calc.exe
  • A ASUS confirmou a distribuição da correção em abril de 2025, e em 9 de maio de 2025 foram divulgados CVE-2025-3462 e CVE-2025-3463; com base em logs de transparência de certificados, não havia sinais visíveis de exploração ativa significativa antes da divulgação

DriverHub local RPC conectado ao site

  • Após comprar uma placa-mãe ASUS e fazer login no Windows, era exibida uma notificação pedindo privilégios de administrador para concluir a instalação do ASUS DriverHub
  • O DriverHub não funciona como uma GUI separada, mas como um processo em segundo plano, e driverhub.asus.com informa quais drivers e atualizações são necessários
  • O site se comunica via RPC com o processo DriverHub em execução local
    • O serviço local roda na porta fixa 53000 de 127.0.0.1
    • A estrutura permite que o site ou serviço envie requisições de API para essa porta local
  • Numa arquitetura assim, se a proteção do RPC não for suficiente, um atacante pode abusar disso para instalar aplicativos maliciosos

Bypass de verificação frouxa de Origin

  • O DriverHub não aceitava requisições de qualquer site; ele foi projetado para responder a requisições cujo cabeçalho Origin fosse driverhub.asus.com
  • O problema era que a verificação não era uma comparação exata, mas algo próximo de correspondência por inclusão de string ou curinga
    • Não era uma comparação direta como origin == driverhub.asus.com
    • Ao definir driverhub.asus.com.mrbruh.com como Origin, a requisição era permitida
  • O atacante podia explorar esse comportamento para acessar o RPC local do DriverHub a partir de domínios no formato driverhub.asus.com.*

Endpoints de RPC expostos

  • Por meio do JavaScript do site e da descompilação do executável, foram identificados vários endpoints de RPC
  • Os principais endpoints eram os seguintes
    • Initialize: retorna se o software está instalado e as informações básicas de instalação
    • DeviceInfo: retorna software ASUS instalado, drivers .sys instalados, componentes de hardware e endereço MAC
    • Reboot: reinicia imediatamente o dispositivo alvo sem confirmação
    • Log: retorna um arquivo compactado com todo o log do DriverHub
    • InstallApp: realiza a instalação por ID de app ou driver; os IDs de app ficam hardcoded em um arquivo XML fornecido pelo instalador do DriverHub
    • UpdateApp: baixa e executa a URL de arquivo fornecida para atualizar o próprio DriverHub

Como o UpdateApp criava as condições para RCE

  • A requisição UpdateApp funciona no seguinte formato
curl "http://127.0.0.1:53000/asus/v1.0/UpdateApp"; -X POST --data-raw '{"List": [{"Url": "https://driverhub.asus.com/<app.exe>"}]}'
  • O comportamento observado de UpdateApp fornecia várias condições necessárias para a cadeia de RCE
    • O parâmetro Url precisava conter a string .asus.com, mas formatos como example.com/payload.exe?foo=.asus.com também eram aceitos
    • O arquivo era salvo com o nome de arquivo especificado no fim da URL
    • Era possível baixar arquivos independentemente da extensão
    • Se o arquivo fosse um executável assinado pela ASUS, ele era executado automaticamente com privilégios de administrador
    • Se fosse um executável assinado pela ASUS, ele era executado mesmo sem ser o instalador do DriverHub
    • Mesmo que o arquivo baixado falhasse na verificação de assinatura, ele não era apagado
  • No início, a validação de assinatura fazia o RCE parecer difícil, mas o comportamento de manter os arquivos que falhavam na assinatura combinado com a instalação de executáveis assinados pela ASUS criou um caminho de bypass

Cadeia de exploit usando AsusSetup.ini

  • O pacote de driver WiFi da ASUS incluía AsusSetup.exe, AsusSetup.ini e SilentInstall.cmd
  • Ao ser executado, AsusSetup.exe lê os metadados do driver em AsusSetup.ini
  • Se AsusSetup.exe for executado com a flag -s, ele realiza uma instalação silenciosa sem GUI e executa o item especificado em SilentInstallRun dentro de AsusSetup.ini
    • O DriverHub usa a flag -s para instalação silenciosa
    • O arquivo INI original especifica um script cmd para instalação automática sem intervenção
    • Também era possível indicar outro executável em SilentInstallRun

  • Sequência final do ataque

    • O usuário visita um site com domínio no formato driverhub.asus.com.*
    • O site solicita calc.exe como executável de PoC via UpdateApp
    • calc.exe é baixado, mas não executado porque falha na verificação de assinatura
    • O arquivo permanece no disco e não é apagado
    • O site solicita um AsusSetup.ini manipulado via UpdateApp
    • Esse arquivo também é baixado, mas não é executado
    [InstallInfo]
SilentInstallPath=.\\
SilentInstallRun=calc.exe
    • O site solicita o binário assinado pela ASUS AsusSetup.exe via UpdateApp
    • AsusSetup.exe é baixado e executado com privilégios de administrador
    • Como o DriverHub o executa com -s, ele lê AsusSetup.ini
    • De acordo com SilentInstallRun=calc.exe, calc.exe é executado com privilégios de administrador

Da denúncia à divulgação dos CVEs

  • O cronograma de tratamento da vulnerabilidade foi o seguinte
    • 2025-04-07: descoberta inicial da vulnerabilidade
    • 2025-04-08: confirmação de que ela podia ser ampliada para RCE
    • 2025-04-08: reporte da vulnerabilidade à ASUS
    • 2025-04-09: recebimento de resposta automática da ASUS
    • 2025-04-17: após contato de acompanhamento, a ASUS enviou o patch concluído e uma build para validação
    • 2025-04-18: a ASUS confirmou a distribuição da correção
    • 2025-05-09: foram divulgados CVE-2025-3462, com pontuação 8.4, e CVE-2025-3463, com pontuação 9.4

Possibilidade de exploração e rastros observados

  • Logo após o reporte, foi executado em um VPS um script que acompanhava atualizações de certificate transparency para verificar se domínios driverhub.asus.com.* estavam sendo registrados
  • Com base em outros sites de logs de transparência de certificados, domínios e subdomínios normalmente apareciam nos logs em até um mês
  • Um mês depois, a verificação mostrou que os únicos sites que batiam com a regex eram domínios de teste
  • Com esse critério, parecia improvável que houvesse exploração ativa relevante antes do reporte

Resposta da ASUS e questões restantes

  • A ASUS não oferece bug bounty e respondeu que, em vez disso, colocaria o nome do pesquisador no hall of fame
  • Depois, outro pesquisador de segurança, leonjza, já havia reportado o mesmo problema de verificação de Origin em fevereiro de 2025, e a ASUS o corrigiu até o momento desta correção
    • A ASUS não informou isso separadamente
    • Na página da cve.org, apenas esse pesquisador aparecia nos créditos, e a empresa respondeu que não faria créditos adicionais
  • Ao enviar o relatório de vulnerabilidade pelo Security Advisory form da ASUS, o Amazon CloudFront detectou o PoC anexado como requisição maliciosa e bloqueou o envio
    • Foi necessário remover parte do código do PoC e enviar no lugar um link para vídeo gravado
  • No DriverHub, ao clicar em “Install All” em vez de instalar cada driver recomendado individualmente, também eram instalados ArmouryCrate, a versão customizada do CPU-Z da ASUS, Norton360 e WinRAR
  • A descrição de CVE da ASUS expressava o escopo e o impacto do RCE de forma mais restrita do que o real
    • A descrição dizia algo no sentido de “limitado a motherboards e sem impacto em laptops e desktop computers”
    • Na prática, afeta qualquer computador com o DriverHub instalado, incluindo desktops e laptops
    • Em vez de falar em execução arbitrária ou remota de código, a formulação dizia algo como “fontes não confiáveis podem afetar o comportamento do sistema”

Leituras relacionadas

1 comentários

 
GN⁺ 2025-05-12
Comentários do Hacker News

  • A divulgação responsável e seus resultados chegaram perto de ser um desastre para a humanidade. Para que as empresas levem a segurança dos clientes mais a sério, elas precisam sentir uma dor muito maior, e com muito mais frequência
    Dar um mês de prazo e ainda entregar a solução mastigada só faz disso mais um ticket no backlog. Se, toda vez que um problema de segurança estourasse, isso virasse uma notícia online grande o suficiente para envolver até o CEO, e a solução tivesse de ser encontrada em horas, não em meses, elas agiriam de forma muito mais proativa. Claro que os usuários finais sofreriam mais, mas, no momento em que compraram ASUS, já estavam sofrendo também

    • A velocidade de resposta da ASUS desta vez foi bem razoável, e não vejo nenhum grande problema aqui. A ASUS não negou o bug, não ameaçou processar por causa de engenharia reversa do software e corrigiu rapidamente
      Antes da era da divulgação responsável, esse processo provavelmente levaria meses e talvez até envolvesse a polícia. Usuários comuns não ligam para vulnerabilidades e fazem operações financeiras em celulares sem atualização há 3 anos. Se você continuar despejando CVEs nas notícias, as pessoas vão se cansar do papo de que “todas as empresas são péssimas” e ficar dessensibilizadas quando surgir uma ameaça real
      A UE está buscando outra solução. Nas novas regras de cibersegurança, produtos com vulnerabilidades conhecidas não poderão ser vendidos nas lojas. Se a ASUS continuar errando, as placas-mãe viram estoque parado, e as lojas também deixam de querer vender hardware da ASUS. Isso vale não só para hardware de computador, mas também para geladeiras inteligentes e máquinas de lavar. Se alguém encontrar uma vulnerabilidade em uma lava-louças e o fabricante não tiver incluído um meio de atualizar o firmware, isso pode criar milhões de dólares em estoque imprestável no setor
    • O nome “divulgação responsável” é irônico. Na prática, está mais para um método totalmente irresponsável
      A maioria das empresas lida pessimamente com divulgação. Não corrige no prazo, por exemplo em uma semana, não dá crédito direito, não avisa os usuários e não aprende com os erros. Divulgação restrita com atraso irresponsável reforça esse comportamento
      O método realmente responsável é revelar tudo de forma imediata, completa e pública. Se necessário, isso pode ser feito anonimamente para se proteger. Só depois de a empresa afetada provar repetidamente que responde de forma adequada ela deveria ganhar o direito a um aviso prévio muito curto, algo como 5 dias úteis
      O próprio fato de esse tipo de divulgação restrita e atrasada ser chamado de “divulgação responsável” é um exemplo de novilíngua
    • O ponto central é a questão de responsabilização por lei. Montadoras podem ser obrigadas a fazer recall e reparos, mas a pressão sobre empresas de software e hardware é fraca demais
      Os clientes deveriam poder receber reembolso integral por aparelhos defeituosos, por exemplo com CVEs não corrigidos
    • Citando o CGPGrey, a primeira solução que vem à cabeça geralmente é horrível e não funciona
      Uma boa cultura de segurança e proteção incentiva os participantes a não esconderem problemas. Empresas são entidades gananciosas e farão qualquer coisa para esconder falhas de segurança
      Se você divulgar para todo mundo um problema legal e corrigível dentro de um mês, a chance de exploração também sobe muito
    • Talvez haja uma ideia de negócio aqui. Talvez até já exista: criar um serviço de intermediação e agregação de divulgações
      Ele protegeria a privacidade de quem reporta, verificaria as vulnerabilidades de segurança e confirmaria que todas as divulgadas são realmente exploráveis. Publicaria em ciclos definidos e cobraria das empresas uma assinatura de “feed antecipado” para receber com antecedência as divulgações que as afetam. Com esse dinheiro, pagaria os relatores, cobriria os custos operacionais e ainda manteria parte do lucro
      Seria, por assim dizer, um mercado de bug bounty um pouco hostil às empresas. Fico curioso se isso seria legal ou se seria visto como extorsão

  • É amargo ler que, ao perguntarem se a ASUS tinha bug bounty, responderam que não, mas que em compensação colocariam o nome da pessoa no “hall da fama”
    A ironia é que dá para entender, já que a ASUS é uma pequena startup e não teria capital para pagar recompensas

    • Também seria compreensível para uma empresa pequena como a Cisco. A Cisco fez algo parecido por anos com inúmeros serviços online que adquiriu
      A Cisco foi além e até esqueceu sua página de avisos de segurança, então qualquer reconhecimento agora simplesmente desaparece no vazio
    • Sem bug bounty, o exploit vai para o mercado negro ou então para divulgação total
    • Vendo esse tipo de resposta, dá vontade de nunca mais comprar produtos da ASUS
    • Não sei de onde saiu essa expressão “Asus é uma pequena startup”. A Asus fabrica placas-mãe e componentes de PC pelo menos desde os anos 90

  • Não é surpresa. O software da ASUS é péssimo e a empresa está mais para uma reincidente habitual quando o assunto é falta de prevenção em segurança
    https://www.techspot.com/news/95425-years-gigabyte-asus-moth...
    https://www.reddit.com/r/ASUS/comments/tg3u2n/removing_bloat...
    https://www.reddit.com/r/ASUS/comments/ojsq80/nahimic_servic...

  • A observação de que, ao verificar os logs de transparência de certificados, os únicos domínios correspondentes a driverhub.asus.com.* eram o próprio domínio de teste, e portanto a falha provavelmente não foi explorada ativamente antes da divulgação, só vale se não houver certificado curinga
    Se alguém tivesse um curinga, poderia ter explorado isso sem aparecer na transparência de certificados

    • Certificados curinga só se aplicam a um único nível de rótulo. *.example.com. não serve para test.test.example.com., mas serve para test.example.com.
      Se alguém tivesse emitido um curinga para *.asus.com.example.com., poderia subir um servidor web sob driverhub.asus.com.example.com. e fazê-lo parecer válido
    • Foi uma boa ideia, então conferi isso agora, e confirmei que não havia nada suspeito nos registros curinga
    • O ponto cego de certificados curinga é real. Se um atacante tivesse um certificado curinga para .example.com, poderia ter explorado o domínio driverhub.asus.com. sem que ele aparecesse de forma específica nos logs de transparência de certificados
      Portanto, monitorar apenas os logs de transparência de certificados não basta para detectar esse tipo de vulnerabilidade de sequestro de subdomínio
    • Além disso, fica a dúvida se certificados autoassinados também teriam funcionado. Esses certificados não entram nos logs de transparência
      E também não está claro se precisava mesmo ser HTTPS

  • O desfecho foi “meu Wi‑Fi onboard ainda não funciona, e eu tive de comprar um adaptador Wi‑Fi USB externo. Obrigado, DriverHub”, então todo esse processo foi literalmente em vão

    • O post do blog em si foi bom
    • Os drivers de Wi‑Fi mais recentes não funcionam, então é preciso usar uma versão anterior

  • A parte em que, ao enviar o relatório da vulnerabilidade pelo formulário de segurança da ASUS, a Amazon CloudFront bloqueou o PoC anexado por considerá-lo uma requisição maliciosa parece um aviso de que firewalls de aplicação web são um antipadrão: https://thedailywtf.com/articles/Injection_Rejection

  • “Dá para entender, a ASUS é uma startup pequena”: quer dizer, uma startup pequena com valor de mercado de apenas US$ 15 bilhões
    O que é realmente difícil de entender é tratar assim não só produtos ruins, mas também um pesquisador que fez um enorme favor aos clientes
    Dá pena dos pesquisadores que fazem esse tipo de trabalho e acabam ignorados ou menosprezados. É muito injusto
    A única coisa que dá para fazer é não comprar produtos ASUS

  • Alguém perguntou se a ASUS tinha bug bounty, e a resposta foi que não, mas que em vez disso colocariam o nome da pessoa no “hall da fama”. A ironia é que a ASUS é uma startup pequena e não teria capital para pagar recompensa
    [1]: https://companiesmarketcap.com/asus/marketcap/

    • Ou talvez seja sarcasm.com ;)

  • Link obrigatório do vídeo Scumbag Asus
    Invidious https://inv.nadeko.net/watch?v=cbGfc-JBxlY
    YouTube https://youtube.com/watch?v=cbGfc-JBxlY
    “A ASUS nos mandou um e-mail na semana passada dizendo que queria vir ao escritório nesta semana para ter uma ‘conversa aberta’ sobre o problema. Nós respondemos que tudo bem, mas que a conversa precisaria ser gravada. Afinal, eles disseram que queriam uma conversa aberta. Depois disso, não houve resposta por 5 dias. Então a ASUS teve a chance de corrigir isso. Nós estávamos segurando o vídeo para dar essa chance. Mas no momento em que dissemos ‘ok, mas vamos filmar para deixar registrado o que foi combinado’, veio o silêncio”

    • Ainda existe algum fabricante de placa-mãe “basicamente aceitável”? Ou há histórias parecidas sobre todos os grandes fabricantes?
      Estou perguntando por um amigo que vai montar um PC novo em breve
    • Isso me irrita, mas fico curioso sobre qual seria a defesa mais forte e plausível possível do lado da ASUS
      Provavelmente é essa que mais bate com a realidade: eles estão correndo atrás do lucro, isso continua passando batido, então não veem motivo para deixar algo registrado e parecer mal; melhor gastar esse tempo com marketing

  • Sem bug bounty é um absurdo. Não vou mais comprar produtos ASUS

    • Deve ser porque eles são uma “startup pequena”
    • O software e o suporte ao cliente da Asus são péssimos, e sempre foram