One-Click-RCE-Schwachstelle in vorinstallierter ASUS-Treibersoftware

 (mrbruh.com)
2 Punkte von GN⁺ 2025-05-12 | 1 Kommentare | Auf WhatsApp teilen
  • ASUS DriverHub, das direkt nach der Windows-Anmeldung installiert werden kann, konnte durch die Art, wie es eine Website mit einem lokalen Dienst verbindet, dazu führen, dass schon der Besuch einer bestimmten Website Codeausführung mit Administratorrechten ermöglichte
  • DriverHub läuft ohne GUI im Hintergrund und ist so aufgebaut, dass driverhub.asus.com Anfragen an einen lokalen HTTP-/WebSocket-Dienst unter 127.0.0.1:53000 sendet; die Origin-Prüfung erlaubte Domains der Form driverhub.asus.com.*
  • Der Endpoint UpdateApp lud Dateien herunter, sobald die URL nur die Zeichenkette .asus.com enthielt; von ASUS signierte ausführbare Dateien wurden mit Administratorrechten ausgeführt, während Dateien mit fehlgeschlagener Signaturprüfung nicht gelöscht wurden
  • Der finale Exploit ließ nacheinander eine unsignierte calc.exe, eine manipulierte AsusSetup.ini und eine signierte AsusSetup.exe herunterladen und erreichte anschließend per SilentInstallRun=calc.exe eine RCE mit Administratorrechten
  • ASUS bestätigte die Verteilung eines Fixes im April 2025; am 9. Mai 2025 wurden CVE-2025-3462 und CVE-2025-3463 veröffentlicht, und anhand von Certificate-Transparency-Logs waren vor der Offenlegung keine Anzeichen für aktive Ausnutzung zu sehen

Mit einer Website verbundener lokaler RPC von DriverHub

  • Nach dem Kauf eines ASUS-Mainboards erschien direkt nach der Windows-Anmeldung eine Benachrichtigung, die Administratorrechte anforderte, um die Installation von ASUS DriverHub abzuschließen
  • DriverHub ist keine separate GUI, sondern läuft als Hintergrundprozess; driverhub.asus.com zeigt die benötigten Treiber und Update-Ziele an
  • Die Website kommuniziert per RPC mit dem lokal laufenden DriverHub-Prozess
    • Der lokale Dienst läuft auf 127.0.0.1 am festen Port 53000
    • Die Architektur sieht vor, dass die Website oder der Dienst API-Anfragen an diesen lokalen Port sendet
  • Wenn der RPC-Schutz in einer solchen Architektur nicht ausreicht, kann ein Angreifer dies zur Installation bösartiger Anwendungen missbrauchen

Umgehung der lockeren Origin-Prüfung

  • DriverHub akzeptierte nicht die Anfragen jeder beliebigen Website, sondern war so konzipiert, dass es auf Anfragen mit dem Origin-Header driverhub.asus.com antwortete
  • Das Problem war, dass die Prüfung kein exakter Vergleich war, sondern eher auf Zeichenketten-Enthaltung oder Wildcards beruhte
    • Es war kein direkter Vergleich wie origin == driverhub.asus.com
    • Wurde driverhub.asus.com.mrbruh.com als Origin gesetzt, wurde die Anfrage zugelassen
  • Ein Angreifer konnte dieses Verhalten nutzen, um von Domains der Form driverhub.asus.com.* auf den lokalen DriverHub-RPC zuzugreifen

