Binding di Canale LDAP, Controller di Dominio, Relay NTLM, LDAPS: La Metà dell'Advisory del 2020 Che Nessuno Ha Completato

Binding di canale LDAP, controller di dominio, relay NTLM, LDAPS — i quattro termini appartengono alla stessa frase, perché il binding di canale è l'unica impostazione del controller di dominio in grado di fermare un relay NTLM che atterra all'interno di una sessione LDAPS sulla porta 636. La maggior parte dei team Active Directory ha letto le linee guida di hardening 2020 di Microsoft come un unico elemento, ha chiuso la metà relativa alla firma LDAP e ha proseguito oltre. La metà relativa al binding di canale è un valore di registro separato che, su Windows Server 2022 e versioni precedenti, non esiste finché un amministratore non lo crea — e Windows Server 2025 ha cambiato questo solo per le nuove implementazioni.

Binding di Canale LDAP, Controller di Dominio, Relay NTLM, LDAPS: Come si Incastrano i Pezzi

Il binding di canale LDAP utilizza un Channel Binding Token (CBT) per legare l'autenticazione che avviene all'interno di una sessione TLS al canale TLS che la trasporta. Microsoft lo descrive come l'uso dei CBT "per legare crittograficamente la sicurezza a livello applicativo (come una sessione SSL/TLS) con la connessione di rete sottostante", in modo che un attaccante che intercetta la sessione cifrata non possa dirottarla o forzarne il downgrade.

Il token esiste in un solo punto. Il riferimento di policy di Windows per Domain controller: LDAP server channel binding token requirements è esplicito: "CBT o EPA vengono utilizzati con le sessioni TLS quando per autenticare l'utente si usa un metodo di autenticazione SASL. SASL significa che si utilizza NTLM o Kerberos per l'autenticazione dell'utente. Il Simple Bind LDAP su TLS non offre protezione tramite channel binding token e pertanto non è consigliato."

Qui contano due porte. LDAP in chiaro è in ascolto sulla porta 389 — la porta su cui si manifestano problemi di enumerazione non autenticata come l'accesso LDAP anonimo tramite dsHeuristics. LDAPS usa la porta 636 e stabilisce SSL/TLS non appena un client si connette. Il binding di canale è un controllo per la seconda.

La capacità in sé non è nuova. Secondo KB4520412, "il supporto al binding di canale LDAP è stato aggiunto da CVE-2017-8563 su Windows Server 2008 e versioni successive", e i channel binding token sono supportati su Windows 10 versione 1709 e successive. Ciò che CVE-2017-8563 ha introdotto è stato il supporto a Extended Protection for Authentication (EPA) più una voce di registro che un amministratore deve creare — non una modifica del valore predefinito.

Perché la Firma LDAP Non Copre il Tuo Traffico LDAPS

Questa è la parte che viene saltata, e il testo stesso di Microsoft sulla vulnerabilità lo dice chiaramente. La descrizione MSRC di CVE-2017-8563 recita:

In Microsoft Windows esiste una vulnerabilità di elevazione dei privilegi quando un attaccante man-in-the-middle riesce a inoltrare con successo una richiesta di autenticazione verso un server LDAP Windows, ad esempio un sistema che esegue Active Directory Domain Services (AD DS) o Active Directory Lightweight Directory Services (AD LDS), che è stato configurato per richiedere la firma (signing) o il sealing sulle connessioni in ingresso.

Rileggi due volte quell'ultima proposizione. Il controller di dominio descritto in quella frase richiede già la firma. È comunque soggetto a relay. La correzione introdotta da Microsoft è stata EPA, e le FAQ dello stesso advisory dicono agli amministratori che installare l'aggiornamento non basta — devono inoltre creare l'impostazione di registro LdapEnforceChannelBinding.

