Ottenere nomi utente validi all'interno di una rete è un passo che fornisce ad un attaccante un grande vantaggio strategico, specialmente quando si tratta di un'operazione che può essere portata a termine quasi senza lasciare tracce. Tecnicamente parlando mi riferisco al processo di enumerazione degli account utente, possedere questo tipo di informazioni può infatti rendere molto più semplice l'esecuzione di altre attività come ad esempio il password guessing, il social engineering o la diffusione di malware via e-mail.

Chi sa di cosa io stia parlando potrebbe pensare che si tratti di un argomento ormai superato in quanto le sessioni nulle (NULL Sessions) su protocolo NetBIOS, grazie agli aggiornamenti di sistema, sono ormai obsolete e impossibili da sfruttare. Non molti però sanno che ancora oggi è possibile sfruttare un meccanismo simile contro un Domain Controller Windows 2003, l'unica differenza è che il protocollo interessato non sarà più il NetBIOS ma l'RPC.

In questo articolo vi presenterò un attualissimo metodo, denominato RID Cycling, che rende possibile l'enumerazione degli oggetti di Active Directory attraverso una sessione nulla RPC, naturalmente vi mostrerò anche come sia possibile proteggersi da questo tipo di attacco.

Nozioni fondamentali

Gli oggetti che si trovano all'interno di un Dominio Active Directory, in particolare le identitià di protezione o i gruppi di protezione, sono identificati da un valore definito Security Identifier (SID) che è così composto:

parte nota del sid + identificatore del dominio + identificatore relativo (RID)

Ad esempio

S-1-5-21-932357163-4043341325-4182193562-500

• S identifica che la stringa è un SID
• 1 è la revisione
• 5 è l'autorità dell'identificatore, per esempio 5 sta per NT Authority System
• 21-932357163-4043341325-4182193562 è l'identificatore del dominio, questo valore è differente per ogni dominio
• 500 è l'identificatore relativo

L'aspetto più importante è che la prima e l'ultima parte di un SID sono well-known (ben conosciute) quindi una volta ottenuto l'identificatore di dominio si sarà perfettamente in grado di generare un SID valido per interrogare il servizio LSA (Local Security Authority) di Windows allo scopo di estrapolare specifiche informazioni da Active Directory.

Per quanto riguarda la parte nota del SID, a questo indirizzo potete trovarne una lista piuttosto esaustiva.

A proposito del RID invece vi sarà sufficiente sapere che:

• 500 è sempre il RID dell'account (built-in) Administrator
• 501 è sempre l'account (built-in) Guest
• 512 è sempre il gruppo (built-in) Domain Admins
• 514 è sempre il gruppo (built-in) Domain Guests
• Qualsiasi altro gruppo o utente che non sia di tipo built-in avrà un valore RID superiore a 1000, in particolare c'è da dire che questi RID vengono creati usufruendo del pool di indirizzi che viene assegnato ad ogni Domain Controller dal RID Master Server (una delle Operazioni Master presenti in un Dominio windows 2003).

L'esempio sopra riportato identifica l'account Administrator del dominio, lo ripeto:

S-1-5-21-932357163-4043341325-4182193562-500

E se fossimo in grado di trasformare il sopra citato SID in un nome utente? In tal caso potremmo comunque risalire all'account utente amministrativo anche se questo fosse stato rinominato... ma questo lo vedremo meglio tra poco.

La vulnerabilità

La vulnerabilità dei Domain controller Windows 2003 consiste nel fatto che in maniera predefinita, per garantire un buon livello di compatibilità, essi permettono la connessione anonima all'interfaccia RPC lsarpc, ciò permette di eseguire con successo traduzioni di SID in nome oggetto.

La dimostrazione

Ecco una dimostrazione della vulnerabilità eseguita utilizzando Ubuntu Linux.

Stabilisco una sessione rpc nulla con il seguente comando:

rpcclient -U "" ip_del_domain_controller

Con il comando lsaquey stabilisco il nome del dominio e il suo SID

Con il comando lookupsids cerco di identificare l'account utente amministrativo (built-in), ho precedentemente affermato che il RID di tale account equivale sempre a 500... questo è il momento di mettere in pratica la teoria

La traduzione da SID a nome utente sembra funzionare... a questo punto si può notare come in questo caso la modifica del nome utente dell'account amministrativo non costituisca una reale protezione infatti, come vi ho precedentemente anticipato, anche se quest'ultimo fosse stato rinominato lo avremo ugualmente potuto enumerare.

Provo ora a risolvere il nome di qualche oggetto con RID superiore a 1000, per brevità salterò subito alla conclusione:

Ho trovato il RID di un utente di dominio, provo ancora una volta...

Questa volta ho identificato invece un account computer.

Se non aveste linux a disposizione potete comunque verificare la vulnerabilità del vostro Domain Controller anche da Windows grazie allo strumento GetAcct.exe (mirror locale).

L'utilizzo è semplicissimo, gli unici dati di cui avrete bisogno sono l'indirizzo IP del server e un RID di riferimento, direi che il 500 (Administrator) va più che bene.

L'attacco

