Jakiś czas temu opisywaliśmy na łamach naszego portalu użycie mechanizmów AdminSDHolder oraz SDProp w kampanii „KILLCHAIN“. W skrócie mechanizmy te odpowiednio wykorzystane umożliwiającą utworzenie w domenie tylnej furtki (ang.backdoor), dzięki której atakujący może uzyskać stały dostęp do najbardziej wrażliwych obiektów.
Za pośrednictwem wbudowanego w AD mechanizmu SDProp uprawnienia AdminSDHolder są przekazywane do wszystkich chronionych obiektów co 60 minut (domyślnie), w tym do grup uprzywilejowanych. Nawet jeśli administrator zobaczy niewłaściwe uprawnienia na chronionym obiekcie i je usunie lub doda, w ciągu godziny te uprawnienia zostaną przywrócone przez mechanizm SDProp.
Jest to bardzo ważne, aby wiedzieć co dane atrybuty robią i w jaki sposób prowadzą do nieautoryzowanej eskalacji uprawień, aby móc skutecznie się przed tym chronić. Dziś opiszemy przykładowe problemy jakie mogą występować z wymienionymi atrybutami.
Problem nr 1
SDPROP wykonuje się zgodnie z harmonogramem. Zadanie SDPROP wykonuje się tylko raz na godzinę (domyślnie). W konsekwencji może minąć nawet godzina, zanim konto dodane do grupy chronionej zostanie zidentyfikowane przez SDPROP jako część zestawu obiektów chronionych. Oznacza to, że jeśli obiekt stanie się członkiem – bezpośrednio lub przejściowo – obiektu chronionego i członkostwo to zostanie usunięte przed wykonaniem SDPROP, obiekt nie zostanie zidentyfikowany jako obiekt chroniony, a wartość atrybutu AdminCount obiektu pozostanie niezmieniona.
Problem nr 2
SDPROP aktualizuje atrybut AdminCount, gdy modyfikuje deskryptor bezpieczeństwa obiektu (listę DACL). O co tu chodzi? Otóż SDPROP nie zwraca uwagi na wartość atrybutu AdminCount obiektu. Jeżeli SDPROP aktualizuje deskryptor zabezpieczeń chronionego obiektu, ustawi wartość jego atrybutu AdminCount na 1. Jeżeli deskryptor zabezpieczeń chronionego obiektu odpowiada Autorytatywnemu Deskryptorowi Bezpieczeństwa, SDPROP pozostawi atrybut AdminCount chronionego obiektu bez zmian, niezależnie od jego wartości. W konsekwencji, zmiana lub usunięcie wartości atrybutu AdminCount chronionego obiektu może skutecznie ukryć chronione obiekty przed prostym skanowaniem do celów raportowych.
Problem nr 3a
SDPROP patrzy tylko na aktywnych członków zbioru obiektów chronionych. Skanowanie SDPROP rozpoczyna się od członków domyślnego zestawu obiektów chronionych, jednakże obiekty wysoko uprzywilejowane, które nie są członkami domyślnego zestawu obiektów chronionych, są ignorowane przez SDPROP, a wartość ich atrybutu AdminCount pozostanie nieustawiona [NOT SET]. W rezultacie nie można polegać na atrybucie AdminCount w celu zidentyfikowania wszystkich obiektów wysoko uprzywilejowanych w domenie.
Problem nr 3b
SDPROP patrzy tylko na aktywnych członków zbioru obiektów chronionych. Gdy obiekt chroniony zostanie usunięty z grup, po których odziedziczył swój status chroniony, będzie następnie ignorowany przez SDPROP, nadal wyglądając dokładnie jak obiekt chroniony. Dzieje się tak dlatego, że Active Directory nie posiada mechanizmu cofania zmian dokonanych przez SDPROP, gdy obiekt stał się członkiem zbioru obiektów chronionych. Obiekt zostanie osierocony a wartość atrybutu AdminCount obiektu pozostaje ustawiona na 1 (lub jakąkolwiek wartość miał przed zmianą przynależności do grupy). Co ważniejsze, deskryptor zabezpieczeń obiektu również pozostanie niezmieniony i będzie nadal blokował dziedziczenie zabezpieczeń od rodziców obiektu. Jest to bardzo istotna kwestia w sytuacji zarządzania uprawnieniami do obiektów.
Problem nr 4
SDPROP nie rozróżnia kategorii grup. Gdy SDPROP przeszukuje członków domyślnego zestawu obiektów chronionych, ignoruje kategorię grup członkowskich. Cofając się nieco w czasie, grupy Active Directory należą do jednej z dwóch kategorii: grupy bezpieczeństwa i grupy dystrybucyjne. Grupy bezpieczeństwa mogą przekazywać uprawnienia swoim członkom, natomiast grupy dystrybucyjne nie. Ponieważ zmiana kategorii grupy zmieni jej zdolność do nadawania przywilejów jej członkom, SDPROP całkowicie ignoruje kategorie grup, aby zapobiec nadużywaniu tego zachowania.
Podsumowanie
AdminCount oraz związane z nim zachowania i procesy są o wiele bardziej złożone, niż większość ludzi zdaje się to doceniać.
Otwarcie sesji konsoli PowerShell i uruchomienie polecenia:
Get-ADObject -LDAPFilter “(adminCount=1)”
nie mówi nam, które obiekty są chronione przez SDPROP; a jedynie, które obiekty mają atrybut AdminCount o wartości 1. Jedynym niezawodnym sposobem dokładnego zidentyfikowania chronionych obiektów jest zrobienie dokładnie tego, co robi SDPROP, czyli zidentyfikowanie domyślnego zestawu chronionych obiektów domeny i określenie pełnego członkostwa każdego z tych obiektów. Atrybut AdminCount jest tylko flagą. Aby zrozumieć, co ta flaga może powiedzieć, musisz również zrozumieć, czego nie jest w stanie ci powiedzieć.
Na koniec dla zainteresowanych w poniższej tabeli zamieściliśmy ściągawkę. Zamieściliśmy domyślne zestawy chronionych obiektów usługi Active Directory, w tym grup, które mogą powodować aktualizację atrybutu AdminCount na jego członkach.
