Security Token, nazywany również Access Tokenem, jak sama nazwa wskazuje – jest biletem dostępu użytkownika. Dokładniej:
Dostęp do zasobów określają Access Listy [Access Conrol List – ACL]. Każdy zasób – plik, rejestr, jednostka organizacyja w domenie – ma swoją listę dostępową. Na tej liście znajdują się GUIDy i SIDy – czyli numery grup i użytkowników [Group Unique ID, Security ID]. W momencie próby dostępu do zasobu, użytkownik przedstawia swój bilet dostępu – Access Token, ten jest porównywany z ACLem zasobu. Jeśli użytkownik należy do grupy o GUIDzie X, i ten sam GUID X jest na liście ACL – to user dostaje odpowiednie uprawnienia.

Backdoor

Bardzo istotnym faktem jest to, iż token ten jest tworzony tylko i wyłącznie podczas procesu logowania. Oznacza to, iż:

Scenariusz

Przychodzi user i mówi, że nie może dostać się do katalogu K. Okazuje się, że do katalogu K ma dstęp tylko grupa G. Dodajemy usera do grupy G, ten sprawdza – ale nadal nie może się dostać do plików.

Jest to jak najbardziej normalna sytuacja. Access Token stworzony był podczas, kiedy user nie należał jeszcze do grupy G. Aby user miał dostęp do plików, musi się przelogować.

Sytuacja tego rodzaju nie jest groźna. Poważniejsze konsekwencje może mieć sytuacja odwrotna.

Scenariusz

Przychodzi specjalista do naszej firmy – ma zlecenie, żeby poprawić aplikację bankową, która działa u pani Krysi z działu księgowości. Aplikacja wymaga stałego maintenancu, więc osoba ta ma już swoje konto w domenie. Tym razem jednak twierdzi, że na czas operacji potrzebuje przywilejów administratora domeny. Tymczasowo przypisujemy go do grupy „domain admins” i obserwujemy mniej-więcej co robi i czy aby nie nadużywa nadanych uprawnień.

O ile scenariusz może wydać się lekko głupawy, to jednak sytuacje tego typu się zdarzają. Niestety poziom aplikacji dostarczanych przez systemy bankowe czy księgowe, mają czasem bardzo dziwne wymagania. Pomimo, że na dzień dzisiejszy wydaje się niemożliwe życie bez sieci, a większość firm ma środowisko wieloużytkownikowe, w wielu miejscach na pojedynczej maszynie loguje się wiele osób, to aplikacje nadal są pisane zupełnie jak na w9x – wymagają uprawnień administratora, są kłopoty z instalacją itp.
Jeśli podczas pracy ww. specjalista nie wylogował się z jakiejś stacji, to pomimo, że usuniemy go z grupy „Domain Admins”, jeśli przyjdzie i zaloguje się za jakiś czas, będzie pracował posiadając AT Domain Administratora.

Terminale – trudne do wykrycia

Trudne, jak trudne. Faktem jest, że nie każdemu chce się sprawdzać, na którym serwerze wiszą jakie sesje. Jeśli posiadając podwyższone przwileje zalogujemy się do zdalnej stacji poprzez terminale, można zrobić disconnect – rozłączenie sesji. Taka wisząca sesja, będzie sobie wisiała z podwyższonymi uprawnieniami, aż ktoś jej nie skilluje.

Text z gry „magia i miecz” – „potwór pozostanie na tym polu, aż ktoś go nie pokona” (;

Wnioski

Wniosków jest kilka:

  • Jeśli przychodzi specjalista i twierdzi, że potrzebuje uprawnień domain admina, to powinniśmy go pożegnać gromkim śmiechem i poprosić o zwrot pieniędzy za aplikację.
  • Powinna być zdefiniowana polisa GPO, określająca maksymalny czas życia rozłączonej sesji.
  • Po modyfikacjach przynależności do grup, powinno się odszukać wszystkie sesje, wszystkich użytkowników, którzy do nich należą, i zakończyć je. Nie jest to sprawa trywialna, jeśli do grupy należy np. kilkaset osób, dla tego też:
  • Wszelkie modyfikacje w grupach powinny być przemyślane, wedle zdefiniowanej polityki bezpieczeństwa i dostępu. Generalnie należy unikać tego rodzaju modyfikacji w 'żywym’ środowisku.
  • Jeśli już trzeba zmodyfikować grupy, najlepiej robić to w czasie kiedy pracuje minimalna ilość osób – np. przed weekendem.

Nieprzetestowany scenariusz

Teoretycznie bilet ma swój czas życia. Nie udało mi się jednak odkryć ile ten czas wynosi. W związku z tym istnieje nieprzetestowany scenariusz:

po instalacji domeny, logujemy się na jakiejś starej stacji, dodanej do domeny. Logujemy się na koncie z uprawnieniami Domain Admins. Następnie stację hibernujemy, odłączamy i chowamy w szafie. Następnie zmieniamy nazwę konta na jkieś zupełnie zwyczajne, nierzucające się w oczy i wyrzucamy z grupy domain admins.

Teoretycznie w szafie mamy backdoora – w razie co wystarczy podłączyć go do sieci i odhibernować… Stacja po odhibernowaniu nie zczytuje przez jakiś czas GPO, a na stacji mamy sesję z uwięzionym tokenem domain admina.
Jeśli ktoś przetestuje podobne rozwiązanie, albo potrafi udowodnić czas życia tokenu [imho nie jest to czas Kerberos Ticket lifetime], to będę wdzięczny za uzupełnienie (:


Refs

-o((:: sprEad the l0ve ::))o-