L'ambito del controllo di firma spiega il perché. Quando la firma LDAP è applicata, un controller di dominio "rifiuta i simple bind LDAP su connessioni non SSL/TLS e i bind SASL che non richiedono la firma". Entrambe le metà di questa regola riguardano traffico che non è già all'interno di TLS. Un simple bind veicolato su LDAPS non è ciò che il controllo di firma rifiuta, e secondo il riferimento di policy sopra citato non riceve nemmeno protezione tramite channel binding token: il CBT si applica quando è un metodo SASL — NTLM o Kerberos — a effettuare l'autenticazione, motivo per cui Microsoft segnala il Simple Bind LDAP su TLS come "non consigliato" piuttosto che come qualcosa che il binding di canale risolve.

Se stai ancora lavorando sul lato della firma, quel controllo è trattato separatamente in Firma LDAP Disabilitata: Come i Bind Non Firmati Espongono Active Directory. Questo articolo è l'altro valore, sull'altra porta.

Il Valore Predefinito Che Non È Mai Cambiato

L'advisory Microsoft ADV190023, Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing, è insolitamente diretto riguardo alla situazione di partenza: "Sui controller di dominio Active Directory esiste un insieme di configurazioni predefinite non sicure per il binding di canale LDAP e la firma LDAP, che permettono ai client LDAP di comunicare con essi senza applicare il binding di canale LDAP e la firma LDAP."

Gli aggiornamenti del 10 marzo 2020 che tutti ricordano hanno aggiunto l'impostazione di Group Policy e gli ID evento. Non hanno modificato nulla. KB4520412 ripete l'avvertimento quattro volte — nell'introduzione e una volta in ciascuna sezione dedicata agli aggiornamenti: "Gli aggiornamenti del 10 marzo 2020, e gli aggiornamenti nel prossimo futuro, non modificheranno le policy predefinite di firma LDAP o di binding di canale LDAP, né il loro equivalente di registro, sui controller di dominio Active Directory nuovi o esistenti." Gli aggiornamenti di auditing dell'8 agosto 2023 e del 10 ottobre 2023 ribadiscono lo stesso concetto ciascuno per la propria release.

Sul lato registro, KB4034879 è altrettanto diretto: "Per impostazione predefinita questa impostazione è disabilitata" e "La voce di registro LdapEnforceChannelBindings deve essere creata esplicitamente."

È con Windows Server 2025 che la storia finalmente cambia — parzialmente.

La documentazione Microsoft afferma che Windows Server 2025 e versioni successive impostano il binding di canale su "When supported" per impostazione predefinita, con l'auditing del binding di canale abilitato di default, e che questi valori predefiniti più severi si applicano alle nuove implementazioni di Active Directory — mentre "le installazioni aggiornate mantengono le proprie impostazioni di sicurezza LDAP correnti per evitare interruzioni". Quindi un controller di dominio Server 2025 che si unisce a un dominio costruito nel 2016 non è automaticamente quello "irrobustito" descritto nel punto elenco di marketing. Se un rinnovo dei controller di dominio è già in programma, questa distinzione conta: vedi Windows Server 2016: Fine del Supporto e Aggiornamento del Controller di Dominio Active Directory.

E "When supported" non è nemmeno il traguardo finale. Secondo la stessa definizione di Microsoft, a quel livello "verranno bloccati solo i binding di canale non corretti, e i client che non supportano il binding di canale possono continuare a connettersi tramite LDAP su TLS". La best practice documentata è Always.

La Catena di Attacco

Step 1 - Ottenere un'autenticazione da inoltrare

L'attaccante ha bisogno che una macchina Windows o un account utente si autentichi verso un host sotto il suo controllo. I meccanismi di questo passaggio — coercizione, poisoning della risoluzione dei nomi, un percorso di condivisione malevolo — sono gli stessi trattati in Attacchi di Relay NTLM: Dirottare l'Autenticazione in AD, e non cambiano per nulla di ciò che riguarda il controller di dominio.

Step 2 - Inoltrarla in relay verso LDAPS sulla porta 636

Invece di terminare l'autenticazione, l'attaccante apre una propria sessione TLS verso un controller di dominio sulla porta 636 e vi inoltra i messaggi di autenticazione della vittima. Questo è esattamente lo scenario descritto da ADV190023: "un attaccante man-in-the-middle che inoltra con successo una richiesta di autenticazione verso un server LDAP Windows ... che non è stato configurato per richiedere il binding di canale, e la firma o il sealing sulle connessioni in ingresso."

