One-Click-RCE-Schwachstelle in vorinstallierter Treiber-Software von ASUS entdeckt

• In der DriverHub-Software von ASUS wurde eine One-Click-Schwachstelle zur Remote Code Execution (RCE) entdeckt
• Aufgrund einer schwachen Origin-Prüfung lokal kann eine bösartige Website per RPC eine Ausführung mit Administratorrechten erreichen
• Durch Missbrauch des UpdateApp-Endpunkts lässt sich schädlicher Code mithilfe einer Kombination aus einer von ASUS signierten ausführbaren Datei und einer manipulierten ini-Datei ausführen
• Die Schwachstelle wurde als CVE-2025-3462, CVE-2025-3463 veröffentlicht, und ASUS hat schnell einen Patch bereitgestellt
• Zum Zeitpunkt der Meldung der Schwachstelle wurden keine Fälle realer Ausnutzung festgestellt, und ASUS belohnte den Fund statt mit einer Bug Bounty mit einem Eintrag in die Hall of Fame

---

Introduction

• Die Geschichte begann mit dem Kauf neuer PC-Komponenten
• Beim Kauf eines ASUS-Mainboards ist die BIOS-Option zur automatischen Software-Installation standardmäßig aktiviert
• Da die Option nicht rechtzeitig deaktiviert wurde, erschien nach der Windows-Anmeldung eine Anfrage zur Installationsberechtigung für DriverHub
• Aus Neugier und wegen des benötigten WiFi-Treibers wurde DriverHub installiert

DriverHub

• DriverHub ist ein Hintergrundprozess ohne GUI
• Es kommuniziert mit driverhub.asus.com und meldet, welche Treiber installiert oder aktualisiert werden müssen
• Lokal stellt es eine HTTP-API (Port 53000) per RPC bereit
• Die Website kann API-Anfragen an diesen lokalen Dienst senden und so die Treiber direkt verwalten
• Dabei wurde erkannt, dass Angreifer bei mangelhafter Absicherung beliebige Anfragen senden könnten

Finding the Vulnerability

• Es wurde getestet, ob eine Website beliebige RPC-Anfragen an das DriverHub-Backend senden kann
• Antworten sollten nur erfolgen, wenn die Origin „driverhub.asus.com“ ist
• Es wurde geprüft, ob die Origin-Prüfung als Wildcard-Match nach dem Muster origin.includes("driverhub.asus.com") erfolgt
• Als die Origin auf „driverhub.asus.com.mrbruh.com“ geändert wurde, zeigte sich, dass die Anfrage akzeptiert wurde
• Damit wurde bestätigt, dass Angreifer über eine bösartige Website RPC-Aufrufe auslösen können, was ein ernstes Risiko darstellt

The Extent of the Damage

• Durch Reversing und JavaScript-Analyse wurde die Liste der im Hintergrund verfügbaren API-Endpunkte ermittelt
• Wichtige Endpunkte:
  • Initialize: gibt Installationsstatus und Informationen zurück
  • DeviceInfo: gibt installierte ASUS-Software/Treiber/Hardware/MAC-Adresse zurück
  • Reboot: führt sofort einen Reboot durch
  • Log: gibt eine Sammlung von Log-Dateien zurück
  • InstallApp: installiert eine App oder einen Treiber mit der angegebenen ID
  • UpdateApp: lädt eine ausführbare Datei von der angegebenen URL herunter und führt sie aus (bei ASUS-Signatur automatische Ausführung)
• Besonderes Augenmerk lag darauf, dass UpdateApp missbraucht werden kann

Achieving RCE

• Der Endpunkt UpdateApp wurde im Detail analysiert
• Beim Parameter „Url“ besteht die Bedingung, dass .asus.com enthalten sein muss, wobei es Umgehungsmöglichkeiten gibt; der Dateiname folgt dem URL-Ende
• Nur von ASUS signierte ausführbare Dateien werden automatisch ausgeführt, aber auch unsignierte Dateien werden heruntergeladen und danach nicht gelöscht
• Eine Timing-Attacke, bei der die Datei nach bestandener Signaturprüfung direkt vor der Ausführung ersetzt wird, wurde geprüft, war jedoch unpraktisch
• Bei der Analyse der Struktur eines ASUS-WiFi-Treiberpakets wurde erkannt, dass die Eigenschaft SilentInstallRun in AsusSetup.ini zur Ausführung beliebiger Befehle genutzt werden kann
• Die finale Angriffskette:
  1. Der Angreifer verleitet zum Besuch einer Website unter einer driverhub.asus.com. * Subdomain
  2. Die Website fordert per UpdateApp ein bösartiges calc.exe an (wird nur heruntergeladen, nicht ausgeführt)
  3. Eine angepasste AsusSetup.ini wird angefordert (SilentInstallRun=calc.exe, ebenfalls ohne Ausführung)
  4. Eine signierte AsusSetup.exe wird angefordert (wird automatisch mit Administratorrechten ausgeführt und liest mit dem Flag -s die ini-Datei ein und startet calc.exe)
