Segreti cPassword GPO SYSVOL Active Directory: perché una patch del 2014 non ha risolto il problema

Segreti cPassword GPO SYSVOL Active Directory: cosa sono

I segreti cPassword GPO SYSVOL Active Directory sono tra le configurazioni errate più vecchie che si rifiutano di scomparire — e una delle configurazioni errate di Active Directory più comuni ancora rilevate oggi negli audit in produzione. Provengono dalle Group Policy Preferences (GPP), una funzionalità aggiunta da Microsoft in Windows Server 2008 che permetteva agli amministratori di distribuire tramite Criteri di gruppo account utente locali, unità mappate, attività pianificate, servizi e origini dati — inclusi, per diversi di questi tipi di preferenza, un nome utente e una password da applicare sulle macchine di destinazione.

Queste credenziali venivano memorizzate nell'attributo cpassword del file XML della preferenza (Groups.xml, Services.xml, ScheduledTasks.xml, Printers.xml, Drives.xml, DataSources.xml), cifrate con AES-256, e scritte nella condivisione SYSVOL del dominio — la stessa condivisione replicata da ogni controller di dominio e leggibile da ogni utente autenticato (e, per impostazione predefinita, dagli utenti di qualsiasi dominio trusted) affinché i client possano recuperare i propri Group Policy Object (GPO).

Il problema: Microsoft ha pubblicato nella propria documentazione di protocollo la chiave AES privata usata per cifrare ogni valore cpassword, perché le GPP avevano bisogno di un modo per decifrare il valore lato client durante l'elaborazione dei criteri. Qualsiasi utente di dominio autenticato in grado di leggere SYSVOL — cioè, per progettazione, tutti — può trovare la stringa cifrata e decifrarla in pochi secondi con strumenti pubblicamente disponibili. L'esposizione è stata documentata pubblicamente per la prima volta nel 2012 dal ricercatore di sicurezza Chris Campbell (obscuresec), che ha rilasciato una proof-of-concept PowerShell per individuare e decifrare questi valori molto prima che Microsoft rilasciasse una correzione.

Perché questo problema riappare ancora a distanza di un decennio

Se MS14-025 è stata rilasciata nel 2014, perché gli audit trovano ancora oggi voci cpassword attive? Alcuni schemi ricorrenti lo spiegano:

• Migrazioni di dominio e acquisizioni. Le GPO vengono spesso migrate in blocco da un dominio legacy, comprese tutte le preferenze configurate prima che l'ambiente acquisito fosse mai corretto o revisionato.
• Backup di GPO ripristinati. I backup di GPO effettuati prima del 2014 e ripristinati anni dopo reintroducono esattamente l'XML che la patch avrebbe dovuto impedire in futuro — la patch protegge l'editor, non un'operazione di ripristino.
• Ambienti gestiti da MSP e fornitori. Un fornitore di servizi gestiti che riutilizza un modello GPO standard su più clienti può propagare la stessa credenziale di amministratore locale esposta a tutti gli ambienti toccati da quel modello.
• Mancanza di revisione periodica di SYSVOL. A differenza di un servizio attivo, il contenuto di SYSVOL non scade e non viene segnalato dal patching di routine — nulla forza una nuova scansione a meno che qualcuno non la avvii deliberatamente.

Nessuno di questi percorsi richiede che un sistema mal configurato abbia saltato la patch del 2014. Richiedono solo che un valore cpassword sia esistito a un certo punto in SYSVOL nel corso della storia del dominio e non sia mai stato ricercato e rimosso attivamente — esattamente per questo la scansione proattiva, e non la conformità alle patch, è il controllo che chiude davvero questa lacuna.

Come funziona

Microsoft ha affrontato parte di questo problema con MS14-025 (CVE-2014-1812), pubblicata il 13 maggio 2014, e distribuita come aggiornamento KB2962486. La patch ha rimosso i campi "Password" dall'editor delle Group Policy Preferences nella console di gestione dei criteri di gruppo (GPMC) e nelle Remote Server Administration Tools (RSAT), in modo che gli amministratori non possano più creare nuove voci GPP contenenti una password (Microsoft Support: MS14-025).

Ciò che KB2962486 non fa è rimuovere retroattivamente i valori cpassword già scritti in SYSVOL prima dell'installazione della patch, e non impedisce nemmeno a un attaccante di decifrare ciò che vi si trova ancora. La guida ANSSI sull'amministrazione sicura di AD segnala esattamente questa lacuna: la patch cambia ciò che l'editor permette a un amministratore di digitare d'ora in poi, ma gli oggetti GPP storici creati prima dell'installazione della patch devono essere individuati e ripuliti manualmente (ANSSI-PA-099).

La chiave AES in sé non è un segreto che l'attaccante debba rubare: è la stessa chiave statica a 32 byte per ogni dominio Active Directory sulla Terra, documentata da Microsoft e ripresa nella ricerca sulla sicurezza fin da quella divulgazione originale del 2012, e successivamente integrata direttamente in strumenti offensivi come PowerSploit e CrackMapExec (adsecurity.org: Finding Passwords in SYSVOL & Exploiting Group Policy Preferences).

La catena di attacco

Sfruttare un cpassword dimenticato non richiede accesso elevato né alcun exploit — è una tecnica post-autenticazione disponibile per qualsiasi utente di dominio, e spesso anche per qualsiasi utente di una foresta trusted.

Passo 1 — Enumerare SYSVOL alla ricerca di cpassword