Offengelegte RPC-Endpoints

  • Durch Website-JavaScript und Decompilieren der ausführbaren Dateien wurden mehrere RPC-Endpoints identifiziert
  • Die wichtigsten Endpoints waren:
    • Initialize: Gibt zurück, ob Software installiert ist, sowie grundlegende Installationsinformationen
    • DeviceInfo: Gibt installierte ASUS-Software, installierte .sys-Treiber, Hardwarekomponenten und MAC-Adressen zurück
    • Reboot: Startet das Zielgerät ohne Bestätigung sofort neu
    • Log: Gibt ein komprimiertes Archiv aller DriverHub-Logs zurück
    • InstallApp: Führt eine Installation anhand einer App- oder Treiber-ID aus; App-IDs sind in einer XML-Datei hartkodiert, die vom DriverHub-Installer bereitgestellt wird
    • UpdateApp: Lädt die angegebene Datei-URL herunter und führt sie aus, um DriverHub selbst zu aktualisieren

Wie UpdateApp die Voraussetzungen für RCE schuf

  • Eine UpdateApp-Anfrage funktioniert in folgender Form:
curl "http://127.0.0.1:53000/asus/v1.0/UpdateApp"; -X POST --data-raw '{"List": [{"Url": "https://driverhub.asus.com/<app.exe>"}]}'
  • Das beobachtete Verhalten von UpdateApp lieferte mehrere für eine RCE-Kette notwendige Bedingungen:
    • Der Parameter Url musste die Zeichenkette .asus.com enthalten, aber auch Formen wie example.com/payload.exe?foo=.asus.com wurden akzeptiert
    • Die Datei wurde unter dem am Ende der URL angegebenen Dateinamen gespeichert
    • Dateien konnten unabhängig von ihrer Dateiendung heruntergeladen werden
    • Wenn die Datei eine von ASUS signierte ausführbare Datei war, wurde sie automatisch mit Administratorrechten ausgeführt
    • Wenn es sich um eine von ASUS signierte ausführbare Datei handelte, wurde sie auch dann ausgeführt, wenn sie kein DriverHub-Installer war
    • Selbst wenn die heruntergeladene Datei die Signaturprüfung nicht bestand, wurde sie nicht gelöscht
  • Zunächst schien RCE wegen der Signaturprüfung schwierig, doch die Kombination aus dem Verbleib von Dateien nach fehlgeschlagener Signaturprüfung und dem Installationsverhalten ASUS-signierter ausführbarer Dateien eröffnete einen Umgehungsweg

Exploit-Kette mit AsusSetup.ini

  • Das ASUS-WiFi-Treiberpaket enthielt AsusSetup.exe, AsusSetup.ini und SilentInstall.cmd
  • AsusSetup.exe liest beim Start Treibermetadaten aus AsusSetup.ini
  • Wird AsusSetup.exe mit dem Flag -s ausgeführt, führt es eine stille Installation ohne GUI durch und startet den in SilentInstallRun in AsusSetup.ini angegebenen Eintrag
    • DriverHub verwendet für stille Installationen das Flag -s
    • Die ursprüngliche INI-Datei verweist auf ein cmd-Skript für automatische unbeaufsichtigte Installation
    • In SilentInstallRun konnten auch andere ausführbare Dateien angegeben werden

  • Vollständige Angriffsabfolge

    • Der Nutzer besucht eine Website mit einer Domain der Form driverhub.asus.com.*
    • Die Website fordert per UpdateApp die PoC-Executable calc.exe an
    • calc.exe wird heruntergeladen, wegen fehlgeschlagener Signaturprüfung aber nicht ausgeführt
    • Die Datei bleibt erhalten und wird nicht gelöscht
    • Die Website fordert per UpdateApp die manipulierte AsusSetup.ini an
    • Auch diese Datei wird heruntergeladen, aber nicht ausgeführt
    [InstallInfo]
SilentInstallPath=.\
SilentInstallRun=calc.exe
    • Die Website fordert per UpdateApp das von ASUS signierte Binary AsusSetup.exe an
    • AsusSetup.exe wird nach dem Download mit Administratorrechten ausgeführt
    • Da DriverHub es mit -s startet, liest es AsusSetup.ini
    • Gemäß SilentInstallRun=calc.exe wird calc.exe mit Administratorrechten ausgeführt

