Az - Illicit Consent Grant
OAuth App Phishing
Azure Applications proszą o uprawnienia do 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 wyrazić zgodę tylko na "Low Impact permissions". W wszystkich innych przypadkach, wymagana jest zgoda administratora.
GA
, ApplicationAdministrator
, CloudApplication
Administrator
i niestandardowa rola zawierająca permission to grant permissions to applications
mogą udzielić zgody na poziomie dzierżawy.
Tylko uprawnienia, które nie wymagają zgody administratora, są klasyfikowane jako low impact. Są to uprawnienia wymagane do podstawowego logowania: openid, profile, email, User.Read i offline_access. Jeśli organizacja zezwala na zgodę użytkownika dla wszystkich aplikacji, pracownik może wyrazić zgodę na aplikację, aby odczytać powyższe informacje z ich 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.
2 Typy Ataków Illicit Consent Grant
Niezautoryzowany: Z zewnętrznego konta utwórz aplikację z uprawnieniami
User.Read
iUser.ReadBasic.All
na przykład, phish użytkownika, i będziesz mógł uzyskać dostęp do informacji katalogowych.To wymaga, aby phished użytkownik mógł akceptować aplikacje OAuth z zewnętrznych środowisk!
Zautoryzowany: Mając skompromitowany podmiot z wystarczającymi uprawnieniami, utwórz aplikację wewnątrz konta i phish niektórych uprzywilejowanych użytkowników, którzy mogą akceptować uprzywilejowane uprawnienia OAuth.
W tym przypadku możesz już uzyskać dostęp do informacji katalogowych, więc uprawnienie
User.ReadBasic.All
nie jest już interesujące.Prawdopodobnie jesteś zainteresowany uprawnieniami, które wymagają zgody administratora, ponieważ zwykły użytkownik nie może przyznać aplikacjom OAuth żadnych uprawnień, dlatego musisz phishować tylko tych użytkowników (więcej na temat, które role/uprawnienia przyznają to uprawnienie później)
Sprawdź, czy użytkownicy mogą wyrazić zgodę
Następujące 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 wyrażania zgody na aplikacje:
Disable user consent: To ustawienie zabrania użytkownikom udzielania uprawnień aplikacjom. Żadna zgoda użytkownika na aplikacje nie jest dozwolona.
Users can consent to apps from verified publishers or your organization, but only for permissions you select: To ustawienie pozwala wszystkim użytkownikom na udzielanie zgody tylko na aplikacje opublikowane przez zweryfikowanego wydawcę oraz aplikacje zarejestrowane w Twoim tenant. Dodaje warstwę kontroli, pozwalając na zgodę tylko na określone uprawnienia.
Users can consent to all apps: To ustawienie jest bardziej liberalne i pozwala wszystkim użytkownikom na udzielanie zgody na dowolne uprawnienia dla aplikacji, o ile te uprawnienia nie wymagają zgody administracyjnej.
Custom app consent policy: To ustawienie wskazuje, że obowiązuje niestandardowa polityka, która może być dostosowana do specyficznych wymagań organizacyjnych i może obejmować kombinację ograniczeń opartych na wydawcy aplikacji, uprawnieniach żądanych przez aplikację i innych czynnikach.
Understanding Illicit Consent Grant Attack
W ataku typu illicit consent grant, atakujący oszukują użytkowników końcowych, aby udzielili uprawnień złośliwej aplikacji zarejestrowanej w Azure. Odbywa się to poprzez sprawienie, że aplikacja wygląda na legalną, co prowadzi ofiary do nieświadomego kliknięcia przycisku "Akceptuj". W rezultacie Azure AD wydaje token do strony atakującego, umożliwiając im dostęp i manipulowanie danymi ofiary, takimi jak czytanie lub wysyłanie e-maili oraz dostęp do plików, bez potrzeby posiadania konta organizacyjnego.
Attack Flow Overview
Atak obejmuje kilka kroków, które są skierowane na ogólną firmę. Oto jak może się to rozwinąć:
Domain Registration and Application Hosting: Atakujący rejestruje domenę przypominającą zaufaną stronę, na przykład "safedomainlogin.com". Pod tą domeną tworzy subdomenę (np. "companyname.safedomainlogin.com") do hostowania aplikacji zaprojektowanej do przechwytywania kodów autoryzacyjnych i żądania tokenów dostępu.
Application Registration in Azure AD: Następnie atakujący rejestruje aplikację Multi-Tenant w swoim tenant Azure AD, nazywając ją po nazwie docelowej firmy, aby wyglądała na legalną. Konfiguruje URL przekierowania aplikacji, aby wskazywał na subdomenę hostującą złośliwą aplikację.
Setting Up Permissions: Atakujący konfiguruje aplikację z różnymi uprawnieniami API (np.
Mail.Read
,Notes.Read.All
,Files.ReadWrite.All
,User.ReadBasic.All
,User.Read
). Te uprawnienia, po udzieleniu przez użytkownika, pozwalają atakującemu na wyciąganie wrażliwych informacji w imieniu użytkownika.Distributing Malicious Links: Atakujący tworzy link zawierający client id złośliwej aplikacji i udostępnia go docelowym użytkownikom, oszukując ich, aby udzielili zgody.
Utilizing Tools for the Attack
Atak może być ułatwiony przy użyciu narzędzi takich jak 365-Stealer.
Pre-Attack Preparation:
Jeśli atakujący 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 utworzyć nową aplikację w swoim Azure Tenant (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
i niestandardowa rola zawierającauprawnienie do przyznawania uprawnień aplikacjom
mogą udzielić zgody na poziomie tenant. Więc powinieneś phishować użytkownika z jedną z tych ról, jeśli chcesz, aby zatwierdził aplikację wymagającą zgody administratora.
Możesz również utworzyć aplikację za pomocą cli z:
Sprawdź https://www.alteredsecurity.com/post/introduction-to-365-stealer, aby dowiedzieć się, jak to skonfigurować.
Zauważ, że uzyskany access token będzie dla graph endpoint z zakresami: User.Read
i User.ReadBasic.All
(żądane uprawnienia). Nie będziesz mógł wykonywać innych działań (ale te wystarczą, aby pobrać informacje o wszystkich użytkownikach w organizacji).
Możesz również użyć tego narzędzia do przeprowadzenia tego ataku.
Post-Exploitation
Po uzyskaniu dostępu do użytkownika możesz robić takie rzeczy, jak kradzież poufnych dokumentów, a nawet przesyłanie plików dokumentów z backdoorem.
References
Last updated