{"id":49681,"date":"2026-08-23T15:41:41","date_gmt":"2026-08-23T13:41:41","guid":{"rendered":"https:\/\/overcentral.com\/de\/?p=49681"},"modified":"2026-08-23T15:41:41","modified_gmt":"2026-08-23T13:41:41","slug":"named-pipes-sicherheitsluecken-windows","status":"publish","type":"post","link":"https:\/\/overcentral.com\/de\/named-pipes-sicherheitsluecken-windows\/","title":{"rendered":"Named Pipes unter Windows \u00f6ffnen Sicherheitsl\u00fccken f\u00fcr lokale Angriffe"},"content":{"rendered":"

Named Pipes<\/a> sind unter Windows-Entwicklern ein beliebtes Mittel f\u00fcr die Interprozesskommunikation (IPC) zwischen Anwendungen auf demselben Rechner. Sie sind schnell, tief im Betriebssystem verankert und eignen sich hervorragend f\u00fcr den Datenaustausch zwischen Windows-Diensten, Desktop-Anwendungen, Tray-Prozessen und Hintergrund-Agents. Die landl\u00e4ufige Annahme, dass diese Kommunikation aufgrund der Lokalit\u00e4t vertrauensw\u00fcrdig sei, ist jedoch ein gef\u00e4hrlicher Trugschluss. In der Realit\u00e4t ist die Pipe, auf die viele unterschiedliche Prozesse mit verschiedenen Benutzerkonten und Sicherheitskontexten zugreifen k\u00f6nnen, eine exponierte lokale Schnittstelle, die ein erhebliches Sicherheitsrisiko darstellt.<\/p>\n

Lokal bedeutet nicht vertrauensw\u00fcrdig<\/h2>\n

Ein typisches Szenario: Ein privilegierter Windows-Dienst (z. B. als LocalSystem) fungiert als Named-Pipe-Server, w\u00e4hrend eine Desktop-Anwendung mit geringeren Rechten als Client agiert. Da beide Prozesse auf demselben Rechner laufen, wird die Kommunikation als intern und sicher behandelt. Jeder Prozess auf dem Rechner, der den Namen der Pipe kennt und \u00fcber die entsprechenden Zugriffsrechte verf\u00fcgt, kann jedoch versuchen, eine Verbindung herzustellen. Windows pr\u00fcft nicht, welche Anwendung die Verbindung aufbauen will. Daher muss eine Named Pipe als exponierte Schnittstelle betrachtet werden, die durch Autorisierung und Validierung gesch\u00fctzt werden muss.<\/p>\n

Identit\u00e4t, Zugriffskontrolle und Berechtigungsgrenzen<\/h2>\n

Das gr\u00f6\u00dfte Risiko besteht, wenn ein privilegierter Windows-Dienst (LocalSystem) mit einer weniger privilegierten Desktop-Anwendung kommuniziert. Ein LocalSystem-Dienst kann sensible Operationen wie das \u00c4ndern von Systemdateien, das Starten von Prozessen oder den Zugriff auf Daten anderer Benutzer ausf\u00fchren. Wird dies \u00fcber eine Named Pipe zug\u00e4nglich gemacht, wird die Pipe zu einer API f\u00fcr privilegierte Funktionen. Eine erfolgreiche Verbindung beweist nur, dass der Client die Pipe \u00f6ffnen durfte, nicht jedoch, dass es sich um die richtige Anwendung oder einen autorisierten Benutzer handelt. Pipe-Berechtigungen sollten daher explizit definiert und auf das N\u00f6tigste beschr\u00e4nkt werden. Authentifizierung und Autorisierung m\u00fcssen getrennt betrachtet werden: Selbst wenn ein Benutzer den Status abfragen darf, sollte er nicht automatisch die M\u00f6glichkeit haben, den Dienst zu stoppen. Jeder sensitive Befehl muss individuell autorisiert werden. Impersonation (Identit\u00e4tswechsel) kann dabei helfen, denn sie f\u00fchrt Operationen im Sicherheitskontext des Clients aus. Dies muss jedoch mit Vorsicht geschehen: Der Server muss pr\u00fcfen, ob die Impersonation erfolgreich war, und nach der Ausf\u00fchrung stets zur eigenen Identit\u00e4t zur\u00fcckkehren.<\/p>\n

Unsere Server, Befehle und Daten<\/h2>\n

Der Client muss den Server ebenso \u00fcberpr\u00fcfen wie der Server den Client. Ein vorhersagbarer Pipe-Name ist kein Geheimnis. Ein Angreifer kann eine Pipe mit dem erwarteten Namen erstellen, bevor der legitime Server startet, und so den Client kapern. Die Option \u201eFirst-Pipe-Instance\u201c hilft, die Neuanlage einer bereits existierenden Pipe zu verhindern, ersetzt aber keine echten Zugriffskontrollen. Jede \u00fcber die Pipe empfangene Nachricht muss als nicht vertrauensw\u00fcrdige Eingabe behandelt werden. Ein authentifizierter Client kann fehlerhafte Payloads, ung\u00fcltige Pfade oder b\u00f6sartige Befehle senden. Ein privilegierter Dienst, der diese Eingaben direkt in Datei- oder Registry-Operationen umwandelt, wird zum \u201eConfused Deputy\u201c (verwirrter Helfer): Der Angreifer liefert die Anweisung, der Dienst die Privilegien.<\/p>\n

Verf\u00fcgbarkeit und Remote-Zugriff<\/h2>\n

Die Risiken beschr\u00e4nken sich nicht auf Privilegieneskalation und unbefugte Befehle. Ein b\u00f6sartiger oder fehlerhafter Prozess kann sich st\u00e4ndig verbinden, Verbindungen offenhalten oder teure Operationen ausl\u00f6sen, was zu einem Denial-of-Service f\u00fchrt. Der Server sollte daher Begrenzungen f\u00fcr gleichzeitige Verbindungen, Timeouts und Nachrichtengr\u00f6\u00dfen einf\u00fchren. Zudem wird oft f\u00e4lschlicherweise angenommen, dass Named Pipes nur lokal erreichbar sind. Windows unterst\u00fctzt jedoch auch Remote-Zugriff auf Named Pipes. F\u00fcr rein lokale Kommunikation sollte die Pipe explizit so konfiguriert werden, dass sie Remote-Clients oder Netzwerkidentit\u00e4ten (wie NT AUTHORITY\\NETWORK<\/code>code) abweist.<\/p>\n

Wenn eine Named Pipe zur Sicherheitsgrenze wird<\/h2>\n

Eine Named Pipe wird dann zu einer Sicherheitsgrenze, wenn die Prozesse an ihren Enden unterschiedliche Privilegien oder Vertrauensstufen haben. Ein typisches Beispiel ist ein LocalSystem-Dienst, der mit einer Standard-Benutzeranwendung kommuniziert. Der Dienst kann gesch\u00fctzte Dateien \u00e4ndern, Prozesse starten und auf die Daten anderer Benutzer zugreifen. Die Desktop-Anwendung kann dies normalerweise nicht. Wenn der Dienst Befehle \u00fcber eine Named Pipe akzeptiert, wird diese Pipe zur Schnittstelle f\u00fcr diese privilegierten F\u00e4higkeiten. Jede Schwachstelle in den Berechtigungen, Identit\u00e4tspr\u00fcfungen oder der Befehlsvalidierung erm\u00f6glicht es einem nicht vertrauensw\u00fcrdigen lokalen Prozess, die Privilegien des Dienstes zu missbrauchen. Der Server muss die Sicherheitsidentit\u00e4t hinter der Verbindung validieren und nicht nur den Prozessnamen oder den geheimen Pipe-Namen \u00fcberpr\u00fcfen.<\/p>\n

Eine Anfrage wie Datei lesen: C:\\ProgramData\\Product\\status.json<\/code>code wird gef\u00e4hrlich, wenn der Client den Pfad auf C:\\Windows\\System32\\config\\SAM<\/code>code \u00e4ndern kann. Ein sicherer Server muss daher eine Reihe von Pr\u00fcfungen durchf\u00fchren: Verifikation der Windows-Identit\u00e4t des Clients, eine restriktive Zugriffsliste (DACL) f\u00fcr die Pipe, unabh\u00e4ngige Autorisierung jedes Befehls und Validierung aller Pfade. Der Grundsatz lautet: Der Pipe-Server darf eine Operation niemals nur ausf\u00fchren, weil ein Client sie angefordert hat. Er darf sie erst ausf\u00fchren, nachdem er best\u00e4tigt hat, wer sie anfordert, ob diese Identit\u00e4t autorisiert ist und ob die Anfrage innerhalb der Sicherheitsgrenzen bleibt.<\/p>\n

Praktische Ma\u00dfnahmen zur Zugriffskontrolle<\/h3>\n

Der Server sollte bereits vor der Verarbeitung von Nachrichten bestimmen, wer eine Verbindung aufbauen darf. Die DACL der Pipe kontrolliert den Zugriff auf beide Enden. Eine Standard-DACL ist riskant, da ihre Berechtigungen oft zu weit gefasst sind. F\u00fcr die lokale Kommunikation zwischen Anwendungen k\u00f6nnen beide Seiten den Prozess am anderen Ende der Pipe \u00fcberpr\u00fcfen: Der Server kann GetNamedPipeClientProcessId<\/code>code aufrufen, der Client GetNamedPipeServerProcessId<\/code>code. Eine starke Implementierung kombiniert mehrere Kontrollen: eine explizite DACL, die Verifikation der Windows-Identit\u00e4t (SID), die Autorisierung f\u00fcr jeden Befehl und die Validierung der Nachrichteninhalte. Die Verbindung sollte abgelehnt werden, wenn die Identit\u00e4tspr\u00fcfung fehlschl\u00e4gt.<\/p>\n

Impersonation sorgf\u00e4ltig einsetzen<\/h3>\n

Named-Pipe-Impersonation erlaubt es dem Server, vor\u00fcbergehend im Sicherheitskontext des Clients zu arbeiten. Windows pr\u00fcft dann den Ressourcenzugriff mit dem Token des Clients, nicht mit dem des Dienstkontos. In .NET bietet NamedPipeServerStream.RunAsClient<\/code>code eine kontrollierte Methode. Dies ist n\u00fctzlich, wenn der Client eine Operation nur dann ausf\u00fchren k\u00f6nnen soll, wenn sein Konto bereits die Berechtigung daf\u00fcr hat. Impersonation ersetzt jedoch nicht die Autorisierung. Ein Dienst sollte beispielsweise nicht ohne weiteres zwischen der Client- und der Dienst-Identit\u00e4t wechseln. Der sicherere Ansatz besteht darin, die Operation in klar definierte Phasen zu unterteilen: Authentifizierung und Autorisierung des Clients, Validierung aller Daten, Impersonation nur f\u00fcr die tats\u00e4chliche Client-Operation und dann die R\u00fcckkehr zur eigenen Identit\u00e4t f\u00fcr die restliche Arbeit. Fehler bei der Impersonation m\u00fcssen dazu f\u00fchren, dass die Anfrage abgelehnt wird, da der Vorgang sonst f\u00e4lschlicherweise mit den Service-Privilegien ausgef\u00fchrt w\u00fcrde.<\/p>\n

Pipe-Nachrichten als nicht vertrauensw\u00fcrdige Eingabe<\/h3>\n

Selbst die Verifikation des verbundenen Prozesses macht die Nachrichten nicht sicher. Die legitime Anwendung k\u00f6nnte kompromittiert sein oder benutzergesteuerte Daten an die Pipe senden. Jede Nachricht muss struktur- und inhaltsseitig validiert werden. Ein gef\u00e4hrliches Szenario ist das direkte Deserialisieren einer Anfrage: Ein Angreifer k\u00f6nnte so den Dienst anweisen, Dateien au\u00dferhalb des Anwendungsverzeichnisses zu \u00fcberschreiben. Der sicherere Ansatz ist, nur eng definierte Befehle und keine allgemeinen Funktionen wie WriteFile(path, content)<\/code>code zu exponieren. Das Protokoll sollte eine explizite Rahmung (z. B. einen Header mit Nachrichtenl\u00e4nge) und strenge Gr\u00f6\u00dfenbeschr\u00e4nkungen aufweisen. Alle Werte wie Pfade m\u00fcssen gegen eine Whitelist gepr\u00fcft und normalisiert werden, um Path-Traversal-Angriffe zu verhindern.<\/p>\n

Denial-of-Service und Fernzugriff vermeiden<\/h2>\n

Ein Named-Pipe-Endpunkt kann vor unbefugten Befehlen gesch\u00fctzt sein und dennoch anf\u00e4llig f\u00fcr DoS-Angriffe sein. Ein Angreifer kann Verbindungen blockieren, indem er alle verf\u00fcgbaren Instanzen belegt oder extrem langsam Daten sendet. Ein defensiver Server muss daher Begrenzungen f\u00fcr gleichzeitige Verbindungen, Nachrichtengr\u00f6\u00dfen und die maximale Dauer einer Anfrage einf\u00fchren. Blockierende Operationen sollten abbrechbar sein. Zudem muss die M\u00f6glichkeit des Remote-Zugriffs ausgeschlossen werden. Die native Windows-Funktion PIPE_REJECT_REMOTE_CLIENTS<\/code>code lehnt Remote-Verbindungen automatisch ab. Alternativ kann die DACL der Pipe den Zugriff f\u00fcr die NT AUTHORITY\\NETWORK<\/code>code-Identit\u00e4t verweigern. Eine Kombination beider Ma\u00dfnahmen ist empfehlenswert.<\/p>\n

Eine sichere Named-Pipe-Architektur entwerfen<\/h2>\n

Ein sicheres Design minimiert die Anzahl exponierter Operationen und die Menge an privilegiertem Code, der direkt mit Client-Daten arbeitet. Die Pipe sollte eine schmale Kommunikationsgrenze sein, keine generische Schnittstelle zum Betriebssystem. Das Protokoll sollte Gesch\u00e4ftsvorg\u00e4nge (z. B. \u201ePolicy aktualisieren\u201c) statt Betriebssystem-Primitive (z. B. \u201eDatei schreiben\u201c) exponieren. Zugriff auf die Pipe und die Erlaubnis zur Ausf\u00fchrung eines Befehls m\u00fcssen getrennt sein. F\u00fcr besonders sensible Operationen k\u00f6nnen separate Named Pipes mit jeweils eigenen Zugriffsregeln verwendet werden. Die Komponente, die die Pipe-Nachrichten liest, sollte so wenig privilegierte Arbeit wie m\u00f6glich verrichten. Sie sollte nur validierte, stark typisierte Anweisungen an eine separate, privilegierte Ausf\u00fchrungsschicht weitergeben. Jede Verbindung sollte einen klaren, begrenzten Lebenszyklus haben: Verbindung annehmen, identifizieren, validieren, autorisieren, ausf\u00fchren und trennen. Der Server sollte autoritativ sein und die Art und Weise der Ausf\u00fchrung einer Aktion selbst bestimmen, anstatt sie dem Client zu \u00fcberlassen. Audit-Logs sollten alle sicherheitsrelevanten Ereignisse aufzeichnen.<\/p>\n

Checkliste f\u00fcr sichere Named Pipes<\/h2>\n

Vor der Implementierung sollten Sie die folgenden Punkte pr\u00fcfen: Definieren Sie die Vertrauensgrenze und behandeln Sie die Pipe als exponierte Schnittstelle. Verwenden Sie eine restriktive DACL. Schlie\u00dfen Sie Remote-Clients aus. \u00dcberpr\u00fcfen Sie beide Endpunkte (Windows-Identit\u00e4t, ggf. Prozess-ID und Signatur). Vertrauen Sie dem Pipe-Namen nicht. Autorisieren Sie jeden Befehl einzeln. Halten Sie das Protokoll eng und exposieren Sie anwendungsspezifische Aktionen. Behandeln Sie alle Nachrichten als nicht vertrauensw\u00fcrdig. Wenden Sie Gr\u00f6\u00dfen- und Zeitlimits fr\u00fchzeitig an. Nutzen Sie Impersonation nur gezielt und in kleinem Umfang. Isolieren Sie die privilegierte Ausf\u00fchrung. Kontrollieren Sie die Ressourcennutzung. Geben Sie kontrollierte Fehlermeldungen zur\u00fcck. F\u00fchren Sie Sicherheitsaudits durch. Scheitern Sie immer sicher (Fail Closed), wenn eine Pr\u00fcfung nicht bestanden wird.<\/p>\n

Eine sichere Named-Pipe-Implementierung st\u00fctzt sich nicht auf eine einzelne Schutzma\u00dfnahme, sondern auf eine Kombination aus restriktiver Zugriffskontrolle, Endpunktverifikation, operationsspezifischer Autorisierung, strenger Eingabevalidierung, begrenztem Ressourcenverbrauch und eng gefasster privilegierter Funktionalit\u00e4t. Dieser mehrschichtige Ansatz ist der einzige Weg, um Named Pipes sicher im Rahmen einer ansonsten anf\u00e4lligen lokalen Infrastruktur einzusetzen.<\/p>\n","protected":false},"excerpt":{"rendered":"

Named Pipes sind unter Windows-Entwicklern ein beliebtes Mittel f\u00fcr die Interprozesskommunikation (IPC) zwischen Anwendungen auf demselben Rechner. Sie sind schnell, tief im Betriebssystem verankert und eignen sich hervorragend f\u00fcr den Datenaustausch zwischen Windows-Diensten, Desktop-Anwendungen, Tray-Prozessen und Hintergrund-Agents. Die landl\u00e4ufige Annahme, dass diese Kommunikation aufgrund der Lokalit\u00e4t vertrauensw\u00fcrdig sei, ist jedoch ein gef\u00e4hrlicher Trugschluss. In der […]<\/p>\n","protected":false},"author":5,"featured_media":53803,"comment_status":"closed","ping_status":"","sticky":false,"template":"","format":"standard","meta":{"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/de\/49681.png","fifu_image_alt":"Named Pipes unter Windows \u00f6ffnen Sicherheitsl\u00fccken f\u00fcr lokale Angriffe","footnotes":""},"categories":[6671],"tags":[],"class_list":["post-49681","post","type-post","status-publish","format-standard","has-post-thumbnail","category-scherheit"],"fifu_image_url":"https:\/\/cards.overcentral.com\/cards\/de\/49681.png","fifu_image_alt":"Named Pipes unter Windows \u00f6ffnen Sicherheitsl\u00fccken f\u00fcr lokale Angriffe","_links":{"self":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/49681","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/users\/5"}],"replies":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/comments?post=49681"}],"version-history":[{"count":2,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/49681\/revisions"}],"predecessor-version":[{"id":49683,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/posts\/49681\/revisions\/49683"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media\/53803"}],"wp:attachment":[{"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/media?parent=49681"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/categories?post=49681"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/overcentral.com\/de\/wp-json\/wp\/v2\/tags?post=49681"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}