Microsoft Windows: vulnerabilitati in servicii
Recent pe comunitatea milw0rm a aparut un cod ASP .NET ce aminteste de niste probleme destul de grave ale sistemelor de operare Microsoft Windows.
Vulnerabilitatea se numeste in linii mari “token kidnapping” si exploateaza metoda prin care serviciilor (procese si thread-uri) li se atribuie drepturi de acces si rulare pe platformele dezvoltate de compania Microsoft.
Serviciile de pe masinile ce ruleaza Windows primesc permisii (token-uri) pentru a executa cod si a avea acces la diferite resure.
Exista insa o problema ce afecteaza toate platformele de tip Microsoft Windows existente pe piata – incluzand XP, 2003, Vista si 2008 – ce permite exploatarea contextului de securitate primit de un serviciu, obtinandu-se astfel privilegii administrative pe sistemul respectiv.
Practic, la inceput orice serviciu deschis rula sub contul local SYSTEM. Acest lucru permitea bineinteles compromiterea intregului sistem de operare daca se putea compromite un serviciu. Apoi, compania Microsoft a introdus conturile de Local Service si Network Service. O imbunatatire majora care are insa unele vulnerabilitati ce afecteaza orice platforma Windows (XP/Vista/2008): thread-urile pot rula cod folosindu-se de informatile de securitate ale altui proces.
Privind mai adanc, securitatea unui proces se bazeaza pe o serie de token-uri ce descriu contextul de securitate al unui proces. Acesta include atat identitatea cat si privilegiile utilizatorului asociate cu respectivul proces. Asignarea initiala se face folosind in token primar, dar contextul de securitate poate suferi modificari pe parcurs printr-un token de impersonare.
Contextul de securitate contine informatii precum:
- Security identifier (SID) al contului
- SID-ul grupului din care face parte contul
- SID-ul ce identifica sesiunea logata curenta
- o lista de privilegii a utilizatorului si/sau grupului
- un DACL (Discretionary Access List) folosit de sistem
- daca token-ul este primar sau de impersonare
- nivelul de impersonare
Impersonarea este un procedeu legitim prin care un proces poate executa intr-un alt context de securitate decat cel descris de valorile SID. In general, un proces dintr-o aplicatie client impersoneaza un client pentru a putea actiona in numele acestuia (pentru a accesa obiecte in proprietatea clientului).
Simpla existenta a acestei optiuni deschide o bresa semnificativa in sistem. In sistemele Windows XP si Windows 2003, thread-urile nu sunt protejate si pot fi manipulate cu usurinta. Folosind instructiunea SetThreadContext(), un thread poate executa orice cod in procesul tinta.
Tintele cele mai bune pentru a executa astfel de operatiuni sunt serviciile RPC, unde atacatorul are nevoie de un token de impersonare de la NetworkService; acesta se poate obtine apeland o simpla functie. Alternativ, acest lucru se poate manipula si in cazul serviciilor SQL Server si IIS 6.
Sub sistemele de operare Windows Vista si Windows 2008, serviciile sunt protejate dar exista si anumite scapari. Token-ul contului SYSTEM se poate obtine cu usurinta de la procesele WMI*.exe. Acesta ruleaza sub NetworkService, LocalService sau SYSTEM, nu este protejat si impersoneaza contul SYSTEM.
Desi acestea sunt operatiuni dificile in mod normal, un tip de vulnerabilitate mi-a atras atentia in mod special si m-a determinat sa scriu articolul: se poate trece peste protectia data de SID ruland un cod dintr-o pagina ASP .NET; astfel un dll poate fi injectat in serviciul RpcSs ce ruleaza sub contul NetworkService. Mai departe, acelasi dll este injectat de RpcSs in serviciul IIS ce ruleaza sub contul de SYSTEM, practic punandu-se stapanire pe sistem.
Cateva concluzii pot fi trase:
1. Fara mici schimbari de finete, pe Windows XP si Windows 2003 un utilizator poate executa cod ca SYSTEM.
2. Sub acelasi context, pe Windows Vista si 2008 LocalService = NetworkService = SYSTEM.
3. Semnalul major de alarma se poate trage in mediile de shared hosting bazate pe solutii Microsoft, unde daca un utilizator ruleaza un ASP .NET poate prelua controlul sistemului.
Codul aparut pe milw0rm arata aproximativ asa si ar trebui restrictionat sub toate formele pe care le poate lua.
…
System.Diagnostics.Process myP = new System.Diagnostics.Process();
myP.StartInfo.RedirectStandardOutput = true;
myP.StartInfo.FileName=Server.MapPath(“exploit.exe”);
myP.StartInfo.UseShellExecute = false;
myP.StartInfo.Arguments= ” \”net user /add own3d\” “;
myP.Start();
string output = myP.StandardOutput.ReadToEnd();
Response.Write(output)
Pentru un studiu aprofundat, codul ASP .NET aparut si aplicatia de exploit pot fi gasite pe comunitatea milw0rm.
4. Un SQL Server DBA poate lua controlul sistemului de operare prin adaugarea unui cont cu privilegii administrative:
exec xp_cmdshell ‘exploit “net user /add own3d”‘
Din fericire, acest lucru este usor reparabil prin inchiderea posibilitatii de a rula comadna xp_cmdshell:
EXEC sp_configure ‘show advanced options’, 1
GO
RECONFIGURE
GO
EXEC sp_configure ‘xp_cmdshell’, 0
GO
RECONFIGURE
GO
Pentru o intelegere mai buna, recomand urmatoarele referinte:
Access Tokens on MSDN
Client Impersonation on MSDN
Alte cateva detalii vulnerabilitate
« Nokia se retrage din IT Security | Home | Politica parolelor: de ce? »
Leave a Comment
You must be logged in to post a comment.