Accesso LDAP anonimo dsHeuristics enumerazione Active Directory: come un unico attributo debole espone l'intero dominio

Accesso LDAP anonimo dsHeuristics enumerazione Active Directory spiegata

Accesso LDAP anonimo dsHeuristics enumerazione Active Directory — se questa frase vi ha portato qui, sospettate già ciò che questo articolo conferma: un solo carattere in un solo attributo riattiva silenziosamente le operazioni LDAP non autenticate su un'intera foresta Active Directory, e quasi nulla nel set di strumenti amministrativi standard segnalerà che è successo.

I controller di dominio Active Directory accettano connessioni LDAP non autenticate solo per due scopi ben precisi: negoziare il bind stesso e interrogare rootDSE (i dati di capacità e configurazione propri del server). Le indicazioni Microsoft sono esplicite su questo confine: «le operazioni LDAP (Lightweight Directory Access Protocol) anonime verso Active Directory, diverse dalle ricerche e dai bind su rootDSE, non sono consentite» sui controller di dominio Windows Server 2003 e versioni successive. Tutto ciò che va oltre — cercare nell'albero della directory stesso, leggere oggetti utente, gruppo o OU — richiede un client autenticato.

Questo comportamento predefinito è più recente di quanto la maggior parte degli amministratori presuma. I controller di dominio basati su Windows 2000 non supportano affatto questa restrizione: se presenti in una foresta basata su Windows Server 2003, semplicemente non applicano il blocco delle operazioni anonime. Il comportamento di blocco è stato introdotto con Windows Server 2003 ed è legato al livello funzionale del controller di dominio, non solo alla versione del sistema operativo. Ogni controller di dominio con livello funzionale inferiore a Windows Server 2003 consente per impostazione predefinita le operazioni anonime; ogni controller di dominio a quel livello o superiore le blocca per impostazione predefinita.

Il blocco è il comportamento predefinito. dsHeuristics è l'unico attributo in grado di disattivarlo silenziosamente — per l'intera foresta, su ogni controller di dominio, senza una singola casella di controllo nella GUI ad avvisare chicchessia che è accaduto.

Come funziona — l'attributo dsHeuristics

dsHeuristics è un attributo stringa Unicode memorizzato sull'oggetto CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration sotto il dominio radice della foresta. Ogni posizione di carattere nella stringa è un'euristica indipendente, e l'ordine è fisso — i caratteri possono essere omessi solo troncando la stringa dalla fine. Secondo la specifica del protocollo [MS-ADTS], per impostazione predefinita l'attributo non esiste affatto, e il valore predefinito di ogni carattere che potrebbe contenere è "0".

Il settimo carattere — fLDAPBlockAnonOps

Il settimo carattere è fLDAPBlockAnonOps: se impostato su "2", l'euristica di blocco delle operazioni anonime è FALSE, il che significa che le operazioni LDAP anonime sono consentite. Qualsiasi altro valore — o l'assenza stessa del carattere — mantiene il blocco attivo sui controller di dominio al livello funzionale Windows Server 2003 o superiore.

dSHeuristics: 0000002
              ^      ^
              caratteri 1-6 al valore predefinito (0)
                     carattere 7 = 2 -> operazioni LDAP anonime consentite

L'attributo non ha un pannello dedicato in Utenti e computer di Active Directory, nessuna impostazione di Criteri di gruppo e nessun banner di avviso da nessuna parte negli strumenti amministrativi predefiniti. Gli unici modi per vederlo sono ADSI Edit (adsiedit.msc) o ldp.exe, collegati al contesto di denominazione Configuration. Un ambiente può superare ogni voce di una checklist che guarda solo alle impostazioni GPO e avere comunque l'accesso LDAP anonimo completamente aperto, perché nulla nel set di strumenti standard mostra questo valore a meno che qualcuno non vada a cercarlo specificamente.

L'ottavo carattere — fAllowAnonNSPI

Un'euristica vicina, spesso trascurata, si trova un carattere più in là: la posizione 8, fAllowAnonNSPI, controlla se i chiamanti anonimi possono usare il metodo di bind RPC NSPI — il protocollo dietro la rubrica di Outlook/Exchange. È una superficie di accesso anonimo separata, non direttamente correlata a LDAP, ma vale la pena controllarla nello stesso passaggio poiché vive nello stesso attributo e nello stesso punto cieco.

Non è la stessa cosa di RestrictAnonymous

Vale anche la pena distinguere questo da un controllo che la maggior parte delle checklist di hardening copre già: il valore di registro RestrictAnonymous e il criterio di sicurezza «Accesso di rete: non consentire l'enumerazione anonima di account e condivisioni SAM». Questi governano l'enumerazione anonima SAM/RPC — un percorso di codice completamente diverso. I team che hanno bloccato RestrictAnonymous e sono andati avanti spesso presumono che LDAP sia coperto dalla stessa impostazione. Non lo è; dsHeuristics è il controllo che regola davvero LDAP, e va verificato a sé — insieme alle altre impostazioni di rete dei controller di dominio trattate in Audit TLS Debole LDAPS, Spooler Stampa, Sincronizzazione Oraria del Domain Controller: Checklist di Igiene di Rete.

Se la vostra organizzazione ha già bloccato la firma LDAP, notate che la firma e dsHeuristics proteggono da cose diverse: la firma impedisce la manomissione e il relay su una connessione già autenticata; dsHeuristics decide se una connessione debba autenticarsi affatto. Correggere l'una non fa nulla per l'altra.

