PowerShell Security - polityki uruchamiania skryptów

Autor: Paulina Januszkiewicz

Opublikowano: 21 lutego 2008

Zawartość strony

	Wstęp
	Coś, co wiesz...
	Coś, co masz...
	Pomijając „domyślne”
	Gdzie jestem i jakie mam uprawnienia?
	Ryzyko zminimalizowane
	Zmiana uprawnień
	Strategia przypisywania uprawnień
	Kulisy podpisywania
	Podsumowanie

Wstęp

Znalezienie osoby, która nie korzystała nigdy z wysłużonego środowiska cmd, jest jak szukanie igły w stogu siana. Nowe środowisko skryptowe PowerShell ma znacznie większą funkcjonalność i jest idealnym narzędziem do administracji systemami, z powodzeniem zastępującym wszystkim znane cmd. Celem tego artykułu jest ukazanie podstawowych funkcjonalności konsoli PowerShell w dziedzinie bezpieczeństwa, takie jak podpisywanie kodu, czy konfiguracja polityk uruchamiania skryptów.

 Do początku strony

Coś, co wiesz...

PowerShell powstał w oparciu o platformę .NET Framework. Już przy pierwszym uruchomieniu użytkownik ma okazję zaobserwować, jak wygląda praca na obiektach. Dzięki temu zyskuje ogromne możliwości w automatyzacji żmudnych zadań administracyjnych oraz ogromne pole do popisu w tworzeniu skomplikowanych i wydajnych skryptów.

PowerShell zawiera wbudowany moduł pomocy dla poszczególnych poleceń. Warto czasem sięgnąć do niego. Środowisko to nie jest proste i zanim przejdziemy do pisania skryptów przejrzenie dodatkowych materiałów może okazać się konieczne. Stworzone skrypty wywołuje się w powłoce w ten sam sposób, w jaki wywoływane są komendy języka.

 Do początku strony

Coś, co masz...

Aby rozpocząć zabawę ze środowiskiem PowerShell, najpierw należy je pobrać ze strony Microsoft: https://www.microsoft.com/technet/scriptcenter/topics/msh/download.mspx (j.ang.) lub w przypadku systemu Windows Server 2008, gdzie PowerShell jest komponentem systemowym, zainstalować poprzez Features.

 Do początku strony

Pomijając „domyślne”

Dlaczego uruchamiamy konsolę? Zwykle po to, aby wykonać jakieś zadanie, niekoniecznie związane z bezpieczeństwem. Nie zmienia to faktu, że mamy w tym jakiś cel i aby cokolwiek wykonać, PowerShell musi być włączony. To pewna forma zabezpieczeń, czyż nie? W PowerShell oprócz tej wysublimowanej formy zabezpieczeń jest jeszcze kilka innych, które zapobiegają wykorzystaniu możliwości konsoli przez szereg osób, które nie mają dobrych intencji.

 Do początku strony

Gdzie jestem i jakie mam uprawnienia?

Pierwszym poważnym zabezpieczeniem jest fakt, że PowerShell nie uruchami skryptów w domyślnej bieżącej ścieżce, w której się one znajdują. Dzieje się tak dlatego, że większość oprogramowania typu „malware” (złośliwy kod) jest uruchamianych w folderze domyślnym („./”), wykorzystując potrzebne przełączniki poleceń (cmdlets). Dla przykładu, jeśli oprogramowanie typu „malware” będzie próbowało uruchomić skrypt bufferoverflow.ps1 w folderze: C:\Malware, trzeba będzie podać całą ścieżkę, w której dany skrypt się znajduje. Nawet w przypadku, gdy bieżącą ścieżką będzie folder C:\Malware (rys. 1.).

Rys. 1. Uruchamianie skryptów w bieżącym folderze.

Niepodpisane skrypty nie będą uruchamiane w konsoli PowerShell, jeśli nie zmieni się polityk wykonywania skryptów. W przeciwnym razie otrzymamy komunikat konsoli widoczny na rys. 2.

Rys. 2. Uruchamianie niepodpisanych skryptów.

Warto dowiedzieć się, jaka obowiązuje polityka wykonywania skryptów w danym momencie. Aby tego dokonać należy w konsoli wypisać polecenie: get-executionpolicy. Domyślnie przyjmuje ona wartość Restricted, czyli nie można uruchamiać żadnych skryptów z żadnego miejsca. Czyż nie jest to podwyższony poziom bezpieczeństwa? To od użytkownika zależy, jaką politykę wykonywania skryptów przyjmie. Wyróżnia się następujące polityki wykonywania skryptów (ExecutionPolicy):

