AD-ventures in offensive security – Parte 5/9 – Unconstrained Delegation

DisclaimerGli 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 è parte della serie AD-ventures: La battaglia per la sicurezza di Active Directory – ICT Power

Nell’articolo precedente abbiamo parlato di Kerberos, dei meccanismi di autenticazione che mette a disposizione e di Kerberoasting, una tecnica utilizzata da un attaccante per effettuare azioni di Privilege Escalation o Lateral Movement. Esistono diversi metodi per analizzare/attaccare i meccanismi di autenticazione, sia per quelle richieste che avvengono tra utenti e macchine sia per quanto concerne l’accesso a servizi/risorse. Con questo articolo continuiamo il nostro percorso restando sempre all’interno del mondo Kerberos parlando di una tecnica nota come Unconstrained Delegation.

Unconstrained Delegation

Immaginate di essere in un parco divertimenti con i vostri amici. Volete tutti provare diverse attrazioni ma, anziché dover acquistare un biglietto per ciascuna, avete un pass VIP che vi permette di accedere a tutto senza ulteriori restrizioni. L’Unconstrained Delegation funziona in modo simile in Active Directory: è un pass VIP per i servizi, consentendo ad un server di impersonare utenti su qualsiasi altro servizio in rete. Tutto ciò avviene da Windows 2000.

Quando un utente effettua un accesso o un servizio si autentica in un’applicazione, è possibile generare una delega contenente le credenziali. In questo modo, l’applicazione può accedere ad altri servizi per conto dell’utente senza richiedere ulteriori autenticazioni. Questo meccanismo semplifica notevolmente l’esperienza dell’utente, evitando la necessità di effettuare ripetuti accessi a diverse risorse o servizi. Di conseguenza, si riduce il tempo e lo sforzo richiesto all’utente, migliorando l’efficienza e la fluidità delle interazioni con l’applicazione.

Per farlo si utilizzano i ticket Kerberos, nello specifico un TGS (KRB_TGS_REQ) ovvero una richiesta di accesso ad un servizio contenente, tra le varie cose, il Service Principal Name (SPN) del servizio desiderato.

Figura 1 – TGS

Immaginiamo di autenticarci su un server dove è attiva l’Unconstrained Delegation, ecco ciò che avviene:

  • Autenticazione Iniziale:
    • L’utente si autentica e riceve un TGT dal Key Distribution Center (KDC);
    • Il TGT viene inviato al server abilitato all’Unconstrained Delegation;
  • Memorizzazione del TGT:
    • Il server salva il TGT dell’utente nel proprio contesto di sicurezza;
    • Da questo momento, il server può usare questo TGT per richiedere Service Tickets per conto dell’utente verso altri servizi;
  • Impersonare l’utente:
    • Quando il server necessita di accedere ad un servizio utilizza il TGT dell’utente per ottenere un Service Ticket dal KDC;
    • Con il Service Ticket, il server accede al servizio richiesto impersonando l’utente ed ottenendone i privilegi;

Cosa vuol dire? Si può agire per conto di qualsiasi utente verso un qualsiasi servizio senza dover aggiungere altre configurazioni. Anche il numero di autenticazioni necessarie all’intero processo è molto ridotto (immaginiamo quelle applicazioni che richiedono accessi frequenti anche a differenti risorse).

Questa delega può essere assegnata sia ad oggetti di tipo computer che ad utenti. Solitamente viene assegnata a quei server che eseguono servizi come IIS o MSSQL. Un tipico scenario viene descritto nell’immagine che segue

Figura 2 – Accesso al DB

Ora che abbiamo più chiaro il meccanismo possiamo riprendere il nostro percorso tentando di utilizzare questa tecnica ed avendo come obbiettivo le azioni di Privilege Escalation o Lateral Movement.

Attacco

La strategia che vogliamo applicare è quella di utilizzare una macchina o un servizio per il quale un utente è stato delegato per l’accesso ad altri servizi.

Figura 3 – Accesso al Servizio C

Se un attaccante riesce a compromettere una macchina dove è abilitata l’Unconstrained Delegation può essere in grado di estrarre il TGT degli account che hanno effettuato (o che hanno tentato) una connessione.

Prima di iniziare, verifichiamo se sono presenti macchine con questa configurazione. Per farlo possiamo seguire varie strade, ad esempio utilizzare il modulo PowerShell PowerView oppure, come in questo caso, il modulo ADModule.

Eseguiamo il comando

Get-ADComputer -Filter {TrustedForDelegation -eq $True}

Figura 4 – Verifica Uncostrained Delegation

Oltre al Domain Controller (configurazione di default) l’Unconstrained Delegation è abilitata sulla macchina WEB01.lab.local.

Continuiamo il nostro percorso seguendo uno dei metodi descritti nelle puntate precedenti, ed assumiamo di aver ottenuto un accesso ad una macchina con privilegi di amministratore locale.

Figura 5 – Utente corrente

