Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-23 13:13:41 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/oauth-to-account-takeover.md

19 KiB
Raw Blame History

OAuth do przejęcia konta

Nauka hakowania AWS od zera do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks:

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

Podstawowe informacje

OAuth oferuje różne wersje, z podstawowymi informacjami dostępnymi na stronie dokumentacji OAuth 2.0. Ta dyskusja skupia się głównie na powszechnie używanym typie autoryzacji OAuth 2.0, zapewniającym framework autoryzacji, który umożliwia aplikacji dostęp lub wykonywanie działań na koncie użytkownika w innej aplikacji (serwer autoryzacji).

Rozważmy hipotetyczną stronę internetową https://example.com, zaprojektowaną do prezentowania wszystkich Twoich postów na mediach społecznościowych, w tym tych prywatnych. Aby to osiągnąć, wykorzystywane jest OAuth 2.0. https://example.com poprosi o zgodę na dostęp do Twoich postów na mediach społecznościowych. W rezultacie na https://socialmedia.com pojawi się ekran zgody, przedstawiający uprawnienia, które są żądane, oraz dewelopera dokonującego żądania. Po udzieleniu zgody, https://example.com uzyskuje możliwość dostępu do Twoich postów w Twoim imieniu.

Należy zrozumieć następujące komponenty w ramach frameworka OAuth 2.0:

  • właściciel zasobu: Ty, jako użytkownik/encja, autoryzujesz dostęp do swojego zasobu, takiego jak Twoje posty na 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 poszukuje autoryzacji od właściciela zasobu, taka jak 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: Poufny 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: URL, do którego użytkownik jest przekierowywany po autoryzacji. Zazwyczaj musi to być zgodne z wcześniej zarejestrowanym adresem przekierowania.
  • state: Parametr służący do przechowywania danych podczas przekierowania użytkownika do i z serwera autoryzacji. Jego unikalność jest kluczowa dla pełnienia roli mechanizmu ochrony CSRF.
  • grant_type: Parametr wskazujący typ autoryzacji i typ zwracanego tokenu.
  • code: Kod autoryzacji z serwera autoryzacji, używany wspólnie z client_id i client_secret przez aplikację klienta do uzyskania tokena dostępu.
  • access_token: Token, którego 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.

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 wysyła żądanie do https://socialmedia.com, prosząc o Twoją autoryzację, aby pozwolić aplikacji https://example.com na dostęp 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

  1. Następnie zostajesz poproszony o wyrażenie zgody.

  2. Po udzieleniu zgody, Media Społecznościowe wysyła odpowiedź do redirect_uri z parametrami code i state:

https://example.com?code=uniqueCode123&state=randomString123
  1. https://example.com wykorzystuje ten code, wraz z jego 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"}
  1. Ostatecznie proces kończy się, gdy https://example.com wykorzystuje Twój access_token do wykonania wywołania interfejsu API do mediów społecznościowych w celu uzyskania dostępu

Luki

Otwarte przekierowanie redirect_uri

redirect_uri jest kluczowy dla bezpieczeństwa w implementacjach OAuth i OpenID, ponieważ określa, dokąd są wysyłane wrażliwe dane, takie jak kody autoryzacyjne, po autoryzacji. W przypadku błędnej konfiguracji, 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 autoryzacyjnego. Mogą one obejmować od dokładnego dopasowania ścieżki do akceptowania dowolnego adresu URL w określonej domenie lub podkatalogu. Powszechne metody eksploatacji obejmują otwarte przekierowania, nawigację ścieżką, wykorzystywanie słabych wyrażeń regularnych oraz wstrzykiwanie HTML w celu kradzieży tokena.

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, istnieje możliwość, że adres URL przekierowania jest odzwierciedlany w odpowiedzi serwera po uwierzytelnieniu użytkownika, co czyni go podatnym na XSS. Możliwy ładunek do testowania:

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

CSRF - Niewłaściwe przetwarzanie parametru stanu

W implementacjach OAuth, nadużycie lub pominięcie parametru state może znacząco zwiększyć ryzyko ataków typu Cross-Site Request Forgery (CSRF). Ta podnośność pojawia się, gdy parametr state jest albo nie używany, używany jako wartość statyczna, albo nieprawidłowo zweryfikowany, co pozwala atakującym ominąć zabezpieczenia 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 do celów uwierzytelniania.

Przykłady tej podatności w rzeczywistym świecie zostały udokumentowane w różnych wyzwaniach CTF i platformach do hakowania, podkreślając 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ą przekierować powiadomienia lub płatności na swoje konta.

Prawidłowe przetwarzanie i weryfikacja parametru state są kluczowe dla ochrony przed CSRF i zabezpieczenia przepływu OAuth.

