• Guide, Sicurezza, Sistemi Operativi
• 10 Dicembre 2024

“Disclaimer: Gli strumenti e le tecniche descritte in questo articolo sono destinati esclusivamente a scopi educativi e di ricerca nel campo della sicurezza informatica. L’uso di tali strumenti e tecniche contro sistemi informatici senza il consenso esplicito del proprietario è illegale e può comportare gravi conseguenze legali. L’autore e gli editori declinano qualsiasi responsabilità per l’abuso o l’uso improprio di queste informazioni da parte degli utenti. Si consiglia vivamente di ottenere il consenso scritto prima di condurre qualsiasi tipo di test o di valutazione della sicurezza su sistemi informatici.”

Questo articolo conclude la serie AD-ventures: La battaglia per la sicurezza di Active Directory – ICT Power

Come ultima tappa del nostro viaggio, ci addentreremo in un territorio affascinante e spesso trascurato: Active Directory Certificate Services (AD CS). Potreste pensare che i certificati siano solo per i siti web con il lucchetto verde, ma vi assicuro che in AD CS si nascondono insidie e opportunità che nemmeno i più scaltri potrebbero immaginare. Quindi, allacciamo le cinture: parleremo dei certificati, esploreremo sommariamente alcune tecniche d’attacco, meccanismi di difesa e, soprattutto, come evitare di finire con le ossa rotte.

Negli articoli precedenti abbiamo visto varie tecniche. Indipendentemente della composizione delle infrastrutture o della complessità dei sistemi, queste vengono attualmente utilizzate negli attacchi. In alcuni casi è più semplice monitorarle, in altri può essere molto più complesso, soprattutto se non si utilizzano le dovute precauzioni. Quello che abbiamo affrontato in questo percorso descrive ciò che può accadere in dominio Active Directory, relativamente al concetto di utente o di identità. Quest’ultima puntata è dedicata a quella porzione di infrastruttura denominata PKI (Public Key Infrastructure), ovvero quel sistema di processi, di policy e di tanto altro che consente di proteggere dati. L’uso della crittografia ed i concetti di certificato digitale sono ormai piuttosto diffusi ma il funzionamento nel dettaglio spesso lo è molto meno. Li utilizziamo in maniera diffusa, ad esempio, per le VPN, per le reti Wi-Fi, per i siti web ma, nonostante ciò, spesso non ci preoccupiamo della generazione e relativa gestione.

Per raccontare bene cos’è e come funziona Active Directory Certificate Services un solo articolo non è sufficiente. Possiamo, però, affrontare il tema in maniera più generale ed approfondirlo successivamente, con altri appuntamenti.

Componenti principali

Il ruolo Active Directory Certificate Services (AD CS) è stato introdotto con Windows 2000, permettendo la sua implementazione in due configurazioni: come Certification Authority (CA) autonoma o come CA aziendale integrata con Active Directory (AD).

PKI e AD CS non sono sistemi semplici per cui è necessario fare almeno le presentazioni degli oggetti principali.

Un certificato è un documento digitale firmato nello standard X.509, utilizzato per crittografia, la firma di messaggi o per autenticazione. Solitamente è formato dai seguenti campi:

• Subject: Il proprietario del certificato o colui al quale viene assegnato.
• Public Key: Associa il proprietario del certificato ad una chiave privata conservata separatamente.
• NotBefore e NotAfter dates: Definiscono il periodo di validità del certificato.
• Serial Number: Identificatore univoco assegnato dalla CA.
• Issuer: Chi ha emesso il certificato (solitamente una CA).
• SubjectAlternativeName: Definisce uno o più nomi alternativi per il Subject (SAN).
• Basic Constraints: Specifica se il certificato è una CA o un’entità finale ed eventuali vincoli sul suo utilizzo.
• Extended Key Usages (EKUs): Identificatori di oggetti (OID) che descrivono come verrà utilizzato il certificato. Alcuni EKU comuni includono:
  • Code Signing (OID 1.3.6.1.5.5.7.3.3): Per la firma di codice eseguibile.
  • Encrypting File System (OID 1.3.6.1.4.1.311.10.3.4): Per la crittografia di file system.
  • Secure Email (OID 1.3.6.1.5.5.7.3.4): Per la crittografia di email.
  • Client Authentication (OID 1.3.6.1.5.5.7.3.2): Per l’autenticazione su un altro server (ad esempio AD).
  • Smart Card Logon (OID 1.3.6.1.4.1.311.20.2.2): Per l’autenticazione con smart card.
  • Server Authentication (OID 1.3.6.1.5.5.7.3.1): Per identificare i server (ad esempio, certificati HTTPS).
