Pořád tu píšu o PowerShellu. Uveřejnil jsem mnoho demonstračních proof-of-concept hacking skriptů (jako je třeba neviditelné registrové hodnoty, čtení seznamu uživatelských účtů/loginů pomocí zkoušení SID a RID a následné zamykání, čtení LSA secrets z registrů běžícího počítače, nebo skenování IP a MAC adres a určitě i jednoduchý Keylogger).
Je tedy možné, že byste chtěli uživatelům zabránit ve spouštění PowerShell skriptů. Jde to? V podstatě to nejde úplně. Můžete se pokusit trošku to omezit nebo to více zkomplikovat, ale nejspiš tomu úplně nezabráníte. Taky uvažte, že musíte dovolit spouštět skripty správcům a kdoví jakým instalacím a programům.
Jaké máte tedy možnosti?
Použití Group Policy (GPO) na vynucení podepsaných skriptů (code signing) a úplné zakázání
Před Group Policy (GPO, zásady skupiny) můžete vnutit na počítače zásadu takovou, že se spouštěcí politika (PowerShell execution policy) nastaví na AllSigned. To by znamenalo, že se dají spouštět pouze digitálně podepsané skripty. Digitální podpisy do skriptů můžete dávat i sami pomocí Code Signing certifikátu, který si buď koupíte, nebo si vydáte vlastní z Windows AD CS autority. Tuto politiku najdete v počítačové i uživatelské části objektu a dá se tedy řídit i jen pro některé uživatelské účty:
User Configuration - Policies - Administrative Templates - Windows Components - Windows PowerShell
Computer Configuration - Policies - Administrative Templates - Windows Components - Windows PowerShell
Turn on script execution
Allow only signed scripts
nebo česky
Konfigurace uživatele - Zásady - Šablony pro správu - Součásti systému Windows - Windows PowerShell
Konfigurace počítače - Zásady - Šablony pro správu - Součásti systému Windows - Windows PowerShell
Výsledek nastavení na stanici, kde se promítá nějaká centrální zásada a současně tam je třeba něco nastaveno lokálně, se dá prohlédnout pomocí Get-ExecutionPolicy -List. Tahle zásada je dokonce silnější, než parametr -ExecutionPolicy pokud spouštíte powershell skript z příkazové řádky nebo BAT souboru. Takže je to poměrně slušné omezení. Akorát to nefunguje
Pokud byste chtěli spouštění skriptů zakázat úplně, touto politikou to nejde. Museli byste pomocí Group Policy Preferences distribuovat registrovou hodnotu:
User Configuration - Preferences - Windows Settings - Registry
HKCU\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
ExecutionPolicy = REG_SZ = Restricted
Computer Configuration - Preferences - Windows Settings - Registry
HKLM\Software\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell
ExecutionPolicy = REG_SZ = Restricted
nebo česky
Kongigurace uživatele a Konfigurace počítače - Předvolby - Nastavení systému Windows - Registr
To je sice pěkné, ale bohužel tahle možnost už není ani silnější, než parametr -ExecutionPolicy pro powershell.exe. Takže pokud někdo spouští skript nikoliv poklikem, ale z příkazové řádky například takto, tak to projde a neomezíte ho:
powershell -ExecutionPolicy Bypass -File "mujskript.ps1"
Parametr -Command, -EncodedCommand a copy-paste metoda
Nicméně, i když cokoliv omezíte, nebo zablokujete v politice, stejně vám to nepomůže. Powershell.exe má parametr -Command na jehož obsah se execution policy vůbec nevztahuje. Takže každý si spustí klidně celý skript přímo napsaný jako parametr powershell.exe.
Mohlo by se zdát, že by mohl mít problémy se zadáváním různých speciálních znaků přímo z CMD příkazové řádky, ale to není problém, protože -EncodedCommand prijímá Base64 zakódovaný skript a tím se to krásně vyřeší.
Ještě pěknější je metoda copy-paste. Prostě si člověk hodí zdroják svého skriptu do schránky a do powershell příkazového okna ho paste vloží pravým tlačítkem myši. Opět totálně bez vlivu execution policy.
Cesta přes RDP RemoteApp
Provozujete terminal server (TS, RDS - remote desktop services) ve formě vzdálených aplikací (RemoteApp). To znamená, že uživatelé vidí pouze okno vzdálené aplikace a dokonce se nemohou dostat vůbec na celou plochu RDP serveru.
Člověk by si řekl, že takto není možné spustit powershell, protože se k němu nemáte jak proklikat. Pokud ho náhodou správce nevypublikoval jako jednu z RemoteApp (nebo tedy cmd.exe). Omyl.
Pokud má vaše vzdálená aplikace k dispozici normální Windows průzkumníkové (explorer) ukládací dialogové okno, tak se stačí proklikat do C:\Windows\System32\WindowsPowerShell, najít tam powershell.exe a pravým tlačítkem zvolit Open / Otevřít. Následující obrázek to snad dostatečně dokumentuje:
Napadlo mě proti tomu použít další zásadu, která blokuje přístup průzkumníka (Windows Explorer neboli ponovu File Explorer) na různé disky, ale stejně to nepomůže. Sice se k adresáři C:\Windows\System32\WindowsPowerShell neproklikáte, ale pokud rovnou nahoru ručně do adresního řádku napíšete celou cestu, tak se PowerShell spustí. Dokonce vám doskakují nabídky podadresářů, i když na disk údajně nemůžete. Ale i tak to může být zajímavá zásada, zablokovat z průzkumníka jednoduchý přístup na disk C:
User configuration - Policies - Administrative templates - Windows components - File Explorer
Prevent access to drives from My Computer
nebo česky
Konfigurace uživatele - Zásady - Šablony pro správu - Součásti systému Windows - Průzkumník souborů
Zabránit přístupu k jednotkám ze složky Tento počítač
Použití Software Restriction Policies na zakázání powershell.exe
Už od Windows XP máte na všech verzích operačních systémů technologii Software Restriction Policies (SRP, Zásady omezení softwaru), které umožňují blokovat spouštění jednotlivých EXE podle jejich celé diskové cesty, nebo i jen jména, nebo například hash (otisku) jejich binárního obsahu. Tyto zásady jsou jak v části uživatele, tak i v části počítače GPO.
Uživatelská část hodí výborně, protože umožňuje cílit toto omezení přímo na konkrétní skupinu uživatelů (například pomocí security filtering aplikovaného na celé GPO, nebo podle organizační jednotky OU). Celé nastavení najdete tady:
User Configuration or Computer Configuration
Policies - Windows Settings - Security Settings - Software Restriction Policies
Additional Rules
c:\windows\system32\WindowsPowerShell\v1.0\powershell.exe
c:\windows\system32\WindowsPowerShell\v1.0\powershell_ise.exe
powershell.exe
powershell_ise.exe
neboli česky
Konfigurace uživatele - Zásady - Nastavení systému Windows - Nastavení zabezpečení - Zásady omezení softwaru
Další pravidla
Zakázal jsem také ISE, což je snad pochopitelné. Upozorňuji, že powershell se takto nespustí ani v případě, že kliknete pravým tlačítkem na PS1 soubor, i kdyby byl digitálně podepsán. Nespustí se ani z BAT/CMD skriptu. Hláška bude něco jako This program is blocked by group policy - Tento program byl zablokován vaším správcem systému, nebo Tento program je blokován zásadami skupiny.
Všimněte si, že jsem zakázal cestu do WindowsPowerShell adresáře, ale také samotné jméno procesu powershell.exe. Tady právě narážíme na problém.
Když zakážete program přesnou cestou, tak stačí uživateli jeho EXE prostě zkopírovat někam jinam. Třeba k sobě na plochu. Odtud už spustit půjde, protože to má jinou diskovou cestu. Snažím se jim to tedy trošku zkomplikovat tím, že jsem zakázal i powershell.exe jenom jako jméno programu. Takže nepůjde spustit od nikud. Samozřejmě se útočníkovi nabízí úplné přejmenování souboru.
Tomu už bohužel nezabárníte, pokud používáte black-listing a nikoliv white-listing, tak s tím nic nenaděláte. Mohlo by vás napadnout blokovat všechny možné verze powershell.exe podle jeho hash, ale to se dá také krásně obejít například digitálním podpisem EXE. Metoda blacklisting prostě není nikdy absolutní. Takto je to snad dost velká obstrukce alespoň pro začátečníky. Otázka je, kdo je hacker powershellista začátečník...
Použití AppLocker (Application Control Policies - Zásady řízení aplikací) k omezení spouštění a běhu powershell.exe
Technologie AppLocker je novější a vylepšená verze SRP, je k dispozici až od Windows Vista a Windows 2008, ale hlavně je jen na serverových edicích (terminal server, RDS) a na Enterprise edicích stanic. Takže použití je omezené. A samozřejmě v režimu black-listing vám nabízí v podstatě to stejné jako SRP, které jsou dostupné kdekoliv.
Má to nějaké podružné výhody, zvláště pokud nechcete stritknější white-listing, tak se věci jako audit-only režim na nic moc nehodí. Group policy object obsahuje jen počítačovou konfiguraci, takže se to sice aplikuje na počítače, ale pravidla se dají specifikovat podle jednotlivých uživatelských skupin.
Opět můžete vyjmenovat spustitelný program pomocí jeho plné cesty (Path rule), ale nemůžete už určit jenom jméno souboru, musí mít plnou cestu. To se ale udělá pomocí jiného typu pravidla - Publisher rule - tedy podle jméno vydavatele, který digitálně podepsal powershell.exe a/nebo podle jména souboru. Teď už bude složitější to powershell.exe někam vykopírovat, protože nestačí ten soubor ani přejmenovat, ani třeba podepsat nějakým svým vlastním podpisovým certifikátem - musela by se odstranit původní signatura, což je o něco náročnější (pracuju na tom :-)).
V group policy (zásadách skupiny) najdete AppLocker nastavení zde (nezapomeňte zapnout službu Application Identity (appidsvc), která se o tuto technologii stará):
Computer Configuration - Policies - Windows Settings - Security Settings - Application Control Policies - AppLocker
nebo česky
Konfigurace počítače - Zásady - Nastavení systému Windows - Nastavení zabezpečení - Zásady řízení aplikací - AppLocker
Auditování a sledování procesů
Pokud byste si zařídili nějaké sledování bezpečnostních událostí například přes SCOM, tak můžete auditovat události Detailed tracking - Audit process creation (Podrobné sledování - auditovat vytvoření procesu), kde se dá zachytávat spouštění procesů. A to už můžete nějak sledovat a případně reagovat.
Kdo se chce naučit sledovat události pomocí SCOM, dojde na můj kurz GOC170, který se zabývá vytvářením management pack balíčků právě pro System Center Operations Manager.
Závěr
Zakázat powershell pro uživatele není úplně sranda, ale za pomoci AppLocker dosáhnete poměrně kvalitního výsledku i pokud používáte jen blacklisting namísto tvrdého whitelistingu, kterým byste zakázali všechno a jenom povolovali výjimky.
Při přístupu black-listing samozřejmě uživatelům nic nebrání stáhnout něco z internetu a spustit to, ale už tím omezením powershellu vyblokujete primární utočný povrch dneška. Zvláště na RDS (remote desktop services).
Pokud zavedete ještě sledování (auditing), máte velmi slušnou ochranu, protože ani členové skupiny Administrators nezvládnou jednoduše vypnout auditování bez předchozího spuštění nějakého procesu, nebo právě powershellu.