Elad Shamir

Alcune persone sono un martello in cerca di un chiodo, ma io sono un martello in cerca della delega Kerberos. Così, quando ho saputo che in BloodHound 4.1 era stato introdotto un edge WriteSPN, ho iniziato a esplorare tecniche di abuso alternative al Kerberoasting mirato e ho trovato un edge case (gioco di parole) che può essere concatenato con la Kerberos Constrained Delegation.

Tl;dr

Si supponga che un aggressore comprometta un account impostato per la delega vincolata, ma che non abbia il privilegio SeEnableDelegation. L'aggressore non sarà in grado di modificare i vincoli (msDS-AllowedToDelegateTo). Tuttavia, se l'aggressore dispone dei diritti di WriteSPN sull'account associato all'SPN di destinazione e su un altro account di computer/servizio, può temporaneamente dirottare l'SPN (una tecnica chiamata 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.

Sarò il primo ad ammettere che non si tratta di una scoperta rivoluzionaria, ma può far rivivere percorsi di attacco apparentemente senza uscita in particolari circostanze. L'SPN-jacking può anche essere una tecnica di acquisizione alternativa se RBCD o Shadow Credentials non sono praticabili.

Primer sulla delega Kerberos

La delega Kerberos è un meccanismo che consente ai servizi di impersonare gli utenti ad altri servizi. Ad esempio, un utente può accedere a un'applicazione front-end, che a sua volta può accedere a un'API back-end con l'identità e i permessi 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

Si supponga che nell'ambiente vi siano tre server: ServerA, ServerB e ServerC. Il ServerA è configurato con delega vincolata a un determinato SPN. L'aggressore ha compromesso il ServerA e l'account NotAdmin, che ha diritti di scrittura SPN sugli account di computer/servizi nell'ambiente. L'obiettivo dell'attaccante è compromettere il 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'aggressore può aggiungere l'SPN interessato al ServerC e quindi eseguire l'attacco S4U completo utilizzando l'account del ServerA per ottenere un ticket di servizio per un utente privilegiato al ServerC.

Il nome del servizio di quel ticket non sarebbe valido per accedere al ServerC perché il nome dell'host non corrisponderebbe e la classe del servizio potrebbe essere inutile. Tuttavia, la cosa importante è che il biglietto è criptato per ServiceC e il nome del servizio non è nella parte criptata del biglietto, quindi l'attaccante può cambiarlo 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'aggressore può aggirare questa barriera rimuovendo temporaneamente l'SPN di destinazione dal ServerB e aggiungendolo solo successivamente al ServerC. L'aggressore può quindi eseguire l'attacco S4U completo utilizzando l'account del ServerA per ottenere un ticket di servizio per un utente privilegiato sul 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 di computer generano eventi di sicurezza con l'ID 4742 (Un account di computer è stato modificato) sul controller di dominio. I dettagli dell'evento mostrano gli attributi modificati e il loro nuovo valore. I Defender possono rilevare SPN con un nome host diverso dai nomi DNS del computer, come mostrato nella schermata seguente:

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

Questo post è stato pubblicato anche su shenaniganslabs.io e eladshamir.com.