Windows-Named-Pipes: Der lokale Kanal, der zum Einfallstor für eine Rechteausweitung werden kann

Interprozesskommunikation ist nicht automatisch vertrauenswürdig

Am 22. August 2026 wurde erneut auf ein in Windows-Architekturen häufig unterschätztes Risiko hingewiesen: Named Pipes sollten nicht allein deshalb als private Kanäle gelten, weil sie Prozesse auf demselben Computer verbinden.

Diese Objekte ermöglichen es Diensten, Desktop-Anwendungen, Befehlszeilenprogrammen, Tray-Prozessen und Hintergrundagenten, Daten auszutauschen. In vielen Fällen läuft der Pipe-Server als privilegierter Dienst, während der Client unter dem Konto eines Benutzers ausgeführt wird.

Auf einem System können jedoch gleichzeitig Prozesse unter LocalSystem, Administratorkonten, Standardbenutzerkonten und Dienstkonten laufen. Hinzu kommen Drittanbietersoftware, Skripte, Diagnosetools und Malware, die mit kompromittierten Zugangsdaten gestartet wurden.

Ein Prozess, der den Namen der Pipe kennt und über die erforderlichen Rechte verfügt, kann versuchen, eine Verbindung herzustellen. Windows überprüft nicht automatisch, ob der Client tatsächlich die vom Entwickler vorgesehene ausführbare Datei ist. Eine erfolgreiche Verbindung beweist lediglich, dass das Token des Prozesses über die erforderlichen Berechtigungen verfügte.

Sie beweist jedoch nicht, dass der Prozess vertrauenswürdig, der Benutzer autorisiert oder die angeforderte Aktion sicher war.

Wann die Pipe zu einer Sicherheitsgrenze wird

Das Risiko steigt, wenn die beiden Kommunikationspartner über unterschiedliche Berechtigungsstufen verfügen. Besonders kritisch ist ein Windows-Dienst, der als LocalSystem ausgeführt wird und Anfragen einer Anwendung akzeptiert, die unter einem Standardbenutzerkonto läuft.

Ein solcher Dienst kann geschützte Dateien ändern, in die Registry schreiben, Prozesse starten, die globale Konfiguration verändern, auf Daten anderer Benutzer zugreifen oder mit Kernel-Treibern kommunizieren.

Die Named Pipe wird damit faktisch zu einer lokalen API für privilegierte Aktionen. Ein Fehler in der DACL, bei der Identifizierung des Clients, bei der Validierung von Befehlen oder in der Autorisierungslogik kann es einem lokalen Prozess ermöglichen, die Rechte des Dienstes auszunutzen.

Das Problem entspricht dem typischen Confused-Deputy-Modell: Der Client bestimmt, welche Aktion angefordert wird, die Ausführung erfolgt jedoch durch den Dienst mit höheren Privilegien.

Nachrichten können Dateipfade, Registry-Schlüssel, Befehlszeilenargumente, Namen ausführbarer Dateien, Anweisungen zum Starten oder Beenden von Prozessen und Installationsanforderungen enthalten. Ein Dienst, der einen generischen Befehl wie „Schreibe einen Wert in einen beliebigen Schlüssel“ akzeptiert, bietet eine deutlich größere Angriffsfläche als ein Dienst, der nur das Aktualisieren einer bestimmten Anwendungseinstellung erlaubt.

Eine korrekte Syntax allein reicht nicht aus. Der Server muss feststellen, ob genau diese Identität genau diese Aktion für die angegebene Ressource ausführen darf.

ACLs, Tokens und Berechtigungen müssen zusammenspielen

Der Schutz sollte mit einem expliziten Security Descriptor beginnen. Seine DACL sollte den Zugriff ausschließlich den erforderlichen Identitäten gewähren: einer bestimmten SID, einem Dienstkonto, einer Administratorgruppe oder einer definierten Sitzung.

Eine alleinige Abhängigkeit von den Standardeinstellungen kann zu weitreichende Rechte vergeben. Allgemeine Berechtigungen für folgende Gruppen sollten vermieden werden:

• Everyone;
• Authenticated Users;
• alle interaktiven Benutzer.

Authentifizierung und Autorisierung sind nicht dasselbe. Ein Client kann berechtigt sein, den Status eines Dienstes zu lesen, ohne ihn beenden, geschützte Einstellungen ändern, Prozesse starten oder beliebige Dateien lesen zu dürfen.

Sensible Aktionen müssen daher jeweils einzeln bewertet werden.

Auch Impersonation erfordert besondere Vorsicht. Sie kann dem Dienst ermöglichen, eine Aktion im Sicherheitskontext des Clients auszuführen. Der Server muss jedoch überprüfen, ob die Aktion tatsächlich erfolgreich war, den während dieser Phase ausgeführten Code auf ein Minimum beschränken und stets zu seiner ursprünglichen Identität zurückkehren.

