Une vulnérabilité RCE en un clic découverte dans le logiciel de pilotes préinstallé d’ASUS

 (mrbruh.com)
2 points par GN⁺ 2025-05-12 | 1 commentaires | Partager sur WhatsApp
  • Une vulnérabilité d’exécution de code à distance (RCE) en un clic a été découverte dans le logiciel DriverHub d’ASUS
  • En local, une validation d’origine défaillante permet à un site web malveillant d’obtenir une exécution avec privilèges administrateur via RPC
  • En abusant de l’endpoint UpdateApp, il est possible d’exécuter du code malveillant en combinant un exécutable signé par ASUS et un fichier ini manipulé
  • La vulnérabilité a été publiée sous les identifiants CVE-2025-3462, CVE-2025-3463, et ASUS a rapidement déployé un correctif
  • Au moment du signalement, aucun cas d’exploitation réelle n’avait été constaté, et ASUS a récompensé la découverte par une inscription au tableau d’honneur plutôt qu’un bug bounty

Introduction

  • L’histoire commence par l’achat de nouveaux composants pour PC
  • Lors de l’achat d’une carte mère ASUS, l’option d’installation automatique de logiciels via le BIOS est activée par défaut
  • Comme l’option n’a pas été désactivée à temps, une demande d’autorisation pour installer DriverHub est apparue après la connexion à Windows
  • Par curiosité, et parce qu’un pilote Wi‑Fi était nécessaire, DriverHub a été installé

DriverHub

  • DriverHub est un processus d’arrière-plan sans interface graphique
  • Il communique avec driverhub.asus.com pour indiquer la liste des pilotes à installer ou mettre à jour
  • Il expose en local une API HTTP (port 53000) utilisée comme RPC
  • Le site web peut envoyer des requêtes API à ce service local pour gérer directement les pilotes
  • Il est alors apparu clairement qu’en cas de sécurité insuffisante, un attaquant pourrait envoyer des requêtes arbitraires

Finding the Vulnerability

  • Des tests ont été menés pour vérifier si un site web pouvait envoyer arbitrairement des requêtes RPC au backend de DriverHub
  • Le système était conçu pour ne répondre que si l’Origin était driverhub.asus.com
  • Il a été vérifié si le contrôle d’Origin reposait sur une correspondance de type wildcard comme origin.includes("driverhub.asus.com")
  • En remplaçant l’Origin par driverhub.asus.com.mrbruh.com, il a été découvert que la requête était acceptée
  • Cela confirme un risque grave, car un attaquant peut effectuer des appels RPC depuis un site malveillant

The Extent of the Damage

  • Le reverse engineering et l’analyse JavaScript ont permis d’identifier la liste des endpoints API accessibles en arrière-plan
  • Endpoints principaux :
    • Initialize : renvoie l’état et les informations d’installation
    • DeviceInfo : renvoie les logiciels ASUS, pilotes, matériels et adresses MAC installés
    • Reboot : déclenche un redémarrage immédiat
    • Log : renvoie un ensemble de fichiers de log
    • InstallApp : installe l’application ou le pilote correspondant à l’ID indiqué
    • UpdateApp : télécharge puis exécute l’exécutable situé à l’URL indiquée (exécution automatique s’il est signé par ASUS)
  • L’attention s’est particulièrement portée sur UpdateApp, qui pouvait être détourné