• Dadurch entsteht effektiv eine One-Click-Remote-Code-Execution (RCE) mit Administratorrechten

Reporting Timeline (DD/MM/YYYY)

• 07/04/2025: Schwachstelle erstmals entdeckt
• 08/04/2025: RCE nachgewiesen und Schwachstelle gemeldet
• 09/04/2025: automatische Antwort von ASUS erhalten
• 17/04/2025: Patch veröffentlicht und gepatchten Build erhalten
• 18/04/2025: bestätigt, dass der Patch live ist
• 09/05/2025: CVE-2025-3462 (8,4 Punkte), CVE-2025-3463 (9,4 Punkte) veröffentlicht

Assessing the Damage

• Unmittelbar nach der Meldung der Schwachstelle wurde ein Tracking-Skript für Certificate Transparency geschrieben
• Damit wurde die Ausstellungshistorie von Zertifikaten für Subdomains unter driverhub.asus.com.* überwacht
• Das einmonatige Monitoring zeigte, dass außer den eigenen Tests keine weiteren Treffer im Filter auftauchten
• Es wurde bestätigt, dass keine Hinweise auf vorherige Ausnutzung vorlagen

Bug Bounty

• ASUS wurde gefragt, ob eine Bug-Bounty-Zahlung erfolgt, was abgelehnt wurde
• Stattdessen gab es als Anerkennung einen Eintrag in die Hall of Fame
• Ergänzend wurde erläutert, dass ASUS trotz seiner Größe keine angemessene Bounty-Politik hat

Fun Notes

• Beim Einreichen des ASUS-Security-Advisory-Formulars wurde der PoC von Amazon CloudFront als bösartige Anfrage blockiert
• Beim Klick auf „Install All“ in DriverHub werden zusätzliche Softwarepakete (Norton360, WinRAR usw.) mitinstalliert
• Die CVE-Beschreibung ist ungenau und missverständlich, da sie den Eindruck erwecken kann, dass Desktop-/Notebook-Geräte nicht betroffen seien (tatsächlich sind alle Geräte mit installiertem DriverHub betroffen)
• WiFi funktioniert immer noch nicht, daher musste ein externer USB-WiFi-Adapter gekauft werden
• Kontakt: Signal: paul19.84, E-Mail contact [at] mrbruh.com

[GN⁺]

Hacker-News-Kommentare

