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

 (mrbruh.com)
2 points par GN⁺ 2025-05-12 | 1 commentaires | Partager sur WhatsApp
  • ASUS DriverHub, qui peut être installé juste après la connexion à Windows, reliait un site web à un service local d’une manière qui pouvait permettre une exécution de code avec des droits administrateur dès qu’un utilisateur visitait un site web spécifique
  • DriverHub fonctionne en arrière-plan, sans GUI, et repose sur une architecture où driverhub.asus.com envoie des requêtes à un service HTTP/WebSocket local sur 127.0.0.1:53000 ; la vérification de l’Origin autorisait les domaines de la forme driverhub.asus.com.*
  • L’endpoint UpdateApp téléchargeait un fichier dès lors que l’URL contenait la chaîne .asus.com ; les exécutables signés par ASUS étaient lancés avec des droits administrateur, tandis que les fichiers échouant à la vérification de signature n’étaient pas supprimés
  • L’exploit final téléchargeait successivement un calc.exe non signé, un AsusSetup.ini modifié et un AsusSetup.exe signé, puis obtenait une RCE avec droits administrateur via SilentInstallRun=calc.exe
  • ASUS a confirmé la diffusion du correctif en avril 2025 ; CVE-2025-3462 et CVE-2025-3463 ont été publiées le 9 mai 2025, et les journaux de transparence des certificats ne montraient pas de signes d’exploitation active avant la divulgation

RPC local de DriverHub connecté au site web

  • Après l’achat d’une carte mère ASUS, une notification demandant des droits administrateur s’affiche juste après la connexion à Windows afin de finaliser l’installation d’ASUS DriverHub
  • DriverHub ne dispose pas d’une GUI séparée : il fonctionne comme un processus en arrière-plan, tandis que driverhub.asus.com indique les pilotes nécessaires et les éléments à mettre à jour
  • Le site web communique par RPC avec le processus DriverHub exécuté localement
    • Le service local fonctionne sur le port fixe 53000 de 127.0.0.1
    • Le site web ou le service envoie des requêtes API vers ce port local
  • Dans ce type d’architecture, si la protection du RPC est insuffisante, un attaquant peut l’exploiter pour installer une application malveillante

Contournement d’une vérification Origin trop permissive

  • DriverHub n’acceptait pas les requêtes de n’importe quel site web : il était conçu pour répondre aux requêtes dont l’en-tête Origin était driverhub.asus.com
  • Le problème était que la vérification ne reposait pas sur une comparaison exacte, mais sur une logique proche d’une inclusion de chaîne ou d’un wildcard
    • Ce n’était pas une comparaison directe du type origin == driverhub.asus.com
    • En définissant driverhub.asus.com.mrbruh.com comme Origin, la requête était acceptée
  • Un attaquant pouvait exploiter ce comportement pour accéder au RPC local de DriverHub depuis un domaine de la forme driverhub.asus.com.*

Endpoints RPC exposés

  • Plusieurs endpoints RPC ont été identifiés en analysant le JavaScript du site web et en décompilant les exécutables
  • Les principaux endpoints étaient les suivants
    • Initialize : renvoie l’état d’installation du logiciel et les informations d’installation de base
    • DeviceInfo : renvoie les logiciels ASUS installés, les pilotes .sys installés, les composants matériels et l’adresse MAC
    • Reboot : redémarre immédiatement l’appareil cible sans confirmation
    • Log : renvoie une archive compressée de l’ensemble des journaux DriverHub
    • InstallApp : installe une application ou un pilote à partir de son ID ; les ID d’applications sont codés en dur dans un fichier XML fourni par l’installateur DriverHub
    • UpdateApp : télécharge et exécute l’URL de fichier fournie pour mettre à jour DriverHub lui-même

Comment UpdateApp créait les conditions d’une RCE

  • Une requête UpdateApp fonctionne sous la forme suivante