Step 3 - Effettuare il bind e agire come il principal oggetto di relay

Con LdapEnforceChannelBinding assente o impostato a 0, il controller di dominio non ha modo di accorgersi che l'autenticazione è stata generata per un canale TLS diverso da quello su cui è arrivata, e il bind ha successo. L'attaccante ora dispone di una sessione LDAP autenticata che porta con sé i diritti nella directory dell'account oggetto di relay — il che, se il principal oggetto di relay è un account macchina di un controller di dominio o un utente privilegiato, è una via molto breve verso il resto del dominio. Una sessione LDAP autenticata è anche il punto in cui vengono scritti gli oggetti della directory, e valori predefiniti come la quota di account macchina determinano quanto può ancora fare un account con pochi privilegi.

Con l'applicazione del CBT impostata su Always, la stessa autenticazione oggetto di relay non porta alcun binding valido per il canale dell'attaccante, e il controller di dominio la rifiuta.

Rilevamento

Inizia da ciò che ogni controller di dominio fa realmente in questo momento, non da ciò che dichiara l'editor delle GPO.

$dcs = (Get-ADDomainController -Filter *).HostName

Invoke-Command -ComputerName $dcs -ScriptBlock {
    $params = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
    $diag   = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics'
    [pscustomobject]@{
        DC          = $env:COMPUTERNAME
        OS          = (Get-CimInstance Win32_OperatingSystem).Caption
        CBT         = (Get-ItemProperty $params -Name LdapEnforceChannelBinding -ErrorAction SilentlyContinue).LdapEnforceChannelBinding
        Signing     = (Get-ItemProperty $params -Name LDAPServerIntegrity -ErrorAction SilentlyContinue).LDAPServerIntegrity
        LdapLogging = (Get-ItemProperty $diag -Name '16 LDAP Interface Events' -ErrorAction SilentlyContinue).'16 LDAP Interface Events'
    }
} | Format-Table -AutoSize

Una colonna CBT vuota significa che il valore non è mai stato creato. Su Windows Server 2022 e versioni precedenti ciò equivale a 0 — Never.

Entrambe le impostazioni risiedono sotto HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters, e KB4520412 le mappa ai nomi delle policy come segue.

Poi ci sono gli eventi. Tutti finiscono nel log Directory Service con origine Microsoft-Windows-ActiveDirectory_DomainService.

🚨 Pericolo: in questa tabella c'è una trappola. KB4520412 afferma che "gli eventi 3039, 3074 e 3075 possono essere generati solo quando il Channel Binding è impostato su When Supported o Always." Un controller di dominio fermo al valore predefinito produce quindi zero inventario dei client — gli eventi di audit che indicano quali client si romperebbero non esistono finché non ci si è già spostati da Never. Il solito istinto "prima verifica, poi abilita" qui è capovolto: passare a 1 è già il passo di verifica.

Gli eventi 3040 e 3041 sono l'eccezione, e sono il tuo oracolo di base. Si generano al livello di logging 0 senza alcuna configurazione, e solo quando la policy è Never. Se un controller di dominio registra il 3041, su quel controller di dominio il binding di canale è disattivato — qualunque cosa dicesse la pagina delle proprietà.

Get-WinEvent -FilterHashtable @{
    LogName   = 'Directory Service'
    Id        = 3039, 3040, 3041, 3074, 3075
    StartTime = (Get-Date).AddDays(-7)
} -ErrorAction SilentlyContinue |
    Group-Object Id |
    Select-Object Name, Count |
    Sort-Object Name

Per raccogliere i dettagli sui client, alza il livello di diagnostica LDAP. KB4520412 fornisce il comando testuale:

Reg Add HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2

Al livello 2, gli eventi 3074 e 3075 riportano i campi necessari per rintracciare un client: l'indirizzo IP e la porta del client, l'identità con cui il client ha tentato di autenticarsi, se il client supporta il binding di canale, se è stato ammesso in modalità when-supported, e un valore di flag del risultato dell'audit.

