OAuth do przejęcia konta

Reading time: 13 minutes

Podstawowe informacje

OAuth oferuje różne wersje, z podstawowymi informacjami dostępnymi w OAuth 2.0 documentation. Ta dyskusja koncentruje się głównie na szeroko stosowanym OAuth 2.0 authorization code grant type, zapewniając ramy autoryzacji, które umożliwiają aplikacji dostęp do konta użytkownika w innej aplikacji lub wykonywanie działań na tym koncie (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 prośbę. 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 komponenty 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 zabezpieczył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 i zabezpieczeniu autoryzacji, np. https://socialmedia.com.
• client_id: Publiczny, unikalny identyfikator aplikacji.
• client_secret: Poufny klucz, znany wyłącznie 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, 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:

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

3. Następnie zostaniesz przedstawiony stronie zgody.
4. Po twojej akceptacji, 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, 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"}

6. Na koniec proces kończy się, gdy https://example.com wykorzystuje twój access_token, aby wykonać wywołanie API do Social Media, aby uzyskać dostęp

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, traversale ścieżek, wykorzystywanie słabych regexów 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ść pojawia się, 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 połączyć 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 warunkach 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 połączyć 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 również niesie ryzyko nieautoryzowanego dostępu 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 stwarza znaczące ryzyko. 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ść pojawia się, gdy aplikacje błędnie obsługują wymianę code autoryzacji na access_token po stronie klienta zamiast 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 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"
}
]
}

Dla bardziej szczegółowych informacji na temat nadużywania AWS cognito sprawdź:

{{#ref}} https://cloud.hacktricks.xyz/pentesting-cloud/aws-pentesting/aws-unauthenticated-enum-access/aws-cognito-unauthenticated-enum {{#endref}}

Nadużywanie tokenów innych aplikacji

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 loguje 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.

Dwa linki i cookie

Zgodnie z tym artykułem, możliwe było zmuszenie ofiary do otwarcia strony z returnUrl wskazującym na hosta atakującego. Te informacje byłyby przechowywane w cookie (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 cookie 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 cookie zostanie ustawione na niego, więc token zostanie wysłany do hosta atakującego w przekierowaniu.

Obejście interakcji z promptem

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 przyznanego dostępu w promptcie 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 ostatecznym 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...

Przepływ OAuth ROPC - obejście 2 FA

Zgodnie z tym wpisem na blogu, jest to przepływ OAuth, który pozwala na logowanie się w OAuth za pomocą nazwa użytkownika i hasła. Jeśli podczas tego prostego przepływu zwrócony zostanie token z dostępem do wszystkich działań, które użytkownik może wykonać, to możliwe jest obejście 2FA przy użyciu tego tokena.

ATO na stronie internetowej przekierowującej na podstawie otwartego przekierowania do referrera

Ten wpis na blogu opisuje, jak możliwe było nadużycie otwartego przekierowania do wartości z referrera, aby nadużyć OAuth do ATO. Atak polegał na:

1. Ofiara uzyskuje dostęp do strony internetowej atakującego
2. Ofiara otwiera złośliwy link, a opener rozpoczyna przepływ Google OAuth z response_type=id_token,code&prompt=none jako dodatkowymi parametrami, używając jako referrera strony internetowej atakującego.
3. W openerze, 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ę internetową atakującego w refererze.
4. Strona ofiary wywołuje otwarte przekierowanie na podstawie referrera, przekierowując użytkownika ofiary na stronę internetową atakującego, ponieważ respose_type był id_token,code, kod zostanie odesłany z powrotem do atakującego w fragmencie URL, co pozwoli mu przejąć konto użytkownika za pośrednictwem Google na stronie ofiary.

Parametry SSRFs

Sprawdź to badanie Aby uzyskać dalsze szczegóły na temat tej techniki.

Dynamiczna rejestracja klienta w OAuth stanowi 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 na otrzymywanie szczegółów dotyczących aplikacji klienckich, w tym wrażliwych adresów URL, które mogą być wykorzystywane.

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óre może być pobierane 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ó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.

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 wcześniej zarejestrowanego, kontrolowanego przez atakującego request_uri może ułatwić SSRF podczas fazy autoryzacji.

Warunki wyścigu dostawców OAuth

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

Odniesienia

• https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1
• https://portswigger.net/research/hidden-oauth-attack-vectors