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

OAuth do przejęcia konta

Dowiedz się, jak hakować AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

• Jeśli chcesz zobaczyć swoją firmę reklamowaną w HackTricks lub pobrać HackTricks w formacie PDF, sprawdź SUBSCRIPTION PLANS!
• Zdobądź oficjalne gadżety PEASS & HackTricks
• Odkryj Rodzinę PEASS, naszą kolekcję ekskluzywnych NFT
• Dołącz do 💬 grupy Discord lub grupy telegramowej lub śledź nas na Twitterze 🐦 @carlospolopm.
• Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do HackTricks i HackTricks Cloud github repos.

Podstawowe informacje

OAuth oferuje różne wersje, a podstawowe informacje są dostępne w dokumentacji OAuth 2.0. Niniejsza dyskusja skupia się głównie na powszechnie stosowanym typie autoryzacji OAuth 2.0 - kod autoryzacyjny, który zapewnia ramy autoryzacji, umożliwiające aplikacji dostęp lub wykonywanie działań na koncie użytkownika w innej aplikacji (serwer autoryzacji).

Rozważmy hipotetyczną witrynę https://example.com, która ma na celu prezentację wszystkich Twoich postów w mediach społecznościowych, w tym prywatnych. W tym celu wykorzystywany jest OAuth 2.0. https://example.com poprosi o zgodę na dostęp do Twoich postów w mediach społecznościowych. W rezultacie na https://socialmedia.com pojawi się ekran zgody, na którym będą przedstawione uprawnienia, które są żądane, oraz deweloper, który składa żądanie. Po udzieleniu autoryzacji https://example.com uzyskuje możliwość dostępu do Twoich postów w Twoim imieniu.

Ważne jest zrozumienie następujących komponentów w ramach OAuth 2.0:

• właściciel zasobu: Ty, jako użytkownik/entitet, autoryzujesz dostęp do swojego zasobu, takiego jak posty na koncie w mediach społecznościowych.
• serwer zasobów: Serwer zarządzający uwierzytelnionymi żądaniami po tym, jak aplikacja uzyskała token dostępu w imieniu właściciela zasobu, np. https://socialmedia.com.
• aplikacja klienta: Aplikacja, która ubiega się o autoryzację od właściciela zasobu, np. https://example.com.
• serwer autoryzacji: Serwer, który wydaje tokeny dostępu dla aplikacji klienta po pomyślnym uwierzytelnieniu właściciela zasobu i uzyskaniu autoryzacji, np. https://socialmedia.com.
• client_id: Publiczny, unikalny identyfikator aplikacji.
• client_secret: Tajny klucz, znany tylko aplikacji i serwerowi autoryzacji, używany do generowania tokenów dostępu.
• response_type: Wartość określająca typ żądanego tokenu, np. code.
• scope: Poziom dostępu, który aplikacja klienta żąda od właściciela zasobu.
• redirect_uri: Adres URL, na który użytkownik zostanie przekierowany po autoryzacji. Zazwyczaj musi być zgodny z wcześniej zarejestrowanym adresem URL przekierowania.
• state: Parametr służący do przekazywania danych między przekierowaniem użytkownika a serwerem autoryzacji. Jego unikalność jest istotna dla zapewnienia ochrony przed CSRF.
• grant_type: Parametr wskazujący typ autoryzacji i typ żądanego tokenu.
• code: Kod autoryzacji z serwera autoryzacji, używany w połączeniu z client_id i client_secret przez aplikację klienta do uzyskania tokena dostępu.
• access_token: Token, który aplikacja klienta 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.

Przebieg

Rzeczywisty przebieg OAuth wygląda następująco:

1. Przechodzisz do https://example.com i wybierasz przycisk "Integruj z mediami społecznościowymi".
2. Strona wysyła żądanie do https://socialmedia.com, prosząc o autoryzację dostępu aplikacji https://example.com do Twoich postów. Żądanie jest zbudowane 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

3. Następnie zostajesz przekierowany na stronę zgody.

4. Po zatwierdzeniu, Social Media wysyła odpowiedź na redirect_uri z parametrami code i state:

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

5. https://example.com wykorzystuje ten code, wraz z client_id i client_secret, aby dokonać żądania 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. Ostatecznie proces kończy się, gdy https://example.com używa twojego access_token do wykonania wywołania API do Social Media w celu uzyskania dostępu.

Podatności

Otwarte przekierowanie redirect_uri