A questo punto, per poter proseguire, è necessario trovare il modo di forzare la connessione di un utente alla macchina target WEB01. Ci sono vari modi per farlo, in questo caso sfrutteremo un bug relativo al servizio di stampa.

Il servizio Print Spooler di Microsoft gestisce i processi di stampa e altre attività ad essa correlate tramite protocollo MS-RPRN. Un attaccante che controlla un utente o un computer di dominio può, tramite una specifica chiamata RPC (Remote Procedure Call), attivare il servizio spooler su un obiettivo che lo esegue e forzarlo ad autenticarsi su un sistema scelto dall’attaccante. Questo difetto, che non verrà corretto da Microsoft, è presente in tutti gli ambienti Windows.

L’obbiettivo, quindi, è quello di forzare una richiesta proveniente dal Domain Controller verso la macchina WEB01 e senza l’utilizzo di ulteriori credenziali.

Questo può essere fatto in vari modi ma quello che preferisco è l’utilizzo del tool SpoolSample, disponibile su GitHub e presentato al DerbyCon 2018.

Per poter carpire la richiesta possiamo utilizzare il tool Rubeus eseguito in monitoring mode e da una shell privilegiata con il comando

Rubeus.exe monitor /interval:1

Successivamente eseguiamo il comando

.\SpoolSample.exe DC01.LAB.LOCAL WEB01.LAB.LOCAL

Figura 6 – Esecuzione SpoolSample.exe

Anche se abbiamo un messaggio d’errore, Rubeus ha carpito correttamente la richiesta e ci mostra il TGT ottenuto

Figura 7 – TGT dell’utente Administrator

Il ticket è dell’utente administrator, un Domain Admin, che ora potremo impersonare! Per farlo copiamo il ticket codificato in Base64 ed utilizziamo Rubeus per forgiare il ticket sulla macchina WEB01 con il seguente comando (la stringa codificata è stata troncata per questioni di comodità)

Rubeus.exe ptt /ticket: doIFwjCCBb6gAwIBBaEDAgEWooIE…

Figura 8 – Import del TGT

Verifichiamo che tutto sia andato a buon fine con il comando

Rubeus klist

Figura 9 – Verifica import TGT

Perfetto! Non ci resta che tentare una connessione verso il Domain Controller utilizzando il comando

Enter-PSSession -ComputerName DC01

Figura 10 – Connessione PowerShell verso il Domain Controller

Il gioco è fatto: siamo Domain Admin all’interno di un Domain Controller.

Come difendersi

La delega incondizionata è una configurazione troppo permissiva. Soprattutto all’interno di grosse infrastrutture è fortemente sconsigliato poiché è facile perderne il controllo. Se è necessario utilizzare questi meccanismi è possibile essere più puntuali nel concedere tali privilegi.

La Constrained Delegation (delega vincolata) è una funzionalità di sicurezza di Active Directory che consente ad un servizio di autenticarsi per conto di un utente su specifici servizi, mantenendo il controllo su quali possono essere utilizzati in questo modo. Questa tecnica è implementata principalmente in ambienti in cui un’applicazione web o un altro servizio deve accedere a risorse aggiuntive, come database o file server, senza richiedere all’utente di autenticarsi nuovamente.

Un’altra valida alternativa è la Resource-based Constrained Delegation una funzionalità di sicurezza introdotta da Microsoft per fornire un controllo più granulare e sicuro sull’autenticazione delegata in ambienti Active Directory. In particolare, la RBCD consente a un servizio di impersonare un utente per accedere a un’altra risorsa ma con la particolarità che è la risorsa stessa (e non il servizio) a specificare quali account possono essere delegati per accedere ad essa.

Entrambe non sono esenti da rischi per cui è necessario prestare attenzione nel caso si decida di utilizzarle.

Infine, è sempre una buona prassi:

  • Utilizzare password complesse per i service account oppure i Managed Service Account (sMSA);
  • Utilizzare il gruppo Protected Users: un gruppo speciale che contiene account che non possono essere delegati;
  • Monitorare il traffico di rete ed i registri di sicurezza in modo da rilevare le richieste di ticket di servizio provenienti da fonti inattese.

Considerazioni

Questa tecnica è stata eseguita in un ambiente preparato allo scopo per cui alcune semplificazioni sono ovvie ed alcuni concetti sono stati dati per scontato.

Ciononostante, non è raro trovare configurazioni simili negli ambienti di produzione.

Conclusioni

Le deleghe degli account non sono un argomento da prendere alla leggera. Sono estremamente utili in molte occasioni ma sono varie le tecniche che consentono di sfruttare le possibili configurazioni errate. Il monitoraggio è una delle armi più efficaci ma ciò che fa davvero la differenza è una conoscenza approfondita di ciò che utilizziamo e come lo applichiamo.

Come sempre abbiamo a disposizione tanti strumenti per migliorare le nostre infrastrutture, per prendercene cura. La consapevolezza deve essere il mantra del 2024, in modo da concentrare l’attenzione dove realmente è necessario.

Stay tuned!