• Restricted - to domyślna polityka w środowisku PowerShell. Przy tej polityce działają tylko osobne komendy, a skrypty *.ps1 lub ps1xml nie uruchamiają się.
• AllSigned - polityka ta umożliwia uruchamianie skryptów, które zostały podpisane przez zaufanego wydawcę. Obejmuje również skrypty utworzone na komputerze lokalnym.
• RemoteSigned - polityka ta umożliwia uruchamianie niepodpisanych skryptów pochodzących z lokalnego komputera, skrypty ściągnięte z Internetu (np. poprzez aplikacje Internet Explorer i Microsoft Outlook) muszą być podpisane przez zaufanego wydawcę. Najlepiej sprawdza się ona w praktyce.
• Unrestricted - polityka ta umożliwia uruchamianie niepodpisanych skryptów. Skrypty pobrane z Internetu wyświetlą odpowiednią notę o pochodzeniu.

 Do początku strony

Ryzyko zminimalizowane

Po zainstalowaniu konsoli PowerShell uruchamianie jakichkolwiek skryptów jest zabronione. Czyżby? Na potrzeby tego artykuły zostało wykonane kilka prostych testów, emulujących zachowania zdeterminowanych użytkowników:

• Test 1. Dwukrotne kliknięcie. Dwukrotne kliknięcie pliku z rozszerzeniem PowerShell, czyli *.ps1 powoduje, że plik ten otwiera się w Notatniku.
• Test 2. Opcja „Open with”, następnie wybranie: PowerShell.EXE powoduje wyświetlenie komunikatu widocznego w Przykładzie 2.
• Test 3. Zmiana domyślnej aplikacji uruchamiania. Efekt ten sam co w teście nr 2.
• Test 4. Uruchomienie skryptu z konsoli PowerShell, wpisanie bufferoverflow.ps1 powoduje, że otrzymujemy komunikat widoczny na rysunku 1.
• Test 5. Uruchomienie skryptu z konsoli PowerShell, wpisanie .\bufferoverflow.ps1 lub całej ścieżki powoduje, że otrzymujemy komunikat widoczny na rysunku nr 2.

Za każdym razem otrzymujemy komunikat, że wykonywanie skryptów na komputerze lokalnym jest zabronione (rys. 2.) oraz co należy zrobić, aby umożliwić ich wykonywanie. Istnieje oczywiście wiele innych metod uruchamiania skryptów. Można to potraktować jako wyzwanie. Microsoft jednak zapewnia, że jakiejkolwiek nie podejmiemy próby, przy ustawionej polityce Restricted, nie będzie to możliwe.

 Do początku strony

Zmiana uprawnień

Aby skonfigurować odpowiednią politykę wystarczy podać jej nazwę, jako parametr polecenia set-ExecutionPolicy: set-ExecutionPolicy RemoteSigned

Uruchamiając ten sam skrypt z podaniem pełnej ścieżki otrzymamy efekt widoczny na rys. nr 3.

Rys. 3. Uruchomienie skryptu bufferoverflow.ps1.

Polecenie set-ExecutionPolicy

Oprócz wykorzystanego już parametru (cmdlet) ExecutionPolicy, w którym podajemy typ polityki, jaki chcemy zastosować, istnieją następujące parametry:

• whatif - pokazuje zmianę, jaka zostanie dokonana przy użyciu tego polecenia, ale nic w efekcie nie jest zmieniane (rys. 4.).

  

  Rys. 4. Polecenie set-executionpolicy z parametrem -whatif.

• confirm - wymaga potwierdzenia zmian (analogia do User Account Control). Efekt działania tego parametru widoczny jest na rysunku nr 5.

  

  Rys. 5. Polecenie set-executionpolicy z parametrem -confirm.

Zmiana ustawień ExecutionPolicy

Może być również wykonana przez narzędzie Registry Editor (Edytor Rejestru). Potrzebne są do tego uprawnienia administratora (rys. 6.).

Rys. 6. Zmiana ustawień polityki dla PowerShell w Edytorze Rejestru.

Ustawienia polityki wykonywania skryptów w PowerShell znajdują się w następującym kluczu rejestru:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

Wartość ExecutionPolicy przyjmuje te same parametry, co w konsoli, czyli: Restricted, AllSigned, RemoteSigned, Unrestricted.

Podobne ustawienia można zmienić przy wykorzystaniu Group Policy. Można w tym celu utworzyć swój szablon ADM lub pobrać go ze strony Microsoft:

https://www.microsoft.com/downloads/details.aspx?FamilyID=2917a564-dbbc-4da7-82c8-fe08b3ef4e6d&DisplayLang=en#QuickInfoContainer (j.ang.)

Paczkę admFiles_PowerShell.msi należy zainstalować, a następnie w przystawce Group Policy Object Editor zaimportować szablon PowerShellExtensionPolicy.ADM ze ścieżki C:\Program Files\Microsoft Group Policy.

Polityka dla PowerShell będzie się znadowała w węzłach:

• Computer Configuration\Administrative Templates\Windows Components\Windows PowerShell (Przykład 7)
• User Configuration\Administrative Templates\Windows Components\Windows PowerShell

Rys. 7. Przystawka Group Policy Object Editor z polityką PowerShell.

Dostępne ustawienia polityk nazywają się nieco inaczej niż polityki w konsoli PowerShell:

• Allow only signed scripts -> AllSigned;
• Allow local scripts and remote signed scripts -> RemoteSigned;
• Allow all scripts -> Unrestricted;
• Ustawienie Disabled (“No scripts allowed”) -> Restricted.

 Do początku strony

Strategia przypisywania uprawnień

Warto się zastanowić, co się stanie, gdy zamapuje się dysk zdalny do folderu lokalnego. Skrypt znajdujący się w takim folderze będzie traktowany, jako zdalny. Oznacza to, że jeśli zaaplikowano politykę RemoteSigned, skrypt ten będzie można uruchomić bez większych problemów. Istnieje wiele podobnych scenariuszy, w których administrator powinien wykazać się dużą świadomością w nadawaniu odpowiednich polityk wybranym użytkownikom.

Administrator taki powinien również przed podjęciem jakiejkolwiek decyzji, przeanalizować scenariusze biznesowe przedsiębiorstwa, włączając w to zagadnienia związane z fizycznym dostępem do zasobów.

Ogólnie jednak przyjęto, że:

1. Programiści PowerShell powinni posiadać politykę Unrestricted lub RemoteSigned. Obydwie polityki zapewniają odpowiedni poziom ochrony.

   • W Unrestricted przy uruchamianiu skryptu pobranego z Internetu użytkownik otrzyma komunikat ostrzegawczy.
   • W RemoteSigned można uruchamiać tylko te skrypty pobrane z Internetu, którego wydawcy użytkownik ufa. Skrypty utworzone lokalnie, czyli te, których użytkownik jest autorem, uruchamiają się bez ograniczeń. Ciężko sobie wyobrazić programistę, który nie może pracować ze skryptami. Dlatego pomimo iż polityki te zwiększają nieco poziom ryzyka, to jednak stanowią pewien komfort pracy umożliwiający działania z konsolą PowerShell.

2. Administratorzy nie mają zwykle potrzeby tworzenia i ciągłego uruchamiania wszelkiego rodzaju skryptów. Zaleca się więc przypisanie im polityki AllSigned lub RemoteSigned, gdyż najprawdopodobniej nigdy nie będą czuli potrzeby skorzystania z polityki mniej restrykcyjnej, a dodatkowo uchroni ich to przed uruchamianiem skryptów, których źródła pochodzenia nie są pewne.

3. Użytkownicy końcowi nie maja potrzeby uruchamiania skryptów, najprawdopodobniej też nie znają języka PowerShell na poziomie budzącym zaufanie administratora lub programisty.

   Warto więc przypisać im politykę Restricted lub AllSigned. Pozwolę sobie w tym miejscu przytoczyć znaną wszystkim parafrazę, że najsłabiej zabezpieczony element wyznacza poziom zabezpieczeń w całym przedsiębiorstwie, podobnie jak niezbadane są działania użytkowników.

 Do początku strony

Kulisy podpisywania

Dodanie podpisu pod skryptem wymaga podpisania skryptu przez certyfikat podpisywania. Do tego celu można wykorzystać dwa typu certyfikatów: certyfikat stworzony przez zaufanego wydawcę (Certification Authority) takiego, jak np. Verisign, lub certyfikat stworzony przez użytkownika (ang. self-signed certificate).

Jeśli skrypty są tworzone tylko na użytek własny nie ma sensu inwestować w certyfikat do podpisywania od oficjalnych wydawców. W certyfikacie użytkownika zaufanym wydawcą jest komputer, z którego dany certyfikat pochodzi. Wadą tego rozwiązania jest fakt, że certyfikat PowerShell musi być zainstalowany na wszystkich komputerach, które chcą uruchomić skrypt podpisany tym certyfikatem. Aby utworzyć taki certyfikat wystarczy skorzystać z programu makecert.exe. Program ten dostępny jest w pakietach Microsoft .NET Framework SDK lub Microsoft Windows Platform SDK:

https://www.microsoft.com/downloads/details.aspx?familyid=fe6f2099-b7b4-4f47-a244-c96d69c35dec&displaylang=en (j.ang.)

Po zainstalowaniu program makecert.exe znajduje się w ścieżce: „C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin\”. Jest on programem wiersza poleceń. Należy więc w takim środowisku go uruchomić, podając odpowiednie parametry w celu utworzenia certyfikatu służącego dla PowerShell. Polecenie powinno wyglądać następująco:

C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin>makecert -n CN=PowerShell -a sha1 -eku 1.3.6.1.5.5.7.3.3 -r -sv root.pvk root.cer -ss Root -sr localMachine (rys. 8.).

Rys. 8. Utworzenie certyfikatu użytkownika.

Po zatwierdzeniu powyższego polecenia pojawi się okno zawierające prośbę o ustalenie hasła do klucza prywatnego, widoczne na rys. 9.

Rys. 9. Ustalenie hasła do klucza prywatnego.

Po kliknięciu OK pojawi się komunikat z prośbą o podanie już utworzonego hasła do klucza prywatnego. Po wpisaniu hasła należy kliknąć OK (rys. 10.).

Rys. 10. Prośba o podanie hasła do klucza prywatnego.

Certyfikat do podpisywania kodu znajduje się w kontenerze Trusted Root Certification Autrorities (rys. 11.), a w jego treści można odczytać do czego jest przeznaczony (rys. 12.).

Rys. 11. Certyfikat PowerShell znajdujący się w węźle: Trusted Root Certification Authorities.

Rys. 12. Wygenerowany certyfikat Certification Authority.

Kolejnym krokiem jest wygenerowanie certyfikatu użytkownika. Można tego dokonać przy użyciu następującego polecenia:

C:\Program Files\Microsoft Visual Studio 8\SDK\v2.0\Bin>makecert -pe -n "CN=PowerShell User" -ss MY -a sha1 -eku 1.3.6.1.5.5.7.3.3 -iv root.pvk -ic root.cer (rys. 14.).

Zatwierdzenie powyższego polecenia uruchomi okno widoczne na rys. 13., w którym użytkownik musi podać hasło do swojego klucza prywatnego.

Rys. 13. Podanie hasła do klucza prywatnego użytkownika.

Podanie hasła i kliknięcie OK zamyka okno, w konsoli natomiast pojawia się informacja Succeeded zwiastująca poprawne utworzenie certyfikatu (rys. 14.).

Rys. 14. Certyfikat użytkownika utworzony prawidłowo.

Warto zweryfikować poprawność certyfikatu, sprawdzając jego właściwości w konsoli Certyfikaty. Certyfikat użytkownika znajduje się w kontenerze Personal\Certificates (rys. 15.), klikając na niego dwukrotnie można zweryfikować, do czego jest przeznaczony (rys. 16.).

Rys. 15. Certyfikat użytkownika w kontenerze Personal\Certificates.

Rys. 16. Wygenerowany certyfikat użytkownika PowerShell.

Podobne informacje można uzyskać w konsoli PowerShell przy wykorzystaniu polecenia:

get-childitem cert:\CurrentUser\My -codesinging

W wyniku powyższego polecenia wyświetlany jest także tzw. Thumbprint (heksadecymalny ciąg znaków będący wynikiem działania funkcji skrótu SHA-1 dla certyfikatu - zwany odciskiem palca).

Rys. 17. Sprawdzenie, czy certyfikat został utworzony poprawnie.

Rysunek 18. ilustruje operację przypisania polityki AllSigned, próbę uruchomienia niepodpisanego skryptu oraz podpisanie skryptu. Skrypt został podpisany przy wykorzystaniu następującego polecenia PowerShell:

set-AuthenticodeSignature C:\Malware\bufferoverflow.ps1 @(get-childitem cert:\CurrentUser\My -codesigning)[0]

Warto skierować uwagę na zwracane informacje. W wyniku otrzymuje się Thumbprint certyfikatu wykorzystanego do podpisania oraz status certyfikatu. Jako ciekawostkę polecam wpisanie polecenia get-Command -pssnapit *security - jest to przystawka bezpieczeństwa PowerShell (Windows PowerShell Security snap-in). Polecenie to wyświetla wszystkie dostępne polecenia dla przystawki, omawiane w niniejszym artykule set-Authenticodesignature.

