mirror of https://github.com/carlospolop/hacktricks synced 2025-01-26 03:45:05 +00:00

Carlos Polop 5e833204fc Recreating repository history for branch pl

2024-12-12 13:54:31 +01:00

21 KiB

Raw Blame History

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 na githubie.

{% 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ą 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 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 on odpowiadać wcześniej zarejestrowanemu 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, który ma być zwrócony.
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:

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:

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

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?code=uniqueCode123&state=randomString123

https://example.com wykorzystuje ten code, razem z jego client_id i client_secret, aby złożyć żą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"}

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ą sięgać od ścisłego dopasowania ścieżek do akceptowania dowolnego URL w określonej domenie lub podkatalogu. Do powszechnych metod eksploatacji należą otwarte przekierowania, traversowanie ścieżek, 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 stanu

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 korzysta z usługi stron trzecich do logowania, aplikacja może nieumyślnie powiązać to konto z wcześniej utworzonym 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 adres 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ą zwiększyć 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ć okno czasowe, 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

As mentioned in this writeup, OAuth flows that expect to receive the token (and not a code) could be vulnerable if they not check that the token belongs to the app.

This is because an attacker could create an application supporting OAuth and login with Facebook (for example) in his own application. Then, once a victim logins with Facebook in the attackers application, the attacker could get the OAuth token of the user given to his application, and use it to login in the victim OAuth application using the victims user token.

{% hint style="danger" %} Therefore, if the attacker manages to get the user access his own OAuth application, he will be able to take over the victims account in applications that are expecting a token and aren't checking if the token was granted to their app ID. {% endhint %}

According to this writeup, it was possible to make a victim open a page with a returnUrl pointing to the attackers host. This info would be stored in a cookie (RU) and in a later step the prompt will ask the user if he wants to give access to that attackers host.

To bypass this prompt, it was possible to open a tab to initiate the Oauth flow that would set this RU cookie using the returnUrl, close the tab before the prompt is shown, and open a new tab without that value. Then, the prompt won't inform about the attackers host, but the cookie would be set to it, so the token will be sent to the attackers host in the redirection.

Prompt Interaction Bypass

As explained in this video, some OAuth implementations allows to indicate the prompt GET parameter as None (&prompt=none) to prevent users being asked to confirm the given access in a prompt in the web if they are already logged in the platform.

response_mode

As explained in this video, it might be possible to indicate the parameter response_mode to indicate where do you want the code to be provided in the final URL:

response_mode=query -> Kod jest dostarczany wewnątrz parametru GET: ?code=2397rf3gu93f
response_mode=fragment -> Kod jest dostarczany wewnątrz fragmentu URL #code=2397rf3gu93f
response_mode=form_post -> Kod jest dostarczany 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...

OAuth ROPC flow - 2 FA bypass

According to this blog post, this is an OAuth flow that allows to login in OAuth via username and password. If during this simple flow a token with access to all the actions the user can perform is returned then it's possible to bypass 2FA using that token.

ATO on web page redirecting based on open redirect to referrer

This blogpost comments how it was possible to abuse an open redirect to the value from the referrer to abuse OAuth to ATO. The attack was:

Ofiara uzyskuje dostęp do strony atakującego
Ofiara otwiera złośliwy link, a otwieracz inicjuje przepływ OAuth Google z response_type=id_token,code&prompt=none jako dodatkowymi parametrami, używając jako referrer strony atakującego.
W otwieraczu, po tym jak dostawca autoryzuje ofiarę, odsyła ich z powrotem do wartości parametru redirect_uri (strona ofiary) z kodem 30X, który nadal utrzymuje stronę atakującego w refererze.
Strona ofiary wywołuje otwarty przekierowanie na podstawie referera, przekierowując użytkownika ofiary na stronę atakującego, ponieważ respose_type był id_token,code, kod zostanie odesłany do atakującego w fragmencie URL, co pozwoli mu przejąć konto użytkownika za pośrednictwem Google na stronie ofiary.

SSRFs parameters

Check this research For further details of this technique.

Dynamic Client Registration in OAuth serves as a less obvious but critical vector for security vulnerabilities, specifically for Server-Side Request Forgery (SSRF) attacks. This endpoint allows OAuth servers to receive details about client applications, including sensitive URLs that could be exploited.

Key Points:

Dynamic Client Registration is often mapped to /register and accepts details like client_name, client_secret, redirect_uris, and URLs for logos or JSON Web Key Sets (JWKs) via POST requests.
This feature adheres to specifications laid out in RFC7591 and OpenID Connect Registration 1.0, which include parameters potentially vulnerable to SSRF.
The registration process can inadvertently expose servers to SSRF in several ways:
logo_uri: URL dla logo aplikacji klienckiej, które może być pobrane przez serwer, wywołując SSRF lub prowadząc do XSS, jeśli URL jest źle obsługiwany.
jwks_uri: 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óre serwer może pobrać, tworząc możliwość SSRF.
request_uris: Wymienia dozwolone URI żądań dla klienta, które mogą być wykorzystywane, jeśli serwer pobiera te URI na początku procesu autoryzacji.

Exploitation Strategy:

SSRF może być wywołane przez zarejestrowanie nowego klienta z złośliwymi URL w parametrach takich jak logo_uri, jwks_uri lub sector_identifier_uri.
Chociaż bezpośrednie wykorzystanie przez request_uris może być ograniczone 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

If the platform you are testing is an OAuth provider read this to test for possible Race Conditions.

References