Cosa ottiene un attaccante da questo

Quando fLDAPBlockAnonOps è disabilitato, un client LDAP anonimo può eseguire qualsiasi operazione che la lista di controllo degli accessi (ACL) di un oggetto consenta al principal «Anonymous Logon» / «Everyone» — senza credenziali richieste, nemmeno un account guest a basso privilegio. In pratica, si tratta delle ACL predefinite sugli oggetti della maggior parte dei domini su utenti, gruppi e unità organizzative, il che è sufficiente per percorrere l'intero albero: nomi utente, appartenenze ai gruppi, struttura delle OU, e spesso attributi descrittivi come i titoli di lavoro o i campi di descrizione in testo libero che finiscono per contenere più di quanto dovrebbero.

Questo è esattamente il profilo che le linee guida congiunte di CISA, NSA e partner internazionali sul rilevamento e la mitigazione delle compromissioni di Active Directory sottolineano ripetutamente: l'enumerazione non autenticata della directory è un passo standard di ricognizione pre-compromissione, perché consegna a un attaccante l'elenco utenti del dominio, le appartenenze ai gruppi e il layout delle OU prima di un solo tentativo di autenticazione — e prima che un solo avviso di logon fallito abbia motivo di scattare. Strumenti pubblici costruiti apposta per questo, come Windapsearch, presumono esattamente questo scenario: puntare a un controller di dominio senza credenziali e vedere cosa rivela un bind anonimo prima di spendere anche una sola password tentata. È uno dei vari vettori di esposizione non autenticata in Active Directory — vedete anche Trasferimento di Zona DNS Active Directory Aggiornamento Dinamico Non Sicuro: Rilevamento e Remediation per un percorso di esposizione comparabile lato DNS.

Confermare l'esposizione con un test di bind diretto

Il modo diretto per confermare l'esposizione è provarlo:

# Nessun -D (bind DN) e nessun -w (password) => bind semplice anonimo
ldapsearch -x -H ldap://dc01.corp.local -b "DC=corp,DC=local" \
  "(objectClass=user)" sAMAccountName

Se questo restituisce oggetti utente invece di una risposta di errore operativo / diritti di accesso insufficienti, l'accesso LDAP anonimo è abilitato su quel controller di dominio.

Rilevamento

Leggere l'attributo direttamente è il controllo più affidabile, poiché non dipende dall'abilitazione del logging di audit da nessuna parte. Il test di bind è il secondo più affidabile, perché riflette ciò che un client sperimenta realmente piuttosto che ciò che la configurazione dichiara. I segnali dei log eventi sono complementari, non primari: aiutano a confermare che l'esposizione è stata utilizzata, non solo che è presente.

Se il logging di audit per queste categorie non è già abilitato sui vostri controller di dominio, si tratta di una lacuna prerequisita da colmare per prima — vedete Lacune nella configurazione dei criteri di controllo di Active Directory per le categorie che la maggior parte degli ambienti lascia disattivate prima ancora di averne bisogno.

Correzione

Passo 1 — Leggere prima di scrivere

Annotate innanzitutto l'intera stringa dsHeuristics esistente — modificarla alla cieca rischia di far scattare un'euristica non correlata da cui potrebbe dipendere qualche altra applicazione o processo.

Passo 2 — Correggere il settimo (e l'ottavo) carattere

Impostate il settimo carattere su 0 (o rimuovetelo del tutto se è il carattere finale) per ripristinare il blocco predefinito delle operazioni anonime. La modifica si replica su ogni controller di dominio della foresta e ha effetto senza riavvio. Già che ci siete, controllate l'ottavo carattere (fAllowAnonNSPI) e ripristinatelo, a meno che non esista una dipendenza documentata da una rubrica legacy di Exchange/Outlook che richieda davvero bind NSPI anonimi. Non date per scontato che RestrictAnonymous copra già l'uno o l'altro — è un controllo diverso per un percorso di protocollo diverso, quindi verificate dsHeuristics in modo indipendente anche in ambienti che si considerano già irrobustiti.

Passo 3 — Ritestare

Rieseguite lo stesso test di bind anonimo ldapsearch / ldp.exe usato per il rilevamento. Ora dovrebbe restituire un errore operativo o una risposta di diritti di accesso insufficienti, non oggetti della directory. Se l'accesso LDAP anonimo è genuinamente necessario per una specifica applicazione legacy, delimitatelo a livello di rete (una regola firewall verso la sorgente specifica) invece di lasciare il valore di dsHeuristics aperto, per l'intera foresta, a qualsiasi client non autenticato.

Come EtcSec rileva questo

L'audit Active Directory di EtcSec legge l'attributo dsHeuristics direttamente dal contesto di denominazione Configuration e segnala due controlli correlati: ANONYMOUS_LDAP_ACCESS quando le operazioni LDAP anonime sono confermate raggiungibili, e DS_HEURISTICS_LDAP_SECURITY quando l'attributo stesso è impostato su un valore che indebolisce la sicurezza LDAP — così la configurazione errata viene individuata alla fonte anziché solo dopo che il traffico di enumerazione compare nei log. Per una copertura più ampia delle impostazioni che la maggior parte degli ambienti dovrebbe controllare per prima, vedete Messa in sicurezza Active Directory: cosa bloccare prima e come validarlo e Quali sono le configurazioni di sicurezza errate di Active Directory più comuni?