Nuovi percorsi di attacco? AS Ticket di servizio richiesti

Jul 18, 2023

Home » Cybersecurity » Notizie SBN » Nuovi percorsi di attacco? AS Ticket di servizio richiesti

Mentre aiutavo Andrew Schwartz con il suo post su Kerberos FAST (che contiene maggiori informazioni su cos'è FAST e come funziona, quindi leggilo), ho notato qualcosa di interessante. Gli AS-REQ per gli account macchina non sono armati. Questo è descritto da Microsoft qui:

La blindatura Kerberos utilizza un ticket di concessione ticket (TGT) per il dispositivo per proteggere gli scambi del servizio di autenticazione con il KDC, pertanto lo scambio del servizio di autenticazione del computer non è blindato. Il TGT dell'utente viene utilizzato per proteggere i suoi scambi TGS con il KDC.

Ciò mi ha portato a chiedermi se fosse possibile richiedere i ticket di servizio (ST) al servizio di autenticazione (AS). La possibilità di richiedere ST all’AS ha diverse conseguenze, tra cui nuovi percorsi di attacco, bypass del rilevamento e potenziale indebolimento dei controlli di sicurezza. Tutti i problemi discussi in questo post sono stati segnalati a Microsoft e sono stati "considerati previsti dalla progettazione" (Figura 1).

Innanzitutto, ecco una panoramica di alto livello del tipico flusso Kerberos (Figura 2, proveniente da ADSecurity):

Il fatto che per ogni ticket venga emessa una chiave di sessione è una caratteristica importante per la ricerca successiva. Questa chiave di sessione viene restituita all'account richiedente all'interno di una sezione crittografata della risposta; la chiave di crittografia è già nota al richiedente.

Ad esempio, la chiave di sessione TGT viene archiviata in una sezione crittografata con la chiave utilizzata per dimostrare l'identità del richiedente quando richiede un TGT. Questa chiave è normalmente la chiave a lungo termine (hash della password) dell'account. Ma nel caso della crittografia a chiave pubblica per l'autenticazione iniziale (PKINIT) nel protocollo Kerberos, la chiave viene derivata dal certificato. La chiave di sessione ST è archiviata in una sezione crittografata con la chiave di sessione TGT.

La chiave di sessione del ticket è necessaria per utilizzare il ticket nel passaggio successivo del flusso Kerberos.

Una richiesta Kerberos ha due sezioni principali:

Il corpo req viene inviato principalmente in testo semplice e contiene diverse informazioni:

Una risposta Kerberos ha diverse sezioni e contiene una parte crittografata:

La parte del flusso Kerberos su cui si concentra questo post è AS-REQ/AS-REP, che viene solitamente utilizzata per richiedere un TGT. Nelle normali operazioni, un AS-REQ ha uno di due valori al suo internodecollacampo all'interno del corpo req:

Ho notato che con l'applicazione del FAST (Flexible Authentication Secure Tunneling) di Kerberos, gli account macchina inviavano ancora i propri AS-REQ senza armatura. Mi chiedevo se fosse possibile utilizzare un AS-REQ per richiedere direttamente un ST, anziché un TGT. Ciò mi ha portato a modificare Rubeus per determinare se specificare un altro SPN all'interno del filedecolla di un AS-REQ farebbe sì che il DC rispondesse con un ST per quell'SPN. A quanto pare, la risposta è stata "sì" (Figura 3).

Utilizzando un account macchina, posso richiedere una ST senza utilizzare l'armatura quando viene applicata la FAST. Cos'altro è possibile?

Kerberoasting, scoperto da Tim Medin, è un metodo per recuperare la password in testo normale o l'hash NT per un account di servizio, generalmente un account utente con un SPN. Il Kerberoasting è possibile perché parte di un ST è crittografato con la chiave a lungo termine dell'account di servizio (hash della password). Estraendo la parte crittografata del ticket, è possibile formare un hash da varie password in chiaro e tentare di decrittografare la parte crittografata. Se la decrittografia ha esito positivo, l'hash utilizzato è la chiave a lungo termine utilizzata per crittografare il ticket. Tale chiave potrà poi essere utilizzata per autenticarsi come account di servizio.

Inoltre, qualsiasi account può richiedere un ST per qualsiasi servizio. Pertanto, per eseguire l'attacco è necessaria la capacità di autenticarsi in Active Directory (AD). Almeno, questo era vero.

Innanzitutto, ho provato a utilizzare un account che non richiedeva la preautenticazione (DONT_REQ_PREAUTH) per richiedere un ST. Quando un account non richiede la pre-autenticazione per l'autenticazione, è possibile richiedere un TGT senza richiedere i dati di pre-autenticazione, che vengono crittografati con una qualche forma di credenziale (ad esempio, hash della password, certificato). Se un utente malintenzionato non ha ottenuto credenziali valide per un account, non è possibile generare una preautenticazione valida. Se la preautenticazione non è richiesta, questo non è un problema.