Get-WinEvent -FilterHashtable @{ LogName = 'Directory Service'; Id = 3074, 3075 } -ErrorAction SilentlyContinue |
    ForEach-Object {
        if ($_.Message -match 'Client IP address:\s*(\d{1,3}(?:\.\d{1,3}){3}):\d+') { $Matches[1] }
    } |
    Group-Object |
    Sort-Object Count -Descending |
    Select-Object Count, Name

Adatta il pattern se alcuni dei tuoi client raggiungono il controller di dominio via IPv6.

I flag del risultato dell'audit si decodificano come segue, secondo KB4520412.

I bit all'interno di 0x30 indicano un CBT valido; i bit all'interno di 0x0C ne indicano uno fallito.

Gli eventi di audit richiedono anche un livello minimo di aggiornamenti: secondo ADV190023, gli eventi di audit del binding di canale 3074 e 3075 sono diventati disponibili senza un passaggio di abilitazione manuale con gli aggiornamenti del 14 novembre 2023 su Windows Server 2022 e con gli aggiornamenti del 9 gennaio 2024 su Windows Server 2019.

Remediation

1. Prima sistema l'idraulica di base. Il binding di canale è un controllo su LDAPS, quindi LDAPS deve essere in salute prima di applicare qualsiasi cosa: un certificato valido su ogni controller di dominio e una configurazione TLS moderna. Se questo terreno non è verificato, inizia da Audit TLS Debole su LDAPS, Spooler di Stampa, Sincronizzazione Oraria.

2. Passa a When Supported (valore 1).

$params = 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Parameters'
New-ItemProperty -Path $params -Name 'LdapEnforceChannelBinding' -PropertyType DWord -Value 1 -Force

KB4034879 conferma che il costo operativo è vicino allo zero: "Il server LDAP risponde dinamicamente alle modifiche a questa voce di registro. Pertanto, non è necessario riavviare il computer dopo aver applicato la modifica al registro." Microsoft consiglia inoltre il valore 1 specificamente per massimizzare la compatibilità con i sistemi operativi più datati.

3. Leggi l'inventario per un intero ciclo di attività. Con il logging diagnostico a 2, raccogli gli eventi 3074 e 3075 su tutti i controller di dominio per un periodo sufficiente a catturare i job mensili e trimestrali. La linea guida di KB4520412 è di suddividere ogni IP sorgente in tre categorie: appliance o router (contattare il fornitore), dispositivo non Windows (verificare con il fornitore del sistema operativo e dell'applicazione che sia la firma sia il binding di canale siano supportati), e dispositivo Windows (verificare che l'applicazione stia effettivamente usando il binding di canale).

4. Aspettati classi specifiche di malfunzionamenti. Le FAQ LDAP di Microsoft segnalano che i client che si connettono via SSL/TLS senza un CBT falliranno una volta che il server lo richiede, e che "le connessioni SSL/TLS terminate da un server intermedio che a sua volta apre una nuova connessione verso un controller di dominio Active Directory falliranno" — un load balancer che effettua la terminazione TLS davanti ai tuoi controller di dominio è una vittima garantita. Le stesse FAQ notano che "il supporto al binding di canale potrebbe essere meno comune sui sistemi operativi e sulle applicazioni di terze parti rispetto alla firma LDAP", il che è esattamente il motivo per cui così tanti ambienti hanno completato la firma e si sono bloccati qui. KB4520412 aggiunge altre due modalità di errore. Windows XP "non supporta il binding di canale LDAP e fallirebbe quando il binding di canale LDAP è configurato usando un valore Always, ma interopererebbe con DC configurati per usare l'impostazione più permissiva When supported" — sopravvive allo step 2 e si rompe allo step 5. Inoltre un client può avere EPA disattivato localmente tramite l'impostazione di registro SuppressExtendedProtection; poiché KB4520412 definisce un client capace di channel binding come uno in cui EPA è "installato o disponibile nel sistema operativo e non disabilitato tramite l'impostazione di registro SuppressExtendedProtection", un client di questo tipo non comparirà mai nel tuo inventario 3075.

5. Applica con Always (valore 2), tramite policy. Una volta che l'inventario è pulito, imposta la Group Policy Domain controller: LDAP server channel binding token requirements su Always sotto Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Security Options nella Default Domain Controllers Policy, in modo che i nuovi controller di dominio la ereditino invece di dipendere da qualcuno che si ricorda di impostare il valore di registro. La best practice dichiarata da Microsoft per questa impostazione è Always; l'effetto collaterale documentato è che i client che non supportano il binding di canale non potranno più eseguire query LDAP contro i controller di dominio.

6. Verifica per assenza. L'evento 3041 si genera solo finché la policy è Never. Quando un controller di dominio smette di registrare il 3040 e il 3041, e inizia a registrare il 3039 per fallimenti reali, l'applicazione è attiva su quell'host. Riesegui l'inventario di registro della sezione Rilevamento su tutti i controller di dominio — inclusi quelli promossi dopo la modifica.

7. Chiudi i percorsi di relay adiacenti. Il binding di canale chiude una destinazione di relay. Le credenziali oggetto di relay di solito hanno origine da qualche parte con SMB non firmato, quindi abbina questo lavoro a Firma SMB Disabilitata: Perché Abilita Ancora il Relay NTLM — e gli endpoint di iscrizione dei certificati sono una destinazione separata che vale la pena controllare nella stessa campagna, trattata in ADCS: Percorsi di Attacco Spiegati.

Come EtcSec Rileva Questo Problema

EtcSec legge la configurazione LDAP effettiva di ogni controller di dominio durante un audit di Active Directory. LDAP_CHANNEL_BINDING_DISABLED segnala i controller di dominio che non richiedono i channel binding token, e LDAP_SIGNING_DISABLED segnala la metà relativa alla firma dello stesso advisory — deliberatamente come due finding distinti, perché chiuderne uno non chiude l'altro. NTLM_RELAY_OPPORTUNITY riporta l'esposizione al relay creata da questi valori predefiniti, e DC_LDAPS_WEAK_TLS verifica che il livello TLS da cui dipende il binding di canale sia esso stesso solido.

Riferimenti Ufficiali

• KB4520412: 2020, 2023, and 2024 LDAP channel binding and LDAP signing requirements for Windows — mapping di registro, tabelle complete degli eventi e dei trigger, flag del risultato dell'audit
• KB4034879: Use the LdapEnforceChannelBinding registry entry to make LDAP authentication over SSL/TLS more secure — semantica dei valori, stato predefinito, nessun riavvio richiesto
• ADV190023: Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing — la dichiarazione sui valori predefiniti non sicuri e la timeline di servicing
• CVE-2017-8563 — Windows Elevation of Privilege Vulnerability — il relay contro un server LDAP con firma applicata, punteggio base CVSS 3.0 pari a 7.5
• Domain controller: LDAP server channel binding token requirements — definizioni dei valori, valori predefiniti effettivi per versione di Windows, best practice
• LDAP signing for Active Directory Domain Services on Windows Server — valori predefiniti di Windows Server 2025 e comportamento in caso di aggiornamento
• Manage LDAP signing using Group Policy — la policy di applicazione della firma per Server 2025 e i passaggi per il logging diagnostico
• KB4546509: Frequently asked questions about changes to Lightweight Directory Access Protocol — modalità di errore per compatibilità

Letture Correlate

• Firma LDAP Disabilitata: Come i Bind Non Firmati Espongono Active Directory
• Attacchi di Relay NTLM: Dirottare l'Autenticazione in AD
• Firma SMB Disabilitata: Perché Abilita Ancora il Relay NTLM
• Audit TLS Debole su LDAPS, Spooler di Stampa, Sincronizzazione Oraria: una Checklist di Igiene di Rete
• Accesso LDAP Anonimo tramite dsHeuristics: Enumerazione di Active Directory
• Quota di Account Macchina in Active Directory (ms-DS-MachineAccountQuota)
• ADCS: Percorsi di Attacco Spiegati - Come le Configurazioni Errate dei Certificati Diventano Percorsi di Escalation in Active Directory
• Windows Server 2016: Fine del Supporto e Aggiornamento del Controller di Dominio Active Directory