hacktricks/pentesting-web/oauth-to-account-takeover.md

OAuth do przejęcia konta

{% hint style="success" %} 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)

Wsparcie dla HackTricks

• Sprawdź plany subskrypcyjne!
• Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @hacktricks_live.
• Podziel się trikami hackingowymi, przesyłając PR-y do HackTricks i HackTricks Cloud repozytoriów github.

{% endhint %}

{% embed url="https://websec.nl/" %}

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 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 access tokens dla aplikacji klienckiej po pomyślnej autoryzacji wł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 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 access_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:

1. Przechodzisz do https://example.com i wybierasz przycisk „Integruj z mediami społecznościowymi”.
2. 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:

https://socialmedia.com/auth
?response_type=code
&client_id=example_clientId
&redirect_uri=https%3A%2F%2Fexample.com%2Fcallback
&scope=readPosts
&state=randomString123

3. Następnie zostaniesz przedstawiony stronie zgody.
4. Po twojej akceptacji, Social Media wysyła odpowiedź do redirect_uri z parametrami code i state:

https://example.com?code=uniqueCode123&state=randomString123

5. 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ę:

POST /oauth/access_token
Host: socialmedia.com
...{"client_id": "example_clientId", "client_secret": "example_clientSecret", "code": "uniqueCode123", "grant_type": "authorization_code"}

6. 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:

https://app.victim.com/login?redirectUrl=https://app.victim.com/dashboard</script><h1>test</h1>

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

1. 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.
2. 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:

POST /token HTTP/1.1
content-type: application/x-www-form-urlencoded
host: 10.10.10.10:3000
content-length: 135
Connection: close

code=77515&redirect_uri=http%3A%2F%2F10.10.10.10%3A3000%2Fcallback&grant_type=authorization_code&client_id=public_client_id&client_secret=[bruteforce]

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

Sprawdź ten post

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.

# Read info of the user
aws cognito-idp get-user --region us-east-1 --access-token eyJraWQiOiJPVj[...]

# Change email address
aws cognito-idp update-user-attributes --region us-east-1 --access-token eyJraWQ[...] --user-attributes Name=email,Value=imaginary@flickr.com
{
"CodeDeliveryDetailsList": [
{
"Destination": "i***@f***.com",
"DeliveryMedium": "EMAIL",
"AttributeName": "email"
}
]
}

For more detailed info about how to abuse AWS cognito check:

{% embed url="https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum" %}

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.

{% hint style="danger" %} 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. {% endhint %}

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 nazwie code 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 jak client_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 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 wstępnie zarejestrowanego, kontrolowanego przez atakującego request_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://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors

{% embed url="https://websec.nl/" %}

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

• Check the subscription plans!
• Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
• Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}