C’è chi è come un martello in cerca di un chiodo, ma io sono un martello in cerca della delega Kerberos. Quindi, quando ho saputo che in BloodHound 4.1 era stato introdotto un edge “WriteSPN”, ho iniziato a esplorare tecniche di abuso alternative che andassero oltre il “Kerberoasting” mirato, e ho trovato un caso limite (gioco di parole voluto) che può essere concatenato con la delega Kerberos con restrizioni.
Tl;dr
Supponiamo che un malintenzionato comprometta un account configurato per la delega limitata (Constrained Delegation) ma non disponga del privilegio SeEnableDelegation. L'autore dell'attacco non sarà in grado di modificare i vincoli (msDS-AllowedToDelegateTo). Tuttavia, se l'autore dell'attacco dispone dei diritti WriteSPN sull'account associato all'SPN di destinazione, nonché su un altro account di computer/servizio, potrà dirottare temporaneamente l'SPN (una tecnica denominata "SPN-jacking"), assegnarlo all'altro computer/server ed eseguire un attacco S4U completo per comprometterlo.
Inoltre, se l'SPN di destinazione non è attualmente associato ad alcun account, l'attaccante può appropriarsene in modo analogo.
Sono il primo ad ammettere che non si tratta di una scoperta rivoluzionaria, ma in determinate circostanze può far rinascere percorsi di attacco che sembravano senza via d’uscita. L’SPN-jacking può anche rappresentare una tecnica alternativa di presa di controllo qualora l’RBCD o le Shadow Credentials non fossero praticabili.
Primer sulla delega Kerberos
La delega Kerberos è un meccanismo che consente ai servizi di agire per conto degli utenti nei confronti di altri servizi. Ad esempio, un utente può accedere a un'applicazione front-end e tale applicazione, a sua volta, può accedere a un'API back-end utilizzando l'identità e le autorizzazioni dell'utente.
La delega Kerberos è disponibile in tre varianti: Unconstrained Delegation, Constrained Delegation e Resource-Based Constrained Delegation (RBCD).
Delega non vincolata
La Delega senza vincoli prevede che gli utenti inviino il loro ticket di concessione (TGT) al servizio front-end (Server A). Il servizio front-end può quindi utilizzare il ticket per impersonare l'utente in qualsiasi servizio, compreso il servizio back-end (Server B).
Delega vincolata
La delega vincolata consente al servizio front-end (Server A) di ottenere i ticket di servizio Kerberos per gli utenti verso un elenco predefinito di servizi specificati dal loro Service Principal Name (SPN), come il servizio back-end, Server B.
Si noti che Constrained Delegation consente al servizio di impersonare gli utenti dal nulla, indipendentemente dal fatto che si siano autenticati o meno al servizio. Molti pensano che dipenda dalla configurazione dell'attributo TrustedToAuthForDelegation. Tuttavia, se concatenata con Resource-Based Constrained Delegation, questa limitazione può essere aggirata, come spiego in questo post.
Delega vincolata basata sulle risorse
RBCD è molto simile a Constrained Delegation, tranne per il fatto che la direzione del vincolo è invertita. Specifica chi è autorizzato a delegare a un servizio piuttosto che a chi il servizio è autorizzato a delegare. In altre parole, se il Server A è autorizzato a delegare al Server B in Constrained Delegation, il vincolo sarà configurato in un attributo del Server A. In RBCD, sarà configurato in un attributo del Server B.
Un'altra differenza importante tra Constrained Delegation e RBCD è che Constrained Delegation specifica l'SPN del servizio di destinazione. Al contrario, RBCD specifica il SID del servizio di origine in un descrittore di sicurezza.
Privilegi richiesti
La configurazione di Unconstrained Delegation e Constrained Delegation richiede il privilegio SeEnableDelegation che, per impostazione predefinita, è concesso solo agli amministratori di dominio. Pertanto, anche se un utente avesse il pieno controllo (GenericAll) su un account AD, non sarebbe in grado di configurare nessuno dei due tipi di delega Kerberos senza avere anche il privilegio SeEnableDelegation. A differenza di Unconstrained Delegation e Constrained Delegation, RBCD richiede il diritto di modificare l'attributo msDS-AllowedToActOnBehalfOtherIdentity, ma non privilegi speciali.
Si noti che gli utenti hanno bisogno di privilegi speciali per modificare la configurazione della Constrained Delegation, ma non sono necessari privilegi speciali per modificare gli SPN. Pertanto, potrebbe essere interessante affrontare gli scenari con la compromissione della Constrained Delegation da un'angolazione diversa: manipolando l'attributo SPN anziché la configurazione della delega.
Come si svolge la scena
Supponiamo che nell'ambiente siano presenti tre server: ServerA, ServerB e ServerC. ServerA è configurato con la delega limitata (Constrained Delegation) a un determinato SPN. L'autore dell'attacco ha compromesso ServerA e l'account NotAdmin, che dispone dei diritti WriteSPN sugli account computer/servizio presenti nell'ambiente. L'obiettivo dell'autore dell'attacco è compromettere ServerC.
Fantasma SPN-jacking
Il primo scenario è il più semplice. Il serverA è configurato per la delega vincolata a un SPN precedentemente associato a un account di computer o servizio che non esiste più. Potrebbe trattarsi di un SPN standard, come cifs/hostname, associato a un account di computer/servizio cancellato o a un account calcolato rinominato se gli SPN sono stati aggiornati di conseguenza. Oppure l'account potrebbe essere un SPN personalizzato con una classe di servizio non standard che è stata rimossa dall'account del computer/servizio, oppure l'account stesso potrebbe non esistere più.
In questo scenario, l'autore dell'attacco può aggiungere l'SPN compromesso a ServerC e quindi eseguire l'attacco S4U completo utilizzando l'account di ServerA per ottenere un ticket di servizio per un utente con privilegi su ServerC.
Il nome del servizio indicato in quel ticket non sarebbe valido per accedere a ServerC perché il nome host non corrisponderebbe, e la classe di servizio potrebbe risultare inutile. Tuttavia, l’aspetto importante è che il ticket è crittografato per il ServizioC e il nome del servizio non è contenuto nella parte crittografata del ticket, quindi l’autore dell’attacco può sostituirlo con uno valido.
Infine, l'attaccante può passare il ticket e compromettere il ServerC.
La catena di attacco è illustrata nel seguente diagramma:
L'attacco è mostrato nella seguente schermata:
In diretta SPN-jacking
Il secondo scenario è un po' più artificioso. Il ServerA è configurato per la delega vincolata a un SPN attualmente associato al ServerB e l'attaccante dispone dei diritti di WriteSPN sul ServerB e sul ServerC.
In ambienti completamente patchati, solo gli amministratori di dominio possono configurare SPN in conflitto, ovvero SPN associati a due o più account diversi. Pertanto, se l'attaccante in questo scenario cercasse di aggiungere l'SPN di destinazione al ServerC, il DC rifiuterebbe la modifica perché è già associato al ServerB.
L'autore dell'attacco può aggirare tale barriera rimuovendo temporaneamente l'SPN di destinazione da ServerB e aggiungendolo solo successivamente a ServerC. A quel punto, l'autore dell'attacco può eseguire l'attacco S4U completo utilizzando l'account di ServerA per ottenere un ticket di servizio per un utente con privilegi su ServerC.
Come nello scenario precedente, il nome del servizio di quel ticket non sarebbe valido per accedere al ServerC. Tuttavia, la cosa importante è che il ticket è criptato per il ServerC e il nome del servizio non è nella parte criptata del ticket, quindi l'attaccante può cambiarlo.
Infine, l'attaccante può passare il ticket e compromettere il ServerC.
Un attaccante ben educato dovrebbe anche eseguire il rollback delle modifiche rimuovendo l'SPN di destinazione dal ServerC e ripristinandolo sul ServerB.
La catena di attacco è illustrata nel seguente diagramma:
SPN-jacking con la classe di servizio HOST
La situazione si fa più interessante quando l'SPN mirato non è definito esplicitamente. Per impostazione predefinita, gli account dei computer hanno SPN associati alle classi di servizio TERMSRV, RestrictedKrbHost e HOST. Se sono installati altri servizi, come LDAP o SQL Server, vengono aggiunti altri SPN anche per questi.
La classe di servizio HOST è mappata per impostazione predefinita alle seguenti classi di servizio:
alerter, appmgmt, cisvc, clipsrv, browser, dhcp, dnscache, replicator, eventlog, eventsystem, policyagent, oakley, dmserver, dns, mcsvc, fax, msiserver, ias, messenger, netlogon, netman, netdde, netddedsm, nmagent, plugplay, protectedstorage, rasman, rpclocator, rpc, rpcss, remoteaccess, rsvp, samss, scardsvr, scesrv, seclogon, scm, dcom, cifs, spooler, snmp, schedule, tapisrv, trksvr, trkwks, ups, time, wins, www, http, w3svc, iisadmin, msdtc.
Se l'aggressore cercasse di mirare a una classe di servizio mappata su HOST, il controller di dominio rifiuterebbe di aggiungere tale classe di servizio al ServerC, anche se non è direttamente associato al ServerB. L'aggressore dovrebbe prima rimuovere gli SPN HOST dal ServerB e poi aggiungere esplicitamente l'SPN di destinazione al ServerC. Tuttavia, dopo aver aggiunto l'SPN di destinazione al ServerC, l'aggressore può aggiungere nuovamente gli SPN HOST al ServerB senza riscontrare alcun errore di convalida, pur avendo già un SPN mappato associato al ServerC, come dimostra la seguente schermata:
Quando si richiedono ticket di servizio all'SPN ambiguo, cifs/SERVERB nella schermata precedente, il controller di dominio li emette per il ServerC anziché per il ServerB.
La catena di attacco è illustrata nel seguente diagramma:
In che modo gli aggressori possono utilizzare l'SPN-jacking?
Se un aggressore compromette un account con diritti GenericAll o GenericWrite su account di computer, potrebbe utilizzare RBCD o Shadow Credentials per compromettere l'host o il servizio associato. Sospetto che la compromissione di un account con i soli diritti di WriteSPN sugli account del computer non sia molto probabile. Tuttavia, in concomitanza con la compromissione di un host con Constrained Delegation già configurato, gli aggressori potrebbero utilizzare questa tecnica in ambienti in cui RBCD e Shadow Credentials sono monitorati o bloccati. I difensori dovrebbero seguire le raccomandazioni riportate di seguito per mitigare gli attacchi SPN-jacking.
Rilevamento di SPN-jacking
Le modifiche all'attributo ServicePrincipalName di un account computer generano eventi di sicurezza con ID 4742 (È stato modificato un account computer) sul controller di dominio. I dettagli dell'evento mostrano gli attributi modificati e il loro nuovo valore. Gli amministratori della sicurezza possono individuare gli SPN con un nome host diverso dai nomi DNS del computer, come mostrato nella schermata qui sotto:
Anche la rimozione della classe di servizio HOST da un account del computer può essere sospetta.
L'attacco S4U genera due eventi di sicurezza con ID 4769 (È stato richiesto un ticket di servizio Kerberos).
Il primo evento è per S4U2Self. I difensori possono rilevarlo quando le informazioni sull'account e quelle sul servizio puntano allo stesso account, come mostrato nell'immagine seguente:
Il secondo evento riguarda S4U2Proxy. I difensori possono rilevarlo quando l'attributo Transited Services non è vuoto, come mostrato nella schermata seguente:
Prevenzione dell'SPN-jacking
I difensori possono applicare diverse tattiche per prevenire questo tipo di abusi:
- Controllare regolarmente Active Directory per verificare la presenza di deleghe vincolate che puntano a SPN fantasma.
- Verificate regolarmente la presenza di diritti di scritturaSPN anomali in Active Directory.
- Aggiungete tutti gli account privilegiati al gruppo Utenti protetti per bloccare qualsiasi tentativo di impersonificazione attraverso la delega Kerberos.
Gli aggressori possono manipolare l'SPN degli account di computer/servizi per reindirizzare la Constrained Delegation preconfigurata a obiettivi non previsti, anche senza ottenere i privilegi di SeEnableDelegation.
Sebbene gli scenari descritti in questo articolo non siano comuni, possono presentare percorsi di attacco praticabili quando un account compromesso è configurato per la Constrained Delegation che altrimenti sarebbe considerata innocua o come alternativa a RBCD e Shadow Credentials.
I difensori devono adottare le misure necessarie per rilevare e prevenire tali attacchi.
Riferimenti
- Presentazione di BloodHound 4.1 - Il mastino a tre teste
- Scodinzolare il cane: Abuso della delega vincolata basata sulle risorse per attaccare Active Directory
Questo post è stato pubblicato anche su shenaniganslabs.io e eladshamir.com.
