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

228 lines
19 KiB
Markdown
Raw Blame History

# OAuth do przejęcia konta
<details>
<summary><strong>Nauka hakowania AWS od zera do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Inne sposoby wsparcia HackTricks:
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) na GitHubie.
</details>
<figure><img src="/.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
## Podstawowe informacje <a href="#d4a8" id="d4a8"></a>
OAuth oferuje różne wersje, z podstawowymi informacjami dostępnymi na stronie [dokumentacji OAuth 2.0](https://oauth.net/2/). Ta dyskusja skupia się głównie na powszechnie używanym [typie autoryzacji OAuth 2.0](https://oauth.net/2/grant-types/authorization-code/), 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](https://example.com) i wybierasz przycisk „Integruj z mediami społecznościowymi”.
2. Strona wysyła żądanie do [https://socialmedia.com](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
```
3. Następnie zostajesz poproszony o wyrażenie zgody.
4. 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
```
5. 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"}
```
6. 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 <a href="#323a" id="323a"></a>
### Otwarte przekierowanie `redirect_uri` <a href="#cc36" id="cc36"></a>
`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 <a href="#bda5" id="bda5"></a>
Jak wspomniano w tym raporcie z programu bug bounty [https://blog.dixitaditya.com/2021/11/19/account-takeover-chain.html](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 <a href="#bda5" id="bda5"></a>
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 <a href="#ebe4" id="ebe4"></a>
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 <a href="#e177" id="e177"></a>
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](https://labs.detectify.com/writeups/account-hijacking-using-dirty-dancing-in-sign-in-oauth-flows/#gadget-2-xss-on-sandbox-third-party-domain-that-gets-the-url)**
### AWS Cognito <a href="#bda5" id="bda5"></a>
W tym raporcie z programu bug bounty: [**https://security.lauritz-holtmann.de/advisories/flickr-account-takeover/**](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.
```bash
# 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 <a href="#bda5" id="bda5"></a>
Jak [**wspomniano w tym opracowaniu**](https://salt.security/blog/oh-auth-abusing-oauth-to-take-over-millions-of-accounts), 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 <a href="#bda5" id="bda5"></a>
Zgodnie z [**tym opracowaniem**](https://medium.com/@metnew/why-electron-apps-cant-store-your-secrets-confidentially-inspect-option-a49950d6d51f), 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 <a href="#bda5" id="bda5"></a>
**[Sprawdź tę analizę](https://portswigger.net/research/hidden-oauth-attack-vectors) 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**](race-condition.md).
## Referencje
* [**https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1**](https://medium.com/a-bugz-life/the-wondeful-world-of-oauth-bug-bounty-edition-af3073b354c1)
* [**https://portswigger.net/research/hidden-oauth-attack-vectors**](https://portswigger.net/research/hidden-oauth-attack-vectors)
<figure><img src="/.gitbook/assets/WebSec_1500x400_10fps_21sn_lightoptimized_v2.gif" alt=""><figcaption></figcaption></figure>
{% embed url="https://websec.nl/" %}
<details>
<summary><strong>Naucz się hakować AWS od zfszero do bohatera z</strong> <a href="https://training.hacktricks.xyz/courses/arte"><strong>htARTE (HackTricks AWS Red Team Expert)</strong></a><strong>!</strong></summary>
Inne sposoby wsparcia HackTricks:
* Jeśli chcesz zobaczyć swoją **firmę reklamowaną w HackTricks** lub **pobrać HackTricks w formacie PDF**, sprawdź [**PLANY SUBSKRYPCYJNE**](https://github.com/sponsors/carlospolop)!
* Zdobądź [**oficjalne gadżety PEASS & HackTricks**](https://peass.creator-spring.com)
* Odkryj [**Rodzinę PEASS**](https://opensea.io/collection/the-peass-family), naszą kolekcję ekskluzywnych [**NFT**](https://opensea.io/collection/the-peass-family)
* **Dołącz do** 💬 [**grupy Discord**](https://discord.gg/hRep4RUj7f) lub [**grupy telegramowej**](https://t.me/peass) lub **śledź** nas na **Twitterze** 🐦 [**@carlospolopm**](https://twitter.com/hacktricks_live)**.**
* **Podziel się swoimi sztuczkami hakerskimi, przesyłając PR-y do** [**HackTricks**](https://github.com/carlospolop/hacktricks) i [**HackTricks Cloud**](https://github.com/carlospolop/hacktricks-cloud) na GitHubie.
</details>
Reference in a new issue View git blame Copy permalink