• Das Ergebnis von Responsible Disclosure fühlt sich wie eine Katastrophe für die Menschheit an; Unternehmen müssten häufiger und stärkere Schmerzen erleiden, damit sie die Sicherheit ihrer Kunden ernst nehmen. Wenn man ein Problem findet und ihnen einen Monat Zeit gibt, es zu beheben, und ihnen sogar die Lösung sagt, ist das aus Unternehmenssicht nur ein weiteres Ticket im Backlog. Wenn es aber Online-Schlagzeilen gibt und sogar der CEO reagieren muss, finden sie innerhalb weniger Stunden einen Weg zur Behebung. Am Ende trifft es natürlich die Nutzer am härtesten, aber wer ASUS kauft, leidet ohnehin schon.
  • ASUS hat diesmal vergleichsweise schnell reagiert: Das Problem wurde nicht abgestritten, der Reverse Engineer wurde nicht verklagt, und es wurde sofort ein Patch veröffentlicht. Früher hätten solche Fälle Monate gedauert oder sogar die Polizei hätte sich eingeschaltet. Normale Nutzer kümmern sich sowieso nicht um Schwachstellen; wir leben schließlich in einer Welt, in der Menschen mit drei Jahre lang nicht aktualisierten Smartphones Bankgeschäfte erledigen. Selbst wenn man die Medien mit CVE-Meldungen flutet, stumpfen am Ende nur alle ab. In Europa ist der Verkauf von Produkten mit bekannten Schwachstellen durch neue Regulierung inzwischen verboten. Wenn ASUS also so weitermacht, stapeln sich Mainboard-Bestände im Lager und Händler werden sie nicht mehr verkaufen wollen. Das gilt auch für Haushaltsgeräte; hätte zum Beispiel eine Spülmaschine eine Schwachstelle, könnte das die ganze Branche hart treffen.
  • Schon der Name „Responsible“ Disclosure ist paradoxerweise völlig verantwortungslos. Die meisten Unternehmen patchen nicht innerhalb einer Woche, erkennen die Leistung nicht an, informieren Nutzer nicht und lernen nichts aus ihren Fehlern. Langsame und eingeschränkte Offenlegung fördert dieses Verhalten sogar noch. Wirklich verantwortungsvoll wäre eine sofortige, vollständige und öffentliche Offenlegung. Und nur wenn sich Vertrauen aufbaut, dass ein Unternehmen sauber reagiert, könnte man vielleicht fünf Werktage Vorwarnung in Betracht ziehen. Langsame und teilweise Offenlegung „responsible disclosure“ zu nennen, ist bloß Wortklauberei.
  • Die Wurzel des Problems ist das Fehlen von Gesetzen zur Produkthaftung. Autohersteller haben Rückrufpflichten, aber auf Software-/Hardware-Unternehmen lastet viel zu wenig Druck. Ich finde, Kunden sollten für Produkte mit ungefixten Schwachstellen (CVE) eine volle Rückerstattung verlangen können.
  • Um CGPGrey zu zitieren: Die erstbeste Lösung ist meistens schlecht und wirkungslos. Eine gute Sicherheitskultur sollte dazu ermutigen, interne Probleme nicht zu verstecken. Unternehmen sind gierig und verbergen deshalb alle Sicherheitsprobleme. Würde man alles sofort offenlegen, wären auch Probleme, die in einem Monat behoben werden könnten, sofort für alle sichtbar und deutlich leichter ausnutzbar.
  • Ich habe eine Geschäftsidee, vielleicht gibt es sie schon: eine Veröffentlichungs-/Vermittlungsplattform, die die Privatsphäre von Meldenden schützt, die tatsächliche Ausnutzbarkeit von Schwachstellen prüft, in festgelegten Intervallen öffentlich bekannt gibt und bei der Unternehmen kostenpflichtig Vorab-Feeds zu für sie relevanten Fällen abonnieren. Das Geld würde für Belohnungen der Meldenden, Betriebskosten und Gewinnverteilung verwendet. Das ähnelt einem Bug-Bounty-Marktplatz, ist aus Unternehmenssicht aber etwas konfrontativer. Ich frage mich, ob das legal wäre oder als Erpressung gelten würde.
  • Ich betone es immer wieder: Wie in anderen Branchen muss es auch hier rechtliche Haftung für Produktmängel geben. Die meisten Menschen akzeptieren mangelhafte Produkte nur dann, wenn sie billig sind; es gibt keinen Grund, warum ausgerechnet Software davon ausgenommen sein sollte.
  • Wenn man die Schwachstelle einfach schon am nächsten Tag veröffentlicht, schafft das die echte Motivation. Auch der Gesichtsverlust hilft letztlich bei der nächsten Sicherheitsmaßnahme.
  • Diese Form von Übertreibung wie „eine Katastrophe für die Menschheit“ ist ein Paradebeispiel dafür, wie man die eigentliche Debatte ruiniert.
• Als ich ASUS nach einer Bug Bounty fragte, sagte man mir, stattdessen könne mein Name in die Hall of Fame aufgenommen werden. Das hinterlässt einen bitteren Beigeschmack, als wäre ASUS nur ein kleines Startup ohne Kapital für Bounties.
  • Kleine Firmen wie Cisco machen es ähnlich und bieten ebenfalls keine Belohnung, sondern nur eine Namensnennung. Bei Cisco wurde dann sogar die Seite mit den Security Advisories vergessen, sodass selbst diese Anerkennung entfiel.
  • Ohne Bug Bounty bleibt nur die Wahl, den Exploit an den Schwarzmarkt zu verkaufen oder ihn vollständig offenzulegen.
  • Wegen solcher Dinge möchte man nie wieder ASUS-Produkte kaufen.
