Password in chiaro e crittografia reversibile Active Directory: la trappola dell'attributo userPassword spiegata

Il problema della password in chiaro e crittografia reversibile Active Directory

Password in chiaro e crittografia reversibile Active Directory: questa esposizione è una delle poche configurazioni errate che saltano completamente il consueto percorso di un attaccante — nessun hash da craccare, nessun ticket da inoltrare, solo una password letterale seduta nella directory, a differenza di un hash NT rubato e riutilizzato tramite Pass-the-Hash. Active Directory è progettato per non memorizzare mai una copia utilizzabile di una password: ogni valore unicodePwd viene sottoposto a hashing monodirezionale (hash NT e chiavi Kerberos a lungo termine) prima di raggiungere il database, e l'attributo stesso non può essere riletto tramite LDAP. La documentazione del protocollo MS-SAMR di Microsoft è esplicita sull'unico caso che rompe questa garanzia: la memorizzazione della password in chiaro per un oggetto viene configurata solo quando il valore Effective-PasswordReversibleEncryptionEnabled dell'account è impostato, oppure quando il suo attributo userAccountControl contiene il bit ENCRYPTED_TEXT_PWD_ALLOWED (0x0080) — dopodiché la successiva impostazione o modifica della password scrive una copia decifrabile in supplementalCredentials.

Questo articolo copre due modalità di guasto distinte, a livello di attributo, che terminano entrambe con un attaccante in possesso di una credenziale in chiaro utilizzabile direttamente dalla directory:

• L'attributo LDAP legacy userPassword, che alcuni ambienti popolano direttamente con una stringa letterale.
• Il flag di crittografia reversibile su userAccountControl, che indica a ogni controller di dominio di conservare una copia decifrabile della password accanto agli hash abituali.

Entrambi sono classificati come Critici nel catalogo di audit di etc-collector (PASSWORD_CLEARTEXT_STORAGE, REVERSIBLE_ENCRYPTION) perché compromettere uno dei due dà a un attaccante la password letterale, non solo un hash da craccare o inoltrare. Questa distinzione conta a livello operativo: un hash craccato o una sessione inoltrata possono essere contenuti ruotando una credenziale e rivedendo cosa ha toccato, ma una password in chiaro recuperata viene spesso riutilizzata altrove — account personali, altri sistemi, altri domini — quindi il raggio d'impatto di entrambe le esposizioni si estende ben oltre l'oggetto AD in cui è stata trovata.

Come funziona

L'attributo userPassword

userPassword è un attributo LDAP standard (definito al di fuori dello schema Microsoft, negli standard di directory derivati dalla RFC 4519) che Active Directory riconosce anche in determinate condizioni. Secondo MS-ADTS §3.1.1.3.1.5.2, AD consente ai client di scrivere e usare userPassword per impostare la password di un account solo quando:

• il DC funziona come AD LDS, oppure
• il DC è AD DS, il livello funzionale del dominio è Windows Server 2003 o superiore, e
• l'euristica fUserPwdSupport nell'attributo dSHeuristics è abilitata.

Quando questa euristica è disabilitata (il default per AD DS), userPassword è semplicemente un attributo ordinario, non indicizzato, senza semantica particolare — il che è esattamente la trappola: molti amministratori e script di provisioning (strumenti di migrazione LDAP, job di sincronizzazione HR, integrazioni Unix/LDAP legacy) scrivono ancora una stringa di password letterale in userPassword per abitudine o per esigenze di interoperabilità. A differenza di unicodePwd, questo attributo è leggibile da chiunque disponga di diritti di lettura generica sull'oggetto, quindi una semplice ricerca LDAP (userPassword=*) può estrarre ogni valore in chiaro mai scritto lì — nessuna escalation di privilegi richiesta, nessun cracking di hash, niente da inoltrare.