Un attaccante con una qualsiasi credenziale di dominio valida (o un punto d'appoggio a basso privilegio) cerca nella condivisione SYSVOL i file XML contenenti l'attributo cpassword:

# Linux, con credenziali di dominio valide
crackmapexec smb <dc-ip> -u 'user' -p 'password' -M gpp_password

# Windows, PowerSploit
Import-Module .\Get-GPPPassword.ps1
Get-GPPPassword -Verbose

Passo 2 — Decifrare con la chiave AES pubblicata

Get-GPPPassword e strumenti equivalenti (Get-DecryptedCpassword, gpp-decrypt) applicano la chiave AES pubblicamente nota al valore cpassword decodificato in Base64 e restituiscono il testo in chiaro istantaneamente — non c'è forza bruta né alcuna fase di cracking, solo una routine di decifratura fissa.

Passo 3 — Riutilizzare la credenziale

Poiché le GPP venivano spesso usate per standardizzare un account amministratore locale su molte macchine, o per eseguire un'attività pianificata o un servizio con un account di servizio di dominio, la password recuperata è spesso direttamente riutilizzabile per il movimento laterale o l'escalation dei privilegi, senza bisogno di alcuna tecnica aggiuntiva. Una singola voce in Groups.xml che impostava una password di amministratore locale comune a livello di dominio è sufficiente a compromettere ogni workstation toccata da quella GPO.

Rilevamento

Per confermare direttamente l'esposizione invece di attendere segnali dai log, la guida ANSSI sull'amministrazione sicura di AD (ANSSI-PA-099) fornisce un controllo proattivo di una riga che gli auditor possono eseguire da un sistema unito al dominio:

:: Sostituire <FQDN> con il nome di dominio completo del dominio AD.
findstr /S /I cpassword \\<FQDN>\sysvol\<FQDN>\policies\*.xml

Qualsiasi corrispondenza significa che un valore cpassword — strumento corretto o meno — si trova ancora oggi in SYSVOL (ANSSI-PA-099, Raccomandazione R31, Listato 3). Poiché questo controllo legge contenuto statico dei file anziché telemetria live, è il modo più rapido per un auditor di ottenere una risposta definitiva senza attendere la conservazione dei log. Lo stesso principio si applica ad altre fughe di credenziali persistenti da verificare nello stesso passaggio, come le password lasciate nei campi descrizione di AD. Per una panoramica più ampia su cosa dare priorità in una revisione completa, consulta la nostra guida su come effettuare l'audit della sicurezza di Active Directory.

Correzione

1. Verifica che KB2962486 sia distribuita su ogni sistema ancora usato per modificare i criteri di gruppo tramite la console nativa GPMC/MMC (versioni precedenti a Windows Server 2016) o tramite strumenti RSAT più vecchi (versioni precedenti a Windows 10). Questo impedisce solo l'inserimento di nuove password nelle GPP d'ora in poi.
2. Esegui la scansione di SYSVOL (comando findstr sopra, o una ricerca ricorsiva equivalente) ed elenca ogni file Groups.xml, Services.xml, ScheduledTasks.xml, Printers.xml, Drives.xml e DataSources.xml di ogni GPO alla ricerca di un attributo cpassword — incluse le GPO disabilitate e non collegate, spesso trascurate durante le revisioni manuali.
3. Ruota immediatamente ogni credenziale trovata. Eliminare la voce XML non invalida una password già decifrabile; assumi che sia stata letta e agisci di conseguenza.
4. Rimuovi l'impostazione GPP invece di lasciare un campo password vuoto — secondo la raccomandazione R32 dell'ANSSI, nessuna password dovrebbe mai più essere registrata in una preferenza di criteri di gruppo (ANSSI-PA-099, Raccomandazione R32, p.49). La nostra guida pratica alle raccomandazioni AD dell'ANSSI spiega come trasformare una raccomandazione come questa in un piano di implementazione.
5. Sostituisci gli account amministratore locale gestiti da GPP con Windows LAPS, che ruota una password unica e casuale per macchina e la memorizza come attributo protetto di AD invece che in un file XML statico.
6. Estendi lo stesso controllo agli script di logon/logoff memorizzati su SYSVOL o NETLOGON — la raccomandazione R31 dell'ANSSI applica lo stesso principio del segreto riutilizzabile a qualsiasi script leggibile da account con privilegi inferiori, non solo all'XML delle GPP. Uno script che mappa un'unità con una password di account di servizio incorporata è esposto esattamente quanto un campo cpassword.
7. Irrobustisci l'accesso in lettura dove possibile. SYSVOL e NETLOGON devono restare leggibili per l'elaborazione dei criteri, ma verifica le deviazioni dei permessi SYSVOL/NETLOGON oltre l'impostazione predefinita, e abilita l'hardening UNC su queste condivisioni affinché i client convalidino l'integrità e l'autenticazione reciproca durante la lettura.
8. Riesegui la scansione dopo ogni ripristino di backup GPO o migrazione di dominio, non solo una volta. Poiché questi sono i due modi più comuni in cui riappaiono le vecchie voci cpassword, rendi la ri-scansione di SYSVOL un passaggio permanente di qualsiasi runbook di migrazione anziché una pulizia una tantum, e assegnane la responsabilità in modo che non dipenda dalla memoria di qualcuno.

Come EtcSec rileva questo problema

L'audit Active Directory di EtcSec segnala questa esposizione come GPO_PASSWORD_IN_SYSVOL, un controllo di severità critica che analizza l'XML delle preferenze di ogni GPO alla ricerca di un attributo cpassword valorizzato — incluse le GPO disabilitate o non collegate, che le revisioni manuali spesso non rilevano. È abbinato a SYSVOL_NETLOGON_PERMISSIONS, che esamina i permessi di lettura/scrittura sulle condivisioni SYSVOL e NETLOGON alla ricerca di deviazioni rispetto alla baseline attesa. Insieme, i due controlli coprono sia l'esposizione GPP storica sia l'igiene dei permessi continua necessaria per evitare che SYSVOL torni a diventare una discarica di segreti riutilizzabili.