Az - Illicit Consent Grant
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Aplikacje Azure proszą o uprawnienia do uzyskania dostępu do danych użytkownika (podstawowe informacje, ale także dostęp do dokumentów, wysyłanie e-maili...).
Jeśli dozwolone, zwykły użytkownik może udzielić zgody tylko na "niskie ryzyko" uprawnienia. W wszystkich innych przypadkach wymagana jest zgoda administratora.
GA
, ApplicationAdministrator
, CloudApplication
Administrator
oraz niestandardowa rola obejmująca uprawnienia do udzielania zgód aplikacjom
mogą zapewnić zgodę na poziomie całego dzierżawcy.
Tylko uprawnienia, które nie wymagają zgody administratora, są klasyfikowane jako niskie ryzyko. Są to uprawnienia wymagane do podstawowego logowania, takie jak openid, profil, e-mail, User.Read i offline_access. Jeśli organizacja pozwala na udzielanie zgody użytkownikom dla wszystkich aplikacji, pracownik może udzielić zgody aplikacji na odczytanie powyższych informacji z jego profilu.
Dlatego atakujący mógłby przygotować złośliwą aplikację i za pomocą phishingu sprawić, że użytkownik zaakceptuje aplikację i ukradnie jego dane.
Nieautoryzowane: Z zewnętrznego konta utwórz aplikację z uprawnieniami User.Read
i User.ReadBasic.All
, na przykład, phishinguj użytkownika, a będziesz mógł uzyskać dostęp do informacji w katalogu.
To wymaga, aby phishingowany użytkownik mógł akceptować aplikacje OAuth z zewnętrznych środowisk!
Autoryzowane: Po skompromitowaniu głównego konta z wystarczającymi uprawnieniami, utwórz aplikację wewnątrz konta i phishinguj niektórego uprzywilejowanego użytkownika, który może zaakceptować uprzywilejowane uprawnienia OAuth.
W tym przypadku możesz już uzyskać dostęp do informacji w katalogu, więc uprawnienie User.ReadBasic.All
nie jest już interesujące.
Prawdopodobnie interesują cię uprawnienia, które wymagają zgody administratora, ponieważ zwykły użytkownik nie może przyznać aplikacjom OAuth żadnych uprawnień, dlatego musisz phishingować tylko tych użytkowników (więcej na temat ról/uprawnień, które przyznają to uprawnienie później).
Poniższe polecenie PowerShell jest używane do sprawdzenia konfiguracji zgody dla użytkowników w Azure Active Directory (Azure AD) w odniesieniu do ich zdolności do udzielania zgody na aplikacje:
Wyłącz zgodę użytkownika: To ustawienie zabrania użytkownikom przyznawania uprawnień aplikacjom. Nie jest dozwolona zgoda użytkownika na aplikacje.
Użytkownicy mogą wyrażać zgodę na aplikacje od zweryfikowanych wydawców lub twojej organizacji, ale tylko na wybrane przez ciebie uprawnienia: To ustawienie pozwala wszystkim użytkownikom na wyrażenie zgody tylko na aplikacje opublikowane przez zweryfikowanego wydawcę oraz aplikacje zarejestrowane w twoim własnym dzierżawcy. Dodaje to warstwę kontroli, pozwalając na zgodę tylko na konkretne uprawnienia.
Użytkownicy mogą wyrażać zgodę na wszystkie aplikacje: To ustawienie jest bardziej liberalne i pozwala wszystkim użytkownikom na wyrażenie zgody na dowolne uprawnienia dla aplikacji, o ile te uprawnienia nie wymagają zgody administracyjnej.
Własna polityka zgody na aplikacje: To ustawienie wskazuje, że obowiązuje własna polityka, która może być dostosowana do specyficznych wymagań organizacyjnych i może obejmować kombinację ograniczeń opartych na wydawcy aplikacji, uprawnieniach, o które prosi aplikacja, oraz innych czynnikach.
W ataku typu illicit consent grant, napastnicy oszukują użytkowników końcowych, aby przyznali uprawnienia złośliwej aplikacji zarejestrowanej w Azure. Dzieje się to poprzez sprawienie, że aplikacja wydaje się wiarygodna, co prowadzi ofiary do nieświadomego kliknięcia przycisku "Akceptuj". W rezultacie Azure AD wydaje token na stronę napastnika, co pozwala im uzyskać dostęp i manipulować danymi ofiary, takimi jak czytanie lub wysyłanie e-maili oraz dostęp do plików, bez potrzeby posiadania konta organizacyjnego.
Atak obejmuje kilka kroków, które celują w ogólną firmę. Oto jak może się to rozwinąć:
Rejestracja domeny i hosting aplikacji: Napastnik rejestruje domenę przypominającą zaufaną stronę, na przykład "safedomainlogin.com". Pod tą domeną tworzona jest subdomena (np. "companyname.safedomainlogin.com"), aby hostować aplikację zaprojektowaną do przechwytywania kodów autoryzacyjnych i żądania tokenów dostępu.
Rejestracja aplikacji w Azure AD: Napastnik następnie rejestruje aplikację wielodostępną w swoim dzierżawcy Azure AD, nazywając ją na cześć docelowej firmy, aby wydawała się wiarygodna. Konfiguruje URL przekierowania aplikacji, aby wskazywał na subdomenę hostującą złośliwą aplikację.
Ustawienie uprawnień: Napastnik ustawia aplikację z różnymi uprawnieniami API (np. Mail.Read
, Notes.Read.All
, Files.ReadWrite.All
, User.ReadBasic.All
, User.Read
). Te uprawnienia, po przyznaniu przez użytkownika, pozwalają napastnikowi na wydobycie wrażliwych informacji w imieniu użytkownika.
Dystrybucja złośliwych linków: Napastnik tworzy link zawierający identyfikator klienta złośliwej aplikacji i dzieli się nim z docelowymi użytkownikami, oszukując ich, aby przyznali zgodę.
Atak można ułatwić za pomocą narzędzi takich jak 365-Stealer.
Jeśli napastnik ma pewien poziom dostępu do użytkownika w organizacji ofiary, może sprawdzić, czy polityka organizacji pozwala użytkownikowi na akceptację aplikacji:
Aby przeprowadzić atak, atakujący musiałby stworzyć nową aplikację w swoim dzierżawcy Azure (w rejestracjach aplikacji), skonfigurowaną z uprawnieniami:
User.ReadBasic.All
znajduje się w Microsoft Graph
w Delegated permissions
. (Uprawnienia aplikacji zawsze będą wymagały dodatkowej zgody).
User.ReadBasic.All
to uprawnienie, które pozwoli ci czytać informacje o wszystkich użytkownikach w organizacji, jeśli zostanie przyznane.
Pamiętaj, że tylko GA
, ApplicationAdministrator
, CloudApplication
Administrator
oraz niestandardowa rola zawierająca uprawnienia do przyznawania uprawnień aplikacjom
mogą udzielić zgody na poziomie dzierżawcy. Dlatego powinieneś phishować użytkownika z jedną z tych ról, jeśli chcesz, aby zatwierdził aplikację, która wymaga zgody administratora.
Możesz również stworzyć aplikację za pomocą cli z:
Sprawdź https://www.alteredsecurity.com/post/introduction-to-365-stealer, aby dowiedzieć się, jak to skonfigurować.
Zauważ, że uzyskany token dostępu będzie dla punktu końcowego grafu z zakresami: User.Read
i User.ReadBasic.All
(żądane uprawnienia). Nie będziesz mógł wykonać innych działań (ale te są wystarczające, aby pobierać informacje o wszystkich użytkownikach w organizacji).
Możesz również użyć tego narzędzia do przeprowadzenia tego ataku.
Gdy uzyskasz dostęp do użytkownika, możesz robić rzeczy takie jak kradzież wrażliwych dokumentów, a nawet przesyłanie zainfekowanych plików dokumentów.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)