OAuth to Account takeover
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)
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Podstawowe informacje
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ą do 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 uzyskała
access token
w imieniuwł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
access tokens
dlaaplikacji klienckiej
po pomyślnej autoryzacjiwłaściciela zasobu
, np. https://socialmedia.com.client_id: Publiczny, unikalny identyfikator aplikacji.
client_secret: Poufny klucz, znany tylko aplikacji i serwerowi autoryzacji, używany do generowania
access_tokens
.response_type: Wartość określająca typ żądanego tokena, jak
code
.scope: poziom dostępu, o który
aplikacja kliencka
prosiwł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 zclient_id
iclient_secret
przez aplikację kliencką do uzyskaniaaccess_token
.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
access_token
bez ponownego pytania użytkownika.
Przepływ
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 z prośbą o twoją autoryzację, aby aplikacja https://example.com mogła uzyskać dostęp do twoich postów. Żądanie jest skonstruowane jako:
Następnie zostaniesz przedstawiony stronie zgody.
Po twojej akceptacji, Social Media wysyła odpowiedź do
redirect_uri
z parametramicode
istate
:
https://example.com wykorzystuje ten
code
, razem z jegoclient_id
iclient_secret
, aby zrealizować żądanie po stronie serwera w celu uzyskaniaaccess_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
Luki
Otwarty redirect_uri
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.
XSS w implementacji przekierowania
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:
CSRF - Niewłaściwe zarządzanie parametrem state
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.
Przed przejęciem konta
Bez weryfikacji e-maila przy tworzeniu konta: Atakujący mogą z wyprzedzeniem stworzyć konto używając e-maila ofiary. Jeśli ofiara później użyje usługi stron trzecich do logowania, aplikacja może nieumyślnie powiązać to konto z wcześniej stworzonym kontem 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.
Ujawnienie sekretów
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.
Bruteforce klienta sekretu
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:
Referer Header leaking Code + State
Gdy klient ma kod i stan, jeśli są one odzwierciedlone w nagłówku Referer podczas przeglądania innej strony, to jest podatny.
Access Token Stored in Browser History
Przejdź do historii przeglądarki i sprawdź, czy token dostępu jest tam zapisany.
Everlasting Authorization Code
Kod autoryzacji powinien żyć tylko przez pewien czas, aby ograniczyć czas, w którym atakujący może go ukraść i użyć.
Authorization/Refresh Token not bound to client
Jeśli możesz uzyskać kod autoryzacji i użyć go z innym klientem, to możesz przejąć inne konta.
Happy Paths, XSS, Iframes & Post Messages to leak code & state values
AWS Cognito
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:
Abusing other Apps tokens
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.
Two links & cookie
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 zapytuje 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 używając 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.
Prompt Interaction Bypass
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.
response_mode
Jak wyjaśniono w tym filmie, może być możliwe 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 nazwiecode
i wartościąresponse_mode=web_message
-> Kod jest wysyłany w wiadomości post:window.opener.postMessage({"code": "asdasdasd...
SSRFs parameters
Sprawdź to badanie Aby uzyskać dalsze szczegóły na temat 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 otrzymywać szczegóły dotyczące aplikacji klienckich, w tym wrażliwe adresy URL, które mogą być wykorzystane.
Kluczowe punkty:
Dynamiczna rejestracja klienta jest często mapowana na
/register
i akceptuje szczegóły takie jakclient_name
,client_secret
,redirect_uris
oraz adresy URL dla logo lub zestawów kluczy JSON Web (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óry może być pobierany 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 JSONredirect_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
lubsector_identifier_uri
.Chociaż bezpośrednia eksploatacja za pomocą
request_uris
może być ograniczona przez kontrole białej listy, dostarczenie wstępnie zarejestrowanego, kontrolowanego przez atakującegorequest_uri
może ułatwić SSRF podczas fazy autoryzacji.
OAuth providers Race Conditions
Jeśli platforma, którą testujesz, jest dostawcą OAuth przeczytaj to, aby przetestować możliwe warunki wyścigu.
References
![](https://book.hacktricks.xyz/~gitbook/image?url=https%3A%2F%2Fpentest.eu%2FRENDER_WebSec_10fps_21sec_9MB_29042024.gif&width=768&dpr=4&quality=100&sign=bc0743d1&sv=1)
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking:
HackTricks Training GCP Red Team Expert (GRTE)
Last updated