• Signature Algorithm: Specifica l’algoritmo utilizzato per firmare il certificato.
• Signature: La firma del corpo del certificato effettuata usando la chiave privata dell’emittente (ad esempio di una CA).

Le informazioni contenute in un certificato legano un’identità (il Subject) a una coppia di chiavi, che può essere usata dalle applicazioni per provare l’identità dell’utente.

Ruolo delle Certification Authority

Le CA sono incaricate di emettere i certificati. Durante il processo di configurazione, una CA deve creare una coppia di chiavi pubblica e privata insieme al proprio certificato, che verrà utilizzato per firmare altri certificati. Per generare il certificato root (certificato radice), la CA firma un nuovo certificato utilizzando la propria chiave privata, rendendolo autofirmato. In AD CS, i campi Subject e Issuer del certificato radice vengono configurati con il nome della CA, mentre i vincoli di base sono impostati con Subject Type=CA e le date NotBefore/NotAfter sono di default fissate a cinque anni. I dispositivi aggiungono questo certificato root al proprio archivio di fiducia, instaurando così un rapporto affidabilità con la CA.

AD CS definisce i certificati delle CA di fiducia nella foresta AD in quattro container sotto il percorso CN=Public Key Services,CN=Services,CN=Configuration,DC=,DC=, ognuno con un scopo diverso:

1. Certification Authorities: Contiene i certificati root CA di fiducia, alla base della gerarchia PKI.
2. Enrollment Services: Rappresenta le CA aziendali. Ogni CA aziendale è un oggetto AD che definisce, tra le altre cose, i template di certificati abilitati.
3. NTAuthCertificates: Definisce i certificati CA che consentono l’autenticazione con AD.
4. AIA (Authority Information Access): Contiene CA intermedie per la validazione delle catene di certificati.

I client interagiscono con le CA aziendali per richiedere certificati basati su template predefiniti.

Figura 1 – ADSI Edit e visualizzazione dei container

Le CA Microsoft emettono certificati con impostazioni definite dai template dei certificati. Questi sono raccolte di policy, di modalità di enrollment, di impostazioni predefinite e definiscono aspetti come la validità, lo scopo, l’utilizzo di uno specifico certificato e molte altre configurazioni.

Figura 2 – Template dei certificati

Figura 3 – Template Certificato Web Server

Per ottenere un certificato, i client eseguono un’azione denominata enrollment:

1. I client individuano la CA basandosi sugli oggetti presenti nel container Enrollment Services.
2. I client generano una coppia di chiavi pubblica-privata e includono la chiave pubblica in un messaggio di richiesta di firma del certificato (Certificate Signing Request o CSR), insieme ad altri dettagli come il subject del certificato e il nome del template del certificato.
3. I client firmano quindi la CSR con la loro chiave privata e la inviano alla CA.

A questo punto:

1. La CA verifica se il client è autorizzato a richiedere certificati. In caso positivo, determina se emettere un certificato sulla base del template specificato nella CSR.
2. La CA controlla se le autorizzazioni del template del certificato permettono all’account autenticato di ottenere un certificato. Anche qui, in caso positivo, la CA genera un certificato sulla base del template (ad esempio, EKU, impostazioni crittografiche e requisiti di emissione) e con le informazioni fornite nella CSR.
3. La CA firma il certificato con la propria chiave privata e lo restituisce al client.

Figura 4 – Richiesta Certificato

Dopo aver visto questi oggetti anche solo in maniera generale possiamo prepararci ad affrontare il passo successivo.

Scenari d’attacco

