• Guide, Sicurezza, Sistemi Operativi
• 4 Gennaio 2024

Il 2023 è terminato. Il passaggio del testimone al novello 2024 è avvenuto come da previsioni: continuando la partita in corso. I vari gruppi criminali continuano le loro attività e sempre più vittime nel mondo continuano a subire problematiche serie, spesso con conseguenze devastanti. Gli attacchi che si concludono con data exfiltration, ransomware, rivendita di dati/utenze, ecc… continuano a farla da padrone. Nella maggioranza dei casi, il problema resta sempre lo stesso: scarsa consapevolezza, disattenzione.

Ma noi vogliamo cambiare marcia, in modo da iniziare l’anno con lo spirito giusto, organizzando le nostre difese al meglio, continuando ad approfondire tutte quelle configurazioni che Microsoft mette a disposizione per le nostre infrastrutture Active Directory.

Tra queste pagine ne abbiamo già parlato altre volte, tra le migliaia di configurazioni possibili ci sono molti oggetti che, se lasciati con i valori di default, possono essere utilizzati per scopi malevoli. Un esempio potete trovarlo qui su ICTPower con l’articolo Blue Team Experience: Detection and Mitigation con l’utilizzo di Mimikatz.

Questa volta parliamo di un’altra configurazione che, fortunatamente, è disabilitata di default ma che viene spesso abilitata per vari motivi.

Solitamente per garantire un determinato livello di sicurezza, il salvataggio delle password viene effettuato a seguito di un’azione di cifratura eseguita con una funzione di hash, ovvero una funzione matematica univoca che permette esclusivamente l’azione di cifratura, senza possibilità di tornare indietro.

Figura 1 – Esempio di funzione NT Hash

Denominata “Reversible Encryption” e presente da Windows 2000, è una configurazione che ha impatti sulle password degli utenti permettendone la decifratura.

Viene utilizzata per fornire supporto alle applicazioni che utilizzano protocolli che richiedono la conoscenza della password dell’utente a scopo di autenticazione. L’archiviazione delle password tramite crittografia reversibile è essenzialmente identica all’archiviazione di versioni in chiaro delle password. Tre esempi per cui viene utilizzata:

• Autenticazione CHAP (Challenge-Handshake Authentication Protocol) tramite accesso remoto
• Internet Authentication Services (IAS)
• Digest Authentication con Internet Information Services (IIS)

Per maggiori informazioni è possibile consultare la documentazione Microsoft alla pagina Store password using reversible encryption for all users in the domain | Microsoft Learn.

Questo approccio, però, è raccomandato solo se si è totalmente consapevoli della sicurezza della propria infrastruttura, soprattutto dei Domain Controller.

Questa configurazione è presente anche nelle odierne versioni di Windows e può essere abilitata in vari modi. Un primo metodo consiste nello spuntare la voce “Store password using reversible encryption” all’interno della finestra delle proprietà dell’utente che necessita di tale configurazione.

Figura 2 – Proprietà utente

Un altro metodo è utilizzando una PowerShell elevata con il comando:

Set-ADUser -Identity <USER> -AllowReversiblePasswordEncryption $True -Verbose

Figura 3 – PowerShell – Set Reversible Encryption

Il metodo più comune consiste nell’utilizzo di una Group Policy.

Figura 4 – Group Policy Management Editor Policy abilitata

Come ragiona un attaccante?

Il primo passo è quello di verificare la presenza di questa configurazione

Figura 5 – Proprietà utente

Spesso non si ha la possibilità di utilizzare una sessione desktop, di conseguenza procediamo con PowerShell utilizzando il comando:

Get-ADUser -Filter { AllowReversiblePasswordEncryption -eq $True}

Figura 6 – PowerShell verifica parametro AllowRreversiblePasswordEncryption

A questo punto è sufficiente utilizzare un tool come Mimikatz per ottenere la password in chiaro dell’utente trovato. In questo caso tentiamo un attacco denominato “DCSync”

Figura 7 – PowerShell esecuzione Mimikatz

Figura 8 – PowerShell password in chiaro

Come ragiona un difensore?

Un difensore non dovrebbe ragionare diversamente: verificare con lo stesso comando PowerShell la presenza di utenze con questa configurazione abilitata.

Per mitigare questo tipo di vulnerabilità è sufficiente inibire la possibilità di abilitare tale opzione con una GPO.

Tramite la console Group Policy Management verifichiamo:

Computer Configuration > Policies > Windows Settings > Security Settings > Account Policies > Password Policy > Store password using reversible encryption

Figura 9 – Group Policy Management Editor Policy non definita

Il valore di default è “Not Defined”. Forziamo la configurazione su “Disabled”

Figura 10 – Group Policy Management Editor Policy disabilitata

Conclusioni

Un attaccante ha molte strade perseguibili per ottenere informazioni utili ai suoi scopi. Spesso, come in questo caso, una leggerezza può essere sufficiente a permettere un problema molto più grande. 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.

A proposito, ma avete già letto l’articolo Active Directory Password Policies: facciamo un po’ di chiarezza – ICT Power?

Stay tuned!