curl "http://127.0.0.1:53000/asus/v1.0/UpdateApp"; -X POST --data-raw '{"List": [{"Url": "https://driverhub.asus.com/<app.exe>"}]}'
  • Le comportement observé de UpdateApp réunissait plusieurs conditions nécessaires à une chaîne RCE
    • Le paramètre Url devait contenir la chaîne .asus.com, mais une forme comme example.com/payload.exe?foo=.asus.com était aussi acceptée
    • Le fichier était enregistré sous le nom de fichier indiqué à la fin de l’URL
    • Des fichiers pouvaient être téléchargés quelle que soit leur extension
    • Si le fichier était un exécutable signé par ASUS, il était automatiquement lancé avec des droits administrateur
    • Un exécutable signé par ASUS était lancé même s’il ne s’agissait pas de l’installateur DriverHub
    • Même si le fichier téléchargé échouait à la vérification de signature, il n’était pas supprimé
  • Au départ, la vérification de signature semblait rendre la RCE difficile, mais le comportement consistant à conserver les fichiers dont la signature échoue combiné au comportement d’installation des exécutables signés par ASUS a créé une voie de contournement

Chaîne d’exploitation avec AsusSetup.ini

  • Le paquet de pilotes WiFi ASUS contenait AsusSetup.exe, AsusSetup.ini et SilentInstall.cmd
  • Au lancement, AsusSetup.exe lit les métadonnées du pilote depuis AsusSetup.ini
  • Lorsque AsusSetup.exe est exécuté avec le flag -s, il effectue une installation silencieuse sans GUI et lance l’élément indiqué dans SilentInstallRun dans AsusSetup.ini
    • DriverHub utilise le flag -s pour les installations silencieuses
    • Le fichier INI d’origine désigne un script cmd pour l’installation automatique sans intervention
    • SilentInstallRun pouvait aussi désigner un autre exécutable

  • Séquence d’attaque complète

    • L’utilisateur visite un site web dont le domaine est de la forme driverhub.asus.com.*
    • Le site demande le fichier exécutable PoC calc.exe via UpdateApp
    • calc.exe est téléchargé, mais n’est pas exécuté car il échoue à la vérification de signature
    • Le fichier n’est pas supprimé et reste présent
    • Le site demande un AsusSetup.ini modifié via UpdateApp
    • Ce fichier est lui aussi téléchargé, mais n’est pas exécuté
    [InstallInfo]
SilentInstallPath=.\
SilentInstallRun=calc.exe
    • Le site demande le binaire ASUS signé AsusSetup.exe via UpdateApp
    • AsusSetup.exe est téléchargé puis exécuté avec des droits administrateur
    • Comme DriverHub l’exécute avec -s, il lit AsusSetup.ini
    • Conformément à SilentInstallRun=calc.exe, calc.exe est exécuté avec des droits administrateur

De la déclaration à la publication des CVE

  • Le calendrier de traitement de la vulnérabilité est le suivant
    • 2025-04-07 : découverte initiale de la vulnérabilité
    • 2025-04-08 : confirmation de l’escalade en RCE
    • 2025-04-08 : signalement de la vulnérabilité à ASUS
    • 2025-04-09 : réception de la réponse automatique d’ASUS
    • 2025-04-17 : après relance, ASUS transmet un build de vérification et indique que le correctif est terminé
    • 2025-04-18 : ASUS confirme la diffusion du correctif
    • 2025-05-09 : publication de CVE-2025-3462, score 8,4, et de CVE-2025-3463, score 9,4

Possibilité d’exploitation et traces observées

  • Juste après le signalement, un script a été lancé sur un VPS pour suivre les mises à jour de la transparence des certificats et vérifier l’enregistrement de domaines driverhub.asus.com.*
  • D’après d’autres sites de journaux de transparence des certificats, les domaines et sous-domaines apparaissaient généralement dans les journaux en moins d’un mois
  • Une vérification un mois plus tard a montré que les seuls sites web correspondant à l’expression régulière étaient des domaines de test
  • Sur cette base, la probabilité d’une exploitation active avant le signalement était faible

