AD CS Domain Escalation
Questa è una sintesi delle sezioni sulle tecniche di escalation dei post:
Modelli di Certificato Malconfigurati - ESC1
Spiegazione
Modelli di Certificato Malconfigurati - ESC1 Spiegati
I diritti di iscrizione sono concessi agli utenti a basso privilegio dall'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 basso privilegio di ottenere i diritti di iscrizione.
I modelli di certificato sono configurati per definire EKU che facilitano l'autenticazione:
Gli identificatori di Extended Key Usage (EKU) come Autenticazione Client (OID 1.3.6.1.5.5.7.3.2), Autenticazione Client PKINIT (1.3.6.1.5.2.3.4), Accesso Smart Card (OID 1.3.6.1.4.1.311.20.2.2), Qualsiasi Scopo (OID 2.5.29.37.0), o nessun EKU (SubCA) sono inclusi.
La possibilità per i richiedenti di includere un subjectAltName nella Richiesta di Firma del Certificato (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 un CSR, è possibile richiedere un certificato per impersonare qualsiasi utente (ad esempio, un amministratore di dominio). Se un richiedente può specificare un SAN è indicato nell'oggetto AD del modello di certificato attraverso la proprietà
mspki-certificate-name-flag. Questa proprietà è una bitmask, e la presenza del flagCT_FLAG_ENROLLEE_SUPPLIES_SUBJECTpermette al richiedente di specificare il SAN.
La configurazione descritta consente agli utenti a basso privilegio di richiedere certificati con qualsiasi SAN a scelta, consentendo l'autenticazione come qualsiasi principale di dominio tramite Kerberos o SChannel.
Questa funzionalità è talvolta abilitata per supportare la generazione on-the-fly 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 avviene quando un modello di certificato esistente (come il modello WebServer, che ha CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT abilitato) viene duplicato e quindi modificato per includere un OID di autenticazione.
Abuso
Per trovare modelli di certificato vulnerabili è possibile eseguire:
Per abusare di questa vulnerabilità per impersonare un amministratore si potrebbe eseguire:
Quindi puoi trasformare il certificato generato nel formato .pfx e usarlo per autenticarti nuovamente utilizzando Rubeus o certipy:
I binari 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, in particolare quelli che non richiedono approvazione o firme, che possiedono un EKU di autenticazione del client o di accesso con smart card, e con il flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT abilitato, può essere eseguita eseguendo la seguente query LDAP:
Modelli di certificato configurati in modo errato - ESC2
Spiegazione
Il secondo scenario di abuso è una variazione del primo:
I diritti di registrazione sono concessi agli utenti a basso privilegio dall'Enterprise CA.
Il requisito di approvazione del manager è disabilitato.
Non viene richiesta la firma autorizzata.
Un descrittore di sicurezza eccessivamente permessivo sul modello di certificato concede i diritti di registrazione del certificato agli utenti a basso privilegio.
Il modello di certificato è definito per includere l'EKU di qualsiasi scopo o nessun EKU.
L'EKU di qualsiasi scopo permette di ottenere un certificato 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 senza EKU, che agiscono come certificati di CA subordinate, possono essere sfruttati per qualsiasi scopo e possono anche essere utilizzati per firmare nuovi certificati. Di conseguenza, un attaccante potrebbe specificare EKU o campi arbitrari nei nuovi certificati utilizzando un certificato di 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 esempio, 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, è possibile eseguire la seguente query LDAP:
Modelli di agente di registrazione non configurati correttamente - ESC3
Spiegazione
Questo scenario è simile al primo e al secondo, ma abusa di un EKU diverso (Agente di Richiesta di Certificato) e 2 modelli diversi (quindi ha 2 insiemi di requisiti),
Il EKU dell'Agente di Richiesta di Certificato (OID 1.3.6.1.4.1.311.20.2.1), noto come Agente di Registrazione nella documentazione di Microsoft, consente a un principale di registrarsi per un certificato per conto di un altro utente.
L'"agente di registrazione" si registra in un tale modello e utilizza il certificato risultante per firmare congiuntamente una CSR per conto dell'altro utente. Invia quindi la CSR congiuntamente firmata alla CA, registrandosi in un modello che consente "registrazioni per conto di", e la CA risponde con un certificato appartenente all'utente "altro".
Requisiti 1:
I diritti di registrazione sono concessi a utenti a basso livello privilegiato dall'Enterprise CA.
L'approvazione del manager è omessa.
Nessun requisito per firme autorizzate.
Il descrittore di sicurezza del modello di certificato è eccessivamente permissivo, concedendo diritti di registrazione a utenti a basso livello privilegiato.
Il modello di certificato include l'EKU dell'Agente di Richiesta di Certificato, abilitando la richiesta di altri modelli di certificato per conto di altri principali.
Requisiti 2:
L'Enterprise CA concede diritti di registrazione a utenti a basso livello privilegiato.
Viene aggirata l'approvazione del manager.
La versione dello schema del modello è 1 o superiore a 2, e specifica un Requisito di Emissione della Policy dell'Applicazione che richiede l'EKU dell'Agente di Richiesta di Certificato.
Un EKU definito nel modello di certificato consente l'autenticazione di dominio.
Le restrizioni per gli agenti di registrazione non sono applicate sulla CA.
Abuso
Puoi utilizzare Certify o Certipy per abusare di questo scenario:
Gli utenti che sono autorizzati a ottenere un certificato di agente di registrazione, i modelli nei quali gli agenti di registrazione sono autorizzati ad iscriversi e gli account per conto dei quali l'agente di registrazione può agire possono essere vincolati dalle CA aziendali. Ciò viene realizzato aprendo il certsrc.msc snap-in, facendo clic con il pulsante destro del mouse sulla CA, cliccando su Proprietà e quindi navigando nella scheda "Agenti di iscrizione".
Tuttavia, si nota che l'impostazione predefinita per le CA è "Non limitare gli agenti di iscrizione". Quando la restrizione sugli agenti di iscrizione è abilitata dagli amministratori, impostandola su "Limita gli agenti di iscrizione", la configurazione predefinita rimane estremamente permissiva. Consente a Tutti l'accesso per iscriversi in tutti i modelli come chiunque.
Controllo degli Accessi ai Modelli di Certificati Vulnerabili - ESC4
Spiegazione
Il descrittore di sicurezza sui modelli di certificati definisce i permessi specifici che i principali AD possiedono riguardo al modello.
Se un attaccante possiede i permessi necessari per modificare un modello e istituire eventuali configurazioni errate sfruttabili descritte nelle sezioni precedenti, potrebbe facilitare l'escalation dei privilegi.
I permessi rilevanti applicabili ai modelli di certificati includono:
Proprietario: Concede il controllo implicito sull'oggetto, consentendo la modifica di qualsiasi attributo.
ControlloCompleto: Abilita l'autorità completa sull'oggetto, compresa la capacità di modificare qualsiasi attributo.
ScriviProprietario: Consente la modifica del proprietario dell'oggetto a un principale sotto il controllo dell'attaccante.
ScriviDacl: Consente l'aggiustamento dei controlli di accesso, potenzialmente concedendo all'attaccante il ControlloCompleto.
ScriviProprietà: Autorizza la modifica di qualsiasi proprietà dell'oggetto.
Abuso
Un esempio di privesc come il precedente:
ESC4 è quando un utente ha privilegi di scrittura su un modello di certificato. Questo può ad esempio essere abusato 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 margine AddKeyCredentialLink a JOHNPC. Poiché questa tecnica è legata ai certificati, ho implementato anche questo attacco, noto come Shadow Credentials. Ecco un piccolo anteprima 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 parametro -save-old per salvare la vecchia configurazione, che sarà utile per ripristinare la configurazione dopo il nostro attacco.
Controllo dell'Accesso agli Oggetti PKI Vulnerabili - ESC5
Spiegazione
La vasta rete di relazioni basate su ACL, che include diversi oggetti oltre ai modelli di certificati e all'autorità di certificazione, può influenzare la sicurezza dell'intero sistema AD CS. Questi oggetti, che possono influenzare significativamente la sicurezza, includono:
L'oggetto computer AD del server CA, che potrebbe 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=Servizi chiave pubbliche,CN=Servizi,CN=Configurazione,DC=<DOMINIO>,DC=<COM>. Questo percorso include, ma non si limita a, contenitori e oggetti come il contenitore Modelli di certificati, il contenitore Autorità di certificazione, l'oggetto NTAuthCertificates e il contenitore Servizi di iscrizione.
La sicurezza del sistema PKI può essere compromessa se un attaccante a basso livello riesce a ottenere il controllo su uno di questi componenti critici.
EDITF_ATTRIBUTESUBJECTALTNAME2 - ESC6
Spiegazione
L'argomento discusso nel post di CQure Academy tratta anche le implicazioni del flag EDITF_ATTRIBUTESUBJECTALTNAME2, come delineato da Microsoft. Questa configurazione, quando attivata su un'Entità di Certificazione (CA), permette 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 iscriversi attraverso qualsiasi modello configurato per l'autenticazione di dominio—in particolare quelli aperti all'iscrizione degli utenti non privilegiati, come il modello Utente standard. Di conseguenza, un certificato può essere ottenuto, consentendo all'intruso di autenticarsi come un 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), tramite l'argomento -attrib "SAN:" in certreq.exe (chiamati "Coppie Nome Valore"), presenta un contrasto rispetto alla strategia di sfruttamento dei SAN in ESC1. Qui, la distinzione risiede in come le informazioni dell'account sono incapsulate—all'interno di un attributo del certificato, piuttosto che in un'estensione.
Abuso
Per verificare se l'impostazione è attivata, le organizzazioni possono utilizzare il seguente comando con certutil.exe:
Questa operazione impiega essenzialmente l'accesso al registro remoto, quindi un approccio alternativo potrebbe essere:
Gli strumenti come Certify e Certipy sono in grado di rilevare questa errata configurazione ed sfruttarla:
Per modificare queste impostazioni, assumendo di possedere i diritti amministrativi di dominio o equivalenti, il comando seguente può essere eseguito da qualsiasi postazione di lavoro:
Per disabilitare questa configurazione nel tuo ambiente, il flag può essere rimosso con:
Dopo gli aggiornamenti di sicurezza di maggio 2022, i certificati appena emessi 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 riflette l'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.
Controllo di Accesso Vulnerabile all'Autorità di Certificazione - ESC7
Attacco 1
Spiegazione
Il controllo di accesso per un'autorità di certificazione è mantenuto attraverso un insieme di autorizzazioni che regolano le azioni della CA. Queste autorizzazioni possono essere visualizzate accedendo a certsrv.msc, facendo clic con il tasto destro su una CA, selezionando Proprietà e quindi navigando nella scheda Sicurezza. Inoltre, le autorizzazioni possono essere enumerate utilizzando il modulo PSPKI con comandi come:
Questo fornisce approfondimenti sui diritti principali, ovvero ManageCA e ManageCertificates, correlati ai ruoli di "amministratore CA" e "Gestore certificati" rispettivamente.
Abuso
Avere i diritti ManageCA su un'autorità di certificazione consente al principale di manipolare le impostazioni a distanza utilizzando PSPKI. Ciò include la commutazione del flag EDITF_ATTRIBUTESUBJECTALTNAME2 per consentire la specifica SAN in qualsiasi modello, un aspetto critico dell'escalation di dominio.
La semplificazione di questo processo è realizzabile tramite l'uso del cmdlet Enable-PolicyModuleFlag di PSPKI, consentendo modifiche senza interazione diretta con l'interfaccia grafica.
Il possesso dei 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:
Attacco 2
Spiegazione
Nell'attacco precedente sono stati utilizzati i permessi Manage CA per abilitare il flag EDITF_ATTRIBUTESUBJECTALTNAME2 per eseguire l'attacco ESC6, ma ciò non avrà alcun effetto fino a quando il servizio CA (CertSvc) non verrà riavviato. Quando un utente ha il diritto di accesso Manage CA, all'utente è anche consentito di riavviare il servizio. Tuttavia, ciò non significa che l'utente possa riavviare il servizio in remoto. Inoltre, ESC6 potrebbe non funzionare immediatamente nella maggior parte degli ambienti aggiornati a causa degli aggiornamenti di sicurezza di maggio 2022.
Pertanto, qui viene presentato un altro attacco.
Prerequisiti:
Solo il permesso
ManageCAPermesso
Manage Certificates(può essere concesso daManageCA)Il modello di certificato
SubCAdeve essere abilitato (può essere abilitato daManageCA)
La tecnica si basa sul fatto che gli utenti con il diritto di accesso Manage CA e Manage Certificates possono emettere richieste di certificato fallite. Il modello di certificato SubCA è vulnerabile a ESC1, ma solo gli amministratori possono iscriversi al modello. Pertanto, un utente può richiedere di iscriversi alla SubCA - che verrà negata - ma successivamente emessa dal responsabile.
Abuso
Puoi concederti il permesso Manage Certificates aggiungendo il tuo utente come nuovo ufficiale.
Il modello SubCA può essere abilitato sul CA con il parametro -enable-template. Per impostazione predefinita, il modello SubCA è abilitato.
Se abbiamo soddisfatto i prerequisiti per questo attacco, possiamo iniziare richiedendo un certificato basato sul modello SubCA.
Questa richiesta verrà rifiutata, ma salveremo la chiave privata e annoteremo l'ID della richiesta.
Con il nostro Gestisci CA e Gestisci Certificati, possiamo quindi emettere la richiesta di certificato fallita con il comando ca e il parametro -issue-request <ID richiesta>.
E infine, possiamo recuperare il certificato emesso con il comando req e il parametro -retrieve <ID richiesta>.
NTLM Relay agli Endpoint HTTP di AD CS - ESC8
Spiegazione
In ambienti in cui è installato AD CS, se esiste un endpoint di registrazione web vulnerabile e almeno un modello di certificato è pubblicato che permette la registrazione di computer di dominio e l'autenticazione del client (come ad esempio il modello predefinito Machine), diventa possibile che qualsiasi computer con il servizio spooler attivo possa essere compromesso da un attaccante!
Diversi metodi di registrazione basati su HTTP sono supportati da AD CS, resi disponibili attraverso ruoli server aggiuntivi che gli amministratori possono installare. Queste interfacce per la registrazione di certificati basata su HTTP sono suscettibili a attacchi di relay NTLM. Un attaccante, da una macchina compromessa, può impersonare qualsiasi account AD che si autentica tramite NTLM in ingresso. Mentre impersona l'account della vittima, questi interfacce web possono essere accessibili da un attaccante per richiedere un certificato di autenticazione del client utilizzando i modelli di certificato User o Machine.
L'interfaccia di registrazione web (un'applicazione ASP più vecchia disponibile su
http://<caserver>/certsrv/), predefinita solo a HTTP, che non offre protezione contro gli attacchi di relay NTLM. Inoltre, permette esplicitamente solo l'autenticazione NTLM attraverso l'intestazione HTTP di Autorizzazione, rendendo metodi di autenticazione più sicuri come Kerberos inapplicabili.Il Servizio di Registrazione Certificati (CES), il Servizio Web di Politica di Registrazione Certificati (CEP) e il Servizio di Registrazione Dispositivi di Rete (NDES) supportano per impostazione predefinita l'autenticazione di negoziazione tramite l'intestazione HTTP di Autorizzazione. L'autenticazione di negoziazione supporta sia Kerberos che NTLM, consentendo a un attaccante di declassare a NTLM durante gli attacchi di relay. Anche se questi servizi web abilitano HTTPS per impostazione predefinita, HTTPS da solo non protegge contro gli attacchi di relay NTLM. La protezione dagli attacchi di relay NTLM per i servizi HTTPS è possibile solo quando HTTPS è combinato con il binding del canale. Sfortunatamente, AD CS non attiva la Protezione Estesa per l'Autenticazione su IIS, che è richiesta per il binding del canale.
Un problema comune con gli attacchi di relay NTLM è la breve durata delle sessioni NTLM e l'incapacità dell'attaccante di interagire con servizi che richiedono la firma NTLM.
Tuttavia, questa limitazione viene superata sfruttando un attacco di relay NTLM per acquisire un certificato per l'utente, poiché il periodo di validità del certificato determina la durata della sessione e il certificato può essere utilizzato con servizi che richiedono la firma NTLM. Per istruzioni sull'utilizzo di un certificato rubato, fare riferimento a:
pageAD CS Account PersistenceUn'altra limitazione degli attacchi di relay NTLM è che una macchina controllata dall'attaccante deve essere autenticata da un account vittima. L'attaccante potrebbe aspettare o tentare di forzare questa autenticazione:
pageForce NTLM Privileged AuthenticationAbuso
Certify’s cas enumera gli endpoint HTTP di AD CS abilitati:
La proprietà msPKI-Enrollment-Servers viene utilizzata dalle Autorità di Certificazione (CA) aziendali per memorizzare gli endpoint del servizio di registrazione dei certificati (CES). Questi endpoint possono essere analizzati e elencati utilizzando lo strumento Certutil.exe:
```powershell Import-Module PSPKI Get-CertificationAuthority | select Name,Enroll* | Format-List * ```
Abuso con Certify
Abuso con Certipy
La richiesta di un certificato viene effettuata da Certipy per impostazione predefinita in base al modello Machine o User, determinato dal fatto che il nome dell'account inoltrato termini con $. La specifica di un modello alternativo può essere ottenuta tramite l'uso del parametro -template.
Una tecnica come PetitPotam può quindi essere impiegata per costringere l'autenticazione. Quando si tratta di controller di dominio, è richiesta la specifica di -template DomainController.
Nessuna estensione di sicurezza - ESC9
Spiegazione
Il nuovo valore CT_FLAG_NO_SECURITY_EXTENSION (0x80000) per msPKI-Enrollment-Flag, noto come ESC9, impedisce l'inclusione della nuova estensione di sicurezza szOID_NTDS_CA_SECURITY_EXT in un certificato. Questo flag diventa rilevante quando StrongCertificateBindingEnforcement è impostato su 1 (impostazione predefinita), in contrasto con un'impostazione di 2. La sua importanza aumenta in scenari in cui potrebbe essere sfruttato un mapping del certificato più debole per Kerberos o Schannel (come in ESC10), dato che l'assenza di ESC9 non altererebbe i requisiti.
Le condizioni in cui diventa significativa l'impostazione di questo flag includono:
StrongCertificateBindingEnforcementnon è regolato su2(con il valore predefinito di1), oCertificateMappingMethodsinclude il flagUPN.Il certificato è contrassegnato con il flag
CT_FLAG_NO_SECURITY_EXTENSIONall'interno dell'impostazione dimsPKI-Enrollment-Flag.Qualsiasi EKU di autenticazione del client è specificato nel certificato.
Sono disponibili le autorizzazioni
GenericWritesu qualsiasi account per comprometterne un altro.
Scenario di abuso
Supponiamo che John@corp.local detenga le autorizzazioni GenericWrite su Jane@corp.local, con l'obiettivo di compromettere Administrator@corp.local. Il modello di certificato ESC9, che Jane@corp.local è autorizzata ad iscriversi, è configurato con il flag CT_FLAG_NO_SECURITY_EXTENSION nelle sue impostazioni di msPKI-Enrollment-Flag.
Inizialmente, l'hash di Jane viene acquisito utilizzando le Credenziali Ombra, grazie al GenericWrite di John:
Successivamente, il userPrincipalName di Jane viene modificato in Administrator, omettendo deliberatamente la parte di dominio @corp.local:
Questa modifica non viola vincoli, dato che Administrator@corp.local rimane distinto come userPrincipalName di Administrator.
Seguendo questo, il modello di certificato ESC9, contrassegnato come vulnerabile, viene richiesto come Jane:
È notato che il userPrincipalName del certificato riflette Administrator, privo di alcun "object SID".
Il userPrincipalName di Jane viene quindi ripristinato al suo originale, Jane@corp.local:
Provare l'autenticazione con il certificato emesso restituisce ora l'hash NT di Administrator@corp.local. Il comando deve includere -domain <domain> a causa della mancanza di specifica del dominio nel certificato:
Mapping certificati deboli - ESC10
Spiegazione
Due valori chiave del registro sul controller di dominio sono indicati da ESC10:
Il valore predefinito per
CertificateMappingMethodssottoHKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\SecurityProviders\Schannelè0x18(0x8 | 0x10), precedentemente impostato su0x1F.L'impostazione predefinita per
StrongCertificateBindingEnforcementsottoHKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Kdcè1, precedentemente0.
Caso 1
Quando StrongCertificateBindingEnforcement è configurato come 0.
Caso 2
Se CertificateMappingMethods include il bit UPN (0x4).
Caso di abuso 1
Con StrongCertificateBindingEnforcement configurato come 0, un account A con permessi GenericWrite può essere sfruttato per compromettere qualsiasi account B.
Ad esempio, avendo i permessi GenericWrite su Jane@corp.local, un attaccante mira a compromettere Administrator@corp.local. La procedura riflette ESC9, consentendo l'utilizzo di qualsiasi modello di certificato.
Inizialmente, l'hash di Jane viene recuperato utilizzando le Credenziali Ombra, sfruttando il GenericWrite.
Successivamente, il userPrincipalName di Jane viene modificato in Administrator, omettendo deliberatamente la parte @corp.local per evitare una violazione vincolante.
Seguendo questo, viene richiesto un certificato che abilita l'autenticazione del client come Jane, utilizzando il modello predefinito Utente.
userPrincipalName di Jane viene quindi ripristinato al suo valore originale, Jane@corp.local.
Autenticarsi con il certificato ottenuto restituirà l'hash NT di Administrator@corp.local, rendendo necessaria la specifica del dominio nel comando a causa dell'assenza di dettagli del dominio nel certificato.
Caso di Abuso 2
Con il CertificateMappingMethods che contiene il flag UPN (0x4), un account A con permessi GenericWrite può compromettere qualsiasi account B che non abbia una proprietà userPrincipalName, inclusi gli account macchina e l'amministratore del dominio incorporato Administrator.
Qui, l'obiettivo è compromettere DC$@corp.local, iniziando con l'ottenimento dell'hash di Jane attraverso le Credenziali Ombra, sfruttando il GenericWrite.
Jane's userPrincipalName viene quindi impostato su DC$@corp.local.
Un certificato per l'autenticazione del client viene richiesto come Jane utilizzando il modello predefinito Utente.
userPrincipalName di Jane viene ripristinato al suo valore originale dopo questo processo.
Per autenticarsi tramite Schannel, viene utilizzata l'opzione -ldap-shell di Certipy, che indica il successo dell'autenticazione come u:CORP\DC$.
Attraverso la shell LDAP, comandi come set_rbcd abilitano gli attacchi di Delega Vincolata basata su Risorse (RBCD), compromettendo potenzialmente il controller di dominio.
Questa vulnerabilità si estende anche a qualsiasi account utente privo di un userPrincipalName o in cui non corrisponde al sAMAccountName, con il predefinito Administrator@corp.local che è un obiettivo principale a causa dei suoi privilegi LDAP elevati e dell'assenza di un userPrincipalName per impostazione predefinita.
Inoltro NTLM a ICPR - ESC11
Spiegazione
Se il server CA non è configurato con IF_ENFORCEENCRYPTICERTREQUEST, è possibile effettuare attacchi di inoltro NTLM senza firma tramite il servizio RPC. Riferimento qui.
È possibile utilizzare certipy per enumerare se Enforce Encryption for Requests è disabilitato e certipy mostrerà le vulnerabilità ESC11.
Scenario di abuso
È necessario configurare un server di rilancio:
Nota: Per i controller di dominio, dobbiamo specificare -template in DomainController.
O utilizzando il fork di sploutchy di impacket:
Accesso alla shell al CA ADCS con YubiHSM - ESC12
Spiegazione
Gli amministratori possono configurare l'Autorità di Certificazione per memorizzarla su un dispositivo esterno come il "Yubico YubiHSM2".
Se il dispositivo USB è collegato al server CA tramite una porta USB, o un server di dispositivo USB nel caso in cui il server CA sia una macchina virtuale, è necessaria una chiave di autenticazione (a volte indicata come "password") affinché il Key Storage Provider generi e utilizzi le chiavi nel YubiHSM.
Questa chiave/password è memorizzata nel registro in HKEY_LOCAL_MACHINE\SOFTWARE\Yubico\YubiHSM\AuthKeysetPassword in chiaro.
Riferimento qui.
Scenario di Abuso
Se la chiave privata del CA è memorizzata su un dispositivo USB fisico quando si ha accesso alla shell, è possibile recuperare la chiave.
In primo luogo, è necessario ottenere il certificato del CA (questo è pubblico) e poi:
Abuso del collegamento del gruppo OID - ESC13
Spiegazione
L'attributo msPKI-Certificate-Policy consente di aggiungere la policy di rilascio al modello del certificato. Gli oggetti msPKI-Enterprise-Oid responsabili delle policy di rilascio possono essere scoperti nel Contesto di Nominazione della Configurazione (CN=OID,CN=Public Key Services,CN=Services) del contenitore OID PKI. Una policy può essere collegata a un gruppo AD utilizzando l'attributo msDS-OIDToGroupLink di questo oggetto, consentendo a un sistema di autorizzare un utente che presenta il certificato come se fosse un membro del gruppo. Riferimento qui.
In altre parole, quando un utente ha il permesso di richiedere un certificato e il certificato è collegato a un gruppo OID, l'utente può ereditare i privilegi di questo gruppo.
Usa Check-ADCSESC13.ps1 per trovare OIDToGroupLink:
Scenario di Abuso
Trova un'autorizzazione utente che può utilizzare certipy find o Certify.exe find /showAllPermissions.
Se John ha il permesso di iscriversi a VulnerableTemplate, l'utente può ereditare i privilegi del gruppo VulnerableGroup.
Tutto ciò che deve fare è specificare il modello e otterrà un certificato con i diritti OIDToGroupLink.
Compromissione delle Foreste con Certificati Spiegata in Voce Passiva
Violazione delle Trust delle Foreste tramite CA Compromesse
La configurazione per l'iscrizione tra foreste è resa relativamente semplice. Il certificato CA radice della foresta delle risorse è pubblicato nelle foreste degli account dagli amministratori, e i certificati CA enterprise della foresta delle risorse sono aggiunti ai contenitori NTAuthCertificates e AIA in ciascuna foresta dell'account. Per chiarire, questo accordo concede al CA nella foresta delle risorse il controllo completo su tutte le altre foreste per le quali gestisce la PKI. Se questo CA viene compromesso dagli attaccanti, i certificati per tutti gli utenti sia nella foresta delle risorse che nelle foreste degli account potrebbero essere falsificati da loro, violando così il confine di sicurezza della foresta.
Privilegi di Iscrizione Concessi a Principi Stranieri
In ambienti multi-foresta, è necessaria cautela riguardo ai CA enterprise che pubblicano modelli di certificati che consentono agli Utenti Autenticati o ai principi stranieri (utenti/gruppi esterni alla foresta a cui appartiene il CA enterprise) diritti di iscrizione e modifica. All'autenticazione attraverso una trust, il SID degli Utenti Autenticati viene aggiunto al token dell'utente da AD. Pertanto, se un dominio possiede un CA enterprise con un modello che consente ai Utenti Autenticati diritti di iscrizione, potenzialmente un modello potrebbe essere iscritto da un utente proveniente da una foresta diversa. Allo stesso modo, se i diritti di iscrizione vengono esplicitamente concessi a un principio straniero da un modello, viene così creato un rapporto di controllo degli accessi tra foreste, consentendo a un principio di una foresta di iscriversi a un modello proveniente da un'altra foresta.
Entrambe le situazioni portano a un aumento della superficie di attacco da una foresta all'altra. Le impostazioni del modello di certificato potrebbero essere sfruttate da un attaccante per ottenere privilegi aggiuntivi in un dominio esterno.
Last updated
