Az - Federation
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
From the docs:Federacja to zbiór domen, które nawiązały zaufanie. Poziom zaufania może się różnić, ale zazwyczaj obejmuje uwierzytelnianie i prawie zawsze obejmuje autoryzację. Typowa federacja może obejmować liczne organizacje, które nawiązały zaufanie do wspólnego dostępu do zestawu zasobów.
Możesz federować swoje lokalne środowisko z Azure AD i używać tej federacji do uwierzytelniania i autoryzacji. Ta metoda logowania zapewnia, że wszystkie uwierzytelnienia użytkowników odbywają się lokalnie. Ta metoda pozwala administratorom wdrażać bardziej rygorystyczne poziomy kontroli dostępu. Federacja z AD FS i PingFederate jest dostępna.
W zasadzie, w Federacji, wszystkie uwierzytelnienia odbywają się w lokalnym środowisku, a użytkownik doświadcza SSO we wszystkich zaufanych środowiskach. Dlatego użytkownicy mogą uzyskiwać dostęp do aplikacji w chmurze używając swoich lokalnych poświadczeń.
Security Assertion Markup Language (SAML) jest używany do wymiany wszystkich informacji o uwierzytelnianiu i autoryzacji między dostawcami.
W każdej konfiguracji federacyjnej są trzy strony:
Użytkownik lub Klient
Dostawca Tożsamości (IdP)
Dostawca Usług (SP)
(Images from https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
Początkowo aplikacja (Dostawca Usług lub SP, taka jak konsola AWS lub klient webowy vSphere) jest dostępna dla użytkownika. Ten krok może być pominięty, prowadząc klienta bezpośrednio do IdP (Dostawca Tożsamości) w zależności od konkretnej implementacji.
Następnie SP identyfikuje odpowiedni IdP (np. AD FS, Okta) do uwierzytelniania użytkownika. Następnie tworzy żądanie AuthnRequest SAML (Security Assertion Markup Language) i przekierowuje klienta do wybranego IdP.
IdP przejmuje, uwierzytelniając użytkownika. Po uwierzytelnieniu, IdP formułuje SAMLResponse i przesyła go do SP przez użytkownika.
Na koniec SP ocenia SAMLResponse. Jeśli zostanie pomyślnie zweryfikowany, co oznacza zaufanie do IdP, użytkownik uzyskuje dostęp. To oznacza zakończenie procesu logowania, umożliwiając użytkownikowi korzystanie z usługi.
Jeśli chcesz dowiedzieć się więcej o uwierzytelnianiu SAML i powszechnych atakach, przejdź do:
AD FS to model tożsamości oparty na roszczeniach.
"..roszczenia to po prostu stwierdzenia (na przykład, imię, tożsamość, grupa), dotyczące użytkowników, które są używane głównie do autoryzacji dostępu do aplikacji opartych na roszczeniach znajdujących się gdziekolwiek w Internecie."
Roszczenia dla użytkownika są zapisane w tokenach SAML i są następnie podpisywane, aby zapewnić poufność przez IdP.
Użytkownik jest identyfikowany przez ImmutableID. Jest on globalnie unikalny i przechowywany w Azure AD.
ImmutableID jest przechowywany lokalnie jako ms-DS-ConsistencyGuid dla użytkownika i/lub może być wyprowadzony z GUID użytkownika.
Atak Golden SAML:
W ADFS, SAML Response jest podpisywany przez certyfikat podpisywania tokenów.
Jeśli certyfikat zostanie skompromitowany, możliwe jest uwierzytelnienie do Azure AD jako DOWOLNY użytkownik zsynchronizowany z Azure AD!
Tak jak w przypadku nadużycia PTA, zmiana hasła dla użytkownika lub MFA nie będzie miała żadnego wpływu, ponieważ fałszujemy odpowiedź uwierzytelniającą.
Certyfikat można wyodrębnić z serwera AD FS z uprawnieniami DA, a następnie można go używać z dowolnej maszyny podłączonej do internetu.
Proces, w którym Dostawca Tożsamości (IdP) produkuje SAMLResponse w celu autoryzacji logowania użytkownika, jest kluczowy. W zależności od konkretnej implementacji IdP, odpowiedź może być podpisana lub szyfrowana przy użyciu prywatnego klucza IdP. Procedura ta umożliwia Dostawcy Usług (SP) potwierdzenie autentyczności SAMLResponse, zapewniając, że rzeczywiście została wydana przez zaufany IdP.
Można to porównać do ataku złotego biletu, gdzie klucz uwierzytelniający tożsamość i uprawnienia użytkownika (KRBTGT dla złotych biletów, prywatny klucz podpisywania tokenów dla złotego SAML) może być manipulowany w celu fałszowania obiektu uwierzytelniającego (TGT lub SAMLResponse). To pozwala na podszywanie się pod dowolnego użytkownika, przyznając nieautoryzowany dostęp do SP.
Złote SAML oferują pewne zalety:
Mogą być tworzone zdalnie, bez potrzeby bycia częścią domeny lub federacji.
Pozostają skuteczne nawet przy włączonym uwierzytelnianiu dwuskładnikowym (2FA).
Prywatny klucz podpisywania tokenów nie odnawia się automatycznie.
Zmiana hasła użytkownika nie unieważnia już wygenerowanego SAML.
Usługi Federacji Active Directory (AD FS) to usługa Microsoftu, która ułatwia bezpieczną wymianę informacji o tożsamości między zaufanymi partnerami biznesowymi (federacja). W zasadzie pozwala usłudze domeny na dzielenie się tożsamościami użytkowników z innymi dostawcami usług w ramach federacji.
Z AWS ufającym skompromitowanej domenie (w federacji), ta luka może być wykorzystana do potencjalnego zdobycia dowolnych uprawnień w środowisku AWS. Atak wymaga prywatnego klucza używanego do podpisywania obiektów SAML, podobnie jak w przypadku potrzeby KRBTGT w ataku złotego biletu. Dostęp do konta użytkownika AD FS jest wystarczający, aby uzyskać ten prywatny klucz.
Wymagania do przeprowadzenia ataku złotego SAML obejmują:
Prywatny klucz podpisywania tokenów
Publiczny certyfikat IdP
Nazwa IdP
Nazwa roli (rola do przyjęcia)
Domenę\username
Nazwę sesji roli w AWS
Identyfikator konta Amazon
Tylko elementy pogrubione są obowiązkowe. Pozostałe można wypełnić według uznania.
Aby uzyskać prywatny klucz, konieczny jest dostęp do konta użytkownika AD FS. Stamtąd prywatny klucz można wyeksportować z osobistego magazynu za pomocą narzędzi takich jak mimikatz. Aby zebrać inne wymagane informacje, możesz wykorzystać snapin Microsoft.Adfs.Powershell w następujący sposób, upewniając się, że jesteś zalogowany jako użytkownik ADFS:
Z wszystkimi informacjami możliwe jest zapomnienie o ważnym SAMLResponse jako użytkownik, którego chcesz udawać, używając shimit:
Możliwe jest również utworzenie ImmutableID użytkowników tylko w chmurze i ich podszywanie się.
Ucz się i ćwicz Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Ucz się i ćwicz Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)