Pobieranie prezentacji. Proszę czekać

Pobieranie prezentacji. Proszę czekać

RYSA NA SZKLE SANDBOKSY W WINDOWS A ARCHITEKTURA SYSTEMU Rafał 'omeg' Wojdyła // Invisible Things Lab //

Podobne prezentacje


Prezentacja na temat: "RYSA NA SZKLE SANDBOKSY W WINDOWS A ARCHITEKTURA SYSTEMU Rafał 'omeg' Wojdyła // Invisible Things Lab //"— Zapis prezentacji:

1 RYSA NA SZKLE SANDBOKSY W WINDOWS A ARCHITEKTURA SYSTEMU Rafał 'omeg' Wojdyła // Invisible Things Lab // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 1

2 O autorze  Programista z zawodu i zamiłowania  Lubi dłubać w bebechach Windows „od małego” ;)  W wolnych chwilach bawi się elektroniką i mikrokontrolerami  Aktualnie pracuje dla Invisible Things Lab (Joanna Rutkowska) nad Qubes OSQubes OS  Kontakt i fingerprint klucza GPG w stopce :) Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A 2

3 Luźna agenda  Skąd to się wszystko wzięło  Co to jest sandbox?  Typy sandboksów i różne cele, jakie im przyświecają  Sandboksy jako kontenery na niezaufany kod  Mechanizmy udostępniane przez system wykorzystywane przez sandboksy i różne mity na ich temat  Skuteczna izolacja niezaufanego kodu w Windows - możliwe, czy nie?  Natywne sandboksy a wirtualizacja Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A 3

4 Geneza prezentacji: Qubes OS  Qubes? A co to?  Co ma Qubes do Windowsów  Genialny pomysł; dziwne, że nikt jeszcze tego nie zrobił… Qubes WNI  …ach, to dlatego nikt jeszcze tego nie zrobił! ;)  (niektórzy chwalą się, że zrobili, ale nie mają racji) Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A 4

5 Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 5

6 6

7 Co to jest ta tytułowa piaskownica?  Izolowany kontener na wykonywany kod  Mniej lub bardziej ściśle kontroluje zasoby wykorzystywane przez izolowany kod  Sposób na wykonywanie testowego lub niezaufanego kodu w zaufanym/kontrolowanym środowisku  Możliwość anulowania zmian poczynionych w testowym środowisku  Opcjonalne logowanie zachowania/automatyczna analiza wykonywanego kodu Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 7

8 Typy sandboksów  Do testowania „w miarę zaufanego” kodu (zazwyczaj używane przez developerów/testerów „normalnego” oprogramowania Nie potrzeba absolutnej izolacji, bo potencjał destrukcyjny jest niewielki… …chyba, że debugujemy program formatujący dyski lub coś podobnego ;)  Do analizy niezaufanego lub stricte złośliwego kodu Wymagana ścisła izolacja od macierzystego systemu Automatyczna analiza zachowania bardzo przydatna Lepiej jednak użyć VM lub oddzielnej fizycznej maszyny ;)  Klient-serwer (target-broker) Używane do izolacji procesów, które wiedzą, że są sandboksowane Chromium, Acrobat Reader, IE…  VM? ;) Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 8

9 No dobrze, mam tutaj kod z internetów, jak go skutecznie zapiaskownicować? Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 9

10 Co tak naprawdę znaczy „izolowany kontener” w kontekście niezaufanego kodu?  Izolowany proces nie może zmienić stanu macierzystego systemu lub innych kontenerów bez zezwolenia  Kontenery nie powinny mieć możliwości „zDoS-owania” systemu poprzez np. wyczerpanie zasobów (pamięć, dysk, czas CPU, obiekty GDI ;) itp. )  Niski koszt wydajnościowy  Możliwość działania wielu kontenerów jednocześnie  Kompatybilność: dowolny (idealnie) program działający na macierzystym systemie powinien działać bez modyfikacji w sandboksie  GUI to też cześć systemu i powinno być odpowiednio izolowane! Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 10

11 Ok, a co uznać za „stan systemu”?  Globalne ustawienia rodem z Panelu Sterowania i podobne  System plików, rejestr  Aktywne procesy/wątki poza sandboksem  Pozostały stan ulotny (sieć, obiekty jądra, COM, GDI, …) Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 11

12 Konkrety: co sandbox musi kontrolować  Dostęp do globalnych ustawień systemu (wiem, mało konkretne ;)  IPC (komunikacja międzyprocesowa) dowolnego rodzaju, a jest tych rodzajów mnóstwo  Dostęp do systemu plików i rejestru poza wyznaczonymi obszarami dla sandboksa  Dostęp do obiektów jądra (szczegóły później)  Dostęp do okien i innych obiektów USER/GDI, w tym clipboard  Dostęp do fizycznych urządzeń wejścia/wyjścia (ekran, klawiatura, mysz, inne)  Dostęp do interfejsów sieciowych, bluetooth i innych komunikacyjnych  Ogólnie, dostęp do jakichkolwiek urządzeń ;) Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 12

13 Przyjrzyjmy się bliżej, czy pod Windows da się zaimplementować wymienione wcześniej wymagania dotyczące izolacji W żadnej prezentacji nie może zabraknąć zdjęć kotów Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB13

14 Kontrola globalnych ustawień systemu  Local Security Policy  ACL na plikach/kluczach rejestru  Przykład problematycznego API: SystemParametersInfo Funkcje ułatwień dostępu Ustawianie tapety, obszaru roboczego ekranu, szybkości myszy itp. Zaimplementowana jako syscall stub do win32k, nie da się łatwo kontrolować Ogólny problem z kontrolowaniem syscalli (kernel hooki są be, KPP, brak oficjalnych API) Job Objects? Działa na SPI, ale są inne funkcje na które nie działa ( SetSysColors ) Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 14

15 IPC, czyli zabawa w głuchy telefon  Pipes – ACL  Mailslots – ACL  Sekcje (pamięć współdzielona) – ACL  Obiekty synchronizacyjne (muteksy, semafory, eventy, timery) – ACL  Dostęp do samych procesów/wątków – ACL  ALPC – ACL (WTF BBQ)  Komunikaty GUI (WM_*) – problem (więcej o GUI dalej)  ACLe można nadawać istniejącym obiektom, ale co z nowo tworzonymi? Hooki w Ob? Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 15

16 System plików i rejestr  Proste w teorii, trudne w praktyce  ACLe wymagają szczegółowych polis  Implementacja prywatnego storage dla poszczególnych instancji sandboksa – coś a’la Wow64 redirection? Teoretycznie da się zrobić poprzez FS filter driver…  Co ze współdzielonymi lokacjami (np. HKLM\Software\... dla różnych instancji)? Rozwiązywanie konfliktów Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 16

17 Obiekty jądra  Trudny orzech do zgryzienia (ha ha ;)  42 typy w Windows 7, więcej w kolejnych wersjach  Dostęp głównie przez różnorakie usermodowe API, część nieudokumentowana  Drzewiasta struktura nazw, separacja per-sesja  Można im przypisywać ACLe – problem rozwiązany? Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 17

18 Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 18

19 Obiekty jądra  Aby użyć ACLi do ochrony obiektów, poszczególne kontenery/instancje sandboksa muszą być rozróżnialne przez Se: odrębne SIDy dla sandboksowanych procesów  Domyślnie procesy należące do interaktywnej sesji mają przypisany logon SID stworzony podczas logowania, ten SID ma dostęp do obiektów tworzonych w danej sesji  Co się stanie, gdy po prostu użyjemy innego logon SIDa ( CreateProcessWithTokenW jako inny user)? Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 19

20 Rezultat uruchomienia procesu z SIDem innym niż ten z aktualnej sesji interaktywnej Nowy SID nie ma praw dostępu do obiektów, których program potrzebuje – desktopu, window station i wielu innych. Systemowe DLLki zwracają błąd przy inicjalizacji. Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB20

21 Tak źle i tak niedobrze  Zablokowanie dostępu do obiektów USER takich jak desktop czy window station jest możliwe, ale raczej niepraktyczne  Zezwolenie dostępu otwiera nas na potencjalne ataki  Nawet jeśli rozwiążemy problemy z GUI (o czym jeszcze później), istnieje wiele innych obiektów używanych przez systemowe biblioteki lub CRT  Zablokowanie dostępu do nich powoduje zazwyczaj katastrofalne skutki (procesy nie działają lub występują różne anomalie – następna strona)  Zezwolenie na dostęp otwiera, znów, potencjalne kanały ataku – obiekty te są tworzone i używane przez zaufane procesy/serwisy  Potencjalne ataki name squatting Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 21

22 Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 22

23 Obiekty jądra – pomysły  Zezwolić na dostęp do systemowych obiektów. Potencjalne źródło ataków (nieudokumentowane protokoły)  Sesje to systemowy mechanizm separacji. Jest tylko kilka problemów… Konsumenckie edycje Windows nie pozwalają na wiele aktywnych sesji jednocześnie Nawet jeśli mielibyśmy wiele sesji, będzie problem z izolacją GUI… Brak udokumentowanych API do tworzenia sesji (SMSS się tym zajmuje) Własna implementacja? ;) Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 23

24 Obiekty jądra – pomysły  Zaimplementować separację przestrzeni nazw obiektów własnoręcznie Hooki w Ob (niepraktyczne) Podmiany funkcji parsujących nazwy w typach obiektów ObRegisterCallbacks : procesy, wątki, desktopy (win10), być może inne typy jeśli pokombinujemy To rozwiąże problem z nowo tworzonymi obiektami, ale już istniejące (tworzone np. na początku sesji interaktywnej lub starcie systemu) pozostają problemem Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 24

25 Izolacja GUI Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 25

26 Problemy z GUI  Okien i innych obiektów USER nie można zabezpieczać ACLami  Komunikaty mogą być wysyłane gdzie popadnie (shatter, spoofowanie klawiatury/myszy itp.) Integrity levels to za mało  Hooki – sniffowanie do woli  Jeśli wątek może pokazać okno na pulpicie, to może rysować tam co chce, potencjalnie oszukując użytkownika  Schowek jest wspólny dla window station, osobne pulpity to za mało Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 26

27 Sesje na ratunek (ponownie)?  Nieaktywne sesje nie renderują swojej zawartości i nie przetwarzają komunikatów okien  Limit aktywnych sesji w konsumenckich Windowsach  Brak API do tworzenia sesji  Kombinacje z RDP? Potencjalne problemy ze zwirtualizowanymi urządzeniami (audio/video, wejście) Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 27

28 Inne pomysły  Tylko jedna window station jest interaktywna, nieużyteczne do izolacji  Pulpity się nie nadają, win32k potrafi renderować tylko na jednym pulpicie na raz (chyba, że w win10 coś się zmieniło) Nie mylić pulpitów z monitorami Tylko aktywny pulpit przetwarza zdarzenia z urządzeń wejściowych i komunikaty (RIT) Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 28

29 Inne pomysły  Job objects? „Kontener” na grupy procesów umożliwiający nakładanie różnorakich limitów związanych z GUI Nie chroni przed globalnymi hookami (wbrew niektórym publikacjom, trywialne do sprawdzenia – przynajmniej na Win7) Zagnieżdżone job objects możliwe dopiero od Windows 8+, problem na Win7 (system sam czasami grupuje procesy w job object (IE, compatibility shims) Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 29

30 Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB30

31 Integrity levels?  Wprowadzone w celu zapobiegania atakom typu shatter  Zaimplementowane specjalnymi polami w access tokenie (mandatory access)  Nie zapobiegają trywialnym interakcjom typu WM_KEYDOWN  Tylko 2-3 możliwe do praktycznego użycia  Większość aplikacji nie działa na niskim poziomie bez modyfikacji Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 31

32 Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 32

33 Podsumowanie  Co robić, jak żyć? ;)  Czyżby jednak powrót do wirtualizacji – zatoczymy pełne koło  Wirtualizacja to też nie panaceum (XSA-148)  Morał: security is hard, zajmijmy się szydełkowaniem… ok, to jeszcze trudniejsze ;)  Pytania? Uwagi? Darmowe piwo? Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 33

34 Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 34

35 Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 35

36 Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 36

37 Rafał 'omeg' Wojdyła // Invisible Things Lab // // 5703 A6D B 126D E582 85A2 F6B0 761A B5BB 37


Pobierz ppt "RYSA NA SZKLE SANDBOKSY W WINDOWS A ARCHITEKTURA SYSTEMU Rafał 'omeg' Wojdyła // Invisible Things Lab //"

Podobne prezentacje


Reklamy Google