AD CS Domain Escalation
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Questo è un riepilogo delle sezioni delle tecniche di escalation dei post:
I diritti di registrazione sono concessi a utenti a bassa privilegio da parte dell'Enterprise CA.
L'approvazione del manager non è richiesta.
Non sono necessarie firme da parte del personale autorizzato.
I descrittori di sicurezza sui modelli di certificato sono eccessivamente permissivi, consentendo agli utenti a bassa privilegio di ottenere diritti di registrazione.
I modelli di certificato sono configurati per definire EKU che facilitano l'autenticazione:
Identificatori di Extended Key Usage (EKU) come Client Authentication (OID 1.3.6.1.5.5.7.3.2), PKINIT Client Authentication (1.3.6.1.5.2.3.4), Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2), Any Purpose (OID 2.5.29.37.0), o nessun EKU (SubCA) sono inclusi.
La possibilità per i richiedenti di includere un subjectAltName nella Certificate Signing Request (CSR) è consentita dal modello:
L'Active Directory (AD) dà priorità al subjectAltName (SAN) in un certificato per la verifica dell'identità se presente. Ciò significa che specificando il SAN in una CSR, può essere richiesto un certificato per impersonare qualsiasi utente (ad es., un amministratore di dominio). Se un SAN può essere specificato dal richiedente è indicato nell'oggetto AD del modello di certificato attraverso la proprietà mspki-certificate-name-flag. Questa proprietà è un bitmask, e la presenza del flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT consente la specifica del SAN da parte del richiedente.
La configurazione delineata consente agli utenti a bassa privilegio di richiedere certificati con qualsiasi SAN a scelta, abilitando l'autenticazione come qualsiasi principale di dominio tramite Kerberos o SChannel.
Questa funzionalità è talvolta abilitata per supportare la generazione al volo di certificati HTTPS o di host da parte di prodotti o servizi di distribuzione, o a causa di una mancanza di comprensione.
Si nota che la creazione di un certificato con questa opzione attiva un avviso, il che non accade quando un modello di certificato esistente (come il modello WebServer, che ha CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT abilitato) viene duplicato e poi modificato per includere un OID di autenticazione.
Per trovare modelli di certificato vulnerabili puoi eseguire:
Per abusare di questa vulnerabilità per impersonare un amministratore si potrebbe eseguire:
Poi puoi trasformare il certificato generato in formato .pfx e usarlo per autenticarti utilizzando Rubeus o certipy di nuovo:
I file binari di Windows "Certreq.exe" e "Certutil.exe" possono essere utilizzati per generare il PFX: https://gist.github.com/b4cktr4ck2/95a9b908e57460d9958e8238f85ef8ee
L'enumerazione dei modelli di certificato all'interno dello schema di configurazione della foresta AD, specificamente quelli che non richiedono approvazione o firme, che possiedono un Client Authentication o Smart Card Logon EKU, e con il flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT abilitato, può essere eseguita eseguendo la seguente query LDAP:
Il secondo scenario di abuso è una variazione del primo:
I diritti di registrazione sono concessi a utenti a bassa privilegi da parte dell'Enterprise CA.
Il requisito per l'approvazione del manager è disabilitato.
La necessità di firme autorizzate è omessa.
Un descrittore di sicurezza eccessivamente permissivo sul modello di certificato concede diritti di registrazione del certificato a utenti a bassa privilegi.
Il modello di certificato è definito per includere l'Any Purpose EKU o nessun EKU.
L'Any Purpose EKU consente a un certificato di essere ottenuto da un attaccante per qualsiasi scopo, inclusa l'autenticazione del client, l'autenticazione del server, la firma del codice, ecc. La stessa tecnica utilizzata per ESC3 può essere impiegata per sfruttare questo scenario.
I certificati con nessun EKU, che fungono da certificati CA subordinati, possono essere sfruttati per qualsiasi scopo e possono anche essere utilizzati per firmare nuovi certificati. Pertanto, un attaccante potrebbe specificare EKU o campi arbitrari nei nuovi certificati utilizzando un certificato CA subordinato.
Tuttavia, i nuovi certificati creati per l'autenticazione del dominio non funzioneranno se la CA subordinata non è fidata dall'oggetto NTAuthCertificates, che è l'impostazione predefinita. Tuttavia, un attaccante può comunque creare nuovi certificati con qualsiasi EKU e valori di certificato arbitrari. Questi potrebbero essere potenzialmente abusati per una vasta gamma di scopi (ad es., firma del codice, autenticazione del server, ecc.) e potrebbero avere implicazioni significative per altre applicazioni nella rete come SAML, AD FS o IPSec.
Per enumerare i modelli che corrispondono a questo scenario all'interno dello schema di configurazione della foresta AD, può essere eseguita la seguente query LDAP:
Questo scenario è simile al primo e al secondo, ma abusa di un EKU diverso (Agente di Richiesta di Certificato) e 2 modelli diversi (pertanto ha 2 set di requisiti),
L'EKU di Agente di Richiesta di Certificato (OID 1.3.6.1.4.1.311.20.2.1), noto come Agente di Iscrizione nella documentazione Microsoft, consente a un principale di iscriversi per un certificato per conto di un altro utente.
L'“agente di iscrizione” si iscrive in un modello e utilizza il certificato risultante per co-firmare un CSR per conto dell'altro utente. Poi invia il CSR co-firmato all'CA, iscrivendosi in un modello che permette “iscriversi per conto di”, e l'CA risponde con un certificato appartenente all'“altro” utente.
Requisiti 1:
I diritti di iscrizione sono concessi a utenti a basso privilegio dall'Enterprise CA.
Il requisito per l'approvazione del manager è omesso.
Nessun requisito per firme autorizzate.
Il descrittore di sicurezza del modello di certificato è eccessivamente permissivo, concedendo diritti di iscrizione a utenti a basso privilegio.
Il modello di certificato include l'EKU di Agente di Richiesta di Certificato, consentendo la richiesta di altri modelli di certificato per conto di altri principali.
Requisiti 2:
L'Enterprise CA concede diritti di iscrizione a utenti a basso privilegio.
L'approvazione del manager è bypassata.
La versione dello schema del modello è 1 o supera 2, e specifica un Requisito di Emissione di Politica Applicativa che richiede l'EKU di Agente di Richiesta di Certificato.
Un EKU definito nel modello di certificato consente l'autenticazione del dominio.
Le restrizioni per gli agenti di iscrizione non sono applicate sull'CA.
Puoi utilizzare Certify o Certipy per abusare di questo scenario:
I utenti che sono autorizzati a ottenere un certificato di agente di registrazione, i modelli nei quali gli agenti di registrazione sono autorizzati a registrarsi e gli account per conto dei quali l'agente di registrazione può agire possono essere limitati dalle CA aziendali. Questo si ottiene aprendo il certsrc.msc snap-in, facendo clic con il tasto destro sulla CA, cliccando su Proprietà, e poi navigando alla scheda “Agenti di registrazione”.
Tuttavia, si nota che l'impostazione predefinita per le CA è di “Non limitare gli agenti di registrazione.” Quando la restrizione sugli agenti di registrazione è abilitata dagli amministratori, impostandola su “Limitare gli agenti di registrazione,” la configurazione predefinita rimane estremamente permissiva. Consente a Tutti di accedere per registrarsi in tutti i modelli come chiunque.
Il descrittore di sicurezza sui modelli di certificato definisce le autorizzazioni specifiche che i principali AD possiedono riguardo al modello.
Se un attaccante possiede le autorizzazioni necessarie per modificare un modello e istituire eventuali misconfigurazioni sfruttabili delineate nelle sezioni precedenti, l'escalation dei privilegi potrebbe essere facilitata.
Le autorizzazioni note applicabili ai modelli di certificato includono:
Proprietario: Concede il controllo implicito sull'oggetto, consentendo la modifica di qualsiasi attributo.
FullControl: Abilita l'autorità completa sull'oggetto, inclusa la capacità di modificare qualsiasi attributo.
WriteOwner: Permette la modifica del proprietario dell'oggetto a un principale sotto il controllo dell'attaccante.
WriteDacl: Consente la regolazione dei controlli di accesso, potenzialmente concedendo a un attaccante FullControl.
WriteProperty: Autorizza la modifica di qualsiasi proprietà dell'oggetto.
Un esempio di privesc come il precedente:
ESC4 è quando un utente ha privilegi di scrittura su un modello di certificato. Questo può essere abusato, ad esempio, per sovrascrivere la configurazione del modello di certificato per renderlo vulnerabile a ESC1.
Come possiamo vedere nel percorso sopra, solo JOHNPC ha questi privilegi, ma il nostro utente JOHN ha il nuovo edge AddKeyCredentialLink verso JOHNPC. Poiché questa tecnica è correlata ai certificati, ho implementato anche questo attacco, noto come Shadow Credentials. Ecco un piccolo assaggio del comando shadow auto di Certipy per recuperare l'hash NT della vittima.
Certipy può sovrascrivere la configurazione di un modello di certificato con un singolo comando. Per default, Certipy sovrascriverà la configurazione per renderla vulnerabile a ESC1. Possiamo anche specificare il -save-old parametro per salvare la vecchia configurazione, che sarà utile per ripristinare la configurazione dopo il nostro attacco.
La vasta rete di relazioni interconnesse basate su ACL, che include diversi oggetti oltre ai modelli di certificato e all'autorità di certificazione, può influenzare la sicurezza dell'intero sistema AD CS. Questi oggetti, che possono influenzare significativamente la sicurezza, comprendono:
L'oggetto computer AD del server CA, che può essere compromesso attraverso meccanismi come S4U2Self o S4U2Proxy.
Il server RPC/DCOM del server CA.
Qualsiasi oggetto o contenitore AD discendente all'interno del percorso del contenitore specifico CN=Public Key Services,CN=Services,CN=Configuration,DC=<DOMAIN>,DC=<COM>. Questo percorso include, ma non è limitato a, contenitori e oggetti come il contenitore dei modelli di certificato, il contenitore delle autorità di certificazione, l'oggetto NTAuthCertificates e il contenitore dei servizi di registrazione.
La sicurezza del sistema PKI può essere compromessa se un attaccante a bassa privilegiatura riesce a ottenere il controllo su uno di questi componenti critici.
L'argomento discusso nel post di CQure Academy tocca anche le implicazioni del flag EDITF_ATTRIBUTESUBJECTALTNAME2, come delineato da Microsoft. Questa configurazione, quando attivata su un'Autorità di Certificazione (CA), consente l'inclusione di valori definiti dall'utente nel nome alternativo del soggetto per qualsiasi richiesta, comprese quelle costruite da Active Directory®. Di conseguenza, questa disposizione consente a un intruso di registrarsi attraverso qualsiasi modello impostato per l'autenticazione del dominio—specificamente quelli aperti alla registrazione di utenti non privilegiati, come il modello standard per gli utenti. Di conseguenza, un certificato può essere ottenuto, consentendo all'intruso di autenticarsi come amministratore di dominio o qualsiasi altra entità attiva all'interno del dominio.
Nota: L'approccio per aggiungere nomi alternativi in una Richiesta di Firma del Certificato (CSR), attraverso l'argomento -attrib "SAN:" in certreq.exe (definito come “Name Value Pairs”), presenta un contrasto rispetto alla strategia di sfruttamento degli SAN in ESC1. Qui, la distinzione risiede in come le informazioni sull'account sono incapsulate—all'interno di un attributo del certificato, piuttosto che in un'estensione.
Per verificare se l'impostazione è attivata, le organizzazioni possono utilizzare il seguente comando con certutil.exe:
Questa operazione impiega essenzialmente l'accesso remoto al registro, quindi, un approccio alternativo potrebbe essere:
Strumenti come Certify e Certipy sono in grado di rilevare questa misconfigurazione e sfruttarla:
Per modificare queste impostazioni, assumendo di possedere diritti amministrativi di dominio o equivalenti, il seguente comando può essere eseguito da qualsiasi workstation:
Per disabilitare questa configurazione nel tuo ambiente, il flag può essere rimosso con:
Dopo gli aggiornamenti di sicurezza di maggio 2022, i certificati emessi di recente conterranno un estensione di sicurezza che incorpora la proprietà objectSid del richiedente. Per ESC1, questo SID è derivato dal SAN specificato. Tuttavia, per ESC6, il SID rispecchia il objectSid del richiedente, non il SAN.
Per sfruttare ESC6, è essenziale che il sistema sia suscettibile a ESC10 (Mappature di Certificati Deboli), che dà priorità al SAN rispetto alla nuova estensione di sicurezza.
Il controllo accesso per un'autorità di certificazione è mantenuto attraverso un insieme di permessi che governano le azioni della CA. Questi permessi possono essere visualizzati accedendo a certsrv.msc, facendo clic destro su una CA, selezionando proprietà e poi navigando alla scheda Sicurezza. Inoltre, i permessi possono essere enumerati utilizzando il modulo PSPKI con comandi come:
Questo fornisce informazioni sui diritti principali, ovvero ManageCA e ManageCertificates, correlati ai ruoli di “amministratore CA” e “gestore certificati” rispettivamente.
Avere diritti ManageCA su un'autorità di certificazione consente al principale di manipolare le impostazioni da remoto utilizzando PSPKI. Questo include l'attivazione del flag EDITF_ATTRIBUTESUBJECTALTNAME2 per consentire la specifica SAN in qualsiasi modello, un aspetto critico dell'escalation del dominio.
La semplificazione di questo processo è realizzabile attraverso l'uso del cmdlet Enable-PolicyModuleFlag di PSPKI, che consente modifiche senza interazione diretta con l'interfaccia grafica.
Il possesso di diritti ManageCertificates facilita l'approvazione delle richieste in sospeso, eludendo efficacemente la protezione "approvazione del gestore certificati CA".
Una combinazione dei moduli Certify e PSPKI può essere utilizzata per richiedere, approvare e scaricare un certificato:
Nel precedente attacco Manage CA sono stati utilizzati i permessi per abilitare il flag EDITF_ATTRIBUTESUBJECTALTNAME2 per eseguire l'attacco ESC6, ma questo non avrà alcun effetto fino a quando il servizio CA (CertSvc) non verrà riavviato. Quando un utente ha il diritto di accesso Manage CA, l'utente è anche autorizzato a riavviare il servizio. Tuttavia, non significa che l'utente possa riavviare il servizio da remoto. Inoltre, l'ESC6 potrebbe non funzionare immediatamente nella maggior parte degli ambienti patchati a causa degli aggiornamenti di sicurezza di maggio 2022.
Pertanto, qui viene presentato un altro attacco.
Prerequisiti:
Solo permesso ManageCA
Permesso Manage Certificates (può essere concesso da ManageCA)
Il modello di certificato SubCA deve essere abilitato (può essere abilitato da ManageCA)
La tecnica si basa sul fatto che gli utenti con il diritto di accesso Manage CA e Manage Certificates possono emissione di richieste di certificato non riuscite. Il modello di certificato SubCA è vulnerabile a ESC1, ma solo gli amministratori possono iscriversi al modello. Pertanto, un utente può richiedere di iscriversi al SubCA - che sarà negata - ma poi emessa dal manager successivamente.
Puoi concederti il diritto di accesso Manage Certificates aggiungendo il tuo utente come nuovo ufficiale.
Il SubCA template può essere abilitato sulla CA con il parametro -enable-template. Per impostazione predefinita, il template SubCA è abilitato.