ldapsearch -x -H ldap://dc01.corp.local -D "[email protected]" -W \
  -b "DC=corp,DC=local" "(userPassword=*)" sAMAccountName userPassword

Il flag UAC di crittografia reversibile

Il secondo meccanismo è il bit ENCRYPTED_TEXT_PWD_ALLOWED (decimale 128 / hex 0x0080) all'interno di userAccountControl, esposto sull'oggetto utente come l'attributo ms-DS-User-Encrypted-Text-Password-Allowed e, nel modulo PowerShell di AD, come la proprietà account AllowReversiblePasswordEncryption. Impostarlo non scrive di per sé una password in chiaro — cambia ciò che accade alla prossima impostazione o modifica della password: AD memorizza la nuova password in supplementalCredentials in una forma decifrabile con la chiave di crittografia stessa del dominio, oltre agli hash abituali.

Questo flag esiste per supportare protocolli di autenticazione legacy che necessitano della password reale per calcolare un challenge-response, più comunemente CHAP per RADIUS/IAS dial-up e VPN, e i vecchi deployment IIS Digest Authentication. La documentazione Microsoft sulla policy di sicurezza è diretta sul compromesso: abilitarlo «equivale essenzialmente a memorizzare versioni in chiaro delle password», e non dovrebbe mai essere attivato a livello di dominio a meno che un'applicazione non ne abbia davvero bisogno.

Se un dominio necessita di questo per un piccolo insieme di account di servizio legacy, limitarne l'ambito conta: una Fine-Grained Password Policy (Password Settings Object) può impostare msDS-PasswordReversibleEncryptionEnabled solo sull'OU o sul gruppo che ne ha bisogno, invece di attivare l'impostazione «Archivia password mediante crittografia reversibile» nella Default Domain Policy per tutti gli account del dominio.

🚨 Pericolo: MITRE ATT&CK T1556.005 documenta questo come una tecnica avversaria attiva, non solo come una configurazione errata legacy: con diritti sufficienti, un attaccante può eseguire Set-ADUser -AllowReversiblePasswordEncryption $true contro un account target, attendere (o forzare) un reset della password, e poi recuperare la password in chiaro dalla successiva credenziale memorizzata dell'account — trasformando un semplice diritto di scrittura in una backdoor permanente di raccolta credenziali che sopravvive alla rotazione delle password.

Perché questo appare ancora negli ambienti moderni

Nessuno dei due meccanismi è una reliquia che colpisce solo i domini dell'era Windows 2000. userPassword riappare ogni volta che un'organizzazione esegue strumenti di sincronizzazione delle identità originariamente costruiti per OpenLDAP o un'altra directory RFC-4519 e puntati verso Active Directory senza adattamenti — il job di sincronizzazione scrive il campo per cui è stato costruito, e nulla in AD lo impedisce se dSHeuristics lo consente. La crittografia reversibile riappare allo stesso modo: un apparato RADIUS, un concentratore VPN legacy, o una vecchia applicazione intranet che usa IIS Digest Authentication viene configurato una volta, la policy a livello di dominio viene attivata per farlo funzionare, e l'impostazione sopravvive tranquillamente all'applicazione che ne aveva bisogno — spesso per anni, su tutti gli account del dominio, molto tempo dopo che chiunque ricordi perché è lì.

Entrambi i casi condividono la stessa causa radice: l'impostazione è un interruttore a livello di dominio o di oggetto, ma la reale necessità è quasi sempre ristretta — un'applicazione, un'integrazione, un protocollo legacy. Nulla obbliga a una revisione quando la dipendenza scompare, quindi l'esposizione persiste come puro debito tecnico finché un audit, o un attaccante, non la trova. Merita un posto nella stessa watchlist delle configurazioni di sicurezza errate di Active Directory più comuni che sopravvivono anni oltre la loro giustificazione originale.

Rilevamento

