We need to go DeEPer, czyli o bezpieczeństwie, UAC i nie tylko

Do wpisu natchnęła mnie dyskusja sprzed kilku dni z działem IT pewnej sporej firmy -(ponad 500 desktopów i laptopów) gdzie na spotkaniu omawialiśmy plan migracji z Windowsa XP do Windows 7. W środowisku tym bardzo istotne jest bezpieczeństwo systemów, więc doszło do rozpisywania za i przeciw migracji do Windows 7, lub Windows 8, oraz system 32‑bitowy vs. 64‑bitowy. W momencie, kiedy podałem argument, że 64‑bity dla Windowsa to rozsądniejsze rozwiązanie także ze względu na bezpieczeństwo, niektóry popatrzyli na mnie jak na idiotę...

Wirusy komputerowe , czyli co nam wyjada sernik z lodówki

Jeszcze kilka lat temu, tj. w czasach, kiedy MacGyver robił rakiety dalekiego zasięgu ze spinacza i długopisu a Marty McFly starał się wrócić do przyszłości, nie było tak powszechnego dostępu do internetu (może przez to, że internetj raczej jeszcze wtedy nie istniał), świadomość co do zagrożeń od strony szkodliwego oprogramowania była bardzo niska. Pod koniec lat 80‑tych programista-matematyk Ś.P. Marek Sell zauważył, że całkiem intratnym zajęciem może być pisanie programów antywirusowych - co niektórzy podejrzliwie doszli też do wniosku, że samo pisanie wirusów też może przynosić korzyści. W tym samym czasie ja, jako gówniarz masakrujący dżojstik na River Raid i Boulder Dash nie za bardzo rozumiałem, co to te wirusy i jedynie przeglądałem bazę wbudowanych w mks_vir demostracji nabijając się np. z robala zgrzytającego przez wbudowany w peceta głośnik „Precz z Wałęsą!” (Cysta.8045 ) - tak, był taki wirus i całkiem prawdopodobne, że powstał w Polsce...

Pierwszego i jedynego wirusa w mojej karierze IT złapałem około roku '96, kiedy przytargałem z giełdy komputerowej IMMORTALa. Działanie nie było aż tak destrukcyjne (w określonym dniu miesiąca przewijał się określony napis przez ekran), ale zmieniał od rozmiar plików wykonywalnych, ponieważ robal ię „doklejał” do exec'ów i com'ów. Wtedy też zacząłem trochę bardziej się tym interesować – szczególnie, co to jest przerwanie 21 (http://www.empik.com/jak-pisac-wirusy-dudek-andrzej,290277,ksiazka-p ). W obecnych czasach jako wirus komputerowy określa się każdego rodzaju szkodliwe, złośliwe oprogramowanie. Cytując Wikipedię:

Pan Marek Sell występując w telewizji starał się uświadomić, że jest wirus komputerowy to kawałek sprytnie napisanego kodu (autorzy to często genialni programiści) a nie świadomy byt, który powstał z nicości i zabłąkanych bitów. Z mojego doświadczenia w IT stwierdzam jedno – skończyły się czasy, że po powrocie do komputera w autogamiczny sposób wskoczył jakiś paskud, który skonsumował już dwa talerze z dysku twardego a na deser wysssał zawartość BIOSu. W większości sytuacji nie są to samo replikujące się programy, ale wcześniej przygotowane ataki bazujący na znanym problemie PEBKAC.

Nie chcę się w tym wpisie nad tym rozwodzić (powstanie o tym osobny tekst), ale jak większość ludzi związanych IT wie, niektórzy nie powinni mieć dostępu do komputera. Nie ważne, jakby ich edukować, nawet 15 latach pracy z klawiaturą jak ktoś im w mailu napisze:

„w celu otrzymania szybszego dostępu do twarzoksiążki proszę wejść w ten czarny ekran i wpisać "net user %username% /del"

Okno zamknięte a jednak ciągnie po nogach

Przez lata pracy z ludźmi mającymi czasem małe pojęcie o komputerach zrozumiałem, że tłumaczenie na przykładach ma ogromny sens. Czasem patrzę z przymrużeniem oka, jak na szkoleniach finansowanych z funduszy UE ludziom, którzy uważają za najbardziej skomplikowaną rzecz techniczną włączenie dekodera telewizji cyfrowej a tu nagle trzeba wytłumaczyć co to jest katalog i plik - slajdy porównują więc to do dokumentów w teczkach schowanych do szuflady. Dokładnie jest tak samo z systemem operacyjnym: jeżeli w domu o wstawienie okna poprosimy osobę, która zostawi ogromne szpary pod parapetem, dodatkowo użyje przy niskiej temperaturze złej pianki uszczelniającej to nic dziwnego, że są przeciągi a źle konserwowane uszczelki szybko parcieją i też może być mało przyjemnie w mroźne wieczory.