Nel 2021, alla Black Hat Conference, SpecterOps ha presentato un paper che descrive le misconfiguration e le vulnerabililtà che possono essere sfruttate in Active Directory Certificate Services. Gli scenari sono vari e contemplano il furto di certificati, meccanismi di persistenza e privilege escalation.

L’abuso dei certificati può concedere ad un attaccante diversi privilegi:

1. Furto delle credenziali utente: acquisendo un certificato utilizzato per l’autenticazione a dominio. Accesso che continua ad essere valido anche in caso di cambio password e che può essere fatto senza manipolare il processo LSASS;
2. Persistenza su una macchina: Come sopra ma relativo ad un account macchina;
3. Domain escalation: utilizzando template di un certificato configurati in modo errato che consentono di utilizzare parametri in maniera troppo permissiva;
4. Persistenza di dominio: acquisendo la chiave privata di una CA può fornire la possibilità di creare certificati.

Proviamo a fare un esempio per capire meglio la portata della questione.

Immaginiamo di avere un web server che ospita tre domini. In questa condizione può essere creato un unico certificato HTTPS contenente nel Subject Alternative Name ogni dominio. Fin qui, nulla di strano, anzi piuttosto utile.

Ora immaginiamo di avere un certificato da utilizzare per l’autenticazione, magari legato a quello descritto precedentemente. Per impostazione predefinita i certificati vengono associati agli account di Active Directory in base ad un User Principal Name (UPN) specificato nel SAN del certificato.

Ora, se un attaccante fosse in grado di specificare un SAN arbitrario durante la richiesta di un certificato per l’autenticazione potrebbe impersonare qualsiasi utente di dominio.

Come per un drago a guardia di un tesoro, AD CS può essere aggirato con astuzia e precisione:

• Furto di certificati: Un attaccante può utilizzare strumenti come Mimikatz e SharpDPAPI per estrarre certificati e chiavi private esistenti dagli account utente o computer. Basta un piccolo errore di configurazione.
• Richieste di certificati dannose: Spesso l’inganno è la chiave del successo. Gli attaccanti possono utilizzare modelli di certificati configurati in modo errato per richiedere nuovi certificati o rinnovare quelli esistenti. In questo modo, si infiltrano nel sistema come un ospite indesiderato ma con tanto di invito ufficiale.
• Furto della chiave privata CA: Il colpo grosso! Ottenendo la chiave privata della CA, gli attaccanti possono falsificare certificati per qualsiasi utente o computer, diventando i padroni assoluti del dominio.

Le possibilità sono molte, vediamone alcune.

1. Furto di Certificati

Come Funziona

Il furto di certificati consente a un attaccante di impersonare legittimamente utenti o dispositivi, eludendo i controlli di sicurezza. Questo avviene attraverso:

• Certificati memorizzati in chiaro su macchine compromesse.
• L’uso di strumenti come Mimikatz per estrarre chiavi private dai dispositivi.
• Certificati ottenuti tramite richieste fraudolente a un CA mal configurato.

Impatto

Con un certificato compromesso, un attaccante può:

• Accedere a risorse protette come se fosse un utente legittimo.
• Eseguire attacchi “man-in-the-middle” utilizzando traffico crittografato.

2. Meccanismi di Persistenza

Come Funziona

La persistenza tramite AD CS sfrutta configurazioni deboli nei modelli di certificati (Certificate Templates) o in impostazioni di autorizzazione. Gli attaccanti possono:

• Richiedere certificati con privilegi elevati, come l’accesso alle funzioni di autenticazione Kerberos.
• Configurare una CA secondaria per generare certificati senza supervisione.

Impatto

Questa tecnica consente all’attaccante di mantenere l’accesso a lungo termine, anche se le credenziali rubate vengono cambiate o revocate.

3. Privilege Escalation

Come Funziona

Le configurazioni errate nei Certificate Templates possono permettere a un attaccante con privilegi bassi di:

• Richiedere certificati che gli conferiscono l’accesso come amministratore.
• Utilizzare il certificato per ottenere accesso completo al dominio.

