Co skutečně znamenají jednotlivá uživatelská práva aneb čeho se bát a čeho ne


Dneska bych se rád poměrně detailně věnoval problematice uživatelských práv, nebo user rights. Jedná se o součást systému zabezpečení Windows, které málokdo rozumí do detailu. Je to ale věc, která má zásadní dopad na bezpečnost operačního systému. Špatným nastavením si můžete přivodit zásadní díry, které je pak možné zneužít bez ohledu na to, jestli dodržujete jakákoliv další bezpečnostní doporučení.

Cílem článku je zdokumentovat uživatelská práva detailně svými vlastními slovy, protože oficiální dokumentace o tom moc přesně nehovoří. Obvykle chybí odkazy na API funkce apod.

Uživatelská práva (někdy privilegia), anglicky je na to přesný termín user rights (neboli privileges). Neplést prosím s oprávněními (anglicky permissions). Nejprve si tyto dva termíny přesněji vymezme:

  • práva (user rights) jsou ty věci, které najdete v konzoli Local Security Policy (Místní zásady zabezpečení, secpol.msc) v položce Local Policies - User rights assignment (neboli místní zásady - přiřazení uživatelských práv). Tento seznam je relativně omezený. Software tam sice může něco přidat, ale skoro nikdy se to neděje.
  • oprávnění (permission) jsou ty klikačky, které najdete na každé tabulce Security (zabezpečení) ve vlastnostech NTFS souborů a adresářů, registrů, AD LDAPu, tiskáren apod. Tohle je tak zvané objektové zabezpečení. To má každý objekt ve svých vlastnostech. Funguje tu dědičnost z nadřazeného objektu. A souvisí s tím termíny jako ACL (access control list) a ACE (access control entries) a discretionary access control (DAC) apod. Tomu se zde věnovat vůbec nebudeme. Někdy příště. I s tím souvisí mnoho zajímavostí.
Takže k uživatelským právům a hlavně o paměťové struktuře zvané access token

Některá uživatelská práva jsou hódně nebezpečná a přitom s tím každý nakládá poměrně bez rozmyslu. Speciálně třeba Debug programs, neboli ladit programy, každý dost významně podceňuje. Možná podobně jako Backup files and folders - zálohovat soubory a složky.

Jedná se o toto:

Práva jsou tedy přidělována jednotlivým uživatelským skupinám, nebo přímo uživatelským účtům. V okamžiku přihlášení je systém umístí každému uživateli do tzv. access tokenu. Access token je paměťová struktura, kterou operační systém dává každému procesu, který se spouští. Access token obsahuje popis identity uživatele - tedy jeho SID (security ID), dále SIDy všech jeho skupin, kterých je uživatel členem přímo, ale i nepřímo. A nakonec seznam všech aktuálně přidělených uživatelských práv.

Access token je to, co se používá ke kontrole přístupu. Pokud proces přistupuje na libovolný prostředek, jako jsou soubory na disku, nebo registrové klíče, přístup se kontroluje právě na základě access token toho procesu. Obsah access tokenu se vyhodnocuje pouze jednou jedinkrát v okamžiku ověření uživatele a potom se na něho už nesahá. Znamená to tedy, že co má daný proces v access token, to určuje jeho přístup až do okamžiku odhlášení.

Obsah access token nějakého procesu, tedy i seznam práv (rights, privileges), která má nějaký proces/uživatel aktuálně k dispozici, najdete například ve výpisu programu whoami:

whoami /all
whoami /priv

Případně si můžete stáhnout process explorer ze SysInternals a podívat se na záložku Security ve vlastnostech libovolného procesu. Zobrazuje to stejné jako whoami, jenom v GUI formě. Výhoda process exploreru je v tom, že umí zobrazit access token libovolného procesu, nejen sám sebe, jak to dělá whoami.

Poznámka: program whoami zobrazuje obsah access token uživatele, pod kterým proces běží. Vzhledem k tomu, že uživatelská práva jsou součást lokálního access tokenu, nejedná se o žádné AD nastavení, ani Kerberos ani nic jiného. Přiřazení práv je prostě součást místních zásad (local security policy). Ano, dá se to nastavit centrálně přes Group Policy (GPO), to ano, ale může se to lišit podle počítače, na kterém zrovna pracujete lokálně, nebo se na něj připojujete přes síť. Pokud řešíte potíže s přístupem, je tedy potřeba kontrolovat access token právě na tom počítači, na kterém potíže máte. Zjistit to vzdáleně moc nejde.

