Il team di ricerca Semperis

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:

  1. Modifica dell'account di un computer dNSHostName in modo che corrisponda a quello di un altro account di computer.
  2. 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).
"Diritto dell'utente "Aggiungi stazioni di lavoro al dominio
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)
attributo ms-DS-MachineAccountQuota
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).

Aggiunta di account di computer
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).

Convalidata l'autorizzazione a scrivere 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).

Figura 5: Modifica del nome del DNShostname
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).

Modello di certificato
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).

Richiesta di un certificato
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.

Obiettivo di un DC - vulnerabilità AD
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).

Certificato richiesto per il nuovo nome - vulnerabilità AD
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).

Modifica di nuovo di dNSHostName - vulnerabilità AD
Figura 10

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).

/getcredentials passa al comando asktgt
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.

Autorizzazione GenericWrite
Figura 12

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).

Modifica di dNSHostName per adattarlo a un altro account
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).

Richiesta di certificato
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).

Collegamento a LDAP
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.

Rifinitura del percorso di attacco (1)
Figura 16
Rifinitura del percorso di attacco (2)
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).

Utilizzo del ticket di servizio
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).

Utilizzo di MS-SAMR
Figura 19

L'account del computer risultante non ha SPN e non richiede la loro cancellazione (vedere Figura 20).

Nessun SPN
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).
Modifica del nome del modello
Figura 21
  • Configurare i modelli di certificato in modo che richiedano l'approvazione del manager per l'iscrizione(Figura 22).
Configurare l'approvazione 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.
DSP bandiere
Figura 23

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).

5136 eventi
Figura 24

Modifica di dNSHostName

Quando l'attributo dNSHostName viene modificato, viene creato un evento 4742(Figura 25).

"Diritto dell'utente "Aggiungi stazioni di lavoro al dominio
Figura 25

La sezione Attributi modificati di questo evento mostra il nuovo valore del nome host DNS (Figura 26).

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).

Valore eliminato
Figura 27

La seconda mostra il nuovo valore di dNSHostName ed è di tipo Value Added (Figura 28).

Valore aggiunto
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).

4741 evento
Figura 29

Nella sezione Attributi di questo evento, i Nomi dei principi del servizio sono vuoti, come mostrato nella Figura 30.

Nomi dei responsabili del servizio vuoti
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).

Conto di richiesta
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).
Violazione del vincolo
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).
Nuovo OID
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).

Errore restituito
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.

Utilizzo di un certificato non aggiornato
Figura 35

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