Schwachstelle im AOMEI-Backupper-Treiber erlaubt Schreibzugriffe auf physischen Datenträger ohne Privilegien

Das Coordination Center CERT (CERT/CC) hat einen Sicherheitshinweis VU#687587 veröffentlicht, in dem die Schwachstelle CVE-2026-12780 im Kernel-Treiber amwrtdrv.sys beschrieben wird, der Teil der Backup-Software AOMEI Backupper ist. Die Schwachstelle erlaubt es einem lokalen Benutzer ohne erhöhte Rechte, beliebige Schreibvorgänge auf den physischen Datenträger auszuführen. Bei deaktiviertem Secure Boot öffnet dies den Weg zur Einschleusung von Schadcode auf UEFI-Ebene – noch bevor das Betriebssystem und seine Schutzmechanismen geladen werden. Nutzern von AOMEI Backupper wird empfohlen, die Software zu aktualisieren, zu entfernen oder den verwundbaren Treiber zu deaktivieren.

Technische Details der Schwachstelle

Dem Sicherheitshinweis von CERT/CC zufolge wird die Schwachstelle als CWE-732 klassifiziert – fehlerhafte Vergabe von Berechtigungen für eine kritische Ressource. Der Treiber amwrtdrv.sys erzeugt ein Geräteobjekt, das für alle Benutzer des Systems zugänglich ist (world-accessible), ohne einen Security Descriptor zu setzen. Das bedeutet, dass jeder Prozess im User Mode das Gerät \\\\.\\mwrtdrv\\DISK0 öffnen und unbegrenzt Schreibanforderungen senden kann.

Nach Angaben von CERT/CC enthält AOMEI Backupper in Version 8.4.0 den verwundbaren Treiber. Bemerkenswert ist, dass im Eintrag der GitHub Advisory Database eine andere Grenze der betroffenen Versionen angegeben ist – bis einschließlich 8.3.0. Diese Diskrepanz ist ungeklärt: CERT/CC als Primärquelle nennt explizit Version 8.4.0, während der GitHub-Eintrag den Status „unreviewed“ trägt und betroffene sowie behobene Versionen als unbekannt markiert. Nutzer einer dieser Versionen sollten sich als potenziell verwundbar betrachten.

Der von CERT/CC beschriebene Angriffsmechanismus sieht wie folgt aus: Ein Angreifer mit lokalem Zugriff modifiziert die Sektoren des Datenträgers im Bereich zwischen den Partitionen (LBA 34–2047), schleust eine bösartige UEFI-Payload ein und verändert die GPT-Partitionstabelle so, dass sie auf diese Payload als EFI-Systempartition verweist. Beim nächsten Systemstart wird der Schadcode in der Phase UEFI Boot Device Selection (BDS) ausgeführt – noch bevor der Windows-Kernel geladen wird.

Auswirkungsbereich und Abhängigkeit von der Konfiguration

Die Analyse des Sicherheitshinweises von CERT/CC zeigt, dass das Risiko mehrere klar umrissene Konfigurationsgrenzen aufweist, die zu unterscheiden wichtig ist:

• Grundlegende Schwachstelle – beliebige Schreibzugriffe auf den physischen Datenträger – kann von jedem lokalen Benutzer ohne erhöhte Rechte auf einem System mit installiertem verwundbarem Treiber ausgenutzt werden. Dieser Teil des Angriffs ist unabhängig vom Status von Secure Boot.
• Ausführung von UEFI-Code vor dem Laden des OS – als Folge der Schreibzugriffe auf den Datenträger – ist nur bei deaktiviertem Secure Boot möglich. Bei aktiviertem Secure Boot muss der Bootloader signiert sein, was die Ausführung des eingeschleusten Codes blockiert.
• Abfangen von BitLocker-Schlüsseln – das Abgreifen des Volume Master Key (VMK) wird von CERT/CC nur für Konfigurationen mit TPM-only-Schutz (ohne PIN-Code oder USB-Schlüssel) beschrieben. Dieser Angriff gehört zur Klasse „evil maid“ – physischer Zugriff auf das Gerät mit anschließender Manipulation des Bootprozesses.

