Servizi certificati AD: Impostazioni rischiose e loro rimedio

I servizi di certificato di Active Directory esistono da molto tempo, ma le risorse per apprenderli non sono eccellenti. Di conseguenza, spesso presentano configurazioni errate che sono un vettore crescente per gli attacchi. Infatti, SpecterOps ha rilasciato un whitepaper che dettaglia una serie di configurazioni errate e potenziali attacchi e fornisce consigli per il rafforzamento. In questo blog, copro diverse impostazioni che possono essere configurate in modo errato e come individuarle, offro diverse opzioni per ulteriori rafforzamenti della sicurezza e spiego come utilizzare uno strumento gratuito per controllare il proprio ambiente.

Sfondo

Quando viene emesso un certificato basato sull'autenticazione a un'identità, il certificato può essere utilizzato per autenticarsi come l'identità impostata nel Subject Alternative Name (SAN); di solito si tratta di un UPN o di un nome DNS. Il certificato viene poi utilizzato al posto di una password per l'autenticazione iniziale. Il riferimento tecnico per questa autenticazione iniziale è RFC4556 se desideri scoprire più dettagli.

Una volta emesso un certificato basato sull'autenticazione, questo può essere utilizzato per autenticarsi come il soggetto fino a quando non viene revocato o scaduto. Questo aggirerà i piani di risposta agli incidenti che si basano su strategie come il reimpostare la password dell'utente per espellere un attaccante; l'attaccante può avere accesso persistente all'account a meno che i certificati non vengano anch'essi revocati.

Impostazioni dei template rischiose

Ecco alcune delle impostazioni dei modelli di certificato che possono portare a configurazioni errate.

EKU basati sull'autenticazione

Prima, cercare gli Usi Chiave Potenziati (EKUs) che abilitano qualsiasi tipo di autenticazione a livello di dominio. Ecco un breve elenco:

• Any Purpose (2.5.29.37.0)
• SubCA (Nessuno)
• Autenticazione del cliente (1.3.6.1.5.5.7.3.2)
• Autenticazione client PKINIT (1.3.6.1.5.2.3.4)
• Smart Card Logon (1.3.6.1.4.1.311.20.2.2)

Il modo più semplice per trovare manualmente tutti i modelli di certificato che consentono ciò è aprire lo snap-in MMC dell'Autorità di Certificazione, connettersi alla propria Autorità di Certificazione, guardare la sezione Modelli di Certificato e scansionare la Colonna Scopo Inteso per qualsiasi EKU di autenticazione. Ad esempio, la figura sottostante mostra che i modelli Computer, Copia di Accesso Smartcard e entrambi i modelli di Controller di Dominio contengono almeno uno dei PKU.

Dopo aver affrontato i template che trovi, assicurati di tenere presente che ci sono modi per abusare anche dei certificati normali. Ad esempio, la funzione Get-SmartCardCertificate di PoshADCS può modificare un template, richiedere certificati per esso e poi annullare le modifiche al template.

“Bandiera dell'oggetto 'Enrollee Supplies Subject'”

Quando il flag CT_FLAG_ENROLLEE_SUPPLIES_SUBJECT è presente nella proprietà mspki-certificate-name-flag, l'iscritto al certificato può fornire il proprio Nome Soggetto alternativo nella richiesta di firma del certificato. Questo significa che qualsiasi utente autorizzato ad iscriversi a un certificato con questa impostazione può richiedere un certificato come qualsiasi utente nella rete, incluso un utente privilegiato.

È possibile verificare questa opzione nella console del Modello di Certificato; si trova sotto la scheda Nome Soggetto come opzione radio “Fornire nella richiesta”:

In alternativa, puoi utilizzare un comando PowerShell come il seguente per ottenere i template da AD e verificare se il flag è impostato nel certificato:

      Get-ADobject -Filter { ObjectClass -eq "PKIcertificateTemplate" } -SearchBase (Get-ADRootDSE).ConfigurationNamingContext -prop * | Select Name, mspki-certificate-name-flag, @{ Name = "SupplyInRequest" ; Expression = { $_.'mspki-certificate-name-flag' -band 0x00000001 } }
      