redirect_uri jest kluczowy dla bezpieczeństwa w implementacjach OAuth i OpenID, ponieważ kieruje, gdzie wysyłane są wrażliwe dane, takie jak kody autoryzacji, po autoryzacji. Jeśli jest źle skonfigurowany, może umożliwić atakującym przekierowanie tych żądań do złośliwych serwerów, umożliwiając przejęcie konta.

Techniki eksploatacji różnią się w zależności od logiki walidacji serwera autoryzacji. Mogą obejmować odporne dopasowanie ścieżki, akceptowanie dowolnego adresu URL w określonej domenie lub podkatalogu. Powszechne metody eksploatacji obejmują otwarte przekierowania, przechodzenie ścieżek, wykorzystywanie słabych wyrażeń regularnych i 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 przekierowania. Te parametry są opcjonalne, a ich obsługa różni się w zależności od serwerów.

Dla osób celujących w serwer OpenID, punkt końcowy odkrywania (**.well-known/openid-configuration**) często zawiera cenne szczegóły konfiguracji, 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 szczegółów konfiguracji serwera.

XSS w implementacji przekierowania

Jak wspomniano w tym raporcie z programu bug bounty https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html, możliwe jest, że URL przekierowania jest odbijany 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 obsługiwanie parametru 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 albo nie używany, używany jako wartość statyczna, albo nieprawidłowo sprawdzany, co umożliwia atakującym obejście zabezpieczeń CSRF.

Atakujący mogą wykorzystać to, przechwytując proces autoryzacji, aby połączyć swoje konto z kontem ofiary, co prowadzi do potencjalnego przejęcia konta. Jest to szczególnie krytyczne w aplikacjach, gdzie OAuth jest używany w celach uwierzytelniania.

Przykłady tej podatności w świecie rzeczywistym zostały udokumentowane w różnych wyzwaniach CTF i platformach do hakowania, co podkreśla jej praktyczne implikacje. Problem ten dotyczy również integracji z usługami osób trzecich, takimi jak Slack, Stripe i PayPal, gdzie atakujący mogą przekierowywać powiadomienia lub płatności na swoje konta.

Prawidłowe obsługiwanie i sprawdzanie parametru state są kluczowe dla ochrony przed CSRF i zabezpieczenia przepływu OAuth.

Przed przejęciem konta

1. Bez weryfikacji adresu e-mail podczas tworzenia konta: Atakujący mogą wcześniej utworzyć konto, używając adresu e-mail ofiary. Jeśli ofiara później użyje usługi osób trzecich do logowania, aplikacja może nieumyślnie połączyć to konto osób trzecich z wcześniej utworzonym kontem atakującego, co prowadzi do nieautoryzowanego dostępu.

2. Wykorzystanie luźnej weryfikacji e-mail w OAuth: Atakujący mogą wykorzystać usługi OAuth, które nie weryfikują adresów e-mail, rejestrując się w ich usłudze, a następnie zmieniając adres e-mail konta na adres ofiary. Ta metoda podobnie naraża na nieautoryzowany dostęp do konta, podobnie jak w pierwszym scenariuszu, ale za pomocą innego wektora ataku.

Ujawnienie sekretów

Identyfikacja i ochrona tajnych parametrów OAuth jest kluczowa. Podczas gdy client_id można bezpiecznie ujawnić, ujawnienie client_secret niesie ze sobą znaczne ryzyko. Jeśli client_secret zostanie kompromitowany, atakujący mogą wykorzystać tożsamość i zaufanie aplikacji, aby ukraść access_tokeny i prywatne informacje.

Powszechną podatnością jest niewłaściwe obsługiwane wymiany kodu autoryzacji na access_token po stronie klienta, a nie po stronie serwera. Ten błąd prowadzi do ujawnienia client_secret, umożliwiając atakującym generowanie access_tokenów pod przykrywką aplikacji. Ponadto, za pomocą inżynierii społecznej, atakujący mogą eskalować uprawnienia, dodając dodatkowe zakresy do autoryzacji OAuth, dalsze wykorzystując zaufane statusu aplikacji.

Bruteforce tajnego klienta

Możesz spróbować przełamać tajny klienta dostawcy usług przy użyciu dostawcy tożsamości, aby próbować kraść 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]

Wyciek kodu i stanu za pomocą nagłówka Referer

Jeśli klient posiada kod i stan, a są one odzwierciedlone w nagłówku Referer podczas przeglądania innej strony, to jest to podatność.