Von der Meldung bis zur CVE-Veröffentlichung

  • Der Zeitplan der Schwachstellenbehandlung war wie folgt:
    • 2025-04-07: Erste Entdeckung der Schwachstelle
    • 2025-04-08: Bestätigung der Ausweitung zu RCE
    • 2025-04-08: Meldung der Schwachstelle an ASUS
    • 2025-04-09: Automatische Antwort von ASUS erhalten
    • 2025-04-17: Nach Follow-up-Kontakt übermittelt ASUS den abgeschlossenen Patch und einen Build zur Verifikation
    • 2025-04-18: ASUS bestätigt die Verteilung des Fixes
    • 2025-05-09: CVE-2025-3462 mit Score 8,4 und CVE-2025-3463 mit Score 9,4 werden veröffentlicht

Ausnutzbarkeit und beobachtete Spuren

  • Direkt nach der Meldung wurde auf einem VPS ein Skript ausgeführt, das Updates der Certificate Transparency verfolgte, um zu prüfen, ob Domains der Form driverhub.asus.com.* registriert wurden
  • Nach anderen Websites für Certificate-Transparency-Logs tauchten Domains und Subdomains in der Regel innerhalb eines Monats in den Logs auf
  • Eine Prüfung einen Monat später ergab, dass die einzigen Websites, die zum regulären Ausdruck passten, Test-Domains waren
  • Nach diesem Kriterium war es unwahrscheinlich, dass die Schwachstelle vor der Meldung aktiv ausgenutzt wurde

ASUS-Reaktion und verbleibende Probleme

  • ASUS bietet kein Bug Bounty an und antwortete stattdessen, den Namen in die Hall of Fame aufzunehmen
  • Später stellte sich heraus, dass der Sicherheitsforscher leonjza dasselbe Origin-Prüfungsproblem bereits im Februar 2025 gemeldet hatte; ASUS hatte es bis zum Zeitpunkt dieses Fixes behoben
    • ASUS teilte diesen Umstand nicht separat mit
    • Auf der cve.org-Seite wurde nur dieser Forscher in den Credits genannt, und ASUS antwortete, keine zusätzlichen Credits aufzunehmen
  • Beim Einreichen des Schwachstellenberichts über das ASUS-Security-Advisory-Formular erkannte Amazon CloudFront den angehängten PoC als bösartige Anfrage und blockierte die Einreichung
    • Einige PoC-Code-Teile mussten entfernt und stattdessen ein Link zu einer Videoaufzeichnung eingereicht werden
  • Wenn man in DriverHub nicht jeden empfohlenen Treiber einzeln installiert, sondern „Install All“ klickt, werden auch ArmouryCrate, ASUS’ angepasstes CPU-Z, Norton360 und WinRAR mitinstalliert
  • Die CVE-Beschreibung von ASUS stellt Umfang und Auswirkungen der RCE enger dar
    • In der Beschreibung hieß es sinngemäß, sie sei auf „motherboards“ beschränkt und betreffe keine „laptops, desktop computers“
    • Tatsächlich sind alle Computer betroffen, auf denen DriverHub installiert ist, einschließlich Desktops und Laptops
    • Statt beliebiger oder entfernter Codeausführung wurde formuliert, dass „untrusted sources“ das „system behaviour“ beeinflussen könnten

Verwandte Beiträge