• ASUS ist auch bei der Softwarequalität schlecht und sorgt ständig für Sicherheitsprobleme. Früher gab es bereits UEFI-Malware-Probleme auf Mainboards, und unnötige vorinstallierte Software ist lästig zu entfernen. Es gibt viele Beschwerden dazu, die man sich ansehen sollte.
  • Das ist nicht das erste Mal; es gab früher schon ähnliche Fälle, und ich habe auch in einem alten Blogeintrag Aufzeichnungen dazu hinterlassen.
• Man sagte, eine Ausnutzung habe es nicht gegeben, weil nur die eigene Test-Domain (driverhub.asus.com.*) die Bedingungen erfülle. Das stimmt aber nur, wenn niemand separat eine Subdomain unter driverhub registriert hat. Mit einem Wildcard-Setup wäre das in Certificate-Transparency-Logs nicht sichtbar und möglicherweise ausnutzbar.
  • Wildcard-Zertifikate decken nur Subdomains eine Ebene tiefer ab. Zum Beispiel gilt *.example.com nur für test.example.com, aber nicht für test.test.example.com. Wenn jemand also ein Wildcard-Zertifikat für *.asus.com.example.com hätte, wäre driverhub.asus.com.example.com gültig.
  • Jemand meinte, die Idee sei gut und wurde sofort geprüft; derzeit gebe es keine verdächtigen Wildcard-Zertifikate.
  • Der Hinweis auf den blinden Fleck bei Wildcard-Zertifikaten ist korrekt. Wenn ein Angreifer ein Wildcard-Zertifikat für .example.com gehabt hätte, wäre eine Ausnutzung tatsächlich auch außerhalb von driverhub.asus.com möglich gewesen. Genau deshalb reicht die Überwachung von CT-Logs allein nicht aus, um solche Subdomain-Takeover-Schwachstellen vollständig zu erfassen.
• Bemerkenswert war die Antwort von ASUS auf die Frage nach einer Bug Bounty: „Wir sind ein kleines Startup, also gibt es keine Bounty, aber wir setzen deinen Namen in die Hall of Fame.“ Tatsächlich ist das Unternehmen ein Riese mit einer Marktkapitalisierung von über 15 Milliarden Dollar.
  • Als sarkastische Replik wurde sarcasm.com empfohlen.
• Weil das Onboard-WLAN nicht funktionierte, wurde ein externer USB-WLAN-Adapter verwendet, aber dank DriverHub war das völlig nutzlos. Angeblich eine Lösung, in Wirklichkeit enttäuschend.
  • Der Blogbeitrag selbst ließ sich immerhin unterhaltsam lesen.
  • Die neuesten WLAN-Treiber funktionierten nicht, sodass eine ältere Version verwendet werden musste.
• ASUS ist ein Großkonzern mit einer Marktkapitalisierung von 15 Milliarden Dollar, bietet aber keine angemessene Belohnung und ignoriert die Mühen von Kunden und Forschenden. Bei so einer Behandlung kann man gut nachvollziehen, wie frustrierend das für Forschende ist. Die Schlussfolgerung lautet: Am besten keine ASUS-Produkte kaufen.
• Beim Einreichen des Bug-Reports wurde die PoC-Datei von Amazon CloudFront als bösartige Anfrage erkannt, sodass die Einreichung selbst blockiert wurde. Solche WAFs (Web Application Firewalls) sind eher ein schlechtes Muster bzw. Negativbeispiel.
• Ich kann den Frust über das Onboard-WLAN nachvollziehen. Eigentlich muss man nur das Chipsatzmodell prüfen und den Treiber dann zum Beispiel bei station-drivers separat herunterladen; das dauert nur ein paar Sekunden. Schon wegen solcher Umstände mag ich ASUS nicht, und BIOS-Optionen, die direkt mit dem Betriebssystem interagieren, mag ich erst recht nicht.
• Ich mag ASUS-Produkte, deaktiviere aber Support-Apps, die im UEFI vorinstalliert werden, grundsätzlich. Früher wurde die Vollversion von ROG Armory Crate installiert, und deren Entfernung war mühsam. Auch nachdem ASUS das NUC-Geschäft von Intel übernommen hatte, wurden BIOS-Updates weiter gepflegt, aber Installations-Apps wie „MyASUS“ wurden standardmäßig hinzugefügt. Zum Glück gibt es eine Option zum Deaktivieren; bei über das Intel-NUC-BIOS aktualisierten Systemen scheint das standardmäßig ausgeschaltet zu sein.