E' certo che eseguire la traduzione manuale di centinaia o migliaia di SID non è sicuramente la strada più comoda da seguire quando si predispone un attacco di questo tipo, ecco dove entra in gioco il RID Cycling.

Per mezzo dello script enum4linux.pl (mirror locale) è possibile automatizzare il processo di risoluzione dei SID, quest'ultimo non farà altro che prendere in input un pool di RID e, tramite un cliclo, ne eseguirà la risoluzione al posto nostro.

In pochissimi secondi potremmo avere risultati come il seguente:

----- Target information -----
Target .......... 192.168.192.180
RID Range ....... 500-550,1000-1200
Username ........ ''
Password ........ ''
Known Username .. 'administrator'
----- Enumerating Workgroup/Domain on 192.168.192.180 ------
[+] Got domain/workgroup name: DOMINIO
----- Session Check on 192.168.192.180 -----
[+] Server 192.168.192.180 allows sessions using username '', password ''
----- Users on 192.168.192.180 via RID cycling (RIDS: 500-550,1000-1200) -----
[+] Got SID: S-1-5-21-932357163-4043341325-4182193562 using username '', password ''
S-1-5-21-932357163-4043341325-4182193562-500 DOMINIO\Administrator (1)
S-1-5-21-932357163-4043341325-4182193562-501 DOMINIO\Guest (1)
S-1-5-21-932357163-4043341325-4182193562-502 DOMINIO\krbtgt (1)
S-1-5-21-932357163-4043341325-4182193562-512 DOMINIO\Domain Admins (2)
S-1-5-21-932357163-4043341325-4182193562-513 DOMINIO\Domain Users (2)
S-1-5-21-932357163-4043341325-4182193562-514 DOMINIO\Domain Guests (2)
S-1-5-21-932357163-4043341325-4182193562-515 DOMINIO\Domain Computers (2)
S-1-5-21-932357163-4043341325-4182193562-516 DOMINIO\Domain Controllers (2)
S-1-5-21-932357163-4043341325-4182193562-517 DOMINIO\Cert Publishers (4)
S-1-5-21-932357163-4043341325-4182193562-518 DOMINIO\Schema Admins (2)
S-1-5-21-932357163-4043341325-4182193562-519 DOMINIO\Enterprise Admins (2)
S-1-5-21-932357163-4043341325-4182193562-520 DOMINIO\Group Policy Creator Owners (2)
S-1-5-21-932357163-4043341325-4182193562-1000 DOMINIO\HelpServicesGroup (4)
S-1-5-21-932357163-4043341325-4182193562-1001 DOMINIO\SUPPORT_388945a0 (1)
S-1-5-21-932357163-4043341325-4182193562-1002 DOMINIO\TelnetClients (4)
S-1-5-21-932357163-4043341325-4182193562-1003 DOMINIO\SERVER-PRX$ (1)
S-1-5-21-932357163-4043341325-4182193562-1104 DOMINIO\DnsAdmins (4)
S-1-5-21-932357163-4043341325-4182193562-1105 DOMINIO\DnsUpdateProxy (2)
S-1-5-21-932357163-4043341325-4182193562-1106 DOMINIO\mirko.iodice (1)
S-1-5-21-932357163-4043341325-4182193562-1107 DOMINIO\COMPUTER-MIRIOD$ (1)
S-1-5-21-932357163-4043341325-4182193562-1108 DOMINIO\VMWXP$ (1)
S-1-5-21-932357163-4043341325-4182193562-1109 DOMINIO\mario.rossi (1)

Come proteggersi

Per proteggersi da questo tipo di attacco non basta, se pur sia sempre buona norma farlo, impostare a 1 il valore della seguente chiave:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\control\LSA\RestrictAnonymous (reg_dword)

Questo tipo di approccio va bene per mettere fine all'enumerazione via NetBIOS e si utilizzava molto su Windows 2000 (il quale supporta addirittura il valore 2 che, anche se poco consigliato, sarebbe in grado di chiudere qualsiasi tipo di connessione anonima), per le sessioni RPC serve qualcosa in più.

Come mostra lo screenshot il corretto approccio per prevenire il RID Cycling è quello di disabilitare, attraverso Group Policy, l'opzione Network Access: Allow Anonymous SID/Name Translation.

Ci tengo a precisare che questo tipo di vulnerabilità interessa soltanto i Server Domain Controller e non i Member Server Windows 2003, ecco infatti come risultano le politiche di sicurezza di un Member Server:

(scusate se questo screen è in italiano, il member server lo avevo soltanto in lingua italiana)

Come avrete potuto notare questo tipo di impostazioni sono molto più restrittive rispetto a quelle di un Domain Controller.

Approfondimenti

Se volete approfondire quanto descritto in questo articolo vi invito a visitare i seguenti link:

• http://www.hsc.fr/ressources/articles/win_net_srv/index.html
• http://www.hsc.fr/ressources/presentations/null_sessions/msrpc_null_sessions.pdf

Autore

Mirko Iodice
mirko -at- notageek (.dot) it

Print This • Email this • Twit This! • Add to del.icio.us • Share on Facebook • Digg This! • Stumble It! • AddThis! • Share on Segnalo Alice • Share on OKNotizie