# Account con crittografia reversibile attualmente abilitata
Get-ADUser -Filter {AllowReversiblePasswordEncryption -eq $true} `
  -Properties AllowReversiblePasswordEncryption, PasswordLastSet |
  Select-Object SamAccountName, PasswordLastSet

# Filtro LDAP bitwise-AND equivalente (matching-rule OID 1.2.840.113556.1.4.803)
Get-ADUser -LDAPFilter "(userAccountControl:1.2.840.113556.1.4.803:=128)" `
  -Properties userAccountControl | Select-Object SamAccountName

Per userPassword, trattandosi di un attributo generico che AD non indicizza né protegge in modo speciale per impostazione predefinita, una scansione LDAP pianificata per (userPassword=*) sull'intero dominio è l'unico modo affidabile per rilevarlo; non esiste un evento di sicurezza dedicato per la scrittura su questo attributo, quindi le rivalutazioni periodiche contano quanto la scansione iniziale.

Bonifica

1. Effettua un audit prima di toccare qualsiasi cosa. Esegui entrambe le query precedenti sull'intero dominio e registra ogni riscontro — disattivare il flag o svuotare userPassword forza un cambio password per quell'account, quindi pianifica la rotazione con i proprietari degli account in anticipo.
2. Disabilita la crittografia reversibile a livello di dominio tramite Criteri di gruppo (Configurazione computer > Criteri > Impostazioni di Windows > Impostazioni di sicurezza > Criteri account > Criteri password > «Archivia password mediante crittografia reversibile» = Disabilitato), a meno che non esista una dipendenza CHAP/RADIUS o IIS Digest Authentication legacy specifica.
3. Se esiste una dipendenza legittima, limitala con una Fine-Grained Password Policy (msDS-PasswordReversibleEncryptionEnabled) applicata solo all'OU o al gruppo che esegue quell'applicazione — mai a livello di dominio.
4. Svuota qualsiasi valore userPassword trovato, e riporta fUserPwdSupport a disabilitato in dSHeuristics a meno che il DC non esegua intenzionalmente AD LDS o un'integrazione documentata ne abbia bisogno.
5. Forza un reset della password per ogni account interessato. Disabilitare il flag o svuotare l'attributo non rimuove retroattivamente il materiale di credenziale già scritto in supplementalCredentials — solo il successivo cambio password lo fa.
6. Blocca l'accesso in scrittura a userAccountControl e userPassword per gli utenti standard; entrambi dovrebbero essere modificabili solo dall'amministrazione delle identità tier-0, e qualsiasi concessione GenericAll/GenericWrite che li raggiunge merita lo stesso livello di controllo di un percorso verso Domain Admin.
7. Collega l'Event ID 4738 al tuo SIEM con un alert quando Encrypted Text Password Allowed appare nell'elenco degli attributi modificati, limitato come minimo agli account privilegiati e di servizio, e ripeti le scansioni LDAP secondo una pianificazione ricorrente invece di trattare questo come una pulizia una tantum.
8. Documenta qualsiasi eccezione residua. Se un'applicazione legacy ha davvero ancora bisogno della crittografia reversibile, registra il proprietario, la data di revisione e il piano di dismissione — un'eccezione non documentata è indistinguibile da un'eccezione passata inosservata al successivo audit.

Come EtcSec rileva questo problema

Il catalogo di audit di EtcSec traccia entrambi i meccanismi come controlli distinti di severità Critica: PASSWORD_CLEARTEXT_STORAGE segnala qualsiasi oggetto in cui userPassword ha un valore, e REVERSIBLE_ENCRYPTION segnala qualsiasi account con AllowReversiblePasswordEncryption (il bit UAC ENCRYPTED_TEXT_PWD_ALLOWED) abilitato. Entrambi si trovano nella categoria Password accanto a controlli correlati come la conformità delle policy password e i segreti cPassword di GPO SYSVOL — insieme coprono la manciata di modi in cui una directory può finire per detenere una password che un attaccante non ha nemmeno bisogno di craccare.