I named pipe sono spesso considerati sicuri per la comunicazione tra applicazioni Windows locali, ma questa fiducia può essere pericolosa. Solo controlli di accesso rigorosi, verifica dell'identità e validazione dei dati possono prevenire attacchi e abusi di privilegi.
I named pipe rappresentano una soluzione rapida e integrata per la comunicazione tra applicazioni su Windows, utilizzata da servizi, utility, processi in background e interfacce desktop. Tuttavia, la tendenza a considerarli affidabili solo perché locali espone a rischi: su una workstation Windows possono operare processi di utenti diversi, sessioni remote, software di terze parti e persino malware, tutti potenzialmente in grado di accedere a un pipe se conoscono il nome e dispongono dei permessi necessari.
Perché la comunicazione locale non è sempre sicura
Molti sviluppatori trattano i named pipe come canali privati, ma questa assunzione è errata. Un servizio privilegiato, ad esempio in esecuzione come LocalSystem, può esporre funzionalità critiche tramite un pipe, diventando un vero e proprio API locale ad alto rischio. Il solo fatto che un client riesca a connettersi non garantisce che sia l'applicazione prevista, né che l'utente sia autorizzato o che la richiesta sia sicura. È fondamentale identificare chi si connette, quali operazioni può eseguire e validare ogni dato ricevuto.
Controllo degli accessi e verifica dell'identità
Il rischio maggiore si verifica quando un servizio con privilegi elevati comunica con un'applicazione meno privilegiata. I permessi del pipe devono essere definiti in modo esplicito e limitati agli utenti strettamente necessari, evitando gruppi ampi come Everyone o Authenticated Users. L'autenticazione e l'autorizzazione devono essere distinte: un utente può avere diritto a leggere lo stato di un servizio, ma non a modificarne la configurazione o avviare processi. L'impersonificazione può aiutare, ma va gestita con attenzione, verificando sempre il successo dell'operazione e limitando la durata dell'impersonificazione.
Verifica reciproca e sicurezza dei comandi
Non solo il server deve verificare il client, ma anche il client deve assicurarsi di collegarsi al server legittimo. Un nome di pipe prevedibile non è una garanzia: un attaccante potrebbe creare un pipe con lo stesso nome prima dell'avvio del vero servizio. Inoltre, ogni messaggio ricevuto deve essere trattato come input non affidabile, anche da client autenticati, per evitare attacchi come payload malformati, percorsi di file pericolosi o comandi non supportati.
Disponibilità e rischio di esposizione remota
Oltre all'escalation di privilegi, i named pipe possono essere sfruttati per attacchi denial-of-service: processi malevoli possono saturare le connessioni, inviare messaggi incompleti o consumare risorse eccessive. È essenziale implementare limiti su connessioni simultanee, timeout, dimensioni dei messaggi e frequenza delle richieste. Inoltre, i pipe possono essere accessibili anche da remoto in alcune configurazioni: per garantire la comunicazione solo locale, bisogna bloccare identità di rete come NT AUTHORITY\NETWORK e usare opzioni che rifiutino connessioni remote.
Quando il named pipe diventa un confine di sicurezza
Il pipe rappresenta un vero confine di sicurezza quando collega processi con privilegi diversi, come un servizio LocalSystem e un'app desktop utente. Qualsiasi debolezza nei permessi, nei controlli di identità o nella validazione dei comandi può consentire a processi non affidabili di sfruttare i privilegi del servizio. Il server deve quindi validare l'identità Windows del client e autorizzare ogni operazione singolarmente, soprattutto quando vengono gestiti percorsi, argomenti o comandi controllati dal client.
Gestione degli accessi e autorizzazione dei client
Prima di processare messaggi, il server deve stabilire chi può connettersi, usando un security descriptor esplicito che limiti l'accesso solo alle identità necessarie. L'uso dei permessi di default è rischioso. L'autorizzazione deve essere applicata per ogni comando sensibile, non solo all'apertura della connessione. Windows offre API come GetNamedPipeClientProcessId e QueryFullProcessImageName per verificare il processo connesso, ma questi controlli devono essere considerati difese aggiuntive, non meccanismi principali, poiché possono essere aggirati.
Impersonificazione e operazioni privilegiate
Un server pipe spesso opera con più privilegi del client. L'impersonificazione permette di eseguire operazioni temporaneamente con il contesto di sicurezza del client, utile per accedere a risorse che il client potrebbe già gestire. Tuttavia, non sostituisce l'autorizzazione: il server deve sempre verificare che il comando sia consentito e limitare la durata dell'impersonificazione, tornando subito all'identità originale dopo l'operazione.
Trattare ogni messaggio come input non affidabile
La verifica del processo connesso non rende sicuri i messaggi: anche un'app legittima può essere compromessa o inviare dati pericolosi. Ogni messaggio deve essere validato nella struttura e nei valori, evitando comandi generici come WriteFile o StartProcess e preferendo richieste specifiche e controllate. Il protocollo deve prevedere framing esplicito, limiti di dimensione e validazione di ogni campo.
Protezione da denial-of-service e accesso remoto
Anche con comandi protetti, un endpoint pipe può essere vulnerabile a denial-of-service: connessioni ripetute, messaggi incompleti o richieste costose possono saturare risorse. Il server deve applicare limiti su connessioni, dimensioni, tempi e frequenza, rilasciando risorse in caso di superamento dei limiti. Inoltre, la sicurezza deve prevedere il rifiuto esplicito dei client remoti, usando opzioni come PIPE_REJECT_REMOTE_CLIENTS e negando accesso a NT AUTHORITY\NETWORK.
Architettura sicura per i named pipe
Un design sicuro riduce al minimo le operazioni esposte e il codice privilegiato che processa dati controllati dal client. Il protocollo deve essere ristretto, con richieste specifiche e autorizzazioni granulari. È consigliabile separare la gestione della connessione, la validazione e l'esecuzione privilegiata, magari usando pipe diversi per livelli di fiducia differenti. La verifica dell'identità deve combinare DACL restrittive, SID, PID, percorso eseguibile e, se possibile, firma digitale.
Audit e checklist di sicurezza
Un'architettura robusta deve registrare eventi rilevanti come connessioni rifiutate, controlli di identità falliti, comandi non autorizzati e richieste malformate, senza esporre dati sensibili nei log. Prima di esporre funzionalità tramite named pipe, è fondamentale seguire una checklist che includa: definizione del confine di fiducia, restrizione esplicita degli accessi, rifiuto dei client remoti, verifica di entrambe le estremità, autorizzazione per ogni comando, protocollo ristretto, validazione di tutti i messaggi, limiti applicati precocemente, uso attento dell'impersonificazione, isolamento dell'esecuzione privilegiata, controllo delle risorse, gestione sicura degli errori, audit degli eventi e policy fail-closed.
La sicurezza dei named pipe non si basa su una singola misura, ma su una combinazione di controlli di accesso restrittivi, verifica delle identità, autorizzazione per operazione, validazione rigorosa degli input e gestione delle risorse. Per approfondire come le vulnerabilità nei sistemi di comunicazione possano essere sfruttate, è utile consultare anche l'analisi sugli attacchi a MLflow pubblicata su QWERTYmag.
