Paweł Goleń, blog

Chcę przedstawić kilka sposobów eskalacji przywilejów w aplikacjach internetowych oraz w systemie Windows. W przypadku aplikacji internetowych przedstawię kilka błędów, które spotkałem w systemach bankowości elektronicznej. W przypadku Windows chcę pokazać dlaczego właściwe uprawnienia do plików, rejestru i usług są istotne.

Pierwszy przykład - bankowość elektroniczna. W przypadku bankowości elektronicznej często rozróżnione są dwa elementy - uwierzytelnienie użytkownika i autoryzacja transakcji. Rozdzielenie to służy między innymi temu, by w przypadku, gdy ktoś w jakis sposób będzie mógł działać w aplikacji w kontekście użytkownika (przejęcie sesji, wykradnięcie hasła przez keylogger), nie mógł on wykonywać żadnych operacji. Idea wydaje się prosta, ale jak miałem okazję się przekonać kilkukrotnie - nawet tak prostą sprawę można zepsuć w implementacji. Przykład? Jest sobie bankowość elektroniczna, w którym zarówno uwierzytelnienie, jak i autoryzacja transakcji odbywa się przy pomocy kluczy. Atakujący przejmuje sesję użytkownika, na przykład przy pomocy ataku session fixation, nie ma jednak możliwości wykonywania operacji, ponieważ nie ma klucza użytkownika. Użytkownik czuje się bezpieczny, ponieważ klucz przechowuje na karcie kryptograficznej, co w praktyce uniemożliwia jego wykradnięcie w sposób inny, niż fizyczne zabranie użytkownikowi karty. Okazuje się jednak, że aplikacja udostępnia interfejs do generowania dodatkowych kluczy i... Nagle okazuje się, że wygenerowany przy jego pomocy klucz jest aktywny i może służyć zarówno do uwierzytelnienia do aplikacji, jak i podpisywania transakcji. Gdzie jest błąd? Oczywiście w możliwości uczynienia klucza aktywnym bez dodatkowej autoryzacji tej operacji. Jak już wielokrotnie powtarzałem, jedynym przypadkiem, w którym akceptowalne jest wykonanie operacji bez dodatkowej autoryzacji są tak zwane "przelewy zdefiniowane". Sam wolałbym, by też były dodatkowo autoryzowane, ale są akceptowalnym kompromisem między wygodą użytkownika/klienta, a bezpieczeństwem systemu.

Drugi przykład również związany z bankowością elektroniczną, ale tym razem z korporacyjną jej wersją. W korporacjach często stosowane są pewne schematy podpisu. Wygląda to mniej więcej tak, że na przykład księgowa przygotowuje przelewy, następnie są one podpisywane przez kilka wyznaczonych osób, a dopiero po zebraniu wszystkich wymaganych podpisów, operacja jest realizowana. Koncepcja i uzasadnienie takiego podejścia jest proste - jedna osoba nie może wykonywać przelewów, bo nie powinna tego robić (np. trudno sobie wyobrazić, by prezes mozolnie wklepywał przelewy, ale lepiej by księgowa sama ich wykonać nie mogła). Co tutaj można zepsuć? Cóż, jest więcej niż jeden sposób wykonania przelewu. Może się okazać (i czasem okazuje się), że o ile schematy podpisów działają prawidłowo przy tworzeniu nowych zleceń przelewu), to stworzenie operacji cyklicznej schematu podpisu po prostu nie weryfikuje. Owszem, jedna osoba nie może wykonać jednorazowego przelewu na swoje konto, ale bez problemu może stworzyć zlecenie cykliczne, które wykona się raz, a później zostanie usunięte...

Windows (z rodziny NT) pozwala na zabezpieczenie praktycznie każdego obiektu w systemie. Wykorzystuje do tego DACL, a od Windows Vista dodatkowo jeszcze Mandatory Integrity Control, a konkretnie implementację modelu Biba. Do obecnych rozważań MIC można zostawić na boku i skupić się na listach ACL. A listy te są przypisane zarówno do plików, kluczy w rejestrze i usług systemowych. Jeśli listy te są ustawione w sposób niepoprawny, możliwa jest eskalacja przywilejów.

Od Windows XP domyślne ustawienia uprawnień w systemie plików są w miarę sensowne. Tutaj oczywiście niektórzy dostawcy OEM "wiedzą lepiej" i można spotkać kwiatki typu Everyone:Full Control. Ja osobiście nieco zmieniam prawa na dyskach, tak, że w katalogu głównym prawa są następujące: C:\>cacls c: C:\ BUILTIN\Administrators:(OI)(CI)F NT AUTHORITY\SYSTEM:(OI)(CI)F BUILTIN\Users:(OI)(CI)R Dwa istotne katalogi to oczywiście %systemroot% oraz %programfiles%. Użytkownik nie powinien mieć tutaj praw do zapisu oraz modyfikacji plików. Jeśli takie prawa posiada, to w zasadzie jest to najprawdopodobniej kwestią czasu, kiedy osoba chcąca zostać administratorem komputera, zostanie nim. Wystarczy tutaj wskazać następujące scenariusze:

• podmiana pliku wykonywalnego jednego z często używanych przez administratora narzędzi,
• podmiana pliku wykonywalnego dla usługi,
• dodanie do katalogu biblioteki o takiej samej nazwie jak ta, z której korzysta program,

Dwa pierwsze scenariusze są chyba oczywiste. W pierwszym przypadku w zasadzie wystarczy zaczekać aż administrator zaloguje się i uruchomi "swój" program. Drugi przypadek jest analogiczny, jedyna różnica to to, że wystarczy zaczekać na uruchomienie usługi (zrestartować komputer). A jak ma działać trzeci przypadek? Wystarczy zapoznać się z dokumentacją do funkcji LoadLibrary. Biblioteki są najpierw szukane "lokalnie", tak więc umieszczając odpowiedni plik w katalogu aplikacji mamy praktycznie gwarancję, że to właśnie ta podstawiona biblioteka zostanie załadowana.

Są oczywiście jeszcze inne scenariusze wykorzystania, ale nie będę się nad tym rozwodził. Zwrócę jeszcze uwagę na możliwość eskalacji przywilejów przez... skrypty. Jeśli skrypty uruchamiane w kontekście użytkownika o dużych uprawnieniach mogą być zmodyfikowane przez innych użytkowników, to aż się prosi, by do nich dopisać coś w stylu: net user h4x0r p@$$w0rd /add net localgroup administrators /add h4x0r Innym trywialnym sposobem jest dopisanie komuś czegoś do autostartu.

Gałąź HKLM jest nietykalna. Użytkownik nie ma prawa modyfikować tej gałęzi. Koniec, kropka. Lepiej nie myśleć co się może stać, jeśli użytkownik może modyfikować klucz HKLM\SYSTEM\CurrentControlSet\Services, albo HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options czy bez polotu HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Run. Spory potencjał kryje się również w kluczu HKEY_LOCAL_MACHINE\SOFTWARE\Classes. Tu warto zapoznać się z tym, czym właściwie jest HKEY_CLASSES_ROOT. Kiedyś był to po prostu alias do klucz HKLM\Software\Classes, obecnie jest to połączony widok HKLM\Sofware\Classes oraz HKCU\Software\Classes. Jak można "zmontować" atak? W kluczu tym są przechowywane informacje między innymi o tym, jaki program jest używany do otwarcia określonego typu plików. Wykonując drobną modyfikację, można spokojnie czekać, aż nieświadomy administrator spróbuje otworzyć jakiś plik tekstowy, oczekuje okna Notatnika, a zamiast tego nieświadomie zakłada konto nowego administratora... Tutaj warto wspomnieć o starej sztuczce z czasów Windows NT 4.0. Problemem były zbyt luźne prawa do klucz HKEY_USERS\.DEFAULT. Sztuczka polegała na zmianie wygaszacza ekranu, który jest uruchamiany, gdy żaden użytkownik nie jest zalogowany. Wystarczyło go zmienić i chwilę poczekać. Program był uruchamiany z prawami LocalSystem. Przykłady można mnożyć, więc zamiast tego wystarczy prosta zasada - użytkownik może pisać wyłącznie do gałęzi HKEY_CURRENT_USER. To jest jego rejestr i może mieć tam co chce. Zaszkodzi sobie, a nie innym użytkownikom.

Usługi też mają swoje prawa, a właściwie nie tyle usługi, co użytkownicy do usług. Jednym z istotnych praw jest prawo do zmiany konfiguracji usługi. I tutaj istnieje spore niebezpieczeństwo. Jeśli użytkownik ma prawo do modyfikacji ustawień usługi, może eskalować swoje uprawnienia do poziomu konta, na którym działa atakowana usługa. Do ataku tego typu wystarczy dostępne standardowo w systemie polecenie SC. No i oczywiście "złośliwa usługa", którą chcemy uruchomić.

W temacie eskalcji uprawnień w Windows w warto zapoznać się z ciekawym artykułem Windows Access Control Demystfied. Innym ciekawym artykułem jest The Power in Power Users.

Można ręcznie i na piechotę, można też proces zautomatyzować. Doskonale nadaje się do tego narzędzie accesschk. Wystarczy wyszukać wśród plików, kluczy rejestru i usług tych, do których zwykły użytkownik ma prawa większe niż odczyt. A później zastanowić się jak podatność wykorzystać. Ćwiczenie to polecam programistom na ich komputerach...

Potem się może okazać, że użytkownik ma prawa do tych plików, które stworzył jako użytkownik z uprawnieniami administracyjnymi. Dlaczego? Z uwagi na to, że jest ich właścicielem. Windows XP pozwala określić, czy właścicielem obiektu tworzonego przez kogoś z uprawnieniami administratora jest ten ktoś (domyślnie), czy też grupa Administrators. Zawsze zmieniam na drugą opcję. Jeśli ta zmiana nie została wykonana, a konfiguracja systemu była przeprowadzona w ten sposób, że założone zostało konto heniek, który dostał uprawnienia administratora, to później ten użytkownik jest właściciel plików, które stworzył (zainstalował). Jako właściciel ma do nich pełne prawo, nawet jeśli lista ACL mówi inaczej. Dlatego lepiej niech administracją zajmuje się wydzielony użytkownik, nawet jeśli fizycznie osoba jest jedna.