Achieving RCE

  • L’endpoint UpdateApp a été analysé en détail
  • Le paramètre Url devait contenir .asus.com, avec des possibilités de contournement, et le nom du fichier dépendait de la fin de l’URL
  • Seuls les exécutables signés par ASUS étaient lancés automatiquement, mais même les fichiers non signés étaient téléchargés sans être supprimés ensuite
  • La possibilité d’une attaque temporelle consistant à remplacer le fichier juste avant l’exécution, après validation de la signature, a été étudiée, mais s’est révélée peu pratique
  • En analysant la structure d’un package de pilote Wi‑Fi ASUS, il a été découvert que la propriété SilentInstallRun de AsusSetup.ini pouvait servir à exécuter une commande arbitraire
  • Chaîne d’attaque finale :
    1. L’attaquant incite la victime à visiter un site web sur un sous-domaine driverhub.asus.com.*
    2. Le site demande via UpdateApp un calc.exe malveillant (téléchargement uniquement, sans exécution)
    3. Il demande ensuite un AsusSetup.ini personnalisé (SilentInstallRun=calc.exe, là aussi sans exécution)
    4. Enfin, il demande le AsusSetup.exe signé, qui s’exécute automatiquement avec les privilèges administrateur et, avec l’option -s, lit le fichier ini puis lance calc.exe
  • Résultat : une exécution de code arbitraire à distance avec privilèges administrateur (RCE) est obtenue en un clic

Reporting Timeline (DD/MM/YYYY)

  • 07/04/2025 : découverte initiale de la vulnérabilité
  • 08/04/2025 : preuve de concept RCE réalisée et vulnérabilité signalée
  • 09/04/2025 : réception de la réponse automatique d’ASUS
  • 17/04/2025 : déploiement du correctif et réception du build corrigé
  • 18/04/2025 : confirmation que le correctif est en ligne
  • 09/05/2025 : publication de CVE-2025-3462 (score 8,4), CVE-2025-3463 (score 9,4)

Assessing the Damage

  • Juste après le signalement, un script de suivi de certificate transparency a été écrit
  • L’historique d’émission de certificats pour les sous-domaines driverhub.asus.com.* a été surveillé
  • Après un mois de monitoring, aucun site autre que les propres tests de l’auteur n’a été détecté par le filtre
  • L’absence d’indices d’exploitation antérieure a ainsi pu être confirmée

Bug Bounty

  • ASUS a été interrogé sur l’éventuel versement d’un bug bounty, mais cela a été refusé
  • À la place, la récompense a pris la forme d’une inscription au tableau d’honneur
  • Il est également noté qu’ASUS, malgré sa taille, ne dispose pas vraiment d’une politique de bounty adaptée

Fun Notes

  • Lors de la soumission du formulaire Security Advisory d’ASUS, la preuve de concept a été bloquée comme requête malveillante par Amazon CloudFront
  • En cliquant sur Install All dans DriverHub, d’autres logiciels (Norton360, WinRAR, etc.) sont installés de force
  • La description des CVE est vague et inexacte, ce qui peut faire croire à tort que les PC de bureau et portables ne sont pas concernés (en réalité, tous les appareils avec DriverHub installé sont affectés)
  • Le Wi‑Fi ne fonctionne toujours pas, ce qui a nécessité l’achat d’un adaptateur Wi‑Fi USB externe
  • Contact : Signal: paul19.84, e-mail contact [at] mrbruh.com

À lire aussi