Token dostępu przechowywany w historii przeglądarki

Przejdź do historii przeglądarki i sprawdź, czy token dostępu jest tam zapisany.

Wieczny kod autoryzacyjny

Kod autoryzacyjny powinien istnieć tylko przez pewien czas, aby ograniczyć okno czasowe, w którym atakujący może go ukraść i wykorzystać.

Token autoryzacyjny/odświeżania niepowiązany z klientem

Jeśli możesz uzyskać kod autoryzacyjny i użyć go z innym klientem, to możesz przejąć inne konta.

Szczęśliwe ścieżki, XSS, Iframes i Post Messages do wycieku kodu i wartości stanu

Sprawdź ten post

AWS Cognito

W raporcie z programu bug bounty: https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/ można 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 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"
}
]
}

Aby uzyskać bardziej szczegółowe informacje na temat nadużywania AWS Cognito, sprawdź:

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

Nadużywanie tokenów innych aplikacji

Jak wspomniano w tym opracowaniu, przepływy OAuth, które oczekują otrzymania tokenu (a nie kodu), mogą być podatne, jeśli nie sprawdzają, czy token należy do aplikacji.

Dzieje się tak dlatego, że atakujący może stworzyć aplikację obsługującą OAuth i zalogować 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 przekazany do swojej aplikacji i użyć go do zalogowania się w aplikacji OAuth ofiary, używając tokenu użytkownika ofiary.

{% hint style="danger" %} Dlatego jeśli atakujący zdoła skłonić użytkownika do udostępnienia dostępu do swojej własnej aplikacji OAuth, będzie mógł przejąć konto ofiary w aplikacjach, które oczekują tokenu i nie sprawdzają, czy token został przyznany dla ich identyfikatora aplikacji. {% endhint %}

Dwa linki i cookie

Zgodnie z tym opracowaniem, było możliwe zmuszenie ofiary do otwarcia strony z returnUrl, wskazującą na host atakującego. Te informacje były przechowywane w pliku cookie (RU), a w kolejnym kroku okno dialogowe pytało użytkownika, czy chce udzielić dostępu temu hostowi atakującego.

Aby ominąć to okno dialogowe, można było otworzyć kartę, aby rozpocząć przepływ OAuth, który ustawiałby to plik cookie RU za pomocą returnUrl, zamknąć kartę przed wyświetleniem okna dialogowego i otworzyć nową kartę bez tej wartości. Wtedy okno dialogowe nie informowałoby o hostu atakującego, ale plik cookie byłby do niego ustawiony, więc token zostanie wysłany do hosta atakującego w przekierowaniu.

Parametry SSRF

Sprawdź tę analizę dla dalszych szczegółów na temat tej techniki.

Dynamiczna rejestracja klienta w OAuth stanowi mniej oczywisty, ale krytyczny wektor podatności na bezpieczeństwo, zwłaszcza dla ataków typu Server-Side Request Forgery (SSRF). Ten punkt końcowy umożliwia serwerom OAuth otrzymywanie informacji na temat aplikacji klienta, w tym wrażliwych adresów 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 logotypów lub zestawów kluczy JSON Web (JWKs) za pomocą żądań POST.
• Ta funkcja przestrzega specyfikacji określonej w RFC7591 i OpenID Connect Registration 1.0, która obejmuje parametry podatne na SSRF.
• Proces rejestracji może nieumyślnie narazić serwery na SSRF na kilka sposobów:
• logo_uri: Adres URL logotypu aplikacji klienta, który może być pobrany przez serwer, wywołując SSRF lub prowadząc do XSS, jeśli adres URL jest nieprawidłowo obsługiwany.
• jwks_uri: Adres URL do dokumentu JWK klienta, który w przypadku złośliwego opracowania może spowodować, że serwer wyśle żądania do serwera kontrolowanego przez atakującego.
• sector_identifier_uri: Odwołuje się do tablicy JSON redirect_uris, które serwer może pobrać, tworząc możliwość SSRF.
• request_uris: Wylicza dozwolone adresy URL żądań dla klienta, które mogą być wykorzystane, jeśli serwer pobiera te adresy URL na początku procesu autoryzacji.

Strategia wykorzystania:

• 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średnie wykorzystanie za pomocą request_uris może być ograniczone przez kontrolę listy białej, dostarczenie wcześniej zarejestrowanego, kontrolowanego przez atakującego request_uri może ułatwić SSRF podczas fazy autoryzacji.