Delega non vincolata

La delega senza restrizioni rappresenta un serio rischio per la sicurezza informatica. Prendendo provvedimenti per abusare dei controlli di delega Active Directory applicati agli oggetti utente e computer in un ambiente AD, un attaccante può muoversi lateralmente e persino ottenere il controllo del dominio.

Questo post del blog esplora quest'area di attacco (delega non vincolata) e offre a team di sicurezza e amministratori strategie efficaci per mitigare questo rischio per la sicurezza.

Cos'è la delega senza vincoli?

La delega consente a un utente o a un computer di impersonare un altro account al fine di accedere a risorse (come server di database back-end). La delega ha diverse applicazioni pratiche, che Microsoft tratta in questo post del blog.

Utilizzando la scheda Delega su un account utente o computer, è possibile configurare la delega illimitata o vincolata:

• Selezionando “Fidati di questo computer per la delega a qualsiasi servizio (delega Kerberos solo),” si sta abilitando la delega senza vincoli
• In alternativa, è possibile limitare i servizi che l'utente o il computer possono impersonare specificando particolari Service Principal Names (SPN), che corrisponde a una delega vincolata.

Si noti che un'altra opzione è la resource-based constrained delegation (RBCD), in cui la delega è configurata sulla risorsa, piuttosto che sugli account che accedono alla risorsa. RBCD può essere impostata utilizzando Windows PowerShell.

Quali sono i rischi della delega senza vincoli?

Diversi attacchi possono essere perpetrati contro la delega non vincolata: alcuni sono coperti in questo post del blog di harmj0y e Sean Metcalf ne descrive altri. Esploriamone un paio.

Esempio 1: Abusare della delega non vincolata per compromettere un intero AD forest

I ricercatori di sicurezza hanno dimostrato come un attaccante che compromette una macchina con delega illimitata in un foresta possa compromettere un'altra foresta e ogni dominio al suo interno. Se hai una fiducia bidirezionale in atto, un attaccante può utilizzare il bug della stampante MS-RPRN per far sì che un DC invii le informazioni di autenticazione indietro all'attaccante, permettendogli di utilizzare DCSync per compromettere il dominio fidato. Ad esempio, se la tua azienda ha acquisito una piccola azienda e ha unito il suo dominio al tuo, un attaccante che compromette un sistema nel piccolo ambiente potrebbe prendere il controllo dell'intera foresta della tua azienda, il che non è assolutamente buono.

È stato rilasciato un KB article per fornire una soluzione a questo bug e, a partire da Windows Server 2012 in poi, esiste un'impostazione di sicurezza per prevenirlo, ma potrebbe non essere attivata per impostazione predefinita.

Esempio 2: Sfruttare la delega non vincolata per abilitare il movimento laterale

Ecco un altro scenario. Se la delega senza restrizioni è attivata per un computer, ogni volta che un account si connette a quel computer, il suo ticket-granting ticket (TGT) del Key Distribution Center (KDC) viene memorizzato nella memoria per un utilizzo successivo da parte del computer. Se la macchina è compromessa, l'avversario può ottenere quel TGT e abusarne per causare molti danni — specialmente se il TGT appartiene a un utente con elevati privilegi.

Ad esempio, supponiamo che un Amministratore di Dominio acceda a un particolare computer tramite il Common Internet File System (CIFS) accedendo a una cartella condivisa. Senza la delega illimitata attiva, solo il ticket-granting server (TGS) verrebbe memorizzato nella memoria; questo biglietto dà accesso solo al servizio CIFS sulla macchina locale, quindi un avversario non può utilizzarlo per muoversi lateralmente. Possiamo vedere ciò utilizzando il comando Mimikatz sekurlsa::tickets /export, che restituisce solo il biglietto di servizio dell'utente (TGS):

Tuttavia, se la delega senza restrizioni è abilitata, il comando restituisce il TGT per l'account amministratore, che un avversario può utilizzare in un attacco di tipo Pass-the-Ticket per compromettere l'intero dominio.

Per raccogliere TGT da qualsiasi utente che si connette al sistema, l'aggressore può utilizzare il seguente comando PowerSpoit:

Diritti necessari per abilitare la Delega senza vincoli

Per poter gestire i controlli di delega di un oggetto, un utente necessita dei seguenti diritti:

• SeEnableDelegationPrivilege, un diritto utente è controllato dalla security policy di un domain controller e gestito tramite l'impostazione di Group Policy “Enable computer and user accounts to be trusted for delegation”, come illustrato di seguito
• La capacità di aggiornare gli attributi msDS-AllowedToDelegateTo e userAccountControl di un computer, dove questa impostazione dei Criteri di gruppo è memorizzata

Rilevamento della delega non vincolata

Per scoprire dove è stata abilitata la delega senza restrizioni, puoi utilizzare il seguente script PowerShell. Verificherà il valore del Controllo Account Utente (UAC) di tutti i computer per vedere dove la delega è attivata senza restrizioni.

Potresti anche voler vedere a chi è stato concesso il diritto SeEnableDelegationPrivilege. Per farlo, puoi utilizzare PowerSploit e il comando Get-DomainPolicy.

Migliori pratiche per ridurre il rischio della delega non vincolata

Per ridurre il rischio derivante dalla delega non vincolata, si raccomanda di:

• Indagate se la delega senza vincoli è effettivamente necessaria. In molti casi, la delega senza vincoli è stata abilitata per errore e può essere disabilitata completamente o convertita in delega vincolata o delega vincolata basata sulle risorse. Tenete presente che non è consigliabile configurare la delega vincolata a un domain controller (DC), perché un attaccante che compromette un account con delega vincolata sarà in grado di impersonare qualsiasi utente per qualsiasi servizio sul DC.
• Utilizza l'opzione “Questo account è sensibile e non può essere delegato” per impedire che gli account sensibili vengano utilizzati nella delega.
• Posiziona gli utenti privilegiati nel gruppo degli Utenti Protetti. Questo aiuta a prevenirne l'uso nella delega e mantiene i loro TGT fuori dal computer dopo che si autenticano.
• Monitorare attentamente l'attività degli account delegati. Tutti i sistemi in cui è configurata e utilizzata qualsiasi tipo di delega dovrebbero essere monitorati per attività sospette.

Come può Netwrix aiutare?

La delega senza restrizioni è uno dei numerosi vettori di attacco che i malintenzionati possono sfruttare per ottenere accesso e creare persistenza nel vostro ambiente di Active Directory. Con la Netwrix Active Directory Security Solution, sarete in grado di:

• Scopri i rischi per la sicurezza, inclusa la delega non necessaria, i permessi eccessivi, i privilegi permanenti e le configurazioni errate dei GPO, e dai priorità ai tuoi sforzi di mitigazione.
• Stabilite configurazioni sicure in tutta l'infrastruttura IT e mantenetele identificando e rimediando a qualsiasi modifica impropria rispetto alla vostra baseline consolidata.
• Rilevate e rispondete prontamente a minacce avanzate, come gli attacchi di Kerberoasting, DCSync, l'estrazione di dit e gli attacchi di Golden Ticket.
• Automatizza la risposta agli attacchi noti per minimizzare i danni.
• Assicurati un rapido recupero di Active Directory in caso di violazione della sicurezza o di altri incidenti.

FAQ

Quali tipi di delega sono disponibili in Active Directory?

Ci sono 3 tipi di delega che la tua organizzazione può utilizzare:

• Delega senza vincoli
• Delega vincolata
• Delega vincolata basata sulle risorse (RBCD)

Cos'è la delega vincolata basata sulle risorse (RBCD)?

Con RBCD, un amministratore che possiede una risorsa può delegare l'accesso ad essa.

Come posso configurare RBCD?

Per configurare un servizio di risorse per consentire l'accesso per conto degli utenti, puoi utilizzare i cmdlet di Windows PowerShell (New-ADComputer, New-ADServiceAccount, New-ADUser, Set-ADComputer, Set-ADServiceAccount e Set-ADUser) con il parametro PrincipalsAllowedToDelegateToAccount.