Un esempio pratico è l’utilizzo di un template configurato per il servizio Enrollment senza restrizioni adeguate. Questo consente agli utenti di autenticarsi come altri utenti o macchine.

Impatto

• Controllo completo del dominio da parte dell’attaccante.
• Estensione dell’attacco ad altre macchine e servizi.

Costruire Fortificazioni: Prevenzione, Mitigazione e Rilevazione

Per difendere la nostra infrastruttura da queste minacce insidiose, è necessario costruire fortificazioni solide e vigili:

• Trattare le CA come asset di livello 0: La CA è il cuore del sistema di certificati. Dobbiamo proteggerla con la stessa cura che dedicheremmo alla cosa più preziosa! Misure di sicurezza rigorose e controlli d’accesso granulari sono fondamentali.
• Indurire le impostazioni del template di certificato: I template dei certificati sono come i progetti per costruire le chiavi. Dobbiamo assicurarci che siano robusti e privi di falle, limitando i diritti di iscrizione, disabilitando le opzioni pericolose come EDITF_ATTRIBUTESUBJECTALTNAME2 e ridurre al minimo gli EKU.
• Proteggere l’archiviazione delle chiavi private del certificato: Le chiavi private sono un tesoro prezioso. Custodirle bene è obbligatorio! Moduli di sicurezza hardware (HSM) e TPM sono i nostri migliori alleati.
• Monitorare gli eventi di autenticazione del certificato: Teniamo d’occhio chi entra ed esce dalla nostra infrastruttura! Monitorare gli eventi di accesso basati su certificati per individuare attività sospette. Anomalie nei nomi utente, negli indirizzi IP o negli user agent HTTP possono segnalare un’intrusione.
• Implementare il rilevamento basato su SACL: I SACL (System Access Control List) sono come sentinelle che sorvegliano i punti d’accesso sensibili. Utilizziamole per controllare l’accesso ai file delle chiavi private e delle masterkey
  DPAPI e per ricevere avvisi immediati in caso di attività sospette.

Considerazioni

AD CS è un tema estremamente vasto, impossibile da riassumere in un solo articolo. Esistono corsi e certificazioni in materia per padroneggiare questo argomento nel modo corretto e che, almeno per il momento, sono fuori dallo scopo di questo articolo.

Gli attacchi alle infrastrutture PKI sono particolarmente comuni quando si parla di APT (Advanced Persistent Threat), dove l’attaccante rimane nella rete per periodi prolungati. Sapere cosa accade all’interno della nostra infrastruttura PKI può evitare problemi molto seri: anche solo immaginare il caso peggiore, il furto della chiave privata della CA, personalmente qualche brivido me lo provoca. Immaginare di dover ricreare una CA compromessa, revocare e rigenerare tutti i certificati emessi e “spediti” ai vari gruppi di lavoro, per le installazioni manuali su apparati, server o altro è un lavoro enorme.

Conclusioni

Osservare cosa accade nel mondo di AD CS ci ha mostrato che la sicurezza dei certificati è una questione delicata e complessa. Ignorarla potrebbe costare caro! Con una solida strategia di prevenzione, mitigazione e rilevamento, è possibile tenere al sicuro un’infrastruttura e dormire sonni tranquilli.

Concludiamo qui il nostro viaggio. Forse ora può essere più semplice capire come mai, nonostante le tecnologie di cui disponiamo, ogni giorno possiamo leggere notizie di nuovi attacchi. Abbiamo visto tanti temi, alcuni caratteristici delle kill chain utilizzate da APT, altri che contemplano comunque il raggiungimento di un obbiettivo remunerativo per un attaccante. La ricerca di informazioni è la base per poter capire quale tecnica applicare ed in quale contesto. Abbiamo, però, capito anche che queste tecniche fanno “rumore”, lasciano tracce. L’inizio del 2024 è stato anche l’inizio di questo percorso con l’obbiettivo di diffondere consapevolezza e cultura. Il 2025 è alle porte e con l’esplosione che ha avuto l’AI probabilmente ne vedremo delle belle. Prepariamoci ad affrontarlo con curiosità, consapevolezza (non mi stancherò mai di dirlo) e tanta grinta!

Stay tuned!