Réponse d’ASUS et problèmes restants

  • ASUS n’offre pas de bug bounty et a répondu qu’elle inscrirait plutôt le nom dans son hall of fame
  • Par la suite, il est apparu qu’un autre chercheur en sécurité, leonjza, avait déjà signalé le même problème de vérification Origin en février 2025, et ASUS l’avait corrigé au moment de ce correctif
    • ASUS n’a pas communiqué séparément cette information
    • Sur la page cve.org, seul ce chercheur est crédité, et ASUS a répondu qu’elle n’ajouterait pas de crédit supplémentaire
  • Lors de la soumission du rapport de vulnérabilité via le formulaire Security Advisory d’ASUS, Amazon CloudFront a détecté la PoC jointe comme une requête malveillante et a bloqué l’envoi
    • Il a fallu retirer une partie du code de la PoC et soumettre à la place un lien vers une vidéo d’enregistrement
  • Dans DriverHub, si l’on clique sur “Install All” au lieu d’installer chaque pilote recommandé individuellement, ArmouryCrate, le CPU-Z personnalisé d’ASUS, Norton360 et WinRAR sont également installés
  • La description CVE d’ASUS présente la portée et l’impact de la RCE de manière restrictive
    • La description contenait une formulation indiquant que le problème était « limité aux cartes mères et n’affectait pas les ordinateurs portables ni les ordinateurs de bureau »
    • En réalité, il affecte tout ordinateur sur lequel DriverHub est installé, y compris les desktops et laptops
    • Au lieu de parler d’exécution de code arbitraire ou à distance, la description indiquait que des « sources non fiables peuvent influencer le comportement du système »

À lire aussi