Die praktische Regel ist einfach: Bevor der Server eine Nachricht verarbeitet, muss er Identität, Privilegien und die konkrete Autorisierung prüfen.

Den verbundenen Prozess identifizieren

Bei lokaler Kommunikation kann der Server die PID des Clients mit GetNamedPipeClientProcessId ermitteln. Umgekehrt kann der Client GetNamedPipeServerProcessId verwenden, um den Serverprozess zu identifizieren.

Die Funktionen gehören zu den nativen APIs von kernel32.dll und sollten nach dem Aufbau der Verbindung aufgerufen werden. Anschließend kann die PID genutzt werden, um mit PROCESS_QUERY_INFORMATION oder PROCESS_QUERY_LIMITED_INFORMATION ein Handle zu öffnen und über QueryFullProcessImageName den Pfad der ausführbaren Datei abzurufen.

Die Prüfung muss unmittelbar nach der Annahme der Verbindung und vor dem Lesen oder Anwenden von Befehlen erfolgen. Der ermittelte Pfad sollte mit dem erwarteten Pfad verglichen werden. Die ausführbare Datei muss sich jedoch in einem Verzeichnis befinden, das von Standardbenutzern nicht verändert werden kann. Andernfalls könnte ein Angreifer die Datei ersetzen und dabei denselben Pfad beibehalten.

Für eine stärkere Prüfung können die Authenticode-Signatur oder eine kryptografische Übereinstimmung mit einer freigegebenen Referenz kontrolliert werden.

Der Name der Pipe ist kein Geheimnis. Ein Angreifer kann ihn kennen, vor dem Start des legitimen Servers eine Pipe mit demselben Namen anzulegen versuchen und den Client dazu bringen, sich mit dem falschen Prozess zu verbinden. Die Option first-pipe-instance kann dabei helfen zu erkennen, dass der Name bereits beansprucht wurde. Sie ersetzt jedoch weder korrekte ACLs noch die Prozessidentifikation.

Jede Nachricht ist als nicht vertrauenswürdige Eingabe zu behandeln

Selbst ein legitimer Client kann beschädigte oder übermäßig große Daten senden oder gezielt Eingaben erzeugen, die Fehler auslösen. Das Protokoll sollte ein strikt definiertes Framing, Größenlimits, ein überprüfbares Schema und eine Allowlist der unterstützten Befehle vorsehen.

Ebenfalls erforderlich sind:

• Normalisierung von Pfaden;
• Ablehnung mehrdeutiger Operationen;
• sichere Fehlerbehandlung;
• Autorisierung für jede einzelne Operation;
• Trennung zwischen Informationsfunktionen und privilegierten Aktionen;
• Beschränkung der Funktionen auf das unbedingt Erforderliche.

Der Dienst sollte keine beliebigen Pfade akzeptieren, wenn er stattdessen mit vordefinierten Bezeichnern arbeiten kann. Sicherer ist beispielsweise, nur die Aktualisierung einer bestimmten Konfiguration zu erlauben, anstatt vom Client den vollständigen Pfad zu einem Registry-Schlüssel entgegenzunehmen.

Dasselbe gilt für Prozesse: Ein auf den Start einer bekannten Komponente beschränkter Befehl ist weniger riskant als eine Schnittstelle, die beliebige Programme mit vom Client gewählten Argumenten ausführen kann.

Verfügbarkeit und Remotezugriff

Die Bedrohung betrifft nicht nur Vertraulichkeit oder Rechteausweitung. Ein schädlicher Prozess kann zahlreiche Verbindungen öffnen, sie dauerhaft offenhalten, unvollständige Nachrichten senden oder Speicher, CPU und Kernelressourcen verbrauchen.

Timeouts, das Abbrechen von Anfragen, eine maximale Verbindungszahl, kontrollierte Parallelität und maximale Nachrichtengrößen verringern das Missbrauchsrisiko.

Außerdem sind nicht alle Named Pipes zwangsläufig auf den lokalen Computer beschränkt. In bestimmten Windows-Konfigurationen kann Windows den Remotezugriff zulassen. Pipes, die ausschließlich für lokale IPC vorgesehen sind, sollten Netzwerkidentitäten wie NT AUTHORITY\NETWORK explizit blockieren oder einen Mechanismus verwenden, der ihre Nutzung ausschließlich lokal gewährleistet.

Für dieses Problem ist kein zugehöriger CVE bekannt. Ebenso werden keine bestimmten Windows-Versionen oder anfälligen Produkte genannt. Es handelt sich um ein Sicherheitsmodell für Implementierungen, die Named Pipes verwenden, nicht um die Beschreibung einer einzelnen identifizierten Schwachstelle.

Eine korrekte Prüfung muss fünf Elemente gemeinsam berücksichtigen: Prozessidentität, tatsächlich wirksame Berechtigungen, Autorisierung der Aktion, Datensicherheit und Ressourcenlimits. Eine akzeptierte Verbindung stellt niemals eine allgemeine Autorisierung dar.