Diese Abgrenzung ist für die Risikobewertung entscheidend: Die Schwachstelle im Treiber besteht unabhängig von Secure Boot, aber die gravierendsten Folgen – Umgehung von HVCI, EDR-Lösungen, Microsoft Defender und der Hyper-V-Isolation – sind nur bei deaktiviertem Secure Boot realisierbar. CERT/CC weist ausdrücklich darauf hin, dass die Aktivierung von Secure Boot einen zusätzlichen gestaffelten Schutz bietet, aber die Schwachstelle im Treiber selbst nicht beseitigt.

Status der Ausnutzung und Reaktion des Herstellers

Zum Zeitpunkt der Veröffentlichung des Sicherheitshinweises teilt CERT/CC mit, dass keine Antwort von AOMEI International Network Limited eingegangen ist. Das bedeutet, dass keine konkret bereinigte Produktversion weder im Sicherheitshinweis von CERT/CC noch in anderen verifizierten Quellen genannt wird.

Zur Ausnutzung unter realen Bedingungen: Die vorliegenden Informationen belegen keine aktive Nutzung der Schwachstelle durch Angreifer. CERT/CC beschreibt den technischen Ausnutzungspfad, und die Erwähnung einer öffentlichen Offenlegung eines Exploits findet sich nur im ungeprüften Eintrag der GitHub Advisory Database. Die Schwachstelle ist nicht im Katalog der CISA Known Exploited Vulnerabilities aufgeführt. Der Status ist als Vorhandensein eines öffentlichen PoC und nicht als bestätigte Ausnutzung in freier Wildbahn zu werten.

Empfehlungen zur Behebung

CERT/CC schlägt folgende Maßnahmen vor, in der Reihenfolge ihrer Priorität:

1. AOMEI Backupper aktualisieren auf eine Version mit bereinigtem Treiber amwrtdrv.sys, der korrekte Zugriffskontrollmechanismen implementiert. Die konkrete Versionsnummer mit Fix ist zum Zeitpunkt der Veröffentlichung des Sicherheitshinweises nicht angegeben.
2. AOMEI Backupper entfernen, falls ein sofortiges Update nicht möglich ist.
3. Den Dienst amwrtdrv.sys deaktivieren, indem der Starttyp von AUTO_START auf „Disabled“ (Deaktiviert) geändert wird – als Zwischenlösung.
4. Secure Boot aktivieren in den UEFI-Einstellungen – als zusätzlichen Schutzwall, der die Ausführung unsignierten Codes in der Bootphase blockiert. Diese Maßnahme ersetzt nicht die Behebung der Schwachstelle im Treiber.

Für Systeme mit BitLocker wird empfohlen, einen Wechsel von einer TPM-only-Konfiguration zu TPM+PIN oder TPM+USB-Schlüssel in Betracht zu ziehen, um das von CERT/CC beschriebene Szenario des VMK-Abfangens in der Pre-Boot-Phase auszuschließen.

Organisationen, die AOMEI Backupper in unternehmensweiten Backup-Szenarien einsetzen, sollten die Deaktivierung oder Entfernung des verwundbaren Treibers priorisieren, bis eine bestätigte Korrektur durch den Hersteller vorliegt. Das Ausbleiben einer Antwort von AOMEI und die Unklarheit über die bereinigte Versionsnummer machen das bloße Abwarten auf einen Patch zu einer riskanten Strategie – zumal die Schwachstelle es einem Angreifer ermöglicht, sich auf einer Ebene unterhalb des Betriebssystems festzusetzen, wo das Erkennen einer Kompromittierung mit Standardmitteln erheblich erschwert ist.