OAuth to Account takeover
Last updated
Last updated
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)
OAuth oferuje różne wersje, z podstawowymi informacjami dostępnymi w dokumentacji OAuth 2.0. Ta dyskusja koncentruje się głównie na szeroko stosowanym typie przyznawania kodu autoryzacji OAuth 2.0, zapewniając ramy autoryzacji, które umożliwiają aplikacji dostęp do konta użytkownika w innej aplikacji lub wykonywanie działań w jego imieniu (serwer autoryzacji).
Rozważmy hipotetyczną stronę https://example.com, zaprojektowaną w celu prezentacji wszystkich twoich postów w mediach społecznościowych, w tym prywatnych. Aby to osiągnąć, wykorzystuje się OAuth 2.0. https://example.com poprosi o twoją zgodę na dostęp do twoich postów w mediach społecznościowych. W konsekwencji na https://socialmedia.com pojawi się ekran zgody, przedstawiający żądane uprawnienia oraz dewelopera składającego wniosek. Po twojej autoryzacji, https://example.com zyskuje możliwość dostępu do twoich postów w twoim imieniu.
Ważne jest, aby zrozumieć następujące elementy w ramach OAuth 2.0:
właściciel zasobu: Ty, jako użytkownik/podmiot, autoryzujesz dostęp do swojego zasobu, jak posty na twoim koncie w mediach społecznościowych.
serwer zasobów: serwer zarządzający uwierzytelnionymi żądaniami po tym, jak aplikacja zabezpieczyła token dostępu w imieniu właściciela zasobu, np. https://socialmedia.com.
aplikacja kliencka: aplikacja ubiegająca się o autoryzację od właściciela zasobu, taka jak https://example.com.
serwer autoryzacji: serwer, który wydaje tokeny dostępu dla aplikacji klienckiej po pomyślnej autoryzacji właściciela zasobu i zabezpieczeniu autoryzacji, np. https://socialmedia.com.
client_id: Publiczny, unikalny identyfikator aplikacji.
client_secret: Poufny klucz, znany tylko aplikacji i serwerowi autoryzacji, używany do generowania tokenów dostępu.
response_type: Wartość określająca typ żądanego tokena, jak code.
scope: poziom dostępu, o który aplikacja kliencka prosi właściciela zasobu.
redirect_uri: URL, na który użytkownik jest przekierowywany po autoryzacji. Zazwyczaj musi być zgodny z wcześniej zarejestrowanym URL przekierowania.
state: Parametr do utrzymywania danych podczas przekierowania użytkownika do i z serwera autoryzacji. Jego unikalność jest kluczowa jako mechanizm ochrony przed CSRF.
grant_type: Parametr wskazujący typ przyznania i typ tokena do zwrócenia.
code: Kod autoryzacji z serwera autoryzacji, używany razem z client_id i client_secret przez aplikację kliencką do uzyskania tokena dostępu.
access_token: token, którego aplikacja kliencka używa do żądań API w imieniu właściciela zasobu.
refresh_token: Umożliwia aplikacji uzyskanie nowego tokena dostępu bez ponownego pytania użytkownika.
Rzeczywisty przepływ OAuth przebiega następująco:
Przechodzisz do https://example.com i wybierasz przycisk „Integruj z mediami społecznościowymi”.
Strona następnie wysyła żądanie do https://socialmedia.com, prosząc o twoją autoryzację, aby aplikacja https://example.com mogła uzyskać dostęp do twoich postów. Żądanie jest skonstruowane w następujący sposób:
Następnie zostaniesz przedstawiony stronie zgody.
Po twojej akceptacji, Social Media wysyła odpowiedź na redirect_uri z parametrami code i state:
https://example.com wykorzystuje ten code, razem z jego client_id i client_secret, aby zrealizować żądanie po stronie serwera w celu uzyskania access_token w Twoim imieniu, umożliwiając dostęp do uprawnień, na które wyraziłeś zgodę:
Na koniec proces kończy się, gdy https://example.com wykorzystuje twój access_token, aby wykonać wywołanie API do Social Media w celu uzyskania dostępu
redirect_uri jest kluczowy dla bezpieczeństwa w implementacjach OAuth i OpenID, ponieważ kieruje, gdzie wrażliwe dane, takie jak kody autoryzacji, są wysyłane po autoryzacji. Jeśli jest źle skonfigurowany, może pozwolić atakującym na przekierowanie tych żądań do złośliwych serwerów, co umożliwia przejęcie konta.
Techniki eksploatacji różnią się w zależności od logiki walidacji serwera autoryzacji. Mogą obejmować od ścisłego dopasowania ścieżek do akceptowania dowolnego URL w określonej domenie lub podkatalogu. Powszechne metody eksploatacji obejmują otwarte przekierowania, przechodzenie przez ścieżki, wykorzystywanie słabych wyrażeń regularnych oraz wstrzykiwanie HTML w celu kradzieży tokenów.
Oprócz redirect_uri, inne parametry OAuth i OpenID, takie jak client_uri, policy_uri, tos_uri i initiate_login_uri, są również podatne na ataki przekierowujące. Parametry te są opcjonalne, a ich wsparcie różni się w zależności od serwerów.
Dla tych, którzy celują w serwer OpenID, punkt końcowy odkrywania (**.well-known/openid-configuration**) często zawiera cenne szczegóły konfiguracyjne, takie jak registration_endpoint, request_uri_parameter_supported i "require_request_uri_registration. Te szczegóły mogą pomóc w identyfikacji punktu końcowego rejestracji i innych specyfikacji konfiguracyjnych serwera.
Jak wspomniano w tym raporcie o bug bounty https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, może być możliwe, że URL przekierowania jest odzwierciedlany w odpowiedzi serwera po uwierzytelnieniu użytkownika, co czyni go podatnym na XSS. Możliwy ładunek do przetestowania:
W implementacjach OAuth, niewłaściwe użycie lub pominięcie parametru state może znacznie zwiększyć ryzyko ataków Cross-Site Request Forgery (CSRF). Ta podatność występuje, gdy parametr state jest nieużywany, używany jako statyczna wartość lub niewłaściwie walidowany, co pozwala atakującym na ominięcie ochrony CSRF.
Atakujący mogą to wykorzystać, przechwytując proces autoryzacji, aby powiązać swoje konto z kontem ofiary, co prowadzi do potencjalnych przejęć konta. Jest to szczególnie krytyczne w aplikacjach, w których OAuth jest używany do celów uwierzytelniania.
Przykłady tej podatności w rzeczywistych sytuacjach zostały udokumentowane w różnych wyzwaniach CTF i platformach hackingowych, podkreślając jej praktyczne implikacje. Problem ten dotyczy również integracji z usługami stron trzecich, takimi jak Slack, Stripe i PayPal, gdzie atakujący mogą przekierowywać powiadomienia lub płatności na swoje konta.
Właściwe zarządzanie i walidacja parametru state są kluczowe dla ochrony przed CSRF i zabezpieczenia przepływu OAuth.
Bez weryfikacji e-maila przy tworzeniu konta: Atakujący mogą prewencyjnie stworzyć konto używając e-maila ofiary. Jeśli ofiara później użyje usługi strony trzeciej do logowania, aplikacja może nieumyślnie powiązać to konto strony trzeciej z kontem stworzonym przez atakującego, co prowadzi do nieautoryzowanego dostępu.
Wykorzystywanie luźnej weryfikacji e-maila w OAuth: Atakujący mogą wykorzystać usługi OAuth, które nie weryfikują e-maili, rejestrując się w ich usłudze, a następnie zmieniając e-mail konta na e-mail ofiary. Ta metoda podobnie naraża na nieautoryzowany dostęp do konta, podobnie jak w pierwszym scenariuszu, ale przez inny wektor ataku.
Identyfikacja i ochrona tajnych parametrów OAuth jest kluczowa. Podczas gdy client_id można bezpiecznie ujawniać, ujawnienie client_secret wiąże się z poważnymi ryzykami. Jeśli client_secret zostanie skompromitowane, atakujący mogą wykorzystać tożsamość i zaufanie aplikacji do kradzieży access_tokens użytkowników i prywatnych informacji.
Powszechna podatność występuje, gdy aplikacje błędnie obsługują wymianę code autoryzacji na access_token po stronie klienta, a nie serwera. Ten błąd prowadzi do ujawnienia client_secret, umożliwiając atakującym generowanie access_tokens pod przykrywką aplikacji. Ponadto, poprzez inżynierię społeczną, atakujący mogą eskalować uprawnienia, dodając dodatkowe zakresy do autoryzacji OAuth, dalej wykorzystując zaufany status aplikacji.
Możesz spróbować bruteforce'ować client_secret dostawcy usług z dostawcą tożsamości, aby spróbować ukraść konta. Żądanie do BF może wyglądać podobnie do:
Gdy klient ma code i state, jeśli są odzwierciedlone w nagłówku Referer podczas przeglądania innej strony, to jest podatne.
Przejdź do historii przeglądarki i sprawdź, czy token dostępu jest tam zapisany.
Kod autoryzacji powinien żyć tylko przez pewien czas, aby ograniczyć czas, w którym atakujący może go ukraść i użyć.
Jeśli możesz uzyskać kod autoryzacji i użyć go z innym klientem, to możesz przejąć inne konta.
W tym raporcie o bug bounty: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ możesz zobaczyć, że token, który AWS Cognito zwraca użytkownikowi, może mieć wystarczające uprawnienia do nadpisania danych użytkownika. Dlatego, jeśli możesz zmienić adres e-mail użytkownika na inny adres e-mail, możesz być w stanie przejąć inne konta.
For more detailed info about how to abuse AWS cognito check:
Jak wspomniano w tym artykule, przepływy OAuth, które oczekują otrzymania tokena (a nie kodu), mogą być podatne, jeśli nie sprawdzają, czy token należy do aplikacji.
Dzieje się tak, ponieważ atakujący może stworzyć aplikację wspierającą OAuth i logować się za pomocą Facebooka (na przykład) w swojej własnej aplikacji. Następnie, gdy ofiara zaloguje się za pomocą Facebooka w aplikacji atakującego, atakujący może uzyskać token OAuth użytkownika przyznany jego aplikacji i użyć go do zalogowania się w aplikacji OAuth ofiary, używając tokena użytkownika ofiary.
Dlatego, jeśli atakujący zdoła uzyskać dostęp użytkownika do swojej własnej aplikacji OAuth, będzie mógł przejąć konto ofiary w aplikacjach, które oczekują tokena i nie sprawdzają, czy token został przyznany ich identyfikatorowi aplikacji.
Zgodnie z tym artykułem, możliwe było zmuszenie ofiary do otwarcia strony z returnUrl wskazującym na host atakującego. Te informacje byłyby przechowywane w ciasteczku (RU), a w późniejszym kroku prompt zapyta użytkownika, czy chce udzielić dostępu do hosta atakującego.
Aby obejść ten prompt, możliwe było otwarcie zakładki w celu zainicjowania przepływu Oauth, który ustawiłby to ciasteczko RU za pomocą returnUrl, zamknięcie zakładki przed wyświetleniem promptu i otwarcie nowej zakładki bez tej wartości. Wtedy prompt nie poinformuje o hoście atakującego, ale ciasteczko zostanie ustawione na niego, więc token zostanie wysłany do hosta atakującego w przekierowaniu.
Jak wyjaśniono w tym filmie, niektóre implementacje OAuth pozwalają wskazać parametr GET prompt jako None (&prompt=none), aby zapobiec pytaniu użytkowników o potwierdzenie danego dostępu w prompt w sieci, jeśli są już zalogowani na platformie.
Jak wyjaśniono w tym filmie, możliwe jest wskazanie parametru response_mode, aby określić, gdzie chcesz, aby kod został podany w końcowym URL:
response_mode=query -> Kod jest podawany wewnątrz parametru GET: ?code=2397rf3gu93f
response_mode=fragment -> Kod jest podawany wewnątrz fragmentu URL #code=2397rf3gu93f
response_mode=form_post -> Kod jest podawany wewnątrz formularza POST z polem o nazwie code i wartością
response_mode=web_message -> Kod jest wysyłany w wiadomości post: window.opener.postMessage({"code": "asdasdasd...
Zgodnie z tym wpisem na blogu, jest to przepływ OAuth, który pozwala na logowanie się w OAuth za pomocą nazwa użytkownika i hasła. Jeśli podczas tego prostego przepływu zwrócony zostanie token z dostępem do wszystkich działań, które użytkownik może wykonać, to możliwe jest ominięcie 2FA za pomocą tego tokena.
Sprawdź to badanie Aby uzyskać dalsze szczegóły tej techniki.
Dynamiczna rejestracja klienta w OAuth służy jako mniej oczywisty, ale krytyczny wektor dla luk w zabezpieczeniach, szczególnie dla ataków Server-Side Request Forgery (SSRF). Ten punkt końcowy pozwala serwerom OAuth na otrzymywanie szczegółów dotyczących aplikacji klienckich, w tym wrażliwych adresów URL, które mogą być wykorzystane.
Kluczowe punkty:
Dynamiczna rejestracja klienta często jest mapowana na /register i akceptuje szczegóły takie jak client_name, client_secret, redirect_uris oraz adresy URL dla logo lub zestawów kluczy JSON Web Key (JWK) za pomocą żądań POST.
Ta funkcja przestrzega specyfikacji zawartych w RFC7591 i OpenID Connect Registration 1.0, które zawierają parametry potencjalnie podatne na SSRF.
Proces rejestracji może nieumyślnie narażać serwery na SSRF na kilka sposobów:
logo_uri: Adres URL dla logo aplikacji klienckiej, które może być pobrane przez serwer, wywołując SSRF lub prowadząc do XSS, jeśli adres URL jest źle obsługiwany.
jwks_uri: Adres URL do dokumentu JWK klienta, który, jeśli zostanie złośliwie skonstruowany, może spowodować, że serwer wykona zewnętrzne żądania do serwera kontrolowanego przez atakującego.
sector_identifier_uri: Odnosi się do tablicy JSON redirect_uris, którą serwer może pobrać, tworząc możliwość SSRF.
request_uris: Wymienia dozwolone URI żądań dla klienta, które mogą być wykorzystane, jeśli serwer pobiera te URI na początku procesu autoryzacji.
Strategia eksploatacji:
SSRF można wywołać, rejestrując nowego klienta z złośliwymi adresami URL w parametrach takich jak logo_uri, jwks_uri lub sector_identifier_uri.
Chociaż bezpośrednia eksploatacja za pomocą request_uris może być ograniczona przez kontrole białej listy, dostarczenie wcześniej zarejestrowanego, kontrolowanego przez atakującego request_uri może ułatwić SSRF podczas fazy autoryzacji.
Jeśli platforma, którą testujesz, jest dostawcą OAuth przeczytaj to, aby przetestować możliwe warunki wyścigu.
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