Przed Przejęciem Konta

  1. Bez Weryfikacji Email podczas Tworzenia Konta: Atakujący mogą uprzednio 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 Email 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 niesie ryzyko nieautoryzowanego dostępu do konta, podobnie jak w pierwszym scenariuszu, ale poprzez inny wektor ataku.

Ujawnienie Sekretów

Identyfikacja i ochrona tajnych parametrów OAuth są kluczowe. Podczas gdy client_id można bezpiecznie ujawnić, ujawnienie client_secret niesie ze sobą znaczne ryzyko. Jeśli client_secret zostanie skompromitowany, atakujący mogą wykorzystać tożsamość i zaufanie aplikacji do kradzieży access_tokens oraz prywatnych informacji.

Powszechną podatnością jest sytuacja, gdy aplikacje błędnie obsługują wymianę 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_tokens pod przykrywką aplikacji. Ponadto, poprzez inżynierię społeczną, atakujący mogą eskalować uprawnienia, dodając dodatkowe zakresy autoryzacji OAuth, dalsze wykorzystując zaufane status aplikacji.

Bruteforce Sekretu Klienta

Możesz spróbować przeprowadzić atak bruteforce na client_secret dostawcy usług z dostawcą 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 nagłówka Referer z kodem + stanem

Kiedy klient ma kod i stan, jeśli jest odzwierciedlony w nagłówku Referer podczas przeglądania innej strony, to jest podatny.

Token dostępu przechowywany w historii przeglądarki

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

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 użyć.

Token autoryzacji/odświeżania niezwią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 & Post Messages do wycieku kodu & wartości stanu

Sprawdź ten post

AWS Cognito

W tym raporcie z programu 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 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"
}
]
}

Nadużywanie tokenów innych aplikacji

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

To dlatego, że atakujący mógłby stworzyć aplikację obsługującą OAuth i zalogować się przez Facebooka (na przykład) w swojej własnej aplikacji. Następnie, gdy ofiara zaloguje się przez Facebooka w aplikacji atakującego, atakujący mógłby uzyskać token OAuth użytkownika udzielony jego aplikacji i użyć go do zalogowania się w aplikacji OAuth ofiary, korzystając z tokenu użytkownika ofiary.

{% hint style="danger" %} Dlatego jeśli atakujący zdoła zdobyć dostęp użytkownika 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ł udzielony dla ich identyfikatora aplikacji. {% endhint %}

Dwa linki i ciasteczko

Zgodnie z tym opracowaniem, było możliwe, aby sprawić, że ofiara otworzy stronę z returnUrl wskazującą na host atakującego. Te informacje byłyby przechowywane w ciasteczku (RU), a w późniejszym kroku prompt zapyta użytkownika, czy chce dać dostęp do tego hosta atakującego.

Aby ominąć ten prompt, można było otworzyć kartę, aby zainicjować przepływ OAuth, który ustawiałby to ciasteczko RU, używając returnUrl, zamknąć kartę przed pokazaniem się promptu i otworzyć nową kartę 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.

Parametry SSRF

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

Dynamiczna Rejestracja Klienta w OAuth służy jako mniej oczywisty, ale krytyczny wektor podatności na bezpieczeństwo, w szczególności dla ataków Server-Side Request Forgery (SSRF). Ten punkt końcowy pozwala serwerom OAuth otrzymywać szczegóły dotyczące aplikacji klienta, 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 do logotypów lub zestawów kluczy JSON Web Key (JWKs) za pomocą żądań POST.
  • Ta funkcja przestrzega specyfikacji określonych w RFC7591 i OpenID Connect Registration 1.0, które obejmują parametry potencjalnie 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 źle 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órą serwer może pobrać, tworząc okazję do SSRF.
  • request_uris: Wylicza dozwolone adresy URI żądań dla klienta, które mogą być wykorzystane, jeśli serwer pobiera te adresy URI na początku procesu autoryzacji.

Strategia Wykorzystania:

  • SSRF może zostać wywołane poprzez zarejestrowanie nowego klienta z złośliwymi adresami URL w parametrach takich jak logo_uri, jwks_uri lub sector_identifier_uri.
  • Podczas gdy bezpośrednie wykorzystanie poprzez request_uris może być ograniczone przez kontrole białej listy, dostarczenie wcześniej zarejestrowanego, kontrolowanego przez atakującego request_uri może ułatwić SSRF podczas fazy autoryzacji.

Wyścig dostawców OAuth

Jeśli platforma, którą testujesz, jest dostawcą OAuth, przeczytaj to, aby przetestować możliwe wyścigi.

Referencje

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

Naucz się hakować AWS od zfszero do bohatera z htARTE (HackTricks AWS Red Team Expert)!

Inne sposoby wsparcia HackTricks: