- Cosa porta a questa vulnerabilità di AD?
- Escalation dei privilegi con la vulnerabilità AD CVE-2022-26923
- Modifica dell'account macchina dNSHostName
- Modello di certificato con flag SubjectAltRequireDns
- Abusi della vulnerabilità AD CVE-2022-26923
- Variazioni del percorso di attacco
- Fattori attenuanti
- DSP rilevamento di questa vulnerabilità AD
- Altri rilevamenti di CVE-2022-26923
- Bonifica delle vulnerabilità AD
Il 10 maggio 2022 è stata resa nota una vulnerabilità all'interno di Active Directory (AD) e di Active Directory Certificate Services (AD CS), che è stata poi patchata. Questa vulnerabilità di AD può portare all'escalation dei privilegi. Nelle installazioni predefinite di AD CS, un utente con un basso livello di privilegio può sfruttare la vulnerabilità richiedendo un certificato di autenticazione e poi utilizzando tale certificato per impersonare un altro account di computer, con conseguente acquisizione di un dominio completo. Di cosa si tratta questa vulnerabilità AD? Continuate a leggere per una guida completa a CVE-2022-26923.
Cosa porta a questa vulnerabilità di AD?
AD è stato rilasciato per la prima volta nel 1999 da Microsoft come sistema centralizzato di gestione delle identità, costituito da un insieme di processi e servizi. AD contiene diversi protocolli che possono essere utilizzati per l'autenticazione e l'autorizzazione delle identità in un'azienda. Più comunemente, AD viene utilizzato per gestire facilmente utenti, gruppi e computer all'interno di un'azienda. AD è diventato il sistema di gestione delle identità più diffuso, utilizzato per gestire le identità nella maggior parte delle aziende.
In Windows Server 2008, Microsoft ha introdotto AD CS, che consente di creare e gestire facilmente i certificati PKI (Public Key Infrastructure). Questi certificati possono essere utilizzati per la firma digitale, la protezione dei protocolli e l'autenticazione.
Quando i certificati di AD CS vengono utilizzati per l'autenticazione all'interno di un ambiente AD (PKINIT), si aprono molte nuove vie di attacco, tra cui configurazioni errate e vulnerabilità. Nel giugno 2021, Will Schroeder e Lee Christensen hanno pubblicato un whitepaper che illustrava in dettaglio diverse configurazioni errate che potevano portare all'escalation dei privilegi. Alcune di queste configurazioni errate erano predefinite all'interno di AD CS al momento dell'installazione e possono portare all'acquisizione completa del dominio. Queste configurazioni errate sono indipendenti dalla vulnerabilità descritta in questo post.
Lettura correlata
Escalation dei privilegi con la vulnerabilità AD CVE-2022-26923
CVE-2022-26923 è una vulnerabilità di privilege escalation scoperta da Oliver Lyak. Lo sfruttamento si basa su due azioni principali:
- Modifica dell'account di un computer dNSHostName in modo che corrisponda a quello di un altro account di computer.
- Richiesta di un certificato per l'account del computer, utilizzando un modello configurato con l'opzione SubjectAltRequireDns
Il flag SubjectAltRequireDns per i modelli di certificato significa che i certificati richiesti utilizzando questo modello hanno un certificato Oggetto corrispondente all'attributo dNSHostName dell'account AD richiedente.
Entrambe le azioni sono possibili in un'installazione predefinita di AD e AD CS.
Richiedendo un certificato utilizzando un account di computer che ha lo stesso dNSHostName di un altro account di computer, gli aggressori possono autenticarsi come account del computer di destinazione e aumentare i privilegi. Questa vulnerabilità può essere utilizzata per colpire qualsiasi computer attivo all'interno di AD.
Modifica dell'account macchina dNSHostName
In un'installazione AD predefinita, qualsiasi utente autenticato può aggiungere account macchina. Questa azione è regolata dalle seguenti impostazioni:
- Il Aggiungi stazioni di lavoro al dominio nel criterio Controller di dominio, che definisce a chi sono concessi i privilegi per aggiungere account di computer al dominio (impostato per default su Utenti autenticati ; Figura 1).
- Il ms-DS-MachineAccountQuota sulla testa del contesto di denominazione (NC), che definisce il numero di account di computer che gli utenti a basso privilegio possono aggiungere (impostato a 10 per impostazione predefinita; Figura 2)
Con queste impostazioni predefinite, qualsiasi account con privilegi bassi può facilmente creare fino a 10 account di computer sul dominio utilizzando il cmdlet New-MachineAccount di Powermadper aggiungere un account di computer denominato LowPrivComputer(Figura 3).
La Discretionary Access Control List (Dacl) per questo nuovo account di computer mostra che l'account creatore ha l'autorizzazione di scrittura convalidata sul nome host DNS (Figura 4).
Pertanto, l'attributo dNSHostName può essere modificato dallo stesso account che lo ha creato, semplicemente utilizzando il cmdlet Set-DomainObject di PowerView(Figura 5).
Modello di certificato con flag SubjectAltRequireDns
In un'installazione AD CS predefinita, diversi modelli di certificato hanno il flag SubjectAltRequireDns impostato. Ad esempio, il modello Macchina è utilizzato per impostazione predefinita per registrare gli account dei computer per l'autenticazione dei certificati. Il cmdlet Get-DomainCertificateTemplate di PowerView viene utilizzato per visualizzare l'attributo msPKI-Certificate-Name-Flag del modello Machine (Figura 6).
Utilizzando l'account macchina precedentemente creato, è possibile richiedere un certificato utilizzando questo modello per l'account LowPrivComputer con il dnshostname modificato(somethingelse.f105-d01.lab). A tale scopo, si utilizza lo strumento Python Certipy (Figura 7).
Abusi della vulnerabilità AD CVE-2022-26923
Come già detto, questo metodo può essere utilizzato per aumentare i privilegi all'interno di un dominio AD. Un percorso di attacco comune consiste nel colpire un controller di dominio (DC). Dopo aver creato l'account del computer(LowPrivComputer), gli aggressori modificano innanzitutto l'attributo dNSHostName dell'account in modo che sia lo stesso del DC(F105-D02-DC01.f105-d01.lab), come mostrato nella Figura 8.
Per questo percorso di attacco, il contenuto del servicePrincipalName (SPN) deve essere cancellato. Quando l'attributo dNSHostName viene aggiornato, anche le voci SPN vengono aggiornate per corrispondere al nuovo nome. Questo va in conflitto con le voci SPN dell'account autentico(F105-D01-DC01) e la modifica fallisce.
Dopo la modifica di dNSHostName, è possibile richiedere un certificato per questo nuovo nome(Figura 9).
Dopo aver recuperato il certificato, il dNSHostName deve essere nuovamente modificato(Figura 10), in modo che quando il certificato viene utilizzato e il DC cerca il nome del client, ci sia una sola corrispondenza (l'account DC autentico).
Ora è possibile autenticarsi come account del computer DC. Rubeus fornisce uno switch /getcredentials al metodo asktgt che utilizza una richiesta da utente a utente (U2U). Quando viene fornito un certificato per l'autenticazione, l'hash NT dell'account richiedente può essere recuperato grazie ai dati delle credenziali PAC NTLM_SUPPLEMENTAL_CREDENTIAL PAC_INFO_BUFFER(Figura 11).
Questo hash NT può essere utilizzato per un'ulteriore autenticazione come DC (utilizzando pass-the-hash o overpass-the-hash) oppure i Silver Ticket possono essere falsificati.
Variazioni del percorso di attacco
Oltre al percorso di attacco mostrato negli esempi precedenti, è possibile utilizzare diverse piccole variazioni per sfruttare questa vulnerabilità di AD.
In primo luogo, un aggressore con un certo controllo su un oggetto informatico esistente non necessita della capacità di creare un account informatico. La Figura 12 mostra che l'account utente con un basso livello di privilegio ha l'opzione GenericWrite sull'oggetto informatico DatabaseServer.
Con questo privilegio, un utente malintenzionato può cancellare gli SPN e modificare l'attributo dNSHostName in modo che corrisponda a quello di un altro account del computer(Figura 13).
Due cose sono degne di nota:
- È stato preso di mira un sistema non DC. Questa vulnerabilità può essere utilizzata per colpire qualsiasi sistema unito al dominio, non solo i DC.
- Questa parte dell'attacco può essere eseguita su DC completamente aggiornati. Se l'account che effettua la modifica dispone di autorizzazioni specifiche GenericAll o GenericWrite, è possibile modificare il dNSHostName in modo che corrisponda a quello appartenente a un altro account di computer. (Questo non è possibile quando l'autorizzazione Validated write to DNS host name è concessa al creatore di un account di computer).
Con la modifica di dNSHostName, è possibile richiedere un certificato utilizzando il nome host DNS di destinazione(Figura 14).
Con la modifica del dNSHostName, come nel precedente percorso di attacco, l'aggressore può ora utilizzare il certificato acquisito per autenticarsi come account del computer di destinazione.
Un'altra differenza tra il percorso di attacco precedente e questo: L'aggressore non ha bisogno di usare il certificato per autenticarsi a Kerberos e richiedere un ticket granting ticket (TGT) per l'account di destinazione. L'attaccante può usare il certificato per autenticarsi direttamente ad alcuni servizi. L'esempio seguente utilizza il certificato per connettersi direttamente a LDAP e configurare la delega vincolata basata sulle risorse (RBCD) sull'oggetto computer di destinazione(Figura 15).
Si noti che la configurazione di RBCD è solo un esempio di ciò che un utente malintenzionato può fare utilizzando il certificato per autenticarsi direttamente contro i servizi. WinRM, RDP e IIS supportano tutti l'autenticazione del client tramite certificati, quindi ci sono molte altre possibilità. Altre azioni, come la configurazione di credenziali ombra, possono essere eseguite tramite LDAP, a seconda dell'ambiente e dei permessi dell'account del computer compromesso.
Per completare il percorso di attacco, l'aggressore può utilizzare l'estensione Kerberos Service-for-User (S4U) per ottenere un ticket di servizio per il sistema di destinazione come utente amministrativo (a condizione che l'utente amministrativo non sia stato protetto contro la delega), come illustrato nella Figura 16 e nella Figura 17.
L'attaccante può utilizzare il ticket di servizio risultante per accedere al servizio sul sistema di destinazione come utente impersonato. Una buona dimostrazione consiste nell'utilizzare WinRM/PowerShell Remoting per generare il valore di "whoami", che richiede un ticket di servizio per il servizio HTTP sul sistema di destinazione(Figura 18).
Nomi dei principi del servizio
Per entrambi i percorsi di attacco dimostrati, gli SPN devono essere cancellati prima di cambiare il dNSHostName. Questo potrebbe sembrare un requisito difficile per lo sfruttamento della vulnerabilità, ma non lo è. Utilizzando il protocollo MS-SAMR per creare un account di computer con il metodo SamrCreateUser2InDomain, un utente malintenzionato può creare un account di computer senza alcun SPN, semplicemente utilizzando lo script di esempio addcomputer.py di impacketper creare un account di computer chiamato NoSPNComputer (Figura 19).
L'account del computer risultante non ha SPN e non richiede la loro cancellazione (vedere Figura 20).
Fattori attenuanti
La limitazione della capacità degli utenti con privilegi bassi di creare account macchina, impostando l'attributo ms-DS-MachineAccountQuota sulla testa NC a 0 o modificando il diritto Aggiungi workstation all' utente del dominio nel criterio del controller di dominio a un gruppo specifico piuttosto che a Utenti autenticati, riduce i percorsi di attacco praticabili per questa vulnerabilità. Altre azioni per ridurre il potenziale di sfruttamento:
- Modificate i modelli di certificato da "Nome DNS" a "Nome principale dell'utente (UPN)"(Figura 21).
- Configurare i modelli di certificato in modo che richiedano l'approvazione del manager per l'iscrizione(Figura 22).
DSP rilevamento di questa vulnerabilità AD
Poiché questo exploit comprende solo due azioni obbligatorie, Semperis Directory Services Protector (DSP) ha due opportunità per rilevarlo:
- Quando si verifica la modifica di dNSHostName
- Quando viene richiesto il certificato
DSP raccoglie già i dati di modifica dell'AD, quindi la scelta più ovvia è quella di rilevare un tentativo di sfruttare questa vulnerabilità quando il dNSHostName viene modificato. L'indicatore DSP esegue questa operazione monitorando la modifica dell'attributo dNSHostName dell'account del computer.
Quando viene rilevata una modifica di questo tipo, DSP esegue una query LDAP per tutti gli account di computer con quel valore dNSHostName, escludendo il nome distinto dell'oggetto (DN) dell'account che ha attivato la query LDAP. DSP contrassegna ogni risultato come indicatore di compromissione (IoC). Questo flag dovrebbe catturare qualsiasi tentativo di sfruttare questa vulnerabilità, indipendentemente dal fatto che l'attacco completo sia andato a buon fine. Come mostrato nella Figura 23, l'IoC restituisce informazioni che includono:
- L'account che ha effettuato la modifica
- I DN di entrambi gli account del computer coinvolti
- Il dNSHostName originale dell'account a cui è stato modificato l'attributo
- L'attributo dNSHostName dell'account da prendere in considerazione.
Altri rilevamenti di CVE-2022-26923
Per identificare i tentativi di sfruttamento di questa vulnerabilità è possibile utilizzare anche diversi eventi Windows rilevanti.
Cancellazione degli SPN
Quando un percorso di attacco richiede la cancellazione degli SPN dell'account del computer utilizzato nell'attacco, viene creato un evento 5136 per ciascuno degli SPN configurati con il tipo di operazione Valore eliminato(Figura 24).
Modifica di dNSHostName
Quando l'attributo dNSHostName viene modificato, viene creato un evento 4742(Figura 25).
La sezione Attributi modificati di questo evento mostra il nuovo valore del nome host DNS (Figura 26).
Oltre all'evento 4742, vengono creati due eventi 5136. Il primo mostra il valore originale di dNSHostName ed è del tipo Value Deleted (Figura 27).
La seconda mostra il nuovo valore di dNSHostName ed è di tipo Value Added (Figura 28).
Creazione di computer senza SPN
Come accennato in precedenza, gli aggressori possono creare account di computer senza alcun SPN iniziale utilizzando MS-SAMR. Quando lo fanno, viene creato un evento 4741(Figura 29).
Nella sezione Attributi di questo evento, i Nomi dei principi del servizio sono vuoti, come mostrato nella Figura 30.
Richiesta di certificato
Quando viene richiesto un certificato, viene creato un evento 4887 sull'autorità di certificazione (CA). Questo evento mostra il nome dell'account richiedente(Requester). Il valore dell'attributo dNSHostName è indicato come Oggetto (Figura 31).
Bonifica delle vulnerabilità AD
Una patch per questa vulnerabilità è stata rilasciata come parte degli aggiornamenti di sicurezza di maggio 2022. Questa patch ha introdotto alcune modifiche:
- Gli account con l'autorizzazione Validated write to DNS host name non sono più in grado di modificare l'attributo dNSHostName in modo che corrisponda a quello di un altro account sui DC patchati. I tentativi in tal senso provocano una violazione dei vincoli(Figura 32).
Nota: come menzionato in precedenza, anche dopo questa patch, gli aggressori possono modificare l'attributo dNSHostName di un account di computer in modo che corrisponda a quello di un altro account di computer, anche se questa azione ora richiede autorizzazioni più elevate come GenericAll/GenericWrite.
- I certificati richiesti alle CA patchate contengono il nuovo OID szOID_NTDS_CA_SECURITY_EXT (1.3.6.1.4.1.311.25.2.1) (Figura 33).
Questo campo contiene una stringa ASCII (in esadecimale) del SID dell'account che ha richiesto il certificato. Quando un certificato utilizzato per sfruttare questa vulnerabilità viene usato per autenticarsi contro un DC patchato, viene restituito un errore CERTIFICATE_MISMATCH (Figura 34).
Nota: se questo certificato viene utilizzato per autenticarsi contro un DC non patchato, l'autenticazione avrà successo e la vulnerabilità sarà sfruttabile(Figura 35). Pertanto, è molto importante aggiornare tutti i DC e le CA con la relativa patch.
Per saperne di più
Per maggiori informazioni su questa vulnerabilità di AD e su come proteggere la tua organizzazione, consulta le risorse e i riferimenti seguenti.
Risorse
Maggiori informazioni su Semperis Directory Services Protector ( DSP)
Maggiori informzioni su Purple Knight, lo strumento di valutazione della sicurezza di Active Directory
Riferimenti
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-2022-26923
- https://research.ifcr.dk/certifried-active-directory-domain-privilege-escalation-cve-2022-26923-9e098fe298f4
- https://offsec.almond.consulting/authenticating-with-certificates-when-pkinit-is-not-supported.html
- https://www.netspi.com/blog/technical/network-penetration-testing/machineaccountquota-is-useful-sometimes/
- https://shenaniganslabs.io/2019/01/28/Wagging-the-Dog.html