Ulteriore riduzione del rischio

Oltre a correggere le configurazioni errate dei certificati, prendi in considerazione l'utilizzo delle seguenti opzioni per controllare l'emissione dei certificati.

Approvazione del Gestore del Certificato CA o Firme Autorizzate

Prima e probabilmente più importante, guardare la scheda Requisiti di Emissione su ogni certificato per vedere se richiede l'approvazione del gestore dell'Autorità di Certificazione (CA) o di uno o più autorizzati.

Abilitando una o entrambe queste impostazioni si può ridurre notevolmente il rischio richiedendo controlli prima che i certificati vengano emessi. Se non sei sicuro riguardo alla richiesta di firme autorizzate, richiedi almeno l'approvazione del gestore dei certificati CA; in questo modo, ogni volta che viene richiesto un certificato, verrà inviato all'Autorità di Certificazione per una revisione manuale prima dell'emissione.

Permessi di iscrizione

In secondo luogo, esaminare i permessi di iscrizione in ogni modello, che possono essere trovati nella scheda Sicurezza. Molte configurazioni errate sono critiche solo quando principi generici o grandi gruppi hanno questi permessi. In particolare, controllare per Utenti Autenticati, Utenti del Dominio e qualsiasi grande gruppo di utenti che non dovrebbero essere in grado di richiedere certificati; se li trovate, prendere in considerazione la revoca dei loro permessi di Iscrizione o AutoIscrizione.

Chiave del Registro di sistema EDITF_ATTRIBUTESUBJECTALTNAME2

Infine, controlla l'impostazione del registro EDITF_ATTRIBUTESUBJECALTNAME2. Questa impostazione è una delle più interessanti: se è abilitata sulla CA, allora qualsiasi certificato basato sull'autenticazione che viene emesso (inclusi i certificati in cui il soggetto è costruito automaticamente da Active Directory) può avere valori definiti dall'utente nel SAN.

Per controllare questa impostazione, puoi eseguire questo comando:

      certutil –getreg policyEditFlags
      

Se EDITF_ATTRIBUTESUBJECALTNAME2 è nell'elenco di output, dovresti rimuoverlo utilizzando questo comando:

      certutil -config "CA CONNECTION STRING" -setreg policyEditFlags - EDITF_ATTRIBUTESUBJECTALTNAME2
      

Ulteriori indicazioni su questa impostazione possono essere trovate qui.

Verifica delle impostazioni a rischio utilizzando PSPKIAudit

Lo strumento PSPKIAudit può aiutarti a verificare la tua infrastruttura PKI. Per utilizzare PSPKIAudit, scarica semplicemente lo strumento da GitHub, importa il modulo e esegui il comando Invoke-PKIAudit. Questo elencherà l'Autorità di Certificazione da Active Directory e poi la interrogherà per alcune delle opzioni predefinite.

Di seguito sono riportate un paio di schermate che mostrano l'output di questo strumento, il quale rivela un certificato mal configurato e configurazioni errate sul CA. Se PSPKIAudit rileva delle configurazioni errate non trattate in questo post, consulta il documento di SpecterOps per consigli sulla risoluzione.

Conclusione

Mi aspetto un numero crescente di attacchi ai servizi di certificati di Active Directory. Infatti, un attacco di tipo PetitPotam con ADCS NTLM Relaying è già stato rilevato da quando è stato pubblicato il documento di SpecterOps, e SpecterOps sta rilasciando ForgeCert, il Golden Ticket dei certificati, al BlackHat 2021. Pertanto, è urgente controllare le configurazioni errate nel proprio ambiente e rimediarle prontamente, per poi ripetere il processo regolarmente.

Per una protezione completa, prendi in considerazione la soluzione di sicurezza Netwrix Active Directory. Ti aiuterà a:

• Identificate proattivamente le lacune di sicurezza attraverso una valutazione del rischio approfondita.
• Minimizza i costosi tempi di inattività e le interruzioni aziendali.
• Rilevate tempestivamente anche le minacce avanzate e rispondete rapidamente.