Dość istotna kwestia jest już podczas instalacji Windowsa dotycząca polityki edukacji użytkownika. Jesteśmy pytani o nowy login, hasło i od tego momentu większość pracuje na koncie z uprawnieniami administratora. W systemach z rodziny *nix (Ubuntu itp.) jesteśmy proszeni o podanie hasła administratora (root), a następnie utworzenie konta użytkownika 'zwykłego'. Nigdy nie mogłem zrozumieć, czemu użytkownicy działający przemienne zarówno na Linuksach, jak i Windowsach stosują dwie różne polityki - w jednym systemie restrykcyjne podejście, delikatne uruchomianie aplikacji potrzebujących większych uprawnień przez 'sudo' a magiczne 'su – root' to już całkowite igranie ze śmiercią – natomiast w przypadku Windowsa pierwsze co robią po instalacji systemu, to dodanie swojego użytkownika do grupy 'administrators' i wyłączenie wszelakich 'UAC-utrudnień', bo wyskakują, drażnią i złorzeczą...

Zejdźmy na chwilę na ziemię, bo nawet stąd słyszę szczęk ściskanych pośladów miłośników jajek Torvaldsa: tak, są oczywiście błędy Windowsa (tzw. luki zero-day), które przy braku firewalla i łatek pozwalają na zdalny, nieautoryzowany dostęp do systemu. To samo tyczy się niektórych kwestii architektury Windowsa, Internet Explorera oraz popularnych programów pisanych czasami przez ludźmi, którzy z takimi kwalifikacjami nie powinni ustawiać nawet pralki. Prawda jest natomiast taka, że od czasów Windowsa 7 (szczególnie 64‑bitowego) nie jest wcale tak źle, jeżeli oczywiście stosujemy się do pewnej 'higieny' systemu. W większości sytuacji dochodzi właśnie do infekcji na własne życzenie, tj. poprzez uruchomienie złośliwego pliku wykonywalnego... starszych wersje Internet Explorera mają strukturę dobrego czedara – w połączeniu z wirtualną maszyną Java script i  Adobe Flash, gdzie 'action script' może zostać zaprogramowany do prostego pominięcia DEP / ASLR tworzy się mieszakna wybuchowa.

UAC-sruac

UAC („User Account Control, czyli „Kontrola Konta Użyszkodnika”) to mechanizm, który wraz z wprowadzeniem Windowsa Vista wzbudził w 2006 roku pewnie więcej kontrowersji, niż 18‑latek strzelający do kolegów z klasy w Niemieckim Emsdetten. Do dzisiaj wpisując w google „UAC Windows Vista” natrafimy głównie na poradniki „jak wyłączyć to wielkie G”, ale rzadko kto dokładnie omawia mechanizm działania całkiem niegłupiego rozwiązania. Dla końcowego użytkownika kojarzy się to głównie z wyskakującymi oknami o treści typu „ar ju siur, że jesteś siur, co do tego ostatniego siur, że chcesz uruchomić Winampa?”. Mówiąc wprost – rozwiązanie, które użytkownikowi przyzwyczajonemu do Windowsa XP i niższych, mającemu nawet uprawnienia administratora nie do końca pozwalało na wszystko w systemie spotkało się z ogromną dezaprobatą a w rzeczywistości jest swego rodzaju odpowiednikiem 'sudo' znamemu np. z Linuksów. W Windows 7 handlowcy i PRowcy zmusili jednak architektów systemu do pewnych modyfikacji: „nie może tak być, żeby użytkownik musiał myśleć! Zróbcie coś z tym!”. No i w W7 rzeczywiście – jakby ciszej! Czasem program zapyta, ale najczęściej jeden raz i jest luz. Zastosowano pewien trik: sprawdzane jest, czy nowy program został podpisany cyfrowo przez Microsoft – jeżeli tak, to jest dla UAC na „białej liście” i 'hulaj dusza, piekła nie ma'. Czy to jest dobre? Jakbym był autorem malware, to jasne, że świetne rozwiązanie – ułatwi to klepanie kodu, wystarczy np. wykorzystać powłokę explorera, bo... jest przecież podpisana przez Microsoft. Problemem są też programiści – ciągle spotykam się z „dużymi” aplikacjami, które wymagają pracy na koncie administratora, lub wyłączenia UAC. Nóż mi się w kieszeni otwiera, jak czytam artykuły, gdzie doświadczony programista (MVP! ) zaczyna od zdania:

Nadaje się na temat na kolejny wpis blogowy, ale pierwszy komentarz praktycznie w stu procentach pokrywa się z moją opinią:

Jest to kompletna ignorancja, brak zrozumienia logiki systemu, który daje programiście chleb, oraz brak poszanowania odbiorcy docelowego swoich programów.

Drogi czytelniku – jeżeli dotarłeś do tego miejsca to jesteś wielki, że poświęciłeś czas na czytanie tekstu, który w zamyśle miał zająć pół strony dokumentu w LibreOffice Writer. Muszę jednak przestrzec, teraz już będzie całkowicie nudno, bo technicznie. Wrócę może do początkowej tezy, że Windows 64‑bitowy jest moim zdaniem bezpieczniejszy. Zacznijmy od  DEP (Data Execution Prevention), czyli mechanizmowi zapobiegania wykonywania kodu z segmentu danych. Najprościej mówiąc za pomocą sprzętowego rozwiązania (na poziomie procesora) jak i programowego można określić, że dany fragment pamięci nie może mieć wykonywalnego kodu. Przed pojawieniem się dodatku SP2 dla Windows XP (który ogromnie zmienił ten system) byle sploit mógł wykonać kod, który wcześniej wrzucił za pomocą VirtualAlloc (http://msdn.microsoft.com/en-us/library/aa366887.aspx) mimo tego, że 'fragment pamięci' pamięci był oznaczony tylko do odczytu (PAGE_READWRITE). Z chwilą pojawienia się w procesorach dla Intela wsparcie dla eXecute Disable (XD) a od strony AMD No Execute (NX) – zrobiło się trochę lepiej, nad PAGE_READWRITE czuwa sprzęt i system operacyjny. Z racji tego, że jestem za cienki w uszach, żeby zrozumieć to dokładnie (znam skutki działania, ale nie sam mechanizm), odsyłam do literatury fachowej a na dobry początek np. http://technet.microsoft.com/en-us/library/bb457155.aspx. Wracając do Windowsa, w wersjach 32‑bitowych domyślnie DEP jest wyłączany ze względu na problemy z kompatybilnością niektórych programów (wyżej wspomniany PEBKAC programistów). W 64‑bitowym środowisku programy nie mogą ominąć tak prosto tego mechanizmu a przynajmniej mają to wyraźnie utrudnione.

Drugim, chyba ważniejszym mechanizmem wspomnianym przez jest ASLR (Address Space Layout Randomization). Chyba każdy mający styczność z komputerami spotkał się z magiczym określeniem „przepełnienie buforu”. Tutaj znowu wszyscy mogą winić programistów z Redmont, rzadko kto jednak pomyśli o programistach aplikacji, którzy pozwalają na „wciśnięcie” spreparowanego fragmentu kodu do pamięci. W sytuacji, gdy jeszcze następuje taka dogodność, że aplikacja ma prawa administratora i możemy przewidzieć, gdzie dokładnie znajdzie się ten kod w pamięci już prosta droga do uruchomienia go. W Windows często szukano takich dziur i  z użyciem różnych rodzajów ataku jak np. return2libc (podmiana adresu powrotu tak, aby wskazywał na jakąś funckję) W systemach 32‑bitowych (począwszy od Visty) też jest zaimplementowane ASLR, ale to tylko namiastka tego, co daje 64‑bitowa przestrzeń adresowa.

ASLR w połączeniu z DEP daje bardzo mocny mechanizm bezpieczeństwa i przez to jest głównym celem badań zarówno od specjalistów od bezpieczeństwa jak i „hakerów” - w większości sytuacji z marnym skutkiem. Czy można w domowych warunkach w jakiś sposób kontrolować, co się dzieje w tych mechanizmach i jak chroniony jest nasz system operacyjny? Oczywiście, ale bywa to upierdliwe, jednak raz nabyta umiejętność i np. utworzenie pewnych szablonów pozwala nam poczuć się pewniejszym – wymaga jednak pracy.

Rok temu januszek opisywał metodę niezbyt przyjazną użytkownikowi:

Są też metody jeszcze bardziej upierdliwe (ale świetne w środowisku produkcyjnym), jak np. EMET, oferujący bardzo głęboką ingerencję w DEP, SEHOP, ASLR, czy Pinning.

W następnym wpisie postaram się opisać jak kontrolować procesy i sprawdzać do czego mają "prawa" (Proces Explorer" ze zbioru Windows SysInternals nadaje się idealnie), oraz jak tworzyć "template" zarówno do zastosowań domowych jak i korporacyjnych.