W mechanizmie uwierzytelniania do usługi Azure Active Directory (Azure AD) Microsoft naprawił lukę, która mogła umożliwić cyberprzestępcom eskalację uprawnień i potencjalne całkowite przejęcie konta ofiary.
Podatność, nazwana „nOAuth” przez odpowiedzialny za jej wykrycie zespół ds. zabezpieczeń Descope, kryje się w błędnej konfiguracji aplikacji używających mechanizmu uwierzytelniania Azure AD OAuth. Może być wykorzystana w atakach na konta i eskalacji uprawnień w aplikacjach posiadających skonfigurowaną autoryzację OAth na podstawie adresu e-mail (token JWT).
Krótko o nOAuth i błędnej konfiguracji
nOAuth to luka w implementacji uwierzytelniania, mogąca wywierać wpływ na wielodostępne aplikacje OAuth Microsoft Azure AD. Specjaliści z Descope piszą na ten temat następująco:
- Zgodnie ze specyfikacją OAuth użytkownik jest jednoznacznie identyfikowany przez roszczenie „sub” (podmiot).
- Większość dostawców tożsamości zapewnia powszechne (choć niestandardowe) żądanie „e-mail”.
- Używanie żądania adresu e-mail jako identyfikatora użytkownika staje się problemem, gdy żądanie to jest zmienne, dlatego większość dostawców tożsamości odradza używanie adresu e-mail jako identyfikatora.
- W usłudze Microsoft Azure AD żądanie adresu e-mail jest zarówno zmienne, jak i niezweryfikowane, więc nigdy nie należy mu ufać ani używać go jako identyfikatora.
- Zły aktor może zmienić atrybut „e-mail” w obszarze „Informacje kontaktowe” na koncie usługi Azure AD, aby kontrolować żądanie „e-mail” w zwróconym tokenie tożsamości JWT.
Powyższe wystarczy atakującym do przejęcia pełnej kontroli nad kontem ofiary, jeżeli docelowe zasoby zezwalały na używanie adresów e-mail jako unikalnych identyfikatorów podczas procesu autoryzacji.
„Łączny efekt powyższych punktów umożliwia osobie atakującej, która utworzyła swoją dzierżawę usługi Azure AD, użycie funkcji «Zaloguj się dzięki firmy Microsoft» z podatną na ataki aplikacją i specjalnie spreparowaną «ofiarą», co skutkuje całkowitym przejęciem konta”.
Taktyka ta mogła być również stosowana, gdy ofiara nie miała choćby konta Microsoft, ponieważ usługa Azure AD nie wymagała sprawdzania poprawności zmian w wiadomościach e-mail.
Skutki ataku nOath
Po pomyślnym zalogowaniu atakujący ma otwarte pole w zależności od charakteru przejętej aplikacji lub witryny. Może ustanowić trwałość, eksfiltrować dane, zbadać, czy ruch boczny jest możliwy i tak dalej.
Wśród wielu dużych organizacji podatnych na tego typu ataki Descope odkrył firmę, która posiada aplikację do projektowania (z milionami użytkowników miesięcznie), notowaną na giełdzie firmę zajmującą się obsługą klienta oraz jedną należącą do wiodącego dostawcy usług konsultingowych w zakresie wielu środowisk chmurowych.
Descope udostępnił również film (zamieszczamy go poniżej), w którym szczegółowo opisano, w jaki sposób wykorzystanie tej błędnej konfiguracji uwierzytelniania usługi AAD może doprowadzić do całkowitego przejęcia konta.
Co na to Microsoft?
Microsoft naprawił konfigurację nOAuth dzięki środków zaradczych wydanych wczoraj, po wstępnym raporcie wysłanym przez Descope 11 kwietnia 2023 r. „Microsoft zidentyfikował kilka aplikacji obsługujących wielu dzierżawców, których użytkownicy używają adresu e-mail niezweryfikowanego właściciela domeny” – poinformował gigant z Redmond.
Firma opublikowała również przewodnik do sprawdzania, czy aplikacja, której używasz, jest narażona na ten atak. Znajdziesz go tutaj. Zdecydowanie zaleciła również programistom, aby dokładnie przeanalizowali logikę biznesową autoryzacji swoich aplikacji i przestrzegali wytycznych w celu zabezpieczenia przed nieautoryzowanym dostępem.
Ponadto Microsoft zachęca deweloperów do przyjęcia zalecanych najlepszych rozwiązań dotyczących sprawdzania poprawności tokenów podczas korzystania z platformy tożsamości firmy Microsoft.
