W części pierwszej (
Jest ona związana z listą DFT (Designated File Types) i Funkcją API ShellExecute(). Jeśli rozszerzenie pliku jest na liście DFT, wtedy ShellExecute() może zablokować otwarcie/uruchomienie pliku.
Blokowanie plików przez ShellExecute() chroni użytkownika przed nieumyślnym lub przypadkowym otwarciem pliku zawierającego złośliwy kod wykonywalny, ale pliki mogą być bez problemu otwierane przez system za pomocą komend.
Dla przykładu, w ten sposób możemy uruchomić plik HTA używając komendy:
'mshta.exe %Userprofile%\Desktop\JakZostaćBogatym.hta'.
Wtedy funkcja ShellExecute() zostanie zignorowana i SRP nie będą wiedzieć, że mamy zamiar cokolwiek uruchomić.
W tym przypadku Windows ma do wyboru dwie możliwości:
1. Pozwolić na otwarcie/uruchomienie pliku.
2. Zastosować inny mechanizm interakcji z SRP
W większości przypadków Windows wybiera sposób nr 1. Czyli, użytkownicy nie mogą otwierać plików umiejscowionych w ‘Przestrzeni Użytkownika’, klikając na ikonę pliku na Pulpicie, wciskając <Enter>, wybierając opcję ‘Otwórz’ lub ‘Otwórz za pomocą ...’ z menu kontekstowego Eksploratora Windows. Stanowi to ochronę przed otwieraniem złośliwych plików z podwójnym rozszerzeniem jak np. CzytajMnie.pdf.exe (z ikonką pliku PDF). Można oczywiście próbować go otworzyć za pomocą Przeglądarki PDF, ale wtedy przeglądarka pokaże błąd (pliki exe nie mają formatu pdf) i plik CzytajMnie.pdf.exe nie zostanie uruchomiony. Jednak nadal wiele plików można uruchomić używając komend odwołujących się do systemowych plików wykonywalnych.
W kilku ważnych przypadkach Microsoft wybrał sposób nr 2. 'Uprzywilejowanymi Obiektami' są: ‘Windows CMD’, ‘Windows Script Host’ i ‘Windows Installer’. Mają one zaprogramowaną zdolność wysyłania zapytań do SRP, dot. obsługiwanych plików. Tak więc w przypadku pliku JakZostaćBogatym.vbs, może on zostać zablokowany, ponieważ ‘Windows Script Host’ wyśle zapytanie do SRP.
Warto zauważyć, że integracja ‘Windows CMD’, ‘Windows Script Host’ i ‘Windows Installer’ z SRP, działa w sposób niezależny i bardziej dogłębny niż ShellExecute() + lista DFT. Dla przykładu plik JakZostaćBogatym.vbs może być uruchomiony poprzez: (A) kliknięcie myszką na ikonkę na Pulpicie, (B) wykonanie komendy 'wscript.exe %Userprofile%\JakZostaćBogatym.vbs'. Jeśli rozszerzenie VBS jest na liście DFT to:
* ShellExecute() potrafi zablokować (A) ale nie (B)
* 'Uprzywilejowane Obiekty' mogą zablokować zarówno (A) jak i (B).
Ktoś może zadać pytanie, po co komu zabezpieczenie przeciwko (B). Przecież użytkownicy otwierają/uruchamiają pliki w sposób (A), czyli poprzez klikanie myszką lub wciśnięcie klawisza Enter (w Eksploratorze Windows), ewentualnie używając menu kontekstowego Eksploratora z opcjami 'Otwórz' lub 'Otwórz za pomocą...'. To prawda, lecz autorun.inf na pendrivie lub DVD, potrafi wywołać wykonywanie komend. Podobnie, gdy luka w systemie lub aplikacji zostanie wykorzystana przez złośliwy program typu exploit. Tego typu zabezpieczenie jest więc istotne i skierowane przeciwko atakom typu 'Drive By'.
Z powyższych ustaleń wynika, że skrypty: BAT, CMD, JS, JSE, VBS, VBS, WSF, WSH oraz pliki MSI mogą być blokowane przez SRP na dwa niezależne sposoby:
* w oparciu o rozszerzenie pliku (ShellExecute() + lista DFT)
* przez 'Uprzywilejowane Obiekty' (Windows CMD, 'Windows Script Host' i 'Windows Installer').
To samo dotyczy plików COM i SCR, które używają funkcji ShellExecute() do stwierdzenia, że w rzeczywistości są tylko specjalnymi plikami typu EXE. W przypadku 16 Bitowych plików COM i EXE, są one uruchamiane w podsystemie NTVDM (emulator MS-DOS), który jest zainstalowany tylko w 32 Bitowych wersjach Windows.
Natywne pliki wykonywalne Windows: tj. pliki EXE (16Bit i 32Bit), są zawsze uruchamiane bez zapytań ShellExecute(). Zamiast tego, używana jest funkcja API CreateProcess(), która integruje się z SRP, aby blokować pliki EXE (COM, SCR)."
Jest jeszcze jedna funkcja API zintegrowana z SRP. LoadLibrary() jest używana przez system, gdy plik typu EXE próbuje załadować binarne biblioteki (pliki typu DLL lub OCX). SRP mogą być skonfigurowane, zarówno do blokowania, jak i zezwalania na ładowanie bibliotek z określonych lokalizacji. W ten sposób SRP mogą powstrzymać wiele ataków, w których używane są biblioteki zawierające złośliwy kod np. (ścieżki plików zostały dla prostoty ominięte):
InstallUtil.exe /logfile= /LogToConsole=false /U malicious.dll
regsvcs.exe virus.dll
regasm.exe /U virus.dll
regsvr32 /s /u virus.dll
regsvr32 /s virus.dll
rundll32 virus.dll,EntryPoint
W SRP występują trzy ustawienia Wymuszania (Enforcement settings):
* 'Nie Wymuszaj (No Enforcement) - ignoruje: listę DFT i zapytania ShellExecute() + CreateProcess() + LoadLibrary(). SRP odpowiadają tylko na zapytania 'Windows CMD', 'Windows Script Host' i 'Windows Installer' (minimalny poziom monitorowania).
* 'bez DLL/OCX’ (Skip DLLs) - ignoruje tylko zapytania LoadLibrary() - odpowiada na zapytania: lista DFT + ShellExecute() + CreateProcess() + 'Windows CMD' + 'Windows Script Host' + 'Windows Installer'.
* 'Wszystkie pliki...' (All files) - odpowiada na wszystkie zapytania (maksymalny poziom monitorowania).
Ograniczenia SRP realizowane przez: CreateProcess(), LoadLibrary(), Windows CMD, Windows Script Host, and Windows Installer, działają nawet jeśli zmienimy rozszerzenie pliku (np. na niewinne TXT).
Wymuszanie w ustawieniu 'Wszystkie pliki...' daje maksymalny poziom bezpieczeństwa, jednak trzeba przy tym pamiętać, że wszystkie używane biblioteki w 'Przestrzeni Użytkownika' (= poza katalogami: 'Windows' i 'Program Files' oraz 'Program Files (x86)' dla wersji 64Bit) muszą być dodane do 'Białej Listy'. W przeciwnym wypadku programy, które je używają nie będą działały poprawnie.
Przykład.
Załóżmy, że mamy następującą listę ‘Designated File Types’:
WSC, WS, VB, URL, SHS, SCT, SCR, REG, PIF, PCD, OCX, MST, MSP, MSC, MDE, MDB, LNK, JAR, ISP, INS, INF, HTA, HLP, EXE, DLL, CRT, CPL, COM, CMD, CHM, BAS, ADP, ADE
Przy ustawieniu <Wymuszanie> = ‘Nie Wymuszaj’ żaden z powyższych typów plików nie będzie monitorowany, gdyż lista ‘Designated File Types’ w tym ustawieniu jest nieaktywna i dodatkowo SRP ignorują funkcje CreateProcess() i LoadLibrary. Monitorowane będą tylko skrypty BAT, CMD, JS, JSE, VBS, VBE, WSF, WSH oraz pliki MSI dzięki integracji ‘Windows CMD’, ‘Windows Script Host’ i 'Windows Installer' z SRP.
Jeśli zmienimy ustawienia na <Wymuszanie> = ‘bez DLL/OCX’ (‘Wszystkie pliki oprócz bibliotek’), monitorowane będą wszystkie powyższe typy plików z listy ‘Designated File Types’, a także skrypty BAT, CMD, JS, JSE, VBS, VBE, WSF, WSH oraz pliki MSI. Monitorowanie DLL/OCX będzie jednak bardzo niepełne, gdyż przy tym ustawieniu wymuszania, funkcja LoadLibrary() jest ignorowana przez SRP.
W Windows Pro, oprócz powyższych ustawień 'Wymuszania', istnieją dwie dodatkowe opcje:
Koniec części 2.
W części 3 omówię reguły Białej/Czarnej listy i Poziomy zabezpieczeń SRP - czyli etap, na którym SRP podejmują ostateczną decyzję czy monitorowane pliki trzeba blokować czy też przepuścić.
[/list]
[Aby zobaczyć linki, zarejestruj się tutaj]
) opisałem pierwszą warstwę ochrony SRP.Jest ona związana z listą DFT (Designated File Types) i Funkcją API ShellExecute(). Jeśli rozszerzenie pliku jest na liście DFT, wtedy ShellExecute() może zablokować otwarcie/uruchomienie pliku.
Blokowanie plików przez ShellExecute() chroni użytkownika przed nieumyślnym lub przypadkowym otwarciem pliku zawierającego złośliwy kod wykonywalny, ale pliki mogą być bez problemu otwierane przez system za pomocą komend.
Dla przykładu, w ten sposób możemy uruchomić plik HTA używając komendy:
'mshta.exe %Userprofile%\Desktop\JakZostaćBogatym.hta'.
Wtedy funkcja ShellExecute() zostanie zignorowana i SRP nie będą wiedzieć, że mamy zamiar cokolwiek uruchomić.
W tym przypadku Windows ma do wyboru dwie możliwości:
1. Pozwolić na otwarcie/uruchomienie pliku.
2. Zastosować inny mechanizm interakcji z SRP
W większości przypadków Windows wybiera sposób nr 1. Czyli, użytkownicy nie mogą otwierać plików umiejscowionych w ‘Przestrzeni Użytkownika’, klikając na ikonę pliku na Pulpicie, wciskając <Enter>, wybierając opcję ‘Otwórz’ lub ‘Otwórz za pomocą ...’ z menu kontekstowego Eksploratora Windows. Stanowi to ochronę przed otwieraniem złośliwych plików z podwójnym rozszerzeniem jak np. CzytajMnie.pdf.exe (z ikonką pliku PDF). Można oczywiście próbować go otworzyć za pomocą Przeglądarki PDF, ale wtedy przeglądarka pokaże błąd (pliki exe nie mają formatu pdf) i plik CzytajMnie.pdf.exe nie zostanie uruchomiony. Jednak nadal wiele plików można uruchomić używając komend odwołujących się do systemowych plików wykonywalnych.
W kilku ważnych przypadkach Microsoft wybrał sposób nr 2. 'Uprzywilejowanymi Obiektami' są: ‘Windows CMD’, ‘Windows Script Host’ i ‘Windows Installer’. Mają one zaprogramowaną zdolność wysyłania zapytań do SRP, dot. obsługiwanych plików. Tak więc w przypadku pliku JakZostaćBogatym.vbs, może on zostać zablokowany, ponieważ ‘Windows Script Host’ wyśle zapytanie do SRP.
Warto zauważyć, że integracja ‘Windows CMD’, ‘Windows Script Host’ i ‘Windows Installer’ z SRP, działa w sposób niezależny i bardziej dogłębny niż ShellExecute() + lista DFT. Dla przykładu plik JakZostaćBogatym.vbs może być uruchomiony poprzez: (A) kliknięcie myszką na ikonkę na Pulpicie, (B) wykonanie komendy 'wscript.exe %Userprofile%\JakZostaćBogatym.vbs'. Jeśli rozszerzenie VBS jest na liście DFT to:
* ShellExecute() potrafi zablokować (A) ale nie (B)
* 'Uprzywilejowane Obiekty' mogą zablokować zarówno (A) jak i (B).
Ktoś może zadać pytanie, po co komu zabezpieczenie przeciwko (B). Przecież użytkownicy otwierają/uruchamiają pliki w sposób (A), czyli poprzez klikanie myszką lub wciśnięcie klawisza Enter (w Eksploratorze Windows), ewentualnie używając menu kontekstowego Eksploratora z opcjami 'Otwórz' lub 'Otwórz za pomocą...'. To prawda, lecz autorun.inf na pendrivie lub DVD, potrafi wywołać wykonywanie komend. Podobnie, gdy luka w systemie lub aplikacji zostanie wykorzystana przez złośliwy program typu exploit. Tego typu zabezpieczenie jest więc istotne i skierowane przeciwko atakom typu 'Drive By'.
Z powyższych ustaleń wynika, że skrypty: BAT, CMD, JS, JSE, VBS, VBS, WSF, WSH oraz pliki MSI mogą być blokowane przez SRP na dwa niezależne sposoby:
* w oparciu o rozszerzenie pliku (ShellExecute() + lista DFT)
* przez 'Uprzywilejowane Obiekty' (Windows CMD, 'Windows Script Host' i 'Windows Installer').
To samo dotyczy plików COM i SCR, które używają funkcji ShellExecute() do stwierdzenia, że w rzeczywistości są tylko specjalnymi plikami typu EXE. W przypadku 16 Bitowych plików COM i EXE, są one uruchamiane w podsystemie NTVDM (emulator MS-DOS), który jest zainstalowany tylko w 32 Bitowych wersjach Windows.
Natywne pliki wykonywalne Windows: tj. pliki EXE (16Bit i 32Bit), są zawsze uruchamiane bez zapytań ShellExecute(). Zamiast tego, używana jest funkcja API CreateProcess(), która integruje się z SRP, aby blokować pliki EXE (COM, SCR)."
Jest jeszcze jedna funkcja API zintegrowana z SRP. LoadLibrary() jest używana przez system, gdy plik typu EXE próbuje załadować binarne biblioteki (pliki typu DLL lub OCX). SRP mogą być skonfigurowane, zarówno do blokowania, jak i zezwalania na ładowanie bibliotek z określonych lokalizacji. W ten sposób SRP mogą powstrzymać wiele ataków, w których używane są biblioteki zawierające złośliwy kod np. (ścieżki plików zostały dla prostoty ominięte):
InstallUtil.exe /logfile= /LogToConsole=false /U malicious.dll
regsvcs.exe virus.dll
regasm.exe /U virus.dll
regsvr32 /s /u virus.dll
regsvr32 /s virus.dll
rundll32 virus.dll,EntryPoint
W SRP występują trzy ustawienia Wymuszania (Enforcement settings):
* 'Nie Wymuszaj (No Enforcement) - ignoruje: listę DFT i zapytania ShellExecute() + CreateProcess() + LoadLibrary(). SRP odpowiadają tylko na zapytania 'Windows CMD', 'Windows Script Host' i 'Windows Installer' (minimalny poziom monitorowania).
* 'bez DLL/OCX’ (Skip DLLs) - ignoruje tylko zapytania LoadLibrary() - odpowiada na zapytania: lista DFT + ShellExecute() + CreateProcess() + 'Windows CMD' + 'Windows Script Host' + 'Windows Installer'.
* 'Wszystkie pliki...' (All files) - odpowiada na wszystkie zapytania (maksymalny poziom monitorowania).
Ograniczenia SRP realizowane przez: CreateProcess(), LoadLibrary(), Windows CMD, Windows Script Host, and Windows Installer, działają nawet jeśli zmienimy rozszerzenie pliku (np. na niewinne TXT).
Wymuszanie w ustawieniu 'Wszystkie pliki...' daje maksymalny poziom bezpieczeństwa, jednak trzeba przy tym pamiętać, że wszystkie używane biblioteki w 'Przestrzeni Użytkownika' (= poza katalogami: 'Windows' i 'Program Files' oraz 'Program Files (x86)' dla wersji 64Bit) muszą być dodane do 'Białej Listy'. W przeciwnym wypadku programy, które je używają nie będą działały poprawnie.
Przykład.
Załóżmy, że mamy następującą listę ‘Designated File Types’:
WSC, WS, VB, URL, SHS, SCT, SCR, REG, PIF, PCD, OCX, MST, MSP, MSC, MDE, MDB, LNK, JAR, ISP, INS, INF, HTA, HLP, EXE, DLL, CRT, CPL, COM, CMD, CHM, BAS, ADP, ADE
Przy ustawieniu <Wymuszanie> = ‘Nie Wymuszaj’ żaden z powyższych typów plików nie będzie monitorowany, gdyż lista ‘Designated File Types’ w tym ustawieniu jest nieaktywna i dodatkowo SRP ignorują funkcje CreateProcess() i LoadLibrary. Monitorowane będą tylko skrypty BAT, CMD, JS, JSE, VBS, VBE, WSF, WSH oraz pliki MSI dzięki integracji ‘Windows CMD’, ‘Windows Script Host’ i 'Windows Installer' z SRP.
Jeśli zmienimy ustawienia na <Wymuszanie> = ‘bez DLL/OCX’ (‘Wszystkie pliki oprócz bibliotek’), monitorowane będą wszystkie powyższe typy plików z listy ‘Designated File Types’, a także skrypty BAT, CMD, JS, JSE, VBS, VBE, WSF, WSH oraz pliki MSI. Monitorowanie DLL/OCX będzie jednak bardzo niepełne, gdyż przy tym ustawieniu wymuszania, funkcja LoadLibrary() jest ignorowana przez SRP.
W Windows Pro, oprócz powyższych ustawień 'Wymuszania', istnieją dwie dodatkowe opcje:
- 'Zastosuj zasady ograniczeń oprogramowania do następujących użytkowników:' z dwoma ustawieniami: (1) Wszyscy użytkownicy, oraz (2) Wszyscy użytkownicy oprócz administratorów lokalnych.
Określają one czy SRP kontrolują uruchamianie plików z uprawnieniami Administratora, czy nie. W Windows Vista i nowszych wersjach preferowane jest drugie rozwiązanie, z uwagi na wprowadzenie Kontroli Konta Użytkownika (User Account Control, w skrócie UAC).
- 'Podczas stosowania zasad ograniczeń oprogramowania:' z dwoma ustawieniami: (1) Wymuś reguły certyfikatów, oraz (2) Ignoruj reguły certyfikatów.
W Windows Home zwykle znajduje zastosowanie drugie rozwiązanie.
Koniec części 2.
W części 3 omówię reguły Białej/Czarnej listy i Poziomy zabezpieczeń SRP - czyli etap, na którym SRP podejmują ostateczną decyzję czy monitorowane pliki trzeba blokować czy też przepuścić.
[/list]
