Se seguite questo blog, saprete che circa due anni e mezzo fa ho iniziato a parlare del ruolo precario di Group Policy nella tipica postura di sicurezza aziendale. Molti, se non la maggior parte, dei negozi AD utilizzano GP per eseguire l'hardening della sicurezza sui loro desktop e server Windows. Questo include tutto, dalla modifica delle impostazioni del sistema operativo alla disattivazione di NTLMv1 o al controllo dell'account utente (UAC), fino al controllo di chi può accedere a quali macchine e quali gruppi AD hanno accesso privilegiato a quali desktop e server. Tutto questo viene memorizzato all'interno delle GPO che, per impostazione predefinita, sono "leggibili al mondo" da qualsiasi utente autenticato. Questo fatto è vero da molto tempo, in realtà dal 2000, quando AD e GP sono stati distribuiti, ma è diventato più visibile come potenziale problema di InfoSec solo negli ultimi anni, in gran parte grazie a strumenti come Bloodhound, PowerView e Grouper che mettono a nudo il fatto che queste informazioni possono essere utilizzate per compiere ogni sorta di malefatte.
Da allora, mi sono concentrato in gran parte sul lato difensivo dell'equazione e principalmente sulle raccomandazioni per ridurre la leggibilità delle GPO relative alla sicurezza per impedire a un aggressore di scoprire facilmente la postura di sicurezza di un'organizzazione. Tuttavia, di recente ho dedicato un po' di tempo a riflettere sulle opportunità di un uso più distruttivo delle GPO, sfruttando le impostazioni esistenti all'interno delle GPO modificabili per eseguire varie attività maligne all'interno di un ambiente. Poiché le GPO hanno spesso un impatto sulla maggior parte, se non su tutti gli utenti e i computer di un'organizzazione, si tratta di un meccanismo di distribuzione del malware molto efficiente, come ho illustrato in un post sul blog di qualche tempo fa. Questi tipi di attacchi, che iniettano impostazioni dannose in una GPO, si basano sulla capacità dell'aggressore di ottenere i permessi di scrittura su una GPO, in particolare sulla parte SYSVOL della GPO, dove la maggior parte (ma non tutte) le estensioni client side (CSE) di GP memorizzano le loro impostazioni. Naturalmente, è necessario comprendere il formato delle impostazioni dell'area dei criteri che si desidera influenzare per poterle dirottare e, per una volta, il modo estremamente complicato con cui Microsoft ha affrontato lo sviluppo dei CSE è un vantaggio in questo caso, poiché praticamente ogni area dei criteri utilizza uno schema e una struttura di dati diversi per memorizzare le impostazioni. Un punto per l'incoerenza architettonica!
Tre modi per creare problemi
Riflettendo su GP e sulle sue fragilità, sono giunto alla conclusione che ci sono (almeno) tre vie principali per un attaccante per utilizzare GP per i suoi scopi nefasti. Vale a dire,
- Sfruttare l'accesso in lettura eccessivamente permissivo alle GPO per conoscere la posizione di sicurezza di un'organizzazione: chi ha accesso privilegiato dove, ecc. Come ho già detto, ho scritto ampiamente su questo argomento e ho fornito suggerimenti su come mitigarlo.
- Sfruttare un accesso in scrittura troppo permissivo alle GPO per iniettare impostazioni dannose nelle GPO esistenti. Ne parlo di seguito nella sezione intitolata "Delega GPO". Il New-GPOImmediateTaskcmdletdi PowerView è un esempio perfetto di questo approccio per iniettare un'attività pianificata in una GPO ed eseguire codice arbitrario.
- Sfruttare i percorsi esterni a cui si fa riferimento nelle GPO e che hanno un accesso in scrittura troppo permissivo. Questa è una variante del punto #2 e mi sono reso conto della potenza di questa idea mentre testavo e collaboravo con @mikeloss alla sua eccellente utility Grouper2, citata in precedenza. Grouper2 cerca elementi "interessanti" nelle GPO, che possono includere qualsiasi cosa, dai criteri dei gruppi ristretti che concedono l'accesso privilegiato alle password GPP persistenti e, cosa più interessante per me, riferimenti a eseguibili, script o programmi di installazione esterni. Parlerò più a lungo di questi percorsi esterni nella sezione intitolata "Percorsi esterni", ma a @mikeloss va il merito di avermi fatto scoprire questo aspetto.
Delega GPO
Parliamo ancora del punto #2. Il modo in cui funziona la delega di una GPO consiste nel concedere a utenti, computer o gruppi vari livelli di accesso a una GPO, di solito in GPMC dalla scheda "Delega" di una determinata GPO o utilizzando PowerShell, e tali autorizzazioni (che includono Lettura, Applicazione della lettura, "Modifica impostazioni" e "Modifica impostazioni, eliminazione e modifica della protezione") vengono impresse nell'oggetto Group Policy Container (GPC) basato su AD corrispondente e nella cartella con nome GUID nel Group Policy Template (GPT) (ad esempio SYSVOL). Ovviamente i permessi AD non corrispondono all'1-1 ai permessi del file system NTFS, ma se si osservano entrambe le parti di una GPO nell'Editor ACL, si vedranno permessi molto simili (vedi sotto).
Quindi, un utente malintenzionato deve essere in grado di ottenere l'accesso in scrittura alla GPT (o in alcuni casi alla GPC) di una determinata GPO per poterla compromettere. Questo non è impossibile, ovviamente, soprattutto se l'attore della minaccia è in grado di elevarsi a un ruolo di amministratore che potrebbe avere permessi di modifica su una GPO. Tuttavia, dal punto di vista di un difensore, sottolinea l'importanza di avere uno stretto controllo sulle deleghe GPO. Le autorizzazioni per la modifica o la creazione di GPO dovrebbero essere delegate a una piccola manciata di amministratori di sistema, e questi responsabili della sicurezza dovrebbero essere trattati come amministratori "Tier 0", dato il potenziale impatto su tutto l'ambiente che una modifica dannosa di GPO può avere. Ancora più preoccupante è il fatto che se un utente malintenzionato ottiene l'accesso in scrittura, ad esempio, al GPT, può essere molto difficile rilevare queste modifiche dannose se l'utente malintenzionato modifica direttamente i file delle impostazioni, anziché passare attraverso strumenti di gestione delle modifiche alle GPO consolidati come GP Editor. Per individuare la maggior parte di queste modifiche indesiderate è necessario cercare le modifiche del file system sul GPT, ma dato che le modifiche GPO legittime generano notifiche di modifica del GPT, è necessario essere in grado di passare al setaccio sia le modifiche GPO dannose che quelle valide per trovare quelle che possono creare problemi. La buona notizia è che se un utente malintenzionato deve aggiungere nuove impostazioni dell'area dei criteri (cioè deve chiamare un CSE diverso da quello già distribuito) a una GPO, le sue possibilità di essere individuato aumentano. Questo perché, affinché un client (server o workstation) elabori una nuova impostazione dell'area di criterio della GPO, devono avvenire diverse modifiche nel GPC (ad esempio, l'incremento del numero di versione e l'aggiunta corretta degli ExtensionGUID del CSE al GPC) per far sì che il client sia a conoscenza di tali impostazioni, il che rende più difficile per un amministratore, con un minimo di auditing GP, non notare la manomissione. Per quanto riguarda le aree di policy più adatte a questo tipo di manipolazione, date un'occhiata all'eccellente post di @_wald0"A Red Teamer's Guide to GPOs and OUs" per alcuni esempi di percorsi di policy che possono essere manipolati con buoni risultati. Questo punto sostiene anche la necessità di mantenere le GPO che implementano aree di policy altamente "sfruttabili", ulteriormente bloccate. In conclusione, bloccate chi può modificare le GPO!
Percorsi esterni
Questo mi porta al mio ultimo fascino (#3), ovvero l'uso di riferimenti a "percorsi esterni" nelle GPO per aggirare la limitazione imposta dagli amministratori al punto #2. Cosa intendo per percorsi esterni? Qualsiasi riferimento presente in una GPO che punta a un eseguibile, a uno script, a un pacchetto MSI o a un altro file che "fa qualcosa" quando viene richiamato e che esiste al di fuori delle normali posizioni GPC e GPT (Sysvol). Perché sono interessanti? Perché, anche se state bloccando l'accesso in scrittura alle GPO come suggerito al punto 2, potreste potenzialmente avere script, eseguibili e pacchetti MSI in giro per i file server di tutta la rete, con vari gradi di controllo dell'accesso, che vengono richiamati ed eseguiti da quelle stesse GPO bloccate che pensavate fossero così sicure. Quindi, un aggressore che non riesce a ottenere l'accesso in scrittura a una GPO, può utilizzare il proprio accesso in lettura (come indicato sopra al punto 1) per cercare questi percorsi esterni di riferimento e cercare di sostituire gli script, gli exe e gli MSI con le proprie versioni dannose (questo compito è in effetti quello che Grouper2 rende molto più semplice). La volta successiva che la GPO viene elaborata da un client, il file dannoso viene tranquillamente eseguito dalla GPO, che non se ne accorge. Esempi di aree di policy che possono tipicamente fare riferimento a percorsi esterni (cioè percorsi al di fuori di GPC e GPT) sono:
- Script di avvio/spegnimento e di logon/logoff
- Installazione del software GP (file MSI)
- Preferenze GP Attività pianificate
- GP Preferenze Stampanti (con Stampanti TCP/IP, è possibile specificare un percorso esterno da cui il client può scaricare i driver della stampante, ottimo!)
- GP Preferences Shortcuts, per le scorciatoie che esistono in posizioni di esecuzione automatica come Startup
- File delle preferenze GP, in cui sono presenti file che possono essere copiati da posizioni esterne arbitrarie in posizioni di esecuzione automatica o in altre posizioni di file locali "facilmente eseguibili".
A dire il vero, probabilmente ci sono altri luoghi di questo tipo nascosti in GP (e io continuo a cercare...). Quelli sopra citati sono i più ovvi.
Quindi, perché ci si deve preoccupare di questi percorsi esterni? Pensateci: il problema di impedire la manomissione indesiderata delle GPO, come descritto al punto #2, è limitato. È sufficiente preoccuparsi della delega su tali GPO per mantenere il controllo di questo tipo di comportamento. Ma quando si dispone di GPO che fanno riferimento a codice eseguibile su condivisioni di file esterne, è necessario estendere il campo d'azione a CIASCUNA DI QUELLE POSTAZIONI DI FILE! Quanti di voi possono essere sicuri della gestione dei permessi su condivisioni di file casuali all'interno del vostro ambiente (per non parlare delle vostre GPO)? Quindi, se una GPO richiama un file eseguibile o un programma di installazione esistente su una condivisione non sicura, le GPO diventano veicoli di distribuzione involontaria per qualsiasi schifezza casuale con cui un aggressore può sostituire gli eseguibili. E naturalmente, poiché non esiste un controllo CRC o un altro controllo di validità all'interno di GP, si è alla mercé di qualsiasi file presente (un'attenuazione a questo problema è il fatto che non tutte le aree di criterio eseguono automaticamente i loro payload in ogni momento. Ad esempio, se un computer ha già ricevuto un'implementazione di software tramite il criterio Installazione software, in circostanze normali non verrà distribuito nuovamente l'MSI dannoso. Ma qualsiasi nuovo computer riceverà ovviamente il pacchetto dannoso).
Qual è la conclusione di questa operazione? Oltre a proteggere le delegazioni GPO, è necessario innanzitutto capire dove si trovano i riferimenti ai percorsi esterni all'interno dell'ambiente, quindi mettere in sicurezza i percorsi esterni!!!!
Sintesi
Spero che questo fornisca ulteriori spunti di riflessione sulla protezione dell'ambiente GP e quindi dell'intero ambiente Windows. Se oggi vi affidate a GP per configurare i vostri sistemi Windows, non potrò mai sottolineare abbastanza quanto sia importante, dal punto di vista dell'InfoSec, assicurarsi che le GPO siano chiuse e che tutto ciò che chiamano dall'esterno sia trattato come 'all'interno dello stesso dominio di interesse' e altrettanto chiuso. Quindi, per riassumere le azioni da intraprendere:
- Bloccate l'accesso in lettura alle GPO critiche e legate alla sicurezza per evitare di svelare la vostra posizione di sicurezza.
- Bloccare l'accesso in scrittura a tutte le GPO per garantire che non vengano cooptate come vettore di attacco.
- Bloccate l'accesso in scrittura a tutti i percorsi esterni a cui fanno riferimento le GPO.
Darren