1 commentaires

 
GN⁺ 2025-05-12
Avis Hacker News
  • Le résultat de la Responsible Disclosure donne l’impression d’être une calamité pour l’humanité ; les entreprises devraient souffrir plus souvent et plus durement pour prendre sérieusement la sécurité de leurs clients ; si on trouve un problème et qu’on leur donne la solution en leur demandant de corriger ça en un mois, pour elles ce n’est qu’un ticket de backlog ; mais si cela devient une affaire publique au point que le CEO doive intervenir, elles trouveront une solution en quelques heures ; bien sûr, au final ce sont les utilisateurs qui subiront le plus de dégâts, mais de toute façon, rien qu’en achetant ASUS, ils souffrent déjà
    • La réaction d’ASUS a été plutôt rapide cette fois-ci ; l’entreprise n’a pas nié le problème, n’a pas poursuivi en justice la personne ayant fait le reverse engineering, et a publié un correctif immédiatement ; auparavant, ce genre de problème prenait des mois, voire impliquait la police ; le grand public ne se soucie pas des vulnérabilités ; on vit déjà dans un monde où des gens font des transactions financières avec des téléphones qui n’ont pas reçu de mise à jour depuis 3 ans ; même si les médias parlaient sans arrêt des CVE, tout le monde finirait juste par s’y habituer ; en Europe, de nouvelles réglementations interdisent carrément la vente de produits comportant des vulnérabilités connues ; donc si ASUS continue ainsi, les cartes mères risquent de s’entasser dans les entrepôts et les distributeurs ne voudront plus les vendre ; cela vaut aussi pour l’électroménager ; par exemple, si un lave-vaisselle a une vulnérabilité, tout le secteur pourrait en souffrir
    • Le terme « Responsible Disclosure » est paradoxalement totalement irresponsable ; la plupart des entreprises ne publient pas de correctif en une semaine, ne reconnaissent pas le mérite, n’informent pas les utilisateurs et n’apprennent rien de leurs erreurs ; une divulgation lente et limitée encourage justement ce comportement ; le vrai comportement responsable consiste à divulguer immédiatement, complètement et publiquement ; et si une entreprise a gagné la confiance par sa bonne gestion, on peut éventuellement envisager un préavis d’environ 5 jours ouvrés ; appeler cela « responsible disclosure » relève surtout du jeu de mots
    • Le vrai problème est l’absence de législation sur la responsabilité produit ; les constructeurs automobiles ont des obligations de rappel, mais les entreprises de software et de hardware subissent trop peu de pression ; je pense que les clients devraient pouvoir obtenir un remboursement intégral pour les produits dont les vulnérabilités (CVE) ne sont pas corrigées
    • Pour reprendre CGPGrey, la première solution qui vient à l’esprit est souvent mauvaise et inefficace ; une bonne culture de la sécurité doit encourager à ne pas cacher les problèmes internes ; les entreprises, par cupidité, dissimulent tous les problèmes de sécurité ; si l’on divulgue tout immédiatement après découverte, un problème qui pourrait être corrigé en un mois devient exposé à tout le monde et bien plus susceptible d’être exploité
    • J’ai une idée de business, qui existe peut-être déjà : une plateforme publique / d’intermédiation protégeant la vie privée du déclarant, vérifiant l’exploitabilité réelle des vulnérabilités, publiant des annonces publiques à des échéances fixes, et où les entreprises paieraient pour s’abonner à un flux en amont concernant ce qui les affecte, l’argent servant à rémunérer les chercheurs, couvrir les coûts d’exploitation et dégager un bénéfice ; c’est similaire à une marketplace de bug bounty, mais un peu plus antagoniste du point de vue des entreprises ; je me demande si ce serait légal ou si cela serait considéré comme de l’extorsion
    • J’insiste : comme dans d’autres secteurs, il devrait y avoir une responsabilité juridique pour les défauts des produits ; la plupart des gens n’acceptent les produits défectueux que s’ils sont bon marché, et il n’y a aucune raison que le software fasse exception
    • Il suffirait de divulguer la vulnérabilité dès le lendemain pour créer une vraie motivation ; perdre la face aide aussi à mieux sécuriser la suite
    • Ce genre d’exagération du type « calamité pour l’humanité » est un exemple classique de formulation qui ruine le débat
  • J’ai demandé à ASUS s’ils accordaient une bug bounty, et ils m’ont répondu qu’ils mettraient mon nom dans leur Hall of Fame à la place ; c’est amer, comme si ASUS n’était qu’une petite startup sans capital pour payer une bounty
    • Même de « petites » entreprises comme Cisco font pareil et se contentent d’afficher le nom sans récompense ; chez Cisco, ils ont même oublié leur page d’avis de sécurité, si bien qu’il n’y a même plus de reconnaissance possible
    • S’il n’y a pas de bug bounty, il ne reste qu’à vendre l’exploit sur le marché noir ou à tout divulguer publiquement
    • Ce genre de situation me donne envie de ne plus jamais acheter de produits ASUS
  • La qualité logicielle d’ASUS est mauvaise, et l’entreprise accumule aussi les problèmes de sécurité ; il y avait déjà eu par le passé une affaire de malware UEFI sur des cartes mères ; des logiciels inutiles sont préinstallés par défaut et sont pénibles à supprimer ; il existe suffisamment de plaintes pour que cela mérite qu’on s’y intéresse
    • Ce n’est pas la première fois ; il y a déjà eu des cas similaires auparavant, et j’en ai gardé la trace dans un ancien billet de blog
  • ASUS a affirmé qu’il n’y avait pas eu d’exploitation, car seul son domaine de test (driverhub.asus.com.*) correspondait aux conditions requises ; mais cela n’est vrai que si personne n’a enregistré séparément un sous-domaine de driverhub ; avec un wildcard, cela pourrait ne pas apparaître dans les journaux de transparence des certificats et rester exploitable
    • Les certificats wildcard ne couvrent que les sous-domaines de premier niveau ; par exemple, *.example.com couvre test.example.com, mais pas test.test.example.com ; si quelqu’un avait utilisé un wildcard *.asus.com.example.com, alors driverhub.asus.com.example.com aurait été valide
    • Quelqu’un a dit que c’était une bonne idée et qu’il avait vérifié immédiatement ; il n’y a actuellement rien de suspect côté certificats wildcard
    • C’est bien vu pour l’angle mort des certificats wildcard ; si un attaquant possédait un certificat wildcard pour .example.com, il aurait effectivement pu exploiter cela ailleurs que sur le vrai driverhub.asus.com ; c’est pour cette raison qu’une surveillance des journaux CT ne suffit pas à détecter parfaitement ce type de vulnérabilité de prise de contrôle de sous-domaine
  • Le passage où ASUS répond à la question sur la bug bounty par « nous sommes une petite startup, nous n’avons pas de bounty, mais nous pouvons mettre votre nom dans le Hall of Fame » est frappant, alors qu’il s’agit en réalité d’un géant dont la capitalisation dépasse 15 milliards de dollars
    • En réponse sarcastique, quelqu’un recommande sarcasm.com
  • Mon Wi‑Fi intégré ne marchait pas, alors j’ai utilisé un adaptateur Wi‑Fi USB externe, mais avec DriverHub cela n’a servi à rien ; on m’avait vendu ça comme une solution, quelle déception
    • Le billet de blog lui-même était agréable à lire
    • Les derniers pilotes Wi‑Fi ne fonctionnaient pas, j’ai donc dû utiliser une ancienne version
  • ASUS est une grande entreprise pesant 15 milliards de dollars en bourse, et pourtant elle ne récompense même pas correctement les chercheurs, tout en ignorant les efforts de ses clients et des chercheurs ; face à un tel traitement, on comprend à quel point cela peut être frustrant pour eux ; au final, le mieux est de ne pas acheter de produits ASUS
  • Lors de l’envoi d’un bug report, le fichier PoC a été détecté par Amazon CloudFront comme une requête malveillante, ce qui a bloqué la soumission elle-même ; ce type de WAF (Web Application Firewall) est plutôt un mauvais pattern et un mauvais exemple
  • Je compatis pour les plaintes sur le Wi‑Fi intégré ; en réalité, il suffit souvent de vérifier le modèle du chipset et de télécharger le pilote séparément depuis un site comme station-drivers, ce qui prend quelques secondes ; c’est à cause de ce genre de désagrément que je n’aime pas ASUS ; je déteste particulièrement les options BIOS qui interagissent directement avec le système d’exploitation
  • J’aime bien les produits ASUS, mais je désactive systématiquement les applications d’assistance préinstallées dans l’UEFI ; autrefois, la version complète de ROG Armory Crate s’installait et était pénible à supprimer ; après la reprise de l’activité NUC d’Intel par ASUS, les mises à jour du BIOS ont été maintenues, mais des applications d’installation comme MyASUS ont été ajoutées par défaut ; heureusement, il existe une option pour les désactiver, et lorsqu’on a mis à jour depuis un BIOS Intel NUC, cela semble être désactivé par défaut