Rys. 18. Podpisanie skryptu utworzonym certyfikatem użytkownika do podpisywania.

Polecenie set-Authenticodesignature umieszcza podpis w treści skryptu (rys. 19). Dodatkowo polecenie to posiada następujące parametry:

• FilePath - określa miejsce, w którym znajduje się plik do podpisania.
• Certificate - określa certyfikat, jaki ma być wykorzystany do podpisania (do wyszukania certyfikatu można wykorzystać dysk „Cert:” wpisując polecenie: set-Location Cert: lub set-Location -path Cert:\LocalMachine\Root jeśli użytkownik chce się znaleźć w folderze certyfikatu Root’a, a dla certyfikatów użytkownika: get-Childitem -path cert:\CurrentUser).
• IncludeChain - określa, które certyfikaty znajdujące się w relacji zaufania z certyfikatem podpisującym będą zawarte w podpisie. Domyślnie zawarte są wszystkie z wyjątkiem certyfikatu Root’a.
• TimeStampServer - określa serwer timestamp (znacznik czasu) dla podpisu. Znacznik czasu definiuje czas, w którym dodano podpis dla skryptu (dzięki temu można ustalić, czy certyfikat był ważny w trakcie podpisywania).
• Whatif - pokazuje zmianę, jaka zostanie dokonana przy użyciu tego polecenia, ale nic w efekcie nie jest zmieniane.
• Confirm - wymaga potwierdzenia zmian.
• Force - nadpisuje ustawienia, które nie pozwalają wykonać polecenia.

Skrypt niepodpisany jest pozbawiony fragmentu odpowiedzialnego za podpis (między znacznikami „# SIG”). Aby móc taki skrypt uruchomić certyfikat PowerShell Certificate Authority (wydawcy) musi być zainstalowany na komputerach użytkowników. W tym celu certyfikat musi zostać wyeksportowany, np. poprzez konsolę Certyfikaty, a następnie zaimportowany na innych stacjach roboczych.

Rys. 19. Zawartość podpisanego skryptu.

Za pomocą polecenia get-AuthenticodeSignature -filePath „C:\Malware\bufferoverflow.ps1” można również wyświetlić informacje o podpisie skryptu.

Podpisany skrypt można uruchomić dwukrotnie na niego klikając. Pod warunkiem, że zmieniono domyślną aplikację uruchamiania z Notatnika na PoweShell. Użytkownik otrzyma komunikat, z zapytaniem, czy zamierza otworzyć skrypt od niezaufanego wydawcy. Jeśli użytkownik wybierze R (Run Once), to za każdym razem, kiedy będzie próbował uruchomić ten sam skrypt, będzie otrzymywał komunikat widoczny na rysunku 20.

Rys. 20. Uruchomienie podpisanego skryptu (dwukrotne kliknięcie).

Skrypt można uruchomić również z konsoli PowerShell (rys. 21.), podając do niego pełną ścieżkę lub wywołując przy podaniu parametrów: ./ - otrzymuje się ten sam komunikat co w przypadku dwukrotnego kliknięcia. Jeśli użytkownik wybierze A (Always Run), więcej tego komunikatu nie otrzyma, a w kontenerze Trusted Publishers\Certificates pojawi się certyfikat właściciela skryptu (rys. 22.).

Rys. 21. Uruchomienie podpisanego skryptu (konsola).

Rys. 22. Certyfikat użytkownika w kontenerze Trusted Publishers\Certificates.

 Do początku strony

Podsumowanie

PowerShell jest nowym środowiskiem skryptowym umożliwiającym zarówno automatyzację wielu procesów systemowych, jak i administrację najnowszymi produktami Micorosft, w tym Exchange Server 2007 oraz System Center Operations Manager 2007. Zakres działań, jakie można przeprowadzić przy wykorzystaniu PowerShell, jest ogromny. Dlatego ze względów bezpieczeństwa, warto zastanowić się nad politykami uruchamiania skryptów dla użytkowników, jak i dla siebie. Domyślną polityką uruchamiania skryptów jest Restricted. Stan ten jest na początek doskonałą metodą ochrony, podobnie jak ustawienie Notatnika jako domyślną aplikację uruchamiania, czy konieczność odwołania się do pełnej ścieżki skryptu (lub ./). Nie należy zapominać, że politykami PowerShell można zarządzać przez konsolę Group Policy. Należy pamiętać, że zmieniając domyślną politykę zwiększa się stopień narażenia na zagrożenia, jakie wynikają z uruchomienia niepodpisanych lub pochodzących z nieznanego źródła skryptów.

Do początku strony

---