1 commentaires

 
GN⁺ 2025-05-12
Avis de Hacker News

  • La divulgation responsable et ses conséquences ont été proches d’une catastrophe pour l’humanité. Pour que les entreprises prennent la sécurité de leurs clients plus au sérieux, elles devraient ressentir une douleur bien plus fréquente et bien plus forte.
    Si on leur laisse un mois et qu’on leur sert même la solution sur un plateau, cela devient simplement un ticket de backlog. Si, à chaque problème de sécurité, l’affaire faisait suffisamment de bruit en ligne pour que le CEO s’en mêle et qu’il faille trouver une solution en quelques heures plutôt qu’en quelques mois, elles agiraient de manière bien plus proactive. Bien sûr, ce sont les utilisateurs finaux qui en pâtiraient le plus, mais ils souffrent déjà dès le moment où ils ont acheté du ASUS.

    • La vitesse de réaction d’ASUS cette fois-ci a été plutôt correcte, et je ne vois pas de gros problème ici. ASUS n’a pas nié le bug, n’a pas menacé de poursuivre pour rétro-ingénierie de son logiciel, et a publié un correctif rapidement.
      À l’époque d’avant la divulgation responsable, ce processus aurait sans doute pris des mois, avec probablement même la police impliquée. Les utilisateurs ordinaires ne s’intéressent pas aux vulnérabilités et font leurs opérations bancaires sur des téléphones qui ne reçoivent plus de mises à jour depuis trois ans. Si l’actualité est constamment inondée de CVE, les gens se lasseront du discours selon lequel « toutes les entreprises sont nulles » et deviendront insensibles même face à de vraies menaces.
      L’UE pousse une autre solution. Le nouveau règlement sur la cybersécurité interdira la vente en magasin de produits présentant des vulnérabilités connues. Si ASUS continue de faire n’importe quoi, ses cartes mères deviendront du stock invendable, et les magasins ne voudront plus vendre de matériel ASUS. Cela concerne non seulement le matériel informatique, mais aussi les réfrigérateurs et lave-linge connectés. Si vous découvrez une vulnérabilité dans un lave-vaisselle, et que le fabricant n’a prévu aucun moyen de mettre à jour le firmware, vous pourriez créer pour le secteur des millions de dollars de stocks inutilisables.
    • Le terme « divulgation responsable » est paradoxal. En réalité, cela ressemble plutôt à une méthode totalement irresponsable.
      La plupart des entreprises gèrent les divulgations de manière lamentable. Elles ne corrigent pas à temps, par exemple en une semaine, n’accordent pas correctement le crédit, n’informent pas les utilisateurs et n’apprennent rien de leurs erreurs. Une divulgation limitée, irresponsablement retardée, renforce ce comportement.
      La méthode réellement responsable consiste à rendre les choses publiques immédiatement, complètement et ouvertement. Si nécessaire, on peut le faire anonymement pour se protéger. Ce n’est qu’après qu’une entreprise concernée a prouvé, à plusieurs reprises, qu’elle réagit correctement qu’elle peut obtenir un droit de préavis très court, par exemple cinq jours ouvrés.
      Le fait même que cette divulgation limitée, retardée et irresponsable soit appelée « divulgation responsable » est un exemple de novlangue.
    • Le cœur du sujet est la responsabilité inscrite dans la loi. Les constructeurs automobiles peuvent se voir imposer des rappels et des réparations, mais les éditeurs de logiciels et fabricants de matériel subissent une pression beaucoup trop faible.
      Les clients devraient par exemple pouvoir obtenir un remboursement intégral pour un appareil défectueux présentant une CVE non corrigée.
    • Pour citer CGPGrey, la première solution qui vient à l’esprit est généralement terrible et inefficace.
      Une bonne culture de la sûreté et de la sécurité encourage les participants à ne pas dissimuler les problèmes. Les entreprises sont des entités cupides et feront tout pour cacher leurs erreurs de sécurité.
      Si l’on rend publics, à tout le monde, des problèmes légitimes et corrigeables en un mois, la probabilité qu’ils soient exploités augmente aussi fortement.
    • Il pourrait y avoir une idée de business là-dedans. Peut-être que cela existe déjà : créer un service d’intermédiation et d’agrégation des divulgations.
      Il protégerait la vie privée des signalants, vérifierait les vulnérabilités de sécurité et s’assurerait que toutes les vulnérabilités publiées sont réellement exploitables. Les publications auraient lieu à intervalles réguliers, et les entreprises paieraient un abonnement à un « flux anticipé » pour recevoir à l’avance les divulgations qui les concernent. Cet argent servirait à rémunérer les signalants, couvrir les coûts d’exploitation et dégager un certain bénéfice.
      En quelque sorte, une place de marché de bug bounty légèrement hostile aux entreprises. Je me demande si ce serait légal, ou si cela serait considéré comme de l’extorsion.

  • Le passage où ils demandent à ASUS s’ils ont un bug bounty, où ASUS répond que non mais propose à la place d’ajouter leur nom au « Hall of Fame », laisse un goût amer.
    C’est une pique ironique : ASUS est une petite startup, donc on peut comprendre qu’elle n’ait pas le capital pour verser des primes.

    • C’est aussi compréhensible pour une petite entreprise comme Cisco. Cisco a fait quelque chose de similaire pendant des années pour de nombreux services en ligne acquis.
      Cisco est allé encore plus loin en oubliant même sa page d’avis de sécurité, si bien que toute reconnaissance s’est désormais évaporée dans le vide.
    • S’il n’y a pas de bug bounty, les exploits finissent sur le marché noir, ou alors en divulgation publique totale.
    • Quand je vois ce genre de réaction, je n’ai plus envie d’acheter de produits ASUS.
    • Je ne sais pas d’où vient l’expression « Asus est une petite startup ». Asus fabrique des cartes mères et des composants PC depuis au moins les années 90.

  • Ce n’est pas surprenant. Les logiciels ASUS sont médiocres et l’entreprise ressemble à un récidiviste qui manque de prévention côté sécurité.
    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...

  • La partie où, après avoir consulté les journaux de transparence des certificats, l’auteur juge qu’il est très probable que la faille n’ait pas été activement exploitée avant le signalement, car les seuls domaines correspondant à driverhub.asus.com.* étaient ses propres domaines de test, ne tient que s’il n’existait pas de certificat wildcard
    Quelqu’un disposant d’un wildcard aurait pu l’exploiter sans apparaître dans la transparence des certificats

    • Un certificat wildcard ne s’applique qu’à un seul niveau de label. *.example.com. ne fonctionne pas pour test.test.example.com., mais fonctionne pour test.example.com.
      Si quelqu’un avait obtenu un wildcard pour *.asus.com.example.com., il aurait pu lancer un serveur web sous driverhub.asus.com.example.com. et le faire paraître valide
    • Bonne idée, je viens de vérifier, et j’ai confirmé qu’il n’y avait rien de suspect du côté des enregistrements wildcard
    • C’est bien un angle mort des certificats wildcard. Si un attaquant avait eu un certificat wildcard pour .example.com, il aurait pu exploiter driverhub.asus.com. sans que ce domaine apparaisse explicitement dans les journaux de transparence des certificats
      Donc la seule surveillance des journaux de transparence des certificats ne suffit pas à détecter ce type de vulnérabilité de prise de contrôle de sous-domaine
    • En plus, je me demande si un certificat auto-signé aurait aussi fonctionné. Ce genre de certificat n’apparaît pas dans les journaux de transparence
      Et je me demande aussi s’il fallait vraiment que ce soit en HTTPS

  • La conclusion « mon WiFi intégré ne fonctionne toujours pas, et j’ai dû acheter un adaptateur WiFi USB externe. Merci DriverHub », cela veut dire que tout ce processus a littéralement été une perte de temps

    • Le billet de blog lui-même était bon
    • Le dernier pilote WiFi ne fonctionne pas, il faut donc utiliser une version antérieure

  • Le passage où Amazon CloudFront a considéré la PoC jointe comme une requête malveillante et l’a bloquée lors de l’envoi du rapport de vulnérabilité via le formulaire de signalement de sécurité d’ASUS ressemble à un rappel que les pare-feu applicatifs web sont un anti-pattern : https://thedailywtf.com/articles/Injection_Rejection

  • « ASUS est une petite startup, on peut comprendre » : on parle donc d’une petite startup dont la capitalisation boursière n’est que de 15 milliards de dollars
    Ce qui est vraiment difficile à comprendre, ce n’est pas seulement la médiocrité des produits, mais aussi la façon dont ils traitent un chercheur qui a fait un énorme travail pour leurs clients
    C’est triste de voir des chercheurs faire ce genre de travail puis se faire ignorer ou rabaisser. C’est profondément injuste
    La seule chose à faire, c’est de ne pas acheter de produits ASUS

  • On a demandé à ASUS s’ils avaient un bug bounty, et ASUS a répondu qu’ils n’en avaient pas, mais qu’ils pouvaient à la place inscrire le nom du chercheur dans leur « Hall of Fame ». C’est une pique disant qu’ASUS est une petite startup et n’a donc sans doute pas les moyens de verser des primes
    [1] : https://companiesmarketcap.com/asus/marketcap/

    • Ou alors c’était peut-être sarcasm.com ;)

  • Lien obligatoire vers la vidéo Scumbag Asus
    Invidious https://inv.nadeko.net/watch?v=cbGfc-JBxlY
    YouTube https://youtube.com/watch?v=cbGfc-JBxlY
    « ASUS nous a envoyé un e-mail la semaine dernière pour nous dire qu’ils voulaient venir au bureau cette semaine afin d’avoir une “discussion ouverte” sur le problème. Nous avons répondu que ça nous allait, mais que la conversation devait être enregistrée. Après tout, ils disaient vouloir une discussion ouverte. Ensuite, aucune réponse pendant cinq jours. ASUS avait donc une occasion de corriger le tir. Nous retenions la vidéo pour leur donner cette chance. Mais dès qu’on a dit “d’accord, mais on filmera pour garder une trace de ce qui a été promis”, silence radio »

    • Existe-t-il malgré tout un fabricant de cartes mères qui soit « globalement correct » ? Ou bien tous les grands acteurs ont-ils des histoires similaires ?
      Je demande pour un ami qui va bientôt monter un nouveau PC
    • Ça me met en colère, mais je me demande quel serait le meilleur argument possible pour défendre la position d’ASUS
      La version la plus proche de la réalité est probablement celle-ci : ils cherchent le profit, ça passe quand même, ils n’ont aucune raison de laisser des traces qui les feraient mal paraître, et ils préfèrent consacrer ce temps au marketing

  • Pas de bug bounty, c’est absurde. Je n’achèterai plus de produits ASUS à l’avenir

    • C’est sans doute parce que c’est une « petite startup »
    • Les logiciels et le support client d’Asus sont catastrophiques, et l’ont toujours été