Creșterea privilegiilor utilizatorului în Windows. Modalități importante de a crește drepturile utilizatorului la administrator în Windows Necesită creșterea drepturilor de acces

Hmm, diferența dintre unul și celălalt este doar în modul în care sunt setați parametrii de compatibilitate, în primul caz - manual, în al doilea - același lucru, doar prin vrăjitor. Dar mulțumesc oricum pentru răspunsul detaliat))

Mulțumesc, știu)))))))))))))))))))

Ok, sunt admin (poate puțin analfabet, dar sper să ajung din urmă...) Cum îmi este permis să rulez această aplicație (și numai aceasta)? În același timp, pentru a nu alerga constant la mașina lui (pentru a introduce parola de administrator local, pe care nu ar trebui să o cunoască) atunci când are nevoie să lanseze această aplicație.

Vă sunt foarte recunoscător pentru că mi-ați amintit o parte din prelegerea pe tema „Sisteme de operare”. Permiteți-mi să vă dau un alt exemplu, acum clasic:

Uneori, un utilizator trebuie să-și schimbe parola de conectare. Utilizatorul însuși nu are drepturi de acces la baza de date de parole. Cu toate acestea, programul pe care îl folosește pentru a schimba parola rulează cu drepturi ridicate. Ceea ce îi permite să-și schimbe în cele din urmă parola.

Deci, cazul meu este similar. Cum îi „spun” sistemului că un program ar trebui să ruleze cu drepturi ridicate? În acest caz, va fi lansat de un utilizator din grupul „utilizator”/„utilizator cu putere”.

Acest lucru se poate face de fapt prin rularea programului ca o „sarcină programată” ca un alt utilizator. Totul ar fi bine - chiar pornește, dar interfața grafică (ferestrele programului) nu este afișată pe desktopul utilizatorului...

Contradicție conceptuală??? Am dat un exemplu mai sus - sarcina este destul de standard pentru orice sistem de operare. Pur și simplu nu vreau să o rezolv cu instrumente terțe (nu sunt incluse în Windows Vista). Am dezactivat deja UAC - în orice caz, aplicația funcționează corect doar cu drepturi de administrator, așa este - specific.... Nu pare posibilă includerea acestui utilizator în grupul local „Administratori” din motive de securitate .

Referitor la scenariu – pt rune există un steag care vă permite să vă amintiți parola, dar în acest caz utilizatorul va putea rula orice program cu drepturi de administrator.

Aceasta înseamnă că nu vreau să lansez software al cărui cod sursă nu l-a văzut nimeni, nu se știe nimic despre furnizor și al cărui site web este „în mâinile oamenilor”. Dar utilizatorii - eh, dacă ar fi fost suficient, atunci discuția asta nu ar fi apărut pe forum..... =(

Aș vrea să cred că nu totul este atât de rău.

Creșterea privilegiilor este poate unul dintre punctele cheie de care depinde scenariul pentru continuarea pentesting sau atac. De foarte multe ori, totul se termină în această etapă dacă nu este posibil să vă „extindeți puterile”. Prin urmare, astăzi vom vorbi puțin despre modalitățile care permit unui utilizator să-și mărească privilegiile nu numai la administrator, ci și la sistem.

Introducere

Escalarea privilegiilor este ușor diferită în Windows și Linux. Deși ambele sisteme de operare poartă numărul obișnuit de vulnerabilități, cercetătorii observă că un server Windows complet corelat este mult mai comun decât un server Linux care a fost actualizat la cea mai recentă stare. În plus, timpul de lansare pentru patch-urile Windows este adesea mai scurt, ceea ce face ca creșterea privilegiilor pe Windows să fie o sarcină destul de interesantă și ambițioasă. Ei îi vom dedica povestea noastră.

Opțiuni

Deci, ce oportunități avem de a ne ridica în lumea Windows? În primul rând, recent s-au găsit destule vulnerabilități legate de analizarea fonturilor în nucleul sistemului de operare, ceea ce face procesul de escaladare a privilegiilor destul de simplu dacă aveți un exploit adecvat la îndemână. Dacă utilizați Metasploit, atunci este suficientă o singură comandă pentru a obține un shell de sistem. Cu toate acestea, este posibil ca toate acestea să funcționeze cu succes numai dacă sistemul nu este complet corectat. Dacă toate actualizările sunt instalate pe mașină, atunci, spre deosebire de Linux, nu va fi posibil să găsiți binare SUID, iar variabilele de mediu nu sunt de obicei transmise serviciilor sau proceselor cu privilegii mai mari. Ce ne rămâne ca rezultat?

De la administrator la sistem, sau ceea ce știe toată lumea

De obicei, atunci când vă gândiți la escaladarea privilegiilor, metoda care vă vine imediat în minte este utilizarea programatorului de sarcini. În Windows, puteți adăuga o sarcină folosind două utilitare: at și schtasks. Al doilea va rula sarcina în numele utilizatorului care a adăugat sarcina, în timp ce primul va rula în numele sistemului. Un truc standard despre care probabil ați auzit și care vă permite să rulați consola cu drepturi de sistem:

La 13:01 /cmd interactiv

Al doilea lucru care îmi vine în minte este adăugarea unui serviciu care va lansa fișierul necesar / va executa comanda:

@echo off @break off rădăcină titlu Cls echo Crearea serviciului. sc create evil binpath= "cmd.exe /K start" type= own type= interact > nul 2>&1 echo Pornirea serviciului. sc start evil > nul 2>&1 echo În așteptare... ping 127.0.0.1 -n 4 > nul 2>&1 echo Se elimină serviciul. ecou. sc delete evil > nul 2>&1

A treia metodă este înlocuirea utilitarului de sistem C:\windows\system32\sethc.exe cu, de exemplu, cmd. Dacă vă deconectați după aceasta și apăsați tasta Shift de mai multe ori, va apărea o consolă cu drepturi de sistem.

În ceea ce privește metodele automate, Metasploit și getsystem-ul său vin imediat în minte. O opțiune alternativă este PsExec de la Sysinternals (psexec -i -s -d cmd.exe).

Vom merge pe alt drum

Toate aceste metode au un dezavantaj comun: sunt necesare privilegii de administrator. Aceasta înseamnă că creștem privilegiile de la un cont privilegiat. În cele mai multe cazuri, când ați primit drepturi de administrator, aveți o mulțime de opțiuni despre cum să creșteți și mai mult. Deci nu este o sarcină foarte dificilă. Astăzi vom vorbi despre metode de escaladare a privilegiilor care nu folosesc vulnerabilități 0day, presupunând că avem un sistem normal și un cont al unui utilizator obișnuit neprivilegiat.

Caută acreditări

Una dintre modalitățile fiabile și stabile de a crește privilegiile și de a obține un punct de sprijin în sistem este obținerea parolelor administratorilor sau utilizatorilor cu privilegii mai mari. Și acum este timpul să ne amintim despre instalarea automată a software-ului. Dacă gestionați un domeniu care include o flotă mare de mașini, cu siguranță nu doriți să mergeți să instalați manual software pe fiecare dintre ele. Și va dura atât de mult timp încât nu va fi suficient pentru alte sarcini. Prin urmare, sunt utilizate instalări Nesupravegheate, care generează fișiere care conțin parole de administrator în forma lor cea mai pură. Ceea ce este pur și simplu o comoară atât pentru pentesteri, cât și pentru atacatori.

Instalații nesupravegheate

În cazul unei instalări automate, fișierul Unattended.xml, care este destul de interesant pentru noi, rămâne pe client, care se află de obicei fie în %WINDIR%\Panther\Unattend\, fie în %WINDIR%\Panther\ și poate stocați parola de administrator în text clar. Pe de altă parte, pentru a obține acest fișier de pe server, nici măcar nu aveți nevoie de nicio autentificare. Trebuie doar să găsiți serverul „Servicii de implementare Windows”. Pentru a face acest lucru, puteți utiliza script-ul auxiliar/scanner/dcerpc/windows_deployment _services de la Metasploit. Deși Windows Deployment Services nu este singura modalitate de a efectua instalări automate, fișierul Unattended.xml este considerat un standard, astfel încât descoperirea acestuia poate fi considerată un succes.

GPP

Fișierele XML de preferințe de politică de grup conțin destul de des un set de acreditări criptate care pot fi folosite pentru a adăuga noi utilizatori, a crea partajări și așa mai departe. Din fericire, metoda de criptare este documentată, astfel încât puteți obține cu ușurință parolele în forma lor pură. Mai mult decât atât, echipa Metasploit a făcut deja totul pentru tine - doar folosește modulul /post/windows/gather/credentials/gpp.rb. Dacă sunteți interesat de detalii, atunci toate informațiile necesare sunt disponibile la acest link.

Drepturile utilizatorului

Foarte des, escaladarea privilegiilor este o consecință a drepturilor utilizatorului configurate incorect. De exemplu, când un utilizator de domeniu este un administrator local (sau Power User) pe gazdă. Sau atunci când utilizatorii de domeniu (sau membrii grupurilor de domenii) sunt administratori locali pe toate gazdele. În acest caz, nu va trebui să faceți nimic. Dar astfel de opțiuni nu apar foarte des.

AlwaysInstallElevated

Uneori, administratorii permit utilizatorilor obișnuiți să instaleze ei înșiși programele, de obicei prin următoarele chei de registry:

HKLM\SOFTWARE\Policies\Microsoft\Windows\Installer\AlwaysInstallElevated

HKCU\SOFTWARE\Policies\Microsoft\Window s\Installer\AlwaysInstallElevated

Ei spun sistemului că orice fișier MSI trebuie instalat cu privilegii ridicate (NT AUTHORITY\SYSTEM). În consecință, utilizând un fișier special creat, puteți efectua din nou acțiuni în numele sistemului și vă puteți actualiza privilegiile.

Metasploit include un modul special exploit/windows/local/always_install_elevated, care creează un fișier MSI cu un fișier executabil special încorporat în el, care este extras și executat de către instalatorul cu privilegii de sistem. Odată executat, fișierul MSI anulează instalarea (prin apelarea unui VBS invalid special creat) pentru a preveni înregistrarea acțiunii în sistem. În plus, dacă porniți instalarea cu comutatorul /quiet, utilizatorul nici măcar nu va vedea o eroare.

Lipsește pornirea automată

Se întâmplă adesea ca sistemul să păstreze o înregistrare a unui fișier care trebuie lansat automat, chiar și după ce fișierul în sine a căzut deja în uitare. Poate că un serviciu a fost eliminat incorect - nu există niciun fișier executabil, dar intrarea din registry rămâne și de fiecare dată când porniți sistemul încearcă să-l pornească fără succes, umplând jurnalul de evenimente cu mesaje despre eșecuri. Această situație poate fi folosită și pentru a vă extinde puterile. Primul pas este să găsiți toate astfel de înregistrări orfane. De exemplu, folosind utilitarul autorunsc de la Sysinternals.

Autorunsc.exe -a | findstr /n /R „Fișier\ nu\ găsit”

După care, după cum ați ghicit, tot ce rămâne este să vă strecurați cumva candidatul în locul dosarului lipsă.

Magia citatelor

Da, da, ghilimele nu numai că pot juca o glumă crudă în interogările SQL, permițând injectarea, dar și pot ajuta la creșterea privilegiilor. Problema este destul de veche și este cunoscută încă din timpurile NT. Ideea este că căile către fișierele executabile ale unor servicii nu sunt înconjurate de ghilimele (de exemplu, ImagePath=C:\Program Files\Common Files\Network Associates\McShield\McShield.exe) și există caractere de spațiu în cale. În acest caz, dacă atacatorul creează un fișier care va adăuga noi administratori la sistem sau va efectua alte acțiuni și îl numește C:\Program Files\common.exe, atunci când serviciul este pornit, va fi obișnuit. exe care va fi lansat, iar partea rămasă a căii va fi luată ca argument(e). Este clar că un utilizator neprivilegiat nu va putea pune nimic în Program Files, dar fișierul executabil al serviciului poate fi localizat într-un alt director, adică utilizatorul va avea posibilitatea să se strecoare în propriul fișier.

Pentru a utiliza această tehnică, trebuie să găsiți un serviciu vulnerabil (care nu va folosi ghilimele în calea către binarul său). Acest lucru se face după cum urmează:

Serviciul Wmic obține numele, numele afișat, calea, modul start |findstr /i "auto" |findstr /i /v "c: \windows\\" |findstr /i /v """

Adevărat, pe XP, acest lucru va necesita privilegii de administrator, deci este mai bine să utilizați următoarea metodă acolo: obțineți o listă de servicii - sc query , apoi uitați-vă la informații pentru fiecare serviciu - sc qc servicename .

Totul conform planului

Un alt mecanism care poate ajuta la creșterea drepturilor și care este de obicei uitat este planificatorul de sarcini. Utilitarul schtasks vă permite să atribuiți sarcini unor evenimente specifice. Cele mai interesante pentru noi sunt ONIDLE, ONLOGON și ONSTART. După cum sugerează numele, ONIDLE va fi executat de fiecare dată când computerul este inactiv, ONLOGON și ONSTART - când utilizatorul se autentifică și, respectiv, când sistemul pornește. Astfel, fiecăruia dintre evenimente poate fi atribuită o sarcină separată. De exemplu, când sistemul pornește, copiați un binar/keylogger/... undeva rău intenționat și rulați-l. Când utilizatorii se conectează, rulați un dumper pentru carduri de credit. Pe scurt, totul este limitat doar de imaginația ta și de sarcina la îndemână.

Trucuri cu permisiuni

Permisiunile pentru fișiere sunt de obicei prima apărare care ne împiedică să ne creștem privilegiile. Ar fi tentant să suprascrieți pur și simplu un fișier de sistem (de exemplu, același sethc.exe menționat chiar la începutul articolului) și să obțineți imediat privilegii de sistem. Dar toate acestea sunt doar vise; de ​​fapt, avem doar permisiunea de a o citi, ceea ce nu ne dă absolut nimic. Cu toate acestea, nu ar trebui să vă atârnați nasul, deoarece, cu permise, nici totul nu este atât de neted - aici, ca și în altă parte, există capcane, a căror cunoaștere vă permite să faceți imposibilul posibil.

Unul dintre directoarele de sistem protejate de acest mecanism este deosebit de interesant din punct de vedere al escaladării privilegiilor - Program Files. Utilizatorilor neprivilegiati li se interzice accesul acolo. Cu toate acestea, uneori se întâmplă ca în timpul procesului de instalare, instalatorii să stabilească incorect permisiunile pentru fișiere, ceea ce duce la acordarea tuturor utilizatorilor de acces deplin la fișierele executabile. Ce rezultă din asta - ai ghicit deja.

O altă limitare este că un muritor obișnuit nu are voie să scrie în rădăcina discului de sistem. Totuși, de exemplu, pe XP, la crearea unui director nou la rădăcina discului, grupul BUILTIN\Users primește permisiunile FILE_APPEND_DATA și FILE_WRITE_DATA (chiar dacă proprietarul folderului este un administrator):

BUILTIN\Utilizatori:(OI)(CI)R BUILTIN\Users:(CI)(acces special:) FILE_APPEND_DATA BUILTIN\Users:(CI)(acces special:) FILE_WRITE_DATA

Pe cei „șapte” se întâmplă aproape același lucru, doar grupul UTENTIFICĂȚI AUTENTIFICAȚI primește permisiunea. Cum poate acest comportament să devină o problemă? Doar că unele aplicații se instalează în afara directoarelor protejate, ceea ce facilitează înlocuirea fișierelor lor executabile. De exemplu, un astfel de incident s-a întâmplat cu Metasploit Framework în cazul instalării sale cu mai mulți utilizatori. Această eroare a fost remediată în versiunea 3.5.2, iar utilitarul a fost mutat în Program Files.

Cum să cauți astfel de directoare/fișiere

Găsirea unui director cu permisiuni incorecte este deja jumătate din luptă. Cu toate acestea, mai întâi trebuie să-l găsiți. Pentru a face acest lucru, puteți utiliza următoarele două instrumente: AccessChk și Cacls/ICacls. Pentru a găsi directoare „slabe” folosind AccessChk, veți avea nevoie de aceste comenzi:

Accesschk.exe -uwdqs utilizatori c:\ accesschk.exe -uwdqs „Utilizatori autentificați” c:\

Pentru a căuta fișiere cu permisiuni „slabe”, utilizați următoarele:

Accesschk.exe -uwqs utilizatori c:\*.* accesschk.exe -uwqs „Utilizatori autentificați” c:\*.*

Același lucru se poate face folosind Cacls/ICacls:

Cacls „c:\Program Files” /T | findstr Utilizatori

Trucuri cu serviciile

O altă opțiune pentru a trece în sus în sistem este să profitați de configurările greșite și erorile de service. După cum arată practica, nu numai fișierele și folderele, ci și serviciile care rulează în sistem pot avea permisiuni incorecte. Pentru a le detecta, puteți folosi utilitarul AccessChk de la binecunoscutul Mark Russinovich:

Accesschk.exe –uwcqv *

Va fi cel mai încurajator să vedeți permisiunea SERVICE_ALL_ACCESS pentru utilizatorii autentificați sau utilizatorii cu putere. Dar următoarele pot fi considerate de asemenea un mare succes:

• SERVICE_CHANGE_CONFIG - putem schimba fișierul executabil al serviciului;
• WRITE_DAC - permisiunile pot fi modificate, ceea ce duce la obținerea permisiunii SERVICE_CHANGE_CONFIG;
• WRITE_OWNER - puteți deveni proprietar și puteți schimba permisiunile;
• GENERIC_WRITE - moștenește permisiunile SERVICE_CHANGE_CONFIG ;
• GENERIC_ALL - moștenește permisiunile SERVICE_CHANGE_CONFIG.

Dacă descoperiți că una (sau mai multe) dintre aceste permisiuni sunt setate pentru utilizatori neprivilegiați, șansele dvs. de a vă escalada privilegiile cresc dramatic.

Cum să măresc?

Să presupunem că ați găsit un serviciu potrivit, este timpul să lucrați la el. Utilitarul de consolă sc va ajuta în acest sens. În primul rând, obținem informații complete despre serviciul care ne interesează, să presupunem că este upnphost:

Sc qc upnphost

Să o configuram folosind același utilitar:

Sc config vulnsrv binpath= "utilizator net john salut /adăugați && net localgroup Administratori john /add" tip= interacționați sc config upnphost obj= „.\LocalSystem” parola=“”

După cum puteți vedea, data viitoare când serviciul pornește, în loc de fișierul său executabil, va fi executată comanda net user john hello /add && net localgroup Administrators john /add, adăugând un nou utilizator john cu parola hello la sistem. Tot ce rămâne este să reporniți manual serviciul:

Net stop upnphost net start upnphost

Asta e toată magia.

Care este rezultatul?

Cândva, am citit un articol de revistă care sublinia tehnici de bază pentru escaladarea privilegiilor în Windows. Nu i-am acordat prea multă importanță atunci, dar teoria mi-a rămas în cap și m-a ajutat o dată foarte mult. Așadar, sper că vei găsi ceva nou pentru tine în acest articol care te va ajuta într-o zi să depășești o altă barieră.

UAC(User Account Control) este o tehnologie de control al contului care a apărut pentru prima dată în Windows Vistași mai în vârstă. Această tehnologie împiedică programele să efectueze acțiuni care necesită drepturi de administrator. Atunci când programul efectuează astfel de acțiuni, activitatea sa este suspendată și utilizatorului i se prezintă o fereastră de solicitare pe desktopul protejat (astfel încât este imposibil să apăsați programatic butonul OK). De exemplu, dacă programul dvs. trebuie să facă modificări la cheia de registry HKEY_LOCAL_MACHINE, atunci va avea nevoie de drepturi de administrator.
Pentru a rezolva această problemă, puteți utiliza implementarea unui fișier manifest în proiect, pe care sistemul de operare îl va citi și va determina automat parametrii necesari pentru lansare.
Să luăm în considerare introducerea unui fișier manifest în aplicație " Windows Form" Pentru a face acest lucru, deschideți Visual Studio (versiunea 2012 este folosită în acest exemplu) și creați un proiect " Windows Form" Deschis " Explorator de soluții(Solution Explorer), care oferă o vizualizare organizată a proiectelor și a fișierelor acestora, accesați meniul Vedere» - « Explorator de soluții" Faceți clic dreapta pe " Explorator de soluții" după numele proiectului și selectați din meniul contextual, " Adăuga» - « Creați element...».

• ca Invocator- cererea începe cu drepturile procesului părinte. Aceasta înseamnă că dacă rulați un program dintr-o aplicație care rulează deja cu drepturi de administrator, acesta va avea automat aceleași drepturi. Acest mod este recomandat de Microsoft în majoritatea cazurilor. Acestea. Acestea sunt acele programe care nu necesită drepturi de administrator;
• cel mai mare disponibil— aplicația este lansată cu drepturi mai mari decât are utilizatorul actual. Regedit.exe, Mmc.exe sunt lansate cu aceste drepturi;
• cereAdministrator- sunt solicitate drepturi complete de administrator. Acestea. necesar pentru aplicațiile care nu pot rula fără drepturi de administrator.

Instalarea aplicațiilor" Faceți clic O dată" este posibil numai cu valoarea "asInvoker". Orice altă valoare nu va permite instalarea.

Multe programe necesită creșterea drepturilor la pornire (o pictogramă de scut lângă pictogramă), dar de fapt nu necesită drepturi de administrator pentru funcționarea lor normală (de exemplu, ați acordat manual drepturile necesare utilizatorilor pentru directorul programului din ProgramFiles și ramurile de registry care sunt utilizate de program). În consecință, atunci când rulați un astfel de program ca utilizator simplu, dacă Controlul contului utilizatorului este activat pe computer, va apărea o solicitare UAC și utilizatorului i se va cere să introducă parola de administrator. Pentru a ocoli acest mecanism, mulți pur și simplu dezactivează UAC sau acordă utilizatorului drepturi de administrator pe computer, adăugându-l la grupul de administratori locali. Desigur, ambele metode sunt nesigure.

De ce o aplicație obișnuită ar putea avea nevoie de drepturi de administrator

Programul poate avea nevoie de drepturi de administrator pentru a modifica anumite fișiere (jurnale, configurații etc.) în propriul folder în C:\Program Files (x86)\SomeApp). În mod implicit, utilizatorii nu au drepturi de a edita acest director; prin urmare, pentru funcționarea normală a unui astfel de program, sunt necesare drepturi de administrator. Pentru a rezolva această problemă, trebuie să atribuiți manual drepturi de modificare/scriere utilizatorului (sau grupului de utilizatori) folderului programului ca administrator la nivel NTFS.

Notă. De fapt, practica de stocare a datelor aplicației modificate în propriul director sub C:\Program Files este incorectă. Este mai corect să stocați datele aplicației în profilul utilizatorului. Dar aceasta este o chestiune de lene și incompetență a dezvoltatorilor.

Rularea unui program care necesită drepturi de administrator de la un utilizator standard

Am descris anterior cum puteți utiliza parametrul RunAsInvoker. Cu toate acestea, această metodă nu este suficient de flexibilă. De asemenea, îl puteți utiliza cu salvarea parolei de administrator /SAVECRED (de asemenea, nesigur). Să luăm în considerare o modalitate mai simplă de a forța lansarea oricărui program fără drepturi de administrator (și fără a introduce parola de administrator) cu UAC activat (4.3 sau nivelul 2).

De exemplu, să luăm utilitarul de editare a registrului - regedit.exe(se află în directorul C:\windows\system32). Când rulați regedit.exe, apare o fereastră UAC și, cu excepția cazului în care confirmați elevarea privilegiilor, Editorul de registry nu pornește.

Să creăm un fișier pe desktop run-as-non-admin.bat cu următorul text:

cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" %1"

Acum, pentru a forța aplicația să ruleze fără drepturi de administrator și pentru a suprima promptul UAC, pur și simplu trageți fișierul exe dorit pe acest fișier bat de pe desktop.

După aceasta, Editorul de registry ar trebui să pornească fără să apară promptul UAC. Deschideți managerul de procese și adăugați o coloană Elevat(Cu un nivel de permisiune mai mare), veți vedea că sistemul are un proces regedit.exe cu o stare neelevată (care rulează cu drepturi de utilizator).

Încercați să editați orice parametru din ramura HKLM. După cum puteți vedea, accesul pentru editarea registrului din această ramură este interzis (acest utilizator nu are drepturi de a scrie în ramurile registrului de sistem). Dar puteți adăuga și edita chei în propria ramură de registru a utilizatorului - HKCU.

În același mod, puteți lansa o anumită aplicație printr-un fișier bat, trebuie doar să specificați calea către fișierul executabil.

run-app-as-non-admin.bat

Setați ApplicationPath="C:\Program Files\MyApp\testapp.exe"
cmd /min /C "set __COMPAT_LAYER=RUNASINVOKER && start "" %ApplicationPath%"

De asemenea, puteți adăuga un meniu contextual, care adaugă posibilitatea ca toate aplicațiile să se lanseze fără elevație. Pentru a face acest lucru, creați următorul fișier reg și importați-l în registry.

Windows Registry Editor versiunea 5.00

@="cmd /min /C \"set __COMPAT_LAYER=RUNASINVOKER && start \"\" \"%1\"\""

După aceasta, pentru a lansa orice aplicație fără drepturi de administrator, trebuie doar să selectați elementul „” din meniul contextual.

Variabila de mediu __COMPAT_LAYER și parametrul RunAsInvoker

Variabila de mediu __COMPAT_LAYER vă permite să setați diferite niveluri de compatibilitate pentru aplicații (tab Compatibilitateîn proprietățile fișierului exe). Folosind această variabilă, puteți specifica setările de compatibilitate cu care ar trebui să ruleze programul. De exemplu, pentru a rula aplicația în modul de compatibilitate Windows 7 și rezoluție 640x480, setați:

setați __COMPAT_LAYER=Win7RTM 640x480

Dintre opțiunile variabilei __COMPAT_LAYER care ne interesează, evidențiem următorii parametri:

• RunAsInvoker- lansarea unei aplicații cu privilegiile procesului părinte fără o solicitare UAC.
• RunAsHighest- lansarea aplicației cu drepturi maxime disponibile utilizatorului (cererea UAC apare dacă utilizatorul are drepturi de administrator).
• RunAsAdmin- lansați aplicația cu drepturi de administrator (apare întotdeauna promptul AUC).

Acestea. Parametrul RunAsInvoker nu oferă drepturi de administrator, ci doar blochează apariția ferestrei UAC.

O parte a articolului a descris în detaliu principiul de funcționare a Controlului contului utilizatorului. În această parte vom vorbi despre configurarea UAC în cazul în care computerul dumneavoastră funcționează independent, adică nu face parte dintr-un domeniu Active Directory. Pentru a configura Controlul contului utilizatorului, utilizați caracteristica Politică de securitate locală, care poate fi găsită în Editorul de obiecte Politica de grup local.

Există 10 setări ale politicii de grup care sunt responsabile pentru configurarea Controlului contului utilizatorului. Pentru a modifica setările politicii, trebuie să deschideți snap-in-ul „Editor de politici de grup local” nodul Configurație computer\Configurație Windows\Setări de securitate\Politici locale\Setări de securitate. Acest articol vă va arăta, de asemenea, cum să configurați fiecare setare de politică folosind registrul de sistem. Următorul tabel arată valorile implicite pentru fiecare setare de politică.

Setări implicite ale politicii de grup Control cont utilizator:

Setările politicii de grup care se referă la Controlul contului utilizatorului (UAC) sunt discutate în detaliu mai jos:

Toți administratorii lucrează în modul de aprobare a administratorului

Această setare de politică determină caracteristicile tuturor politicilor de control cont utilizator pentru computer. Această setare determină dacă conturile de administrator vor rula în „modul aprobat de administrator”, adică dacă vor fi afișate dialoguri care solicită creșterea privilegiilor. Dezactivarea acestei setări, aproximativ vorbind, dezactivează complet funcționalitatea de control al contului de utilizator. Dacă modificați această setare de politică, trebuie să reporniți computerul. Valoarea implicită este activată.

Valori posibile ale parametrilor:

• Inclus. Modul de aprobare a administratorului este activat pentru a permite contul de administrator încorporat și toți ceilalți utilizatori care sunt membri ai grupului „Administratori”, lucrează în modul de aprobare a administratorului.
• Dezactivat. Modul de aprobare a administratorului și toate setările de politică asociate Control cont utilizator vor fi dezactivate.

;Dezactivați „EnableLUA”=dword:00000000

Detectați instalarea aplicației și solicitați elevația

Această setare definește caracteristicile de detectare a instalării aplicației pentru un computer, verificând dacă programele utilizate pentru implementarea aplicațiilor sunt sau nu semnate. În mod implicit, dacă un utilizator este membru al unui grup de lucru, acesta este activat.

Valori posibile ale parametrilor:

• Activat (implicit pentru acasă). Dacă programul de instalare a aplicației detectează necesitatea unor privilegii ridicate, utilizatorului i se solicită să introducă numele de utilizator și parola pentru contul de administrator. Dacă utilizatorul introduce acreditările corecte, operațiunea continuă cu drepturile corespunzătoare. Tipul de solicitare depinde de grupul din care face parte utilizatorul.
• Dezactivat (prestabilit al organizației). Când selectați această setare, detectarea aplicației de instalare nu vă solicită elevația. De obicei, această setare este utilizată în organizațiile ale căror computere și utilizatori fac parte dintr-un domeniu și utilizează tehnologii de instalare delegate (Group Policy Software Install - GPSI) pentru a implementa aplicații. În consecință, nu este nevoie să detectați instalatorul.

Setările actuale ale politicii utilizând registrul:

;Dezactivați „EnableInstallerDetection”=dword:00000000

Comutați la desktopul securizat atunci când vi se solicită elevația

Această setare de politică determină dacă solicitările de elevație sunt afișate pe desktopul interactiv al utilizatorului sau pe desktopul securizat atunci când este inițiată o solicitare UAC. Valoarea implicită este activată. Dacă modificați această setare de politică, trebuie să reporniți computerul.

Valori posibile ale parametrilor:

• Inclus. Toate solicitările de ridicare sunt afișate pe desktopul securizat, indiferent de setările politicii de comportament prompt pentru administratori și utilizatori standard.
• Dezactivat. Toate cererile de ridicare a drepturilor sunt afișate pe desktopul interactiv al utilizatorului.

Setările actuale ale politicii utilizând registrul:

;Dezactivați „PromptOnSecureDesktop”=dword:00000000

Comportamentul promptului de ridicare pentru administratori în modul de aprobare de administrator

Setarea curentă vă permite să determinați acțiunile unui utilizator care este membru al grupului „Administratori” atunci când se efectuează o operațiune care necesită ridicarea drepturilor. Valoarea implicită este setată „Solicitați consimțământul pentru binare terțe (non-Windows)”.

Valori posibile ale parametrilor:

• Promovare fara solicitare. Permite conturilor privilegiate să efectueze o operațiune care necesită ridicare fără a necesita consimțământ sau introducerea acreditărilor. Este recomandabil să utilizați această opțiune numai în medii cu restricții maxime de utilizare. Când selectați această setare, permisiunile utilizatorului vor fi identice cu contul de administrator încorporat.
• . Pentru orice operațiune care necesită ridicare, desktopul securizat vă va solicita să introduceți numele de utilizator root și parola. Dacă sunt introduse acreditările corecte, operațiunea va continua cu drepturile de utilizator maxime disponibile.
• Solicitați consimțământul pe desktop securizat. Pentru orice operațiune care necesită ridicare, desktopul securizat vă va solicita să selectați: "Permite" sau "Interzice". La selectarea opțiunii "Permite", operațiunea va continua cu drepturile de utilizator maxime disponibile.
• Cerere de acreditări. Pentru orice operațiune care necesită elevație, vi se va solicita să introduceți numele de utilizator și parola pentru contul de administrator. Dacă introduceți acreditările corecte, operațiunea va continua cu privilegii ridicate.
• Cerere de acord. La selectarea acestei opțiuni, pentru orice operațiune care necesită creșterea drepturilor, utilizatorului i se va solicita să selecteze un buton: "Permite" sau "Interzice". Când apăsați butonul "Permite"
• Solicitați consimțământul pentru binare terțe (non-Windows). Când selectați această opțiune, pe desktopul securizat va fi afișată o solicitare de selecție: "Permite" sau "Interzice", în cazul în care operațiunea pentru o aplicație terță parte (non-Microsoft) necesită creșterea drepturilor. La un clic pe un buton "Permite", operațiunea va continua cu privilegiile maxime disponibile ale utilizatorului.

Setările actuale ale politicii utilizând registrul:

;Promovare fără solicitarea „ConsentPromptBehaviorAdmin”=dword:00000000 ;Solicitare acreditări pe desktopul securizat; „ConsentPromptBehaviorAdmin”=dword:00000001 ;Solicitarea consimțământului pe desktop securizat; „ConsentPromptBehaviorAdmin”=0Prompt:0200002000 administrator" =dword:00000003 ;Solicitare de consimțământ;"ConsentPromptBehaviorAdmin"=dword:00000004 ;Solicitare de consimțământ pentru date binare non-Windows ;"ConsentPromptBehaviorAdmin"=dword:00000005

Comportament prompt la altitudine pentru utilizatorii standard

Această setare de politică determină acțiunile întreprinse atunci când un utilizator standard interacționează cu aplicații care necesită privilegii ridicate. Valoare implicită - „Solicitați acreditările pe desktop securizat”.

Valori posibile ale parametrilor:

• Cerere de acreditări. Folosind această opțiune, utilizatorului standard i se solicită să selecteze un cont de administrator și să introducă o parolă pentru a efectua acțiunile ulterioare. Operația va continua doar dacă acreditările sunt introduse corect.
• Respinge automat solicitările de altitudine. Dacă selectați această opțiune, unui utilizator standard i se va afișa un mesaj de eroare cu acces refuzat atunci când efectuează o operațiune care necesită privilegii ridicate. Organizațiile ale căror computere desktop sunt folosite de utilizatori obișnuiți pot selecta această setare de politică pentru a reduce numărul de apeluri de asistență.
• Solicitați acreditările pe desktop securizat. Prin selectarea acestei opțiuni, utilizatorului standard i se solicită să selecteze un cont de administrator și să introducă o parolă pentru a efectua acțiuni ulterioare numai pe desktopul securizat. Operația va continua doar dacă acreditările sunt introduse corect.

Setările actuale ale politicii utilizând registrul:

;Respinge automat cererile de elevare „ConsentPromptBehaviorUser”=dword:00000000 ;Solicitare acreditări pe desktopul securizat „ConsentPromptBehaviorUser”=dword:00000001 ; Solicitare acreditări „ConsentPromptBehaviorUser”=dword:00000003

Creșteți drepturile pentru aplicațiile UIAccess numai atunci când sunt instalate în locații securizate

Setarea curentă de politică vă permite să controlați permisiunea de locație a aplicațiilor care solicită execuția la nivelul de integritate definit de atributul User Interface of Access (UIAccess) într-o locație securizată a sistemului de fișiere. În mod implicit, această setare este activată, iar pentru aplicațiile accesibile, atributul UIAccess din manifest este setat la True pentru a controla fereastra de solicitare de escaladare a privilegiilor. Dacă aplicațiile sunt setate la false, adică dacă atributul este omis sau nu există niciun manifest pentru asamblare, aplicația nu va putea accesa interfața de utilizator protejată. Doar următoarele foldere sunt considerate sigure:

…\Program Files\, inclusiv subfolderele

…\Windows\system32\

...\Program Files (x86)\, inclusiv subfolderele pentru versiunile pe 64 de biți de Windows

Valori posibile ale parametrilor:

• Inclus. Aplicația va rula doar cu nivelul de integritate UIAccess dacă se află într-un folder securizat de pe sistemul de fișiere.
• Dezactivat. Aplicația va rula cu nivelul de integritate UIAccess chiar dacă nu se află într-un folder de sistem de fișiere securizat.

Setările actuale ale politicii utilizând registrul:

;Dezactivați „EnableSecureUIAPaths”=dword:00000000

Ridicarea privilegiilor numai pentru executabilele semnate și verificate

Această setare de politică de grup de control cont de utilizator vă permite să determinați dacă să autentificați semnăturile aplicațiilor interactive Public Key Infrastructure (PKI) care necesită creșterea privilegiilor. Scopul PKI este de a determina politica de emitere a certificatelor digitale, emiterea și revocarea acestora, precum și stocarea informațiilor necesare pentru verificarea ulterioară a corectitudinii certificatelor. Aplicațiile care acceptă PKI includ: e-mail securizat, protocoale de plată, cecuri electronice, schimb electronic de informații, securitatea datelor prin rețele IP, formulare electronice și documente semnate electronic. Dacă această verificare este activată, programele inițiază verificarea căii certificatului. Valoarea implicită a acestei setări este Dezactivată.

Valori posibile ale parametrilor:

• Inclus. O verificare a căii pentru certificatele PKI este forțată înainte ca fișierul să fie executat. Această setare este utilizată în principal în organizațiile cu domeniu, dacă administratorul a plasat certificate PKI în magazinul editorilor de încredere.
• Dezactivat. Când această opțiune este setată, User Account Control nu inițiază o verificare a lanțului de verificare a certificatului PKI înainte de a permite execuția unui anumit fișier executabil.

Setările actuale ale politicii utilizând registrul:

;Dezactivați „ValidateAdminCodeSignatures”=dword:00000000

Dacă scrierea într-un fișier sau un registru eșuează, virtualizați la locația utilizatorului

Această setare controlează dacă eșecurile de scriere a aplicației sunt redirecționate către anumite locații din registry și sistemul de fișiere. Când această setare este activată, pentru aplicațiile vechi care încearcă să citească sau să scrie informații folosind zone protejate ale sistemului, Controlul contului utilizator virtualizează registrul și sistemul de fișiere. Datorită acestei setări, UAC vă permite să reduceți pericolul aplicațiilor vechi care rulează ca administrator și să scrieți date în folderul %ProgramFiles%, %Windir% în timpul execuției; %Windir%\system32 sau la cheia de registry de sistem HKLM\Software\. Valoarea implicită este activată.

Valori posibile ale parametrilor:

• Inclus. Eșecurile de scriere a aplicației sunt redirecționate în timpul rulării către locații definite de utilizator din sistemul de fișiere și registry.
• Dezactivat. Aplicațiile care scriu date în locații securizate vor eșua și nu se vor executa.

Setările actuale ale politicii utilizând registrul:

;Dezactivați „EnableVirtualization”=dword:00000000

Permiteți aplicațiilor UIAccess să solicite elevație fără a utiliza desktopul securizat

Această nouă setare de politică, introdusă în sistemele de operare Windows 7 și Windows Server 2008 R2, controlează dacă aplicațiile UIAccess pot dezactiva automat desktopul securizat pentru solicitările de elevație utilizate de un utilizator standard. Valoarea implicită este dezactivată.

Valori posibile ale parametrilor:

• Inclus. Când selectați această setare, programele UIAccess, inclusiv Windows Remote Assistance, dezactivează automat Secure Desktop pentru solicitările de elevație. Dacă setarea de politică „Control cont utilizator: comutați la desktop securizat atunci când vi se solicită elevație” este activată, solicitarea apare pe desktopul interactiv al utilizatorului, mai degrabă decât pe desktopul securizat.
• Dezactivat. Când este selectată această opțiune, desktopul securizat poate fi dezactivat numai de utilizatorul desktopului interactiv sau prin dezactivarea setării de politică „Control cont utilizator: comutați la desktop securizat atunci când vi se solicită elevație”.

Setările actuale ale politicii utilizând registrul:

;Dezactivați „EnableUIADesktopToggle”=dword:00000000

Modul de aprobare de administrator pentru contul de administrator încorporat

Această setare determină dacă Controlul contului utilizator aplică modul de aprobare de administrator contului încorporat "Administrator". Acest cont implicit încorporat permite utilizatorului să se conecteze în modul de compatibilitate Windows XP, permițându-i să ruleze orice aplicație cu drepturi complete de administrator. În mod implicit, această setare de politică este dezactivată.

Valori posibile ale parametrilor:

• Inclus. Când selectați această opțiune, contul de administrator încorporat va folosi modul de aprobare a administratorului. În acest caz, orice operațiune care necesită ridicarea drepturilor va fi însoțită de o solicitare de confirmare a operațiunii.
• Dezactivat. Contul de administrator încorporat rulează toate aplicațiile cu drepturi complete de administrator.

Setările actuale ale politicii utilizând registrul:

;Dezactivați „FilterAdministratorToken”=dword:00000000

Concluzie

Acest articol explică toate setările posibile pentru Controlul contului de utilizator. Sunt luate în considerare toate cele zece setări ale politicii de securitate, care sunt responsabile pentru toate acțiunile posibile legate de UAC. Pe lângă configurarea Controlului contului de utilizator folosind Politica de grup, sunt discutate și modificările echivalente ale registrului.