puterea în Utilizatorii de putere

publicat pentru prima dată pe TechNet pe Mai 01, 2006

plasarea conturilor de utilizator Windows în grupul de securitate Power Users este o abordare comună pe care o adoptă organizațiile IT pentru a atrage utilizatorii într-un mediu cu cel mai mic privilegiu, evitând în același timp numeroasele dureri de a rula cu adevărat ca utilizator limitat. Grupul Power Users este capabil să instaleze software, să gestioneze setările de alimentare și fus orar și să instaleze controale ActiveX, acțiuni pe care utilizatorii limitați le refuză.
ceea ce mulți administratori nu reușesc să realizeze, totuși, este că această putere vine cu prețul unei adevărate securități a utilizatorilor limitați. Multe articole, inclusiv acest articol din Baza de cunoștințe Microsoft și această postare pe blog a specialistului în securitate Microsoft, Jesper Johansen, subliniază că un utilizator care aparține grupului Power Users se poate ridica cu ușurință la administratori complet privilegiați, dar nu am putut găsi o descriere detaliată a mecanismelor de ridicare la care se referă. Prin urmare, am decis să investighez.
înainte de a putea începe ancheta, a trebuit să definesc problema. În absența unui defect de securitate, cum ar fi un buffer overflow privilegiu escaladarea este posibilă numai dacă un cont poate configura codul arbitrar pentru a executa în contextul unui cont mai privilegiat. Conturile implicite care au mai multe privilegii decât utilizatorii Power includ administratorii și contul de sistem Local, în care rulează mai multe procese de servicii Windows. Astfel, dacă un membru Power Users poate modifica un fișier executat de unul dintre aceste conturi, poate configura unul dintre executabilele lor pentru a încărca un DLL arbitrar sau poate adăuga un executabil pornire automată la aceste conturi, pot obține privilegii administrative complete.
primul meu pas a fost să văd ce fișiere și directoare la care grupul Power Users are acces la scriere, dar utilizatorii limitați nu. Sistemele am considerat au fost stoc Windows 2000 Professional SP4, Windows XP SP2, și Windows Vista. Nu mă voi deranja să mă uit la sistemele de servere, deoarece cel mai comun scenariu al utilizatorilor de energie este pe o stație de lucru.
metoda forței brute de a vedea ce obiecte ale sistemului de fișiere pot modifica utilizatorii necesită vizitarea fiecărui fișier și director și examinarea permisiunilor sale, lucru care în mod clar nu este practic. Utilitarul Cacls din linia de comandă pe care Windows include descriptorii de securitate haldele, dar nu m-am deranjat niciodată să învăț limbajul descriptor de securitate (SDDL) și să analizez ieșirea ar necesita scrierea unui script. Utilitarul AccessEnum pe care Bryce l-a scris părea promițător și se poate uita și la securitatea registrului, dar are ca scop afișarea potențialelor puncte slabe ale permisiunilor, nu accesele disponibile pentru anumite conturi. Mai mult, știam că va trebui să examinez și securitatea aplicată serviciilor Windows.

am ajuns la concluzia că a trebuit să scriu un nou utilitar pentru job, așa că am creat AccessChk . Treci AccessChk un nume de cont sau de grup și o cale de sistem de fișiere, cheie de Registry, sau numele serviciului Windows, și raportează accesează efectiv contul sau grupul are pentru obiect, luând în considerare apartenența la grupul contului. De exemplu, dacă contul Mark a avut acces la un fișier, dar Mark aparține grupului de dezvoltatori căruia i se refuză în mod explicit accesul, atunci AccessChk ar arăta Mark ca neavând acces.
pentru a face ieșirea ușor de citit AccessChk imprimă ‘W’ lângă numele obiectului dacă un cont are permisiuni care i-ar permite să modifice un obiect și ‘R’ dacă un cont poate citi datele sau starea obiectului. Diverse switch-uri provoca AccessChk să reapară în subdirectoare sau subcheile de Registry și comutatorul –v a raporta accesele specifice disponibile în cont. Un comutator pe care l –am adăugat special pentru a căuta obiecte pentru care un cont are acces la scriere este-w.
înarmat cu acest nou instrument am fost gata să încep să investighez. Prima mea țintă a fost o instalare Windows XP SP2 VMWare care nu are alte aplicații instalate decât instrumentele VMWare. Prima comandă pe care am executat-o a fost:
accesschk-ws “power users” c:\windows
aceasta arată toate fișierele și directoarele din directorul \Windows pe care grupul Power Users le poate modifica. Desigur, multe dintre fișierele din \Windows fac parte din sistemul de operare sau serviciile Windows și, prin urmare, se execută în contul sistemului Local. AccessChk a raportat că utilizatorii de putere pot modifica cele mai multe dintre directoarele sub \Windows, care permite utilizatorilor membre pentru a crea fișiere în aceste directoare. Astfel, un membru al Grupului Power Users poate crea fișiere în directorul \Windows și \ Windows \ System32, care este o cerință comună a aplicațiilor moștenite slab scrise. În plus, utilizatorii Power trebuie să poată crea fișiere în directorul \Windows\Downloaded Program Files, astfel încât să poată instala controale ActiveX, deoarece Internet Explorer le salvează în acel director. Cu toate acestea, simpla creare a unui fișier în aceste directoare nu este o cale către ridicarea privilegiilor.
în ciuda faptului că utilizatorii Power pot crea fișiere sub \Windows și majoritatea subdirectoarelor sale, Windows configurează permisiunile de securitate implicite pentru majoritatea fișierelor conținute în aceste directoare, astfel încât doar membrii grupului Administratori și contul de sistem Local să aibă acces la scriere. Excepțiile includ fișierele font (.fon), multe fișiere jurnal de sistem (.jurnal), unele fișiere de ajutor (.chm), imagini și clipuri audio (.jpg, .gif, și .wmv) și fișiere de instalare (.inf), dar niciunul dintre aceste fișiere nu poate fi modificat sau înlocuit pentru a obține privilegiul administrativ. Driverele de dispozitiv din\Windows \ System32 \ Drivers ar permite o escaladare ușoară, dar Power Users nu are acces la scriere la niciunul dintre ele.

am văzut un număr de .exe și .dll este în listă, totuși, așa că le-am examinat pentru posibile exploatări. Majoritatea executabilelor pentru care Power Users are acces la scriere sunt utilitare interactive sau rulate cu privilegii reduse. Cu excepția cazului în care puteți păcăli un administrator să se conecteze interactiv la sistem, acestea nu pot fi utilizate pentru a ridica. Dar există o excepție evidentă: ntoskrnl.exe:

așa este, utilizatorii Power pot înlocui sau modifica fișierul de bază al sistemului de operare Windows. Cu toate acestea, la cinci secunde după modificarea fișierului, Windows File Protection (WFP) îl va înlocui cu o copie de rezervă pe care o recuperează, în majoritatea cazurilor, din \Windows\System32\Dllcache. Utilizatorii de putere nu are acces la scriere la fișierele din Dllcache, astfel încât să nu poată submina copia de rezervă. Dar membrii grupului Power Users pot eluda WFP scriind un program simplu care înlocuiește fișierul, spală datele modificate pe disc, apoi repornește sistemul înainte ca WFP să acționeze.
am verificat că această abordare funcționează, dar întrebarea a rămas despre modul în care această vulnerabilitate poate fi folosită pentru a ridica privilegiul. Răspunsul este la fel de ușor ca utilizarea unui dezasamblator pentru a găsi funcția pe care Windows o folosește pentru verificările privilegiilor, SeSinglePrivilegeCheck și patch-ul punctului său de intrare în imaginea de pe disc , astfel încât să returneze întotdeauna TRUE, care este codul rezultat care indică faptul că un utilizator are privilegiul verificat. Odată ce un utilizator rulează pe un kernel modificat în acest mod, va părea că are toate privilegiile, inclusiv Load Driver, Take Ownership și Create Token, pentru a numi doar câteva dintre privilegiile pe care le pot folosi cu ușurință pentru a prelua controlul administrativ complet al unui sistem. Deși Windows XP pe 64 de biți împiedică modificarea kernel-ului cu PatchGuard , puține întreprinderi rulează pe Windows pe 64 de biți.
Înlocuirea Ntoksrnl.cu toate acestea, exe nu este singura modalitate de a accesa privilegiul administrativ prin directorul \Windows. Cel puțin unul dintre DLL-urile pentru care permisiunile implicite permit modificarea de către Power User, Schedsvc.dll, rulează ca un serviciu Windows în contul de sistem Local. Schedsvc.dll este DLL care implementează serviciul Windows Task Scheduler. Windows poate funcționa cu succes fără serviciu, astfel încât utilizatorii Power să poată înlocui DLL-ul cu un DLL arbitrar, cum ar fi unul care își adaugă pur și simplu contul la grupul administratorilor locali. Desigur, WFP protejează și acest fișier, astfel încât înlocuirea acestuia necesită utilizarea tehnicii WFP-bypass pe care am descris-o.

am identificat deja mai mulți vectori de altitudine, dar mi-am continuat investigația uitându-mă la accesul utilizatorilor de putere la directorul \Program Files unde am găsit permisiuni implicite similare cu cele din directorul \Windows. Utilizatorii Power pot crea subdirectoare sub \Program Files, dar nu pot modifica majoritatea componentelor Windows preinstalate. Din nou, excepțiile, cum ar fi Windows Messenger (\Program Files\Messenger\Msmgs.exe) și Windows Media Player (\Program Files\Windows Media Player\Wmplayer.exe) rulați interactiv.
asta nu înseamnă că \Program Files nu are găuri potențiale. Când am examinat cea mai recentă ieșire, am văzut că utilizatorii de energie pot modifica orice fișier sau director creat în \Program Files ulterior celor create în timpul instalării Windows de bază. Pe sistemul meu de testare \Program Files \ VMware \ VMware Tools \ Vmwareservice.exe, fișierul imagine pentru serviciul VMware Windows care rulează în contul de sistem Local, a fost un astfel de fișier. Un alt exemplu oarecum ironic este Microsoft Windows Defender Beta 2, care își instalează serviciul executabil în \Program Files\Windows Defender cu setări de securitate implicite. Înlocuirea acestor fișiere imagine de serviciu este o cale rapidă către privilegiul de administrator și este chiar mai ușoară decât înlocuirea fișierelor din directorul \Windows, deoarece WFP nu se amestecă cu înlocuirile.
apoi mi –am îndreptat atenția către registru executând această comandă:
accesschk-swk “power users” hklm
lista de ieșire a fost enormă, deoarece Power Users are acces la scriere la marea majoritate a cheii Software HKLM\. Prima zonă pe care am studiat-o pentru posibile creșteri a fost cheia HKLM\System, deoarece accesul la scriere la multe setări de sub ea, cum ar fi serviciul Windows și cheile de configurare a driverului din HKLM\System\CurrentControlSet\Services, ar permite subversiunea banală a contului de sistem Local. Analiza a arătat că utilizatorii de putere nu au acces la scriere la nimic semnificativ sub acea cheie.
majoritatea utilizatorilor de energie – zone inscriptibile sub cealaltă ramură majoră a HKLM, Software, legate de Internet Explorer, Explorer și asociațiile sale de fișiere și configurația de gestionare a energiei. Power Users are, de asemenea, acces de scriere la HKLM\Software\Microsoft\Windows\CurrentVersion\Run, permițându-le să configureze executabile arbitrare pentru a rula ori de câte ori cineva se conectează interactiv, dar exploatarea acestui lucru necesită un utilizator cu privilegiu administrativ să se conecteze la sistem interactiv (ceea ce, în funcție de sistem, s-ar putea să nu se întâmple niciodată sau să se întâmple rar). Și la fel ca în directorul \Program Files, Power Users are acces implicit la scriere la subcheile non-Windows ale HKLM\Software, ceea ce înseamnă că aplicațiile terțe care configurează căile de cod executabile în cheile de Registry la nivel de sistem ar putea deschide găuri de securitate. VMWare, singura aplicație instalată pe sistem, nu a făcut-o.

zona rămasă de explorare a fost Serviciile Windows. Singurele permisiuni de serviciu pe care AccessChk le consideră a fi accesări de scriere sunt SERVICE_CHANGE_CONFIG și WRITE_DAC. Un utilizator cu SERVICE_CHANGE_CONFIG poate configura un executabil arbitrar pentru a lansa atunci când începe un serviciu și dat WRITE_DAC ei pot modifica permisiunile pe un serviciu pentru a se acorda acces SERVICE_CHANGE_CONFIG. AccessChk a dezvăluit următoarele pe sistemul meu de stoc Windows XP SP2:

apoi am rulat PsService pentru a vedea contul în care se execută serviciul DcomLaunch:

astfel, membrii grupului Power Users pot schimba pur și simplu calea imaginii DComLauncher pentru a indica propria imagine, a reporni sistemul și a se bucura de privilegii administrative.
pot exista și alte servicii care introduc exploatări în securitatea lor. Seturile implicite de permisiuni Windows pentru serviciile create de aplicații terțe nu permit accesul utilizatorilor la scriere, dar unele aplicații terțe pot configura permisiuni personalizate pentru a le permite să facă acest lucru. De fapt, pe producția mea pe 64 de biți de instalare Windows XP AccessChk dezvăluie o gaură pe care nu numai utilizatorii de putere pot folosi pentru a se ridica, dar că utilizatorii limitate pot la fel de bine:

am terminat acum faza majoră a investigației mele și tocmai am confirmat ceea ce toată lumea a spus: un membru hotărât al Grupului Power Users se poate face destul de ușor administrator complet folosind exploatări în sistemul de operare și cele create de aplicații terțe.
ultimul meu pas a fost să văd cum a evoluat abordarea Microsoft față de contul Power Users de-a lungul timpului. Acest articol din Baza de cunoștințe Microsoft din 1999 documentează faimoasa vulnerabilitate de elevație a economizorului de ecran care exista pe Windows NT 4, dar Microsoft a închis acea gaură înainte de lansarea Windows 2000. Articolul KB arată, de asemenea, că Microsoft aparent nu știa de alte vulnerabilități care probabil existau. Windows 2000 SP4 include, de asemenea, găuri, dar este de fapt puțin mai sigur decât configurația implicită Windows XP SP2: utilizatorii de putere nu au acces la scriere la Ntoskrnl.exe sau fișierul de imagine Task Scheduler, dar în loc de acces la scriere la serviciul DComLauncher pot submina serviciul WMI, care rulează și în contul de sistem Local.
Windows XP SP1 a adăugat mai multe puncte slabe ale utilizatorilor de putere, inclusiv accesul la scriere la fișierele de sistem critice precum Svchost.exe, procesul de găzduire a serviciilor Windows și servicii suplimentare, WMI și SSDPSRV, cu permisiuni exploatabile. Mai multe servicii au permis chiar utilizatorilor limitați să se ridice așa cum este descris în acest articol Microsoft KB din luna martie a acestui an.
cel mai nou sistem de operare Microsoft, Windows Vista, închide toate vulnerabilitățile pe care le-am descris prin sterilizarea utilizatorilor de energie, astfel încât să se comporte identic cu utilizatorii limitați. Microsoft a închis astfel ușa utilizatorilor de putere pentru a forța personalul IT să-și securizeze sistemele prin mutarea utilizatorilor în conturi de utilizatori limitate sau în conturi administrative în care trebuie să recunoască controlul utilizatorului final asupra sistemelor lor.
concluzia este că, deși Microsoft ar putea remedia vulnerabilitățile pe care le-am găsit în ancheta mea, acestea nu pot împiedica aplicațiile terțe să introducă altele noi, păstrând în același timp capacitatea utilizatorilor de putere de a instala aplicații și controale ActiveX. Lecția este că, în calitate de administrator IT, nu ar trebui să vă păcăliți să credeți că grupul Power Users este un compromis sigur pe calea de a rula ca utilizator limitat.

inițial de Mark Russinovich pe 5/1/2006 11:01: 00 AM
migrat de la original Sysinternals.com/Blog