1 Kommentare

 
GN⁺ 2025-05-12
Meinungen auf Hacker News

  • Responsible Disclosure und ihre Folgen waren für die Menschheit nahezu katastrophal. Unternehmen müssen viel häufiger und viel stärkeren Schmerz spüren, damit sie die Sicherheit ihrer Kunden ernster nehmen
    Wenn man ihnen einen Monat gibt und die Lösung gleich mit auf dem Silbertablett serviert, wird daraus nur ein weiteres Backlog-Ticket. Wenn jedes Sicherheitsproblem online groß genug Schlagzeilen machen würde, dass sogar der CEO involviert ist und eine Lösung nicht binnen Monaten, sondern binnen Stunden gefunden werden muss, würden sie deutlich proaktiver handeln. Natürlich würden die Endnutzer am stärksten darunter leiden, aber wer ASUS gekauft hat, leidet ja ohnehin schon

    • Die Reaktionsgeschwindigkeit von ASUS war in diesem Fall ziemlich ordentlich, und ich sehe hier kein großes Problem. ASUS hat den Bug nicht bestritten, nicht mit einer Klage wegen Reverse Engineering der Software gedroht und schnell gepatcht
      In der Zeit vor Responsible Disclosure hätte dieser Prozess vermutlich Monate gedauert, und wahrscheinlich wäre sogar die Polizei involviert gewesen. Normale Nutzer interessieren sich nicht für Schwachstellen und erledigen Bankgeschäfte auf einem Smartphone, das seit drei Jahren keine Updates mehr bekommt. Wenn man die Nachrichten ständig mit CVEs flutet, werden sie der Aussage „alle Unternehmen sind miserabel“ überdrüssig und stumpfen selbst gegenüber echten Bedrohungen ab
      Die EU verfolgt einen anderen Ansatz. Nach den neuen Cybersicherheitsvorschriften dürfen Produkte mit bekannten Schwachstellen nicht mehr im Laden verkauft werden. Wenn ASUS weiter patzt, werden Mainboards zu Ladenhütern, und Händler werden keine ASUS-Hardware mehr verkaufen wollen. Das gilt nicht nur für Computerhardware, sondern auch für smarte Kühlschränke und Waschmaschinen. Wenn man eine Schwachstelle in einer Spülmaschine findet und der Hersteller keine Möglichkeit für Firmware-Updates eingebaut hat, könnte das in der Branche unbrauchbare Lagerbestände im Wert von Millionen Dollar erzeugen
    • Der Begriff „Responsible Disclosure“ ist paradox. In Wirklichkeit ist das nämlich eher ein völlig unverantwortlicher Ansatz
      Die meisten Unternehmen gehen miserabel mit Offenlegungen um. Sie beheben Probleme nicht rechtzeitig, etwa innerhalb einer Woche, nennen die Finder nicht angemessen, informieren die Nutzer nicht und lernen nicht aus ihren Fehlern. Unverantwortlich verzögerte, eingeschränkte Offenlegung verstärkt genau dieses Verhalten
      Wirklich verantwortungsvoll wäre es, sofort, vollständig und öffentlich offenzulegen. Falls nötig, kann man das anonym tun, um sich selbst zu schützen. Erst nachdem ein betroffenes Unternehmen wiederholt bewiesen hat, dass es korrekt reagiert, könnte es das Recht auf eine sehr kurze Vorabinformation bekommen, etwa fünf Werktage
      Dass diese unverantwortliche, verzögerte, eingeschränkte Offenlegung „Responsible Disclosure“ genannt wird, ist ein Beispiel für Neusprech
    • Im Kern geht es um die gesetzliche Verankerung von Haftung. Autohersteller können zu Rückrufen und Reparaturen verpflichtet werden, aber Software- und Hardwareunternehmen stehen unter viel zu geringem Druck
      Kunden sollten zum Beispiel für defekte Geräte mit ungepatchten CVEs eine vollständige Rückerstattung erhalten können
    • Um CGPGrey zu zitieren: Die erste Lösung, die einem einfällt, ist meistens furchtbar und wirkungslos
      Eine gute Sicherheitskultur ermutigt die Beteiligten, Probleme nicht zu verstecken. Unternehmen sind gierige Gebilde und werden alles tun, um Sicherheitsfehler zu verbergen
      Wenn man ein legales und behebbares Problem, das innerhalb eines Monats korrigiert werden kann, allen öffentlich macht, steigt auch die Wahrscheinlichkeit erheblich, dass es ausgenutzt wird
    • So eine Geschäftsidee könnte es geben. Vielleicht gibt es sie schon: einen Offenlegungs-Vermittlungs- und Aggregationsdienst aufzubauen
      Er schützt die Privatsphäre der Hinweisgeber, verifiziert Sicherheitslücken und stellt sicher, dass jede veröffentlichte Schwachstelle tatsächlich ausnutzbar ist. Er veröffentlicht in festen Abständen und verlangt von Unternehmen eine Abogebühr für einen „Early Feed“ mit Offenlegungen, die sie betreffen. Mit dem Geld werden Hinweisgeber bezahlt, die Betriebskosten gedeckt und ein Teil Gewinn einbehalten
      Sozusagen ein gegenüber Unternehmen leicht feindseliger Bug-Bounty-Marktplatz. Ich frage mich, ob das legal wäre oder als Erpressung gelten würde

  • Bitter ist die Stelle, an der gefragt wurde, ob ASUS ein Bug-Bounty-Programm hat, und sie antworteten, nein, boten aber stattdessen an, den Namen in eine „Hall of Fame“ aufzunehmen
    Das ist natürlich sarkastisch gemeint: ASUS ist ja ein kleines Startup und hat vermutlich nicht das Kapital für Bounties

    • Auch bei kleinen Firmen wie Cisco ist das nachvollziehbar. Cisco hat das über Jahre hinweg bei vielen übernommenen Online-Diensten ähnlich gemacht
      Cisco ging sogar noch weiter und hat seine Security-Advisory-Seite vergessen, sodass jede Anerkennung inzwischen im Nichts verschwunden ist
    • Wenn es keine Bug Bounties gibt, landen Exploits auf dem Schwarzmarkt oder werden vollständig öffentlich gemacht
    • Bei so einer Reaktion habe ich keine Lust, jemals wieder ASUS-Produkte zu kaufen
    • Ich weiß nicht, woher die Formulierung „Asus ist ein kleines Startup“ kommt. Asus stellt mindestens seit den 90ern Mainboards und PC-Komponenten her

  • Nicht überraschend. ASUS-Software ist miserabel, und in Sachen Sicherheit ist das Unternehmen eher ein Wiederholungstäter mit zu wenig Prävention
    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...

  • Der Punkt, dass man anhand der Certificate-Transparency-Logs gesehen habe, dass die einzigen Domains, die zu driverhub.asus.com.* passen, eigene Test-Domains seien, und deshalb vor der Meldung vermutlich keine aktive Ausnutzung stattfand, gilt nur, wenn es kein Wildcard-Zertifikat gab.
    Jemand mit einem Wildcard-Zertifikat hätte das ausnutzen können, ohne in Certificate Transparency aufzufallen.

    • Wildcard-Zertifikate gelten nur für eine einzelne Label-Ebene. *.example.com. gilt nicht für test.test.example.com., aber für test.example.com..
      Wenn jemand ein Wildcard-Zertifikat für *.asus.com.example.com. ausgestellt bekommen hätte, hätte er unter driverhub.asus.com.example.com. einen Webserver betreiben und gültig erscheinen lassen können.
    • Gute Idee, ich habe das gerade überprüft und bestätigt, dass es bei Wildcard-Records nichts Verdächtiges gab.
    • Die blinde Stelle bei Wildcard-Zertifikaten stimmt. Wenn ein Angreifer ein Wildcard-Zertifikat für .example.com gehabt hätte, hätte er es ausnutzen können, ohne dass driverhub.asus.com. konkret in den Certificate-Transparency-Logs auftaucht.
      Deshalb reicht Monitoring von Certificate-Transparency-Logs allein nicht aus, um diese Art von Subdomain-Takeover-Schwachstelle zu erkennen.
    • Zusätzlich frage ich mich, ob auch ein selbstsigniertes Zertifikat funktioniert hätte. Solche Zertifikate landen nicht in Transparency-Logs.
      Und fraglich ist auch, ob es überhaupt HTTPS sein musste.

  • Dass das Ganze mit „Mein Onboard-WiFi funktioniert immer noch nicht, und ich musste einen externen USB-WiFi-Adapter kaufen. Danke, DriverHub“ endet, macht den gesamten Ablauf buchstäblich zu vergeblicher Mühe.

    • Der Blogpost selbst war gut.
    • Der neueste WiFi-Treiber funktioniert nicht, man muss also eine ältere Version verwenden.

  • Der Teil, in dem Amazon CloudFront beim Einreichen des Schwachstellenberichts über das ASUS-Sicherheitsmeldeformular den angehängten PoC als bösartige Anfrage einstufte und blockierte, wirkt wie ein Hinweis darauf, dass eine Web Application Firewall ein Anti-Pattern ist: https://thedailywtf.com/articles/Injection_Rejection

  • „ASUS ist ein kleines Startup, das versteht man“ – gemeint ist also ein kleines Startup mit einer Marktkapitalisierung von gerade einmal 15 Milliarden Dollar.
    Was wirklich schwer zu verstehen ist: nicht nur die miserablen Produkte, sondern auch der Umgang mit einem Forscher, der enorme Arbeit im Interesse der Kunden geleistet hat.
    Es ist traurig, dass Forscher, die so etwas tun, ignoriert oder herabgewürdigt werden. Das ist extrem unfair.
    Das Einzige, was man tun kann, ist, keine ASUS-Produkte zu kaufen.

  • Es wurde gefragt, ob ASUS ein Bug Bounty hat, und ASUS antwortete, man habe keines, werde den Namen aber stattdessen in die „Hall of Fame“ aufnehmen. Das ist die ironische Aussage, dass ASUS als kleines Startup wohl nicht über das Kapital für ein Bounty verfügt.
    [1]: https://companiesmarketcap.com/asus/marketcap/

    • Oder es könnte sarcasm.com sein ;)

  • Der obligatorische Link zum Scumbag Asus-Video.
    Invidious https://inv.nadeko.net/watch?v=cbGfc-JBxlY
    YouTube https://youtube.com/watch?v=cbGfc-JBxlY
    „ASUS hat uns letzte Woche per E-Mail geschrieben, dass sie diese Woche in unser Büro kommen und einen ‚offenen Dialog‘ über das Problem führen möchten. Wir sagten: gern, aber das Gespräch müsse aufgezeichnet werden. Schließlich hätten sie ja einen offenen Dialog gewollt. Danach kam fünf Tage lang keine Antwort. ASUS hatte also die Gelegenheit, das in Ordnung zu bringen. Wir hielten das Video zurück, um ihnen diese Chance zu geben. Aber sobald wir sagten: ‚Gut, aber wir filmen, damit die zugesagten Dinge dokumentiert sind‘, kam Schweigen.“

    • Gibt es eigentlich überhaupt Mainboard-Hersteller, die „im Grunde okay“ sind? Oder gibt es ähnliche Geschichten bei allen großen Anbietern?
      Ich frage für einen Freund, der demnächst einen neuen PC zusammenbauen will.
    • Das macht mich wütend, aber ich frage mich, wie die stärkste plausible Verteidigung aus Sicht von ASUS aussehen würde.
      Die Version, die der Realität wahrscheinlich am nächsten kommt, ist wohl diese: Sie jagen dem Profit hinterher, kommen damit trotzdem durch, haben keinen Grund, sich dokumentiert schlecht aussehen zu lassen, und investieren die Zeit lieber ins Marketing.

  • Kein Bug Bounty ist absurd. Ich werde künftig keine ASUS-Produkte mehr kaufen.

    • Vermutlich, weil sie ein „kleines Startup“ sind.
    • Asus-Software und Kundensupport sind schrecklich und waren es schon immer.