Przejmowanie uprawnień dostępu do plików w systemach Windows

W artykule tym Paula Januszkiewicz zademonstruje, jak uzyskać dostęp do pliku nie będąc jego właścicielem.Mając taki dostęp, można odczytać plik lub folder, a także je zmodyfikować.I wszystko odbywa się omijając Kontrolną Listę Dostępu do pliku.

Systemy Windows znane są z mocno rozbudowanego zarządzania dostępem do plików. Niniejszy artykuł ma na celu pokazanie, jednej z ciekawszych metod uzyskiwania dostępu do plików z pominięciem podstawowych mechanizmów zabezpieczeń, jakimi są listy Access Control List.

Mimo tego, że artykuł obejmuje tematykę przeznaczoną raczej dla administratorów niż programistów, na wstępie chciałabym zaznaczyć, że w niektórych miejscach pozwoliłam sobie na opisanie poszczególnych funkcji systemowych. Inaczej po prostu się nie da. Zasadniczym celem artykułu jest wykazanie, że istnieje wiele "wbudowanych" metod pozwalających na uzyskanie dostępu do plików nawet, jeżeli użytkownik nie znajduje się na liście uprawnionych kont systemowych.

Take ownership

Najprostsza metoda uzyskania dostępu do plików wymaga uprawnień "Take ownership" - niezależnie od tego, czy obiektem występującym o przejęcie pliku na własność jest Administrator (konto to ma domyślne uprawnienia "Take ownership of files or other objects"), czy zwykły użytkownik. Uściślając zagadnienie, kiedy obiekt (np. plik, folder) jest tworzony, ten kto dany obiekt tworzy, jest przez system operacyjny uznany za właściciela. W standardowym funkcjonowaniu konto użytkownika posiada uprawnienia do obiektów w folderach prywatnych danego użytkownika, czyli jest ich właścicielem (w większości przypadków właścicielem elementów systemowych jest wirtualne konto TrustedInstaller np. w Windows 7). Przejęcia na własność może dokonać konto Administrator, bądź też inny użytkownik z uprawieniami "Take ownership". Bieżący właściciel obiektu, użytkownikA może przekazać uprawnienia do obiektu innemu użytkownikowi (dodać go do listy potencjalnych właścicieli). UżytkownikB musi zdecydować się samemu na przejęcie na własność, inaczej nie będzie właścicielem obiektu. Właściciel obiektu może w praktyce dowolnie ustawiać uprawnienia do niego. Oznacza to, że mając uprawnienie do zostania właścicielem, Administrator może sięgnąć do pliku, do którego chwilę wcześniej nie miał żadnych uprawień. W systemach Windows Vista, Windows Server 2008 nieco się to zmieniło (powstał nowy Security Identifier: OWNER_RIGHT, mogący zabronić zmiany uprawnień właścicielowi do jego własnego obiektu) ale idea pozostała ta sama. Przykład 1 oraz Przykład 2 ukazują podstawowe sposoby przejmowania na własność w systemach Windows.

Przykład 1

Przejęcia na własność np. dla folderu, można dokonać wybierając jego Właściwości, na zakładce Security, kliknąć Edit, z zakładki Owner wybrać Edit i określić właściciela (Rysunek 1).

Rys. 1. Określanie właściciela obiektu.


Przykład 2

Przejęcia na własność można dokonać również z wiersza poleceń przy wykorzystaniu takeown.exe, wbudowanego w system (Rysunek 2). Podano dwa przykłady: próba przejęcia na własność z uprawnieniami użytkownika (1) oraz z uprawnieniami Administratora (2). Parametr /F określa miejsce docelowe działania polecenia, /R określa wszystkie obiekty wewnątrz folderu ‘Dst’, /A przyznaje Administratorowi uprawnienia do obiektów (zamiast bieżącego użytkownika).

Rys. 2.Przejmowanie na własność przy wykorzystaniu polecenia takeown.exe.

Przejmowanie zasobów na własność opiera się o uprawnienia zdefiniowane w ACL. Działa więc jedynie w systemie operacyjnym, który rozumie ACL i całe funkcjonowanie opiera na tychże listach.

UWAGA: Istnieją w przyrodzie programy, które nie do końca szanują określone przez Administratora reguły dostępu do plików, np. Total Commander. Dobrym przykładem jest Junction (dowiązanie) ‘Documents and Settings’ w Windows Vista i Windows 7 (aby wyświetlić to dowiązanie należy włączyć wyświetlanie ukrytych folderów i plików systemowych). Folder oznaczony jest symbolem kłódki i przy próbie wejścia domyślnie w Windows Explorerze otrzyma się komunikat z informacją o braku dostępu (można oczywiście przejąć go na własność, ale nie w tym rzecz). W Total Commanderze – ten sam folder przekieruje użytkownika bezpośrednio do miejsca przeznaczenia dowiązania, czyli do folderu %SystemDrive%\Users. W tym temacie odsyłam do: http://blogs.technet.com/plwit/archive/2009/01/14/symlink-czyli-mklink-w-windows-server-2008.aspx

 

Dostęp Offline

W kolejnej metodzie dostępu schodzi się już nieco poniżej poziomu, na którym operują listy ACL. Wszelkie ataki offline bazują na omijaniu list ACL poprzez np. przepięcie dysku do innego komputera. W wielu sytuacjach płyta DVD z systemem Windows Vista uratowała niejednemu pechowcowi cały informatyczny dorobek, właśnie poprzez fakt, że wszelkie uprawnienia ACL przy uruchomieniu systemu z płyty CD/DVD są po prostu pomijane. A co gdyby móc uzyskać dostęp do danych pomijając ACL oraz sięgać do systemu Online? W końcu ACL to nie żadna świętość.

Odczyt zawartości sektorów na dysku

Odczyt zawartości sektorów na dysku jest kolejną metodą dostępu przy ominięciu list ACL, między innymi za pomocą programów takich typu WinHex (Rysunek 3). Założenie jest proste: ACL nie funkcjonują na tym poziomie - zupełnie inna technologia, zupełnie inna koncepcja. W tym przypadku najlepiej sprawdziłyby się rozwiązania typu BitLocker (czy inne alternatywne metody niskopoziomowego szyfrowania).

Rys. 3. Edycja lub odczytywanie zawartości sektorów na dysku - WinHex.

Wadą tego rozwiązania jest fakt, iż aby móc uzyskać dostęp do pożądanego dysku, należy także uzyskać do niego fizyczny dostęp (np. w scenariuszu, gdy wielu użytkowników pracuje na tym samym komputerze w trybie zmiennym). Ponadto, dostęp taki wymaga zazwyczaj praw administratora, który zazwyczaj do danych może sięgnąć kilkoma innymi sposobami.

BackupRead

Przedstawione wcześniej metody dostępu do plików opierały się na pewnych niewielkich oszustwach. Pierwsza metoda polegała na nadaniu sobie uprawnień (trudno tu mówić o dostępie bez uprawnień) druga (dostęp offline) wykorzystywała fakt, że wyłączony system nie ma szans bronić praw, trzecia metoda tak naprawdę nie była dostępem do plików, więc trudno, żeby respektowała uprawnienia wymuszane przez ACL.

Przedstawiony poniżej odczyt plików przez BackupRead jest najmniej znany i jako jedyna z metod przedstawionych w niniejszym artykule faktycznie odczytuje pliki, do których użytkownik nie ma uprawnień. Działa przy włączonym systemie, nie zmienia istniejących list ACL i nie wymaga żadnego "oszukiwania". Jak łatwo się domyślić, taki sposób odczytu został w systemach Windows zaimplementowany celowo i istnieje "od zawsze", czyli od Windows NT 3.1. Założenie było bardzo proste: skoro w systemie ma być wykonywany backup, to musi istnieć metoda odczytania wszystkich plików bez względu na uprawnienia. W przeciwnym przypadku, backup serwera plików, gdzie każdy użytkownik ma indywidualnie ustawione prawa w katalogu domowym mijałby się z celem. Skoro taka metoda istnieje, to warto spróbować użyć ją do własnych celów, czyż nie?

Jak się łatwo domyślić, nie każdemu użytkownikowi wolno tak zrobić. Gdyby tak było, cały system zabezpieczeń nie byłby wiele warty. Dlatego, prawa do specjalnego trybu odczytu plików nadawane są jako jeden z tak zwanych przywilejów systemowych. Przywilej ten nazywa się SeBackupPrivilege i można nim zarządzać poprzez Local Security Policy. Użytkownik, który ma nadany ten przywilej może sięgać po nie swoje pliki. Domyślnie, przywilej ten mają administratorzy oraz użytkownicy należący do grupy "Backup Operators". Nic jednak nie stoi na przeszkodzie, aby nadać go dowolnej innej grupie czy pojedynczemu użytkownikowi. W dalszej części artykułu przyjęto założenie, że przywilej ten jest nadany użytkownikowi, który wykonuje opisane operacje.

Z punktu widzenia programisty, odczyt pliku sprowadza się do dwóch czynności. Po pierwsze – musi on uzyskać tak zwany uchwyt (ang. handle) do pliku. Uchwyt ten jest tak naprawdę liczbą, którą posługują się wszystkie kolejne operacje plikowe. Następnie, podając numer uchwytu może na pliku wykonać zamierzone operacje. Wygląda to w praktyce tak, że programista chcąc przeczytać plik c:\test.txt prosi o uchwyt do pliku o takiej nazwie. Służy do tego funkcja CreateFile(), która wbrew mylącej nazwie nie tworzy żadnego pliku. Używając CreateFile() programista określa, co będzie z takim uchwytem robił. Można prosić o uchwyt do odczytu albo do zapisu. Ponadto, prosząc system o uchwyt, określić należy, jaki uchwyt do takiego pliku system da innym, którzy o to poproszą.

Przykładowo, możliwe jest uzyskanie uchwytu do pliku w taki sposób, że będzie możliwy zapis danych, a wszyscy inni dostaną zakaz dostępu dopóki uchwyt nie zostanie zwolniony. Zdecydowanie ma to sens. Zazwyczaj zapisując dane, programista nie życzy sobie, aby w tym samym czasie ktoś inny modyfikował jego plik. Z drugiej strony, możliwe jest na przykład uzyskanie własnych uchwytów tylko do odczytu przez wiele aplikacji równocześnie. Przykładem może być program notepad.exe. Można w notatniku otworzyć plik, po czym nie zamykając notatnika – skasować plik z dysku. Notatnik dostał swój uchwyt, ale nie zabronił innym uzyskania swoich własnych uchwytów dostosowanych do innych potrzeb. Ta sama operacja z plikiem otwartym przez Microsoft Word nie miałaby już szans powodzenia. Wszystko przez uchwyty. Prosząc o uchwyt określa się wiele innych parametrów, takich na przykład jak informacja dla systemu, co zrobić w sytuacji, kiedy podany plik nie istnieje. Utworzyć nowy? Zgłosić błąd? A może skasować istniejący i utworzyć w jego miejscu nowy? Wszystko jest możliwe i zależy od decyzji programisty.

Mając już zgodny z życzeniem uchwyt, programista może użyć go do operacji na plikach. Operacji tych ma do dyspozycji stosunkowo dużo, ale do odczytu danych zazwyczaj używa funkcji ReadFile(). Funkcja ta, dostaje od programisty informacje o numerze uchwytu, ilości bajtów, które należy odczytać oraz o miejscu w pamięci, które zostało przygotowane na odczytane dane. Jeżeli wykona się poprawnie, to w przygotowanym miejscu znajdują się dane z pliku. Aby móc odczytywać dane, uchwyt musi być utworzony do odczytu. Aby zapisywać – do zapisu. Dzięki temu, system dodatkowo kontroluje programistę.

Opisana powyżej metoda stosowana jest praktycznie przez każdą operację plikową w systemie. Po uruchomieniu Task Managera, można na zakładce Performance zobaczyć ile w danej chwili system przydzielił uchwytów. Choć nie są to tylko uchwyty do plików, to i tak liczba ta jest stosunkowo duża. Informacja ta, w bardziej szczegółowej postaci dostępna jest również w aplikacji Process Explorer po naciśnięciu Ctrl+H.

Opisana powyżej metoda dostępu wykorzystująca CreateFile() i ReadFile() charakteryzuje się tym, że system sprawdza listy ACL dla pliku nim pozwoli na odczyt danych. Jest to słuszne i oczywiste i na tym właśnie polegają zabezpieczenia.

Jeżeli jednak użytkownik ma wspomniane wcześniej systemowe uprawnienie SeBackuPrivilege, może tworząc uchwyt podać specjalny parametr FILE_FLAG_BACKUP_SEMANTICS. Oznacza on dla systemu, że uchwyt będzie służył do potrzeb backupu. System nie sprawdza czy faktycznie tak zostanie on użyty, ale sprawia, że zamiast tradycyjnego ReadFile() można zastosować funkcję BackupRead(). Funkcjonalnie, funkcje te niczym się nie różnią, ponieważ obie działają tak, że do przeznaczonego dla nich miejsca w pamięci wczytują fragment pliku o zadanej długości. W praktyce jednak ReadFile() musi mieć uprawnienia do pliku, podczas gdy BackupRead() – nie musi. Oznacza to, że napisanie własnego programu, który odczyta dane bez uprawnień do pliku jest bardzo proste. Tak naprawdę musi być, ponieważ mechanizmy kopii zapasowych powinny używać legalnych metod, przewidzianych właśnie do tego celu przez twórców systemu. To, że zamiast wbudowanego lub kupionego programu do backupu, użytkownik posłuży się własnym – nie może robić systemowi różnicy. Warto pamiętać, że metoda ta omija prawa ACL, jednak nadal nie można otrzymać uchwytu, jeżeli ktoś wcześniej uzyskał uchwyt zabraniający systemowi przydzielania kolejnych. Jest to mechanizm niezależny od ACL i ma na celu ochronę integralności danych. To właśnie przez takie "zabraniające" uchwyty, aplikacje do backupu mają często problem z "otwartymi plikami". Od strony programisty, otwarty plik oznacza właśnie, że ktoś wziął do niego uchwyt w taki sposób, że póki go nie zwolni – nie można utworzyć kolejnego.

Zdarzają się oczywiście przypadki, kiedy użytkownik chciałby sięgnąć do niedostępnych dla niego danych, ale nie jest programistą. W takiej sytuacji, najlepiej posłużyć się gotowym rozwiązaniem. Rozwiązanie dla zupełnych laików polega na zastosowaniu programu do backupu. Programem takim, należy zrobić kopię pliku a następnie odtworzyć go w inne miejsce, w sposób, który zagwarantuje, że odczyt będzie możliwy. Rozwiązanie dla bardziej świadomych administratorów polega na użyciu niedocenianego zwykle narzędzia robocopy.exe. Jest to program wiersza poleceń wbudowany w systemy Windows Vista i nowsze. Dla starszych systemów, można go bezpłatnie pobrać ze stron Microsoft jako element pakietu rktools. Wśród wielu możliwości, robocopy ma opcję pozwalającą na kopiowanie plików z wykorzystaniem BackupRead() zamiast ReadFile(). Dzięki temu można kopiować cudze pliki do swojego folderu. Podejście polegające na "przerobieniu" programu notepad.exe albo Word tak, by czytał pliki niedostępne dla użytkownika raczej nie wchodzi w grę. Albo należy napisać własny program albo trzeba polegać na kopiowaniu plików w nowe miejsce i tradycyjny odczyt tak utworzonej kopii.

Analogicznie, do opisanej powyżej pary SeBackupPrivilege i BackupRead() istnieje w systemie para SeRestorePrivilege i BackupWrite(). Zastosowanie łatwo sobie wyobrazić, jednak wykracza ona poza zakres niniejszego artykułu.

Jako przykład przedstawione zostało kopiowanie plików z użyciem wymienionych praw (w Windows Server 2003 działa bez szemrania, w Windows Vista trzeba zainstalować KB950790, w Windows 7 niestety nie zadziałało, ale może kiedyś... – ten sam objaw co w Vista, ale nie ma jeszcze KB). Użytkownikowi należy nadać uprawnienia w Local Security Policy: "Backup files and directories" oraz "Restore Files and Directories" (Rysunek 4).

Rys. 4. Nadanie uprawnień użytkownikowi (w Windows Vista, ale w Windows Server 2003 jest podobnie).

Kopiowanie zostało przedstawione na przykładzie Windows Server 2003 (Rysunek 5). Zalogowany użytkownik z opisanymi uprawnieniami może spróbować uzyskać dostęp do folderu (Desktop), do którego dostać się może teoretycznie tylko Administrator. Zwykły użytkownik nie ma dostępu do danych prywatnych innych użytkowników (1). Polecenie copy również w takiej sytuacji nie zadziała, ponieważ jego działenie opiera się na funkcji ReadFile() uwzględniającej zawsze prawa ACL, które wyraźnie w tym przypadku określają, że użytkownik nie powinien mieć wstępu na pulpit Administratora (2). Użycie polecenia robocopy /B sprawdza, czy użytkownik ma uprawnienia SeBackupPrivilege, w tym przypadku ma, więc kopiowanie przebiega bez zarzutów, mimo iż użytkownik nie ma dostępu do folderu (3).

Rys. 5. Wykorzystanie uprawnień "backupowych" do kopiowania plików, do których nie ma się dostępu.

Podsumowanie

Prawa ACL są istotnym mechanizmem odpowiadającym za zarządzanie dostępem do zasobów. Nie wszystkich użytkowników jednak takie prawa obowiązują. Mechanizmami, które zostały zaprojektowane dla kopii zapasowych, można odczytać praktycznie każdy plik, niezależnie od faktycznych jego uprawnień.

O autorce

Paula Januszkiewicz Pasjonatka rozwiązań dotyczących bezpieczeństwa. Na co dzień zajmuje się audytowaniem systemów, witryn internetowych oraz środowisk informatycznych, zarówno od strony organizacyjnej, jak i ściśle technicznej. Chętnie każde rozwiązanie, które trafi w jej ręce zepsuje, bądź skrytykuje. Prowadzi szkolenia dotyczące obszarów, w których się specjalizuje. Prelegentka wielu warsztatów oraz konferencji krajowych i zagranicznych (spotkacie ją jako prelegenta między innymi na konferencji Microsoft TechEd w Berlinie). Hobbistycznie zajmuje się poznawaniem nowych technologii, w głównej mierze wykorzystujących rozwiązania Microsoft. Założycielka i liderka grupy Women in Technology oraz organizatorka spotkań Warsaw Girl Geek Dinners. Na co dzień pracuje w firmie ISCG Sp. z o.o. Posiadane certyfikaty MS: MCP/MCSA/MCDBA/MCSE+S/MCTS/MCITP/MCT Witryny/blogi: http://blogs.technet.com/plwit, http://ms-groups.pl/wit