Členové skupiny Administrators toho mají přiděleno vcelku hodně. Ale jak si můžete všimnout, i obyčejní uživatelé něco přecejen mají. Na následujících dvou obrázcích je to porovnáno. Dokonce stejný úživatel, jednou pracující s právy správce, zatímco podruhé jen omezeně při zapnutém user account control (UAC - řízení uživatelských účtů).

Podobný obrázek dostanete pomocí Microsoft nástroje Process Explorer (procexp)- ke stažení také zde:

Různé druhy uživatelských práv

Práva jsou v podstatě tří druhů:

  • logon rights - práva přihlašovací
  • práva k provedení nějaké systémové akce, která nelze zabezpečit pomocí oprávnění (permissions)
  • silová práva, která přebíjí nějaká oprávnění

Tyto tři druhý práv se liší jak použitím, tak také svou citlivostí a nebezpečností. Za nejnebezpečnější se dají považovat práva "silová", tedy ta poslední skupina. Ale obecně, každé právo má svou bezpečnostní kvalitu, kterou není dobré přehlížet.

Logon rights - práva přihlašovací, přesněji řečeno práva na vznik access token

To jsou práva jako logon locally, nebo access this computer from network. Jedná se o právo na přihlášení - přesněji vznik access tokenu daného typu. Řídí se tím tedy, jestli se můžu přihlási na daném počítači pomocí Ctrl-Alt-Del, nebo jestli se dostanu na jeho sdílené soubory, nebo IISweb server přes síť.

Tahle práva se dokonce potom už v access token ani nevyskytují a ve výstupu programu whoami je neuvidíte. Tato práva, jako jediná, mají také opačnou, zakazovací obdobu, která je silnější, než jejich povolovací verze - například deny logon locally.

Jak už jsem říkal, tato práva v access tokenu neuvidíte. Pokud dané právo nemáte, nebo vám bylo explicitně odepřeno, ani se nepřihlásíte, nevznikne vám tedy access token. Místo tohoto přihlašovacího práva v access tokenu, v něm uvidíte NT AUTHORITY SID (jakoby skupina). Například INTERACTIVE. Takže pomocí whoami si musíte vypsat skupiny (whoami /groups) a ne privilegia. Díky odpovídajícímu SIDu se pak dá omezit přístup na prostředky pomocí jejich objektových permissions(oprávnění).

Mohli byste tedy zařídit, aby se uživatel do nějakého adresáře dostal jen přes síť, zatímco by se do něho nemohl podívat lokálně, když se přihlásí pomocí Ctrl-Alt-Del. Není k tomu asi moc důvodů, proč to takhle využívat. Rozhodně je ale dobré vědět, že to tak funguje, protože občas se přece jen něco najde.

Následující tabulka zachycuje název práva a jemu odpovídající skupinu (SID), kterou dostanete do access tokenu.

right/privilege právo/privilegium skupina/SID v access tokenu vysvětlení Logon Event
Logon Type
logon locally povolit místní prihlášení INTERACTIVE S-1-5-4 interaktivní přihlášení pomocí CTRL-ALT-DEL 2
logon through remote desktop services povolit přihlášení prostřednictvím vzdálené plochy REMOTE INTERACTIVE LOGON
S-1-5-14
přístup přes RDP, od Windows 2003 k tomu nepotřebujete logon locally, protože právě k tomu přibylo tohle právo, aby se to dalo oddělit 10
logon as a batch job přihlásit jako dávkovou úlohu BATCH
S-1-5-3
naplánovaná úloha (scheduled task)
IIS app pool (fond aplikací IIS)
4
logon as a service přihlásit jako službu SERVICE
S-1-5-6
služba (Windows service) 5
access this computer from network přistupovat k tomuto počítače přes síť NETWORK
S-1-5-2
přístup ze sítě na tento server, například na server sdílených souborů (SMB), nebo do SQL serveru, nebo do Exchange a LDAP a certifikační autority a kamkoliv jinam 3

Při přihlašování (přesněji řečeno právě při vzniku access token) také vznikají události v Security log protokolu událostí. Až do Windows 2003 to byly události číslo 528, nebo 534 v případě neúspěchu, od Windows Vista a Windows 2008 mají číslo 4624 a pro failure audit je to 4625. Neúspěchem (failure audit) může být právě fakt, že daný uživatelský účet nemá přiděleno požadované přihlašovací právo, nebo ho má naopak explicitně odepřeno:

Event Id: 528
Event Type: audit success
Event Log: Security
Event Category: Logon/Logoff
Message: Logon success. Logon type 2
Event Id: 534
Event Type: audit failure
Event Log: Security
Event Category: Logon/Logoff
Message: Logon failure. Logon type 2

Event Id: 4624
Event Type: audit success
Event Log: Security
Event Category: Logon/Logoff
Message: An account was successfully logged on. Logon type: 2
Event Id: 4625
Event Type: audit failure
Event Log: Security
Event Category: Logon/Logoff
Message: An account failed to log on. Logon type: 2

V předchozích obrázcích i v tabulce je právě vidět také číslo Logon Type, které určuje typ access tokenu a tedy i přihlašovací právo, které k tomu bylo potřeba. Tyto události (kategorie logon/logoff) se objevují na konkrétním počítači, kde takový access token vzniká. Je to tedy trošku něco jiného než u událostí typu account logon, o kterých jsem mluvil někdy minule v souvislosti s rozdělováním NTLM a Kerberos ověření.

Teď se bavíme o lokálním vzniku paměťové struktury access token, která v podstatě s NTLM nebo Kerberospřímo nesouvisí.

Práva k provedení nějaké systémové akce

To je například právo change system time, nebo shutdown the system. Je to prostě povolení k nějaké akci. Kdyby ta akce například zapisovala něco do registrů, nebo do nějakého souboru, bylo by možné to ochránit a řídit pomocí oprávnění (permissions). Jenže změna času se zapisuje do "firmware" počítače. Stejně tak vypnutí systému v principu nevyžaduje žádný zápis do nějakého prostředku operačního systému, ani do souboru, ani do registrů. Prostě řeknete hardware, aby se restartoval, nebo vypnul.

Proto jsou k tomu udělaná práva (rights, privileges) a nikoliv oprávnění na nějakém souboru, nebo v registrech.

Tahle práva už jsou, narozdíl od práv přihlašovacích, zapsaná v access token hned po jeho vytvoření a každá aplikace si je může přečíst, pokud podle nich chce něco řídit. Práva mají nějaký popisek, ale mají také svoje systémové jméno, které uvidíte jak ve výpisu whoami, tak i v process explorer (procexp), případně v protokolu událostí.

Neřekl bych, že bych se těchto práv nějak zvlášť bál. V podstatě je můžete povolit každému, kdo danou akci potřebuje, protože nějak agresivně zneužít se to nedá.

right/privilege typ systémový název nebezpe
čnost
vysvětlení
change system time hardware SeSystem
timePrivilege
nízká  
change the time zone hardware SeTime
ZonePrivilege
nízká  
shutdown the system hardware SeShutdown
Privilege
nízká  
force shutdown from a remote system hardware SeRemote
Shutdown
Privilege
nízká nejprve se musíte připojit vzdáleně třeba na WMI, nebo na lanmanserver named pipe (pouze Administrators ve výchozím stavu) a teprve potom můžete tohle vyvolat. Takže nic extra nebezpečného.
remove compute from docking station hardware SeUndock
Privilege
nízká  
modify firmware environment values hardware SeSystem
Environment
Privilege
nízká  
create a pagefile API akce jádra SeCreate
PagefilePrivilege
nízká pokud chcete zavolat nativní API jádra, které způsobí, že se vytvoří někde nějaký pagefile (stránkovací soubor), nebo se mu nastaví nějaké parametry, potřebujete k tomu tohle právo. Prostě to není zabezpečení nikde jinde a API funkce si kontroluje, jestli máte toto právo. Samozřejmě můžete tyto parametry nastavit i v registrech, kde se to kontroluje pomocí oprávnění a může tam ve výchozím stavu jen skupina Administrators. Ale to je věc, která vyžaduje restart a je trvalá. Pokud chcete naopak tuhle akci udělat jen za běhu pomocí API funkce za běhu, prostě se kontroluje navíc toto právo. V podstatě to tam je proto, abyste mohli tuto schopnost přidělit i někomu jinému, než jen skupině Administrators.
Jak se to dá vyzkoušet je například přes WMI třídu Win32_PageFileSetting. K vytvoření její instance prostě potřebujete toto právo.
create global objects API akce jádra SeCreate
GlobalPrivilege
   
load and unload device drivers API akce jádra SeLoad
DriverPrivilege
střední nainstalovat ovladač jádra (SYS) musíte zápisem do registrů. To je chráněno normálně přes oprávnění (permissions) v registrech. Tam se samozřejmě dá taky nastavit, že se ten ovladač má nahrávat automaticky při startu systému. Výchozí oprávnění v registrech je jen pro skupinu Administrators. Pokud ale chcete nějaký (už nainstalovaný) ovladač zavést na váš požadavek za jízdy, nebo ho naopak vypnout, API si kontroluje toto právo (privilege). Důvod proč to existuje je opět možnost tuto akci povolit nějaké slabší skupině, bez nutnosti jim dovolit modifikovat celé registry. Například máte driver HTTP.SYS. Je zaregistrován v registrech. Parametry nezměníte, protože nejste Administrators, abyste mohli do těch registrů zapisovat. Ale pokud máte toto právo, můžete za jízdy požádat systém, aby driver HTTP.SYS odstranil z paměti a potom ho tam zase vrátit a tím ho v podstatě restartovat.
generate security audits API funkce SeAuditPrivilege nízká API funkce, pomocí které se vytváří auditové události do security logu tohle prostě kontroluje. Program, který by chtěl auditovat do security logu svoje vlastní události, musí běžet pod účtem, který má toto právo. Potřebuje to například servisní účet SQL serveru, který by chtěl do Security logu zapisovat Application generated audity. To pak vyžaduje povolit mu toto právo a zapnout auditování Application generated.
Zneužití minimální. Řekněme že by zlák mohl ten log zacpat, nebo přepsat nesmysly.
Někde jsem četl, že i toto právo umožňuje Security event log číst a mazat, ale není tomu tak.
manage auditing and security log posílení NTFS, registry a LDAP a Security log ochrany SeSecurity
Privilege
střední pokud chcete číst obsah, nebo něco změnit na záložce Auditing ve vlastnostech NTFS souborů, nebo registrů a podobně - tedy přesněji pokud chcete číst nebo změnit auditing (SACL) v oprávněních (permissions) nějakého objektu - musíte mít toto právo (right). Prostě posílení ochrany, aby někdo jen tak nezahltil systém velikým množstvím auditních událostí.
Funguje to také jako silové právo. Protokol událostí Security má svoje normální oprávnění. Tam je napsáno, že se do něho dostane jenom skupina Administrators. Pokud chcete někomu povolit, aby se tam taky podíval, máte dvě možnosti. Buď musíte změnit oprávnění na ten Security log, například pomocí wevtutil. Nebo můžete využít tohoto práva. Kdo má toto right, dostane se do Security logu bez ohledu na jeho permissions.
enable computer and user accounts to be trusted for delegation posílení AD ochrany SeEnable
Delegation
Privilege
vysoká Kerberos delegation (delegování) se nastavuje jako AD LDAP atribut ve vlastnostech účtu v Active Directory. K ochraně toho by stačilo použít normální LDAP oprávnění v AD. Taky to tak je. Správná oprávnění v LDAPu mít musíte. Bez toho to nepojede. Ale navíc musíte mít toto právo (privilege). Proč? Protože je to tak mnohem striktněji chráněno.
Takže citlivé, ale je to až druhá vrstva zabezpečení, takže ne až tak moc citlivé.
impersonate client after authentication práce s access token API SeImpersonate
Privilege
nízká zase se jedná prostě o kontrolu nějaké API funkce, která něco dělá, místo aby se použilo nějaké objektové oprávnění. V tomto případě to musíte mít k tomu, aby se vám, jako službě, podařilo impersonovat (impersonifikovat) nějakého přicházejícího uživatele, který se do vaší síťové služby přihlásil a tím vám poskytl svůj access token. Jestli pod tímto účtem běží služba, nejspíš bude toto právo potřebovat vždycky. Ve výchozím stavu je tam právě taky proto SID NT AUTHORITY\SERVICE. Pokud se nainstaluje IIS, tak v tom seznamu přibude i SID IIS_IUSRS, protože i fondy aplikací (app pool), které mají automaticky tento SID, potřebují provádět impersonation. Pokud byste jim to vypnuli, classic ASP vám nepojede vůbec. ASP.NET vám pojede jen trošinku, protože může alespoň částečně fungovat i jen s velice omezeným identification access tokenem. Na moc prostředků se s tím ale nedostanete, jako třeba na disk ne. Na to už potřebujete impersonation access token a k tomu potřebujete toto právo (privilege). Vyzkoušet se to dá například pomocí mých testovacích webových aplikací, co jsem publikoval nedávno.
replace a process level token posílení zabezpečení a práce s access token API SeAssign
PrimaryToken
Privilege
nízká zase se jedná prostě o kontrolu nějaké API funkce, navíc nad jiná objektová oprávnění. Jde o spouštění nových procesů pod jiným, konkrétním, uživatelem. Tak jak dělají například služby Task scheduler. nebo Secondary logon (runas). Prostě a jednoduše, jestli program volá CreateProcessAsUser nebo CreateProcessWithToken funkce, musí mít navíc toto právo. Není to nic moc nebezpečného, protože pro tu funkci musíte znát login a heslo daného uživatele. Tak proč si ho nepřihlásit. Proto taky je ve výchozím nastavení Local Service a Network Service.
Ono by se to dalo zneužít. Znamená to ve skutečnosti, že byste mohli vzít nový access token (uživatele, kterého jste si přihlásili) a natvrdo to nastavit na nějaký jiný, už běžící proces - pomocí NtSetInformationProcess (ProcessAccessToken = PROCESS_ACCESS_TOKEN) - nepodporované, od Vista nefunkční.
Jenže k tomu byste museli být schopni ten proces otevřít. Ve výchozím stavu můžete otevírat jen svoje vlastní procesy, které jste si vytvořili. Pouze skupina Administrators může otevírat ostatní/cizí procesy díky svému silovému právu Debug programs.
Dal by se vzít i access token jiného procesu, ale opět byste museli ten proces otevřít a ještě jeho access token duplikovat s přístupem TOKEN_ASSIGN_PRIMARY.
Takže tohle právo je jen posílení výchozí bezpečnosti, prostě další vrstva.
perform volume maintenance tasks API funkce pro sektorový (blokový) přístup na diskové oddíly SeManage
VolumePrivilege
vysoká pokud chcete číst, nebo modifikovat sektory disku, nebo třeba i jen změnit jeho jméno, nebo písmeno disku, potřebujete toto právo pro příslušné API funkce.
Tohle nejde zabezpečovat jinak pomocí oprávnění, takže je k tomu toto právo.
Uvědomte si, že to znamená přímé čtení a zápis sektorů disku a diskových oddílů (partition) a to bez ohledu na BitLocker a NTFS oprávnění. Protože tyto operace děláte pomocí API, tedy v době, kdy BitLocker už jenom transparentně dešifruje a šifruje data z/do disku. A děláte to na vrstvě až pod NTFS kontrolami.

Silová práva - tudíž značně citlivá a nebezpečná

Potom existují skutečně velmi nebezpečná a citlivá práva z této třetí skupiny. Silová práva v principu slouží k přebíjení jakýchkoliv objektových oprávnění, která by mohla stát někomu v cestě. Patří sem například Backup files and directories, Take ownership a nebo Synchronize directory service data.

Uplatňují se v okamžiku, kdy uživatel nemá konkrétní objektové oprávnění (permission) k provedení nějaké akce. Pěkně se to vysvětlí na příkladu backup files and directories.

right/privilege typ systémový název nebez
pečnost
vysvětlení
backup files and directories silové přebití NTFS oprávnění SeBackup
Privilege
vysoká sice se to nazývá "backup files and directories", ale na zálohováním to není omezeno a stejně tak to není omezeno jenom na soubory a složky.
Ve skutečnosti by se to mělo spíš jmenovat read all, nebo třeba data reader. A to na jakékoliv objekty, nejen NTFS, ale i registry, tiskárny a služby, desktopy, procesy apod.
Jestli tohle právo máte, můžete číst úplně cokoliv. V takovém okamžiku se na vás nevztahují vůbec oprávnění pro čtení. I kdybyste měli explicitně zakázán přístup (deny permission) k nějakým registrům, nebo souborům, stejně si je přečtete.
Jmenuje se to backup, protože to samozřejmě využívají zálohovací programy, aby se nemusely starat o oprávnění.
restore files and directories silové přebití NTFS oprávnění SeRestore
Privilege
vysoká opačná verze backup files and directories. Mělo by se to spíše jmenovat write all, nebo data writer. Znamená to, že můžete zapsat do jakéhokoliv souboru a nikdo na vás nemůže. Můžete samozřejmě zapisovat i do registrů a kamkoliv jinam, protože oprávnění v takové situaci nehrají roli. A tím se myslí i explicitní Deny zákazy na nějakých souborech apod.
take ownership of files or other objects silové přebití NTFS oprávnění SeTake
Ownership
Privilege
vysoká mormálně si může vlastníka (owner) na libovolných objektech měnit jen podle oprávnění na Take Ownership. Kdo je vlastník, může měnit oprávnění.
Pokud nejste ani jedno a přitom máte toto právo (right), můžete natvrdo změnit vlastníka libovolného objektu a nikdo s vámi nediskutuje. Nelze vám tu změnu už nijak dál zakázat. Následně si tedy můžete změnit oprávnění a už se k datům takového objektu pohodlně dostanete.
synchronize directory service data silové přebití
LDAP oprávnění
SeSync
Agent
Privilege
vysoká toto právo umožňuje jeho vlastníkovi, aby si z Active Directory stáhnul veškerý obsah celého NTDS.DIT databáze, včetně hesel a čehokoliv dalšího.
Normálně se toto řídí pomocí LDAP oprávnění (permissions) na úrovni domény (konkrétně Relicating Directory Changes - to je bez hesel a Confidential atributů, a Replicate Directory Changes All - což je i včetně hesel v všeho ostatního - krásně vysvětleno tady).
debug programs silové přebití oprávěnní ve vlastnostech process objetů SeDebug
Privilege
vysoká bez ohledu na toto právo - každý proces má svoje vlastní oprávnění. Můžete je vidět v process exploreru, na tabulce Security je v pravo dole čudlík Permissions. Pokud si proces spustíte sami (i když nemáte toto právo), máte k němu vždycky plná oprávnění a můžete si s ním dělat co chcete - kill, suspend, krokovat, přepisovat a číst paměť - prostě cokoliv. Takže vývojáři ve skutečnosti nepotřebují být mnohdy vůbec členem skupiny Administrators. To oni jenom tak kecají, že to chtějí 🙂
Pokud ovšem chcete číst paměť nebo krokovat, nebo kill, nebo zapisovat do paměti procesu, který běží pod cizím účtem, nejspíš to ve výchozím stavu nepůjde. To je samozřejmě dobře - viz. terminálový server (RDP), kde běží padesát uživatelů a nechceme, aby si četli vzájemně paměti, že?
Jestliže někomu toto právo dáte, tak si může s ostatními procesy dělat co chce. Používá se to pro krokování systémových procesů například. Nebo to používá psexec k tomu, aby si zduplikoval SYSTEM access token a spouštěl si procesy pod tímto účtem. Případně to já používám na vybírání LSA secrets.
Nebo to využívá hekovací nástroj wce, kterému to stačí k tomu, aby vykradl plnotextová hesla z paměti operačního systému.
Ani jeden ze zmíněných programů nemusí běžet pod účtem skupiny Administrators. Stačí jim právo debug! Tak pozor.
add workstation to domain silové přebití LDAP oprávnění SeMachine
Account
Privilege
střední opět to ruší kontrolu oprvánění v LDAPu. S tímto právem si můžete vytvořit účet počítače v Active Directory, aniž byste k tomu museli mít normální legitimní oprávnění. Výchozí limit je 10 různých účtů počítačů (computer class). S tím souvisí LDAP atributy msDS-MachineAccountQuota a msDS-CreatorSID, což je ale mimo rozsah tohoto článku.
adjust memory quotas for a process silové přebití oprávnění na objektech process SeIncrease
Quota
Privilege
střední tohle opět přebíjí jakákoliv oprávnění na libovolných procesech a umožňuje jim změnit limity na spotřebu virtuální a fyzické paměti. Zneužít se to moc nedá, kromě řekněme DoS, kdy by útočník omezil někomu jinému paměť natolik, že by to spadlo. Potřebuje to třeba funkce SetProcessWorkingSetSize, nebo SetSystemFileCacheSize, která umí za jízdy změnit velikost RAM keše pro soubory.
Je zajímavé, že to potřebujete k tomu, abyste volali taky API funkci CreateProcessAsUser a CreateProcessWithToken, což jsme diskutovali v předchozí kapitole. Proto taky ten výchozí Local Service a Network Service.
bypass traverse checking API funkce pro directory change notification
a něco jako silové přebití oprávnění v cestě k objektu
SeChange
Notify
Privilege
žádná tohle právo je dvousečné. Zaprvé ho potřebují programy jako průzkumník Windows (Windows explorer), nebo Salamander, nebo Total Commander, k tomu, aby jim operační systém dal vědět, když se změní obsah nějakého adresáře.
Bez tohoto práva by totiž nemohli otevírat objekty adresářů tak, aby je systém sám notifikoval o změně a museli by se tam jednou za čas dívat.
Druhá věc, kterou to dělá je zajímavá. Máte třeba hlubokou NTFS cestu několika složek. Nemáte ale přístup do nějaké z mezi složek. Takže zvrchu se do té spodní skutečně neproklikáte. Ale pokud znáte celou cestu, tak si ji otevřít můžete. Kdybyste toto právo neměli, tak byste se do té spodní složky nedostali, protože by se kontrola přístupu zasekla na té nějaké zablokované mezi-složce.
Act as part of operating system Ultra mega silové právo SeTcb
Privilege
ultra vysoká zkratka TCB znamená thread control block. To je kernelová paměťová struktura, která popisuje každé vlákno každého procesu. Pokud máte toto právo, můžete si dělat s TCB cokoliv, bez ohledu na normální oprávnění daného procesu. Můžete si například ručně vyrobit libovolný access token, dát si do něho libovolné SIDy a třeba i libovolná další práva. Znamená to, že si můžete vytvořit dokonce i úplně virtuální identitu i s neexistujícím SIDem a spustit si pod ní nějaký proces. A to je pěkně drsné 🙂 Ve výchozím stavu to má přiděleno pouze uživatel SYSTEM a nerad bych, aby to dostal do ruky nějaký útočník.
Tohle právo potřebujete třeba v případě, že se snažíte dělat Kerberos constrained delgation with protocol transition, což je vlastně přesně to vytváření access token úplně ze vzduchu - tedy volání LogonUser API bez hesla, pouze s loginem, nebo to stejné voláním kontruktoru WindowsIdentity opět bez hesla. Pokud jednu z těchhle dvou metod voláte a přitom právo SE_TCB_NAME nemáte, dostanete jenom Identification token. S takovým se na prostředky ani nedostanete. Pokud toto právo máte, už vám je systém ochoten vydat i plnohodnotný Impersonation access token.
Je to podobné, jako v případě práva SeImpersonatePrivilege (impersonate client after authentication), jen s tím rozdílem, že v případě SeImpersonatePrivilege se uživatel musí ověřit heslem (apod.), zatímco tady vzniká access token bez jakéhokoliv prokazování identity.

Jak vidíte z přechozího, silová práva jsou skutečně nebezpečná.

- Ondřej Ševeček, MVP

Comments (4)

  1. pekny a co treba skryta prava ? says:

    existuji jeste takzvana skryta predpokladana prava k nekterym castem OS dle clenstvi v zakladnich skupinach

    tato prava jsou pridelena na objektech

    kdo ma pravo vytvaret share, kdo ma pravo formatovat disk ?

    tady by mne zajimalo jak se aplikuji tato prava ted win 2008/2012, v NT 4.0 to mam jeste v jedne knizce

  2. formátovat disk může ten, kdo má "user right" "perform volume management tasks". Tohle není chráněno nikde pomocí oprávnění "permissions".

    oprávnění "permission" pro vytváření sdílených adresářů jsou uložena v registrech v klíči HKLMSYSTEMCurrentControlSetServicesLanManServerDefaultSecurity. Jsou v tom podklíči s binární reprezentací ACL pro každou z těch funkcí, které SMB server plní. Tato
    oprávnění není možné nikde v GUI změnit. Na Windows XP k tomu bylo TweakUI nástroj od MS, ale dnes už to asi nejede.

    Dalo by se to vypsat například pomocí PowerShellu a tím pádem taky změnit. Takže by se skutečně dalo zařídit, aby nějaký uživatel měl možnost nasdílet adresář. Nebo by se zde dalo změnit výchozí oprávnění na Admin Share typu C$ a pod. takže byste klidně dokázal
    zařídit, aby se do C$ dostala I skupina Users například.

    Ondra.

  3. Anonymous says:

    Deny není žádný rváč, ani můj sparing partner v soutěži o hrdinu na benčpresu

  4. Anonymous says:

    Na této stránce najdete archiv článků z Technet Flash zpravodaje, pravidelného

Skip to main content