Az - Federation
Podstawowe informacje
Z dokumentacji:Federacja to zbiór domen, które ustanowiły zaufanie. Poziom zaufania może się różnić, ale zazwyczaj obejmuje uwierzytelnianie i prawie zawsze obejmuje autoryzację. Typowa federacja może obejmować wiele organizacji, które ustanowiły zaufanie dla wspólnego dostępu do zestawu zasobów.
Możesz federować swoje środowisko on-premises z Azure AD i używać tej federacji do uwierzytelniania i autoryzacji. Ta metoda logowania zapewnia, że całe uwierzytelnianie użytkowników odbywa się on-premises. Ta metoda pozwala administratorom na wdrożenie bardziej rygorystycznych poziomów kontroli dostępu. Dostępna jest federacja z AD FS i PingFederate.
W zasadzie, w Federacji, całe uwierzytelnianie odbywa się w środowisku on-prem i użytkownik doświadcza SSO we wszystkich zaufanych środowiskach. Dlatego użytkownicy mogą uzyskiwać dostęp do aplikacji w chmurze za pomocą swoich poświadczeń on-prem.
Security Assertion Markup Language (SAML) jest używany do wymiany wszystkich informacji o uwierzytelnianiu i autoryzacji między dostawcami.
W każdej konfiguracji federacji są trzy strony:
Użytkownik lub Klient
Dostawca Tożsamości (IdP)
Dostawca Usług (SP)
(Obrazy z https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
Początkowo użytkownik uzyskuje dostęp do aplikacji (Dostawca Usług lub SP, takich jak AWS console lub vSphere web client). Ten krok może zostać 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 uwierzytelnienia użytkownika. Tworzy SAML (Security Assertion Markup Language) AuthnRequest i przekierowuje klienta do wybranego IdP.
IdP przejmuje kontrolę, uwierzytelniając użytkownika. Po uwierzytelnieniu IdP formułuje SAMLResponse i przekazuje go do SP za pośrednictwem użytkownika.
Na koniec SP ocenia SAMLResponse. Jeśli zostanie pomyślnie zweryfikowany, co oznacza zaufanie do IdP, użytkownik uzyskuje dostęp. To kończy proces logowania, umożliwiając użytkownikowi korzystanie z usługi.
Jeśli chcesz dowiedzieć się więcej o uwierzytelnianiu SAML i typowych atakach, przejdź do:
Pivoting
AD FS to model tożsamości oparty na roszczeniach.
"..roszczenia to po prostu oświadczenia (na przykład imię, tożsamość, grupa), składane na temat użytkowników, które są używane głównie do autoryzacji dostępu do aplikacji opartych na roszczeniach znajdujących się w dowolnym miejscu w Internecie."
Roszczenia dla użytkownika są zapisywane wewnątrz tokenów SAML i są następnie podpisywane przez IdP w celu zapewnienia poufności.
Użytkownik jest identyfikowany przez ImmutableID. Jest on globalnie unikalny i przechowywany w Azure AD.
ImmutableID jest przechowywany on-prem jako ms-DS-ConsistencyGuid dla użytkownika i/lub może być wyprowadzony z GUID użytkownika.
Golden SAML attack:
W ADFS, odpowiedź SAML jest podpisywana przez certyfikat podpisywania tokenów.
Jeśli certyfikat zostanie skompromitowany, możliwe jest uwierzytelnienie się w Azure AD jako DOWOLNY użytkownik zsynchronizowany z Azure AD!
Podobnie jak w przypadku nadużycia PTA, zmiana hasła 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 dowolnego urządzenia podłączonego do internetu.
Golden SAML
Proces, w którym Dostawca Tożsamości (IdP) generuje SAMLResponse w celu autoryzacji logowania użytkownika, jest kluczowy. W zależności od konkretnej implementacji IdP, odpowiedź może być podpisana lub zaszyfrowana przy użyciu prywatnego klucza IdP. Ta procedura umożliwia Dostawcy Usług (SP) potwierdzenie autentyczności SAMLResponse, zapewniając, że została ona rzeczywiście wydana przez zaufany IdP.
Można to porównać do ataku golden ticket, gdzie klucz uwierzytelniający tożsamość i uprawnienia użytkownika (KRBTGT dla golden tickets, prywatny klucz podpisywania tokenów dla golden SAML) może być manipulowany w celu sfałszowania obiektu uwierzytelniającego (TGT lub SAMLResponse). To pozwala na podszywanie się pod dowolnego użytkownika, dając nieautoryzowany dostęp do SP.
Golden SAML oferuje pewne zalety:
Mogą być tworzone zdalnie, bez konieczności bycia częścią domeny lub federacji.
Pozostają skuteczne nawet przy włączonym Two-Factor Authentication (2FA).
Prywatny klucz podpisywania tokenów nie odnawia się automatycznie.
Zmiana hasła użytkownika nie unieważnia już wygenerowanego SAML.
AWS + AD FS + Golden SAML
Active Directory Federation Services (AD FS) to usługa Microsoftu, która ułatwia bezpieczną wymianę informacji o tożsamości między zaufanymi partnerami biznesowymi (federacja). Zasadniczo pozwala na udostępnianie tożsamości użytkowników przez usługę domenową innym dostawcom usług w ramach federacji.
Z AWS ufającym skompromitowanej domenie (w federacji), ta luka może być wykorzystana do potencjalnego uzyskania dowolnych uprawnień w środowisku AWS. Atak wymaga prywatnego klucza używanego do podpisywania obiektów SAML, podobnie jak w przypadku potrzeby KRBTGT w ataku golden ticket. Dostęp do konta użytkownika AD FS jest wystarczający, aby uzyskać ten prywatny klucz.
Wymagania do przeprowadzenia ataku golden SAML obejmują:
Prywatny klucz podpisywania tokenów
Publiczny certyfikat IdP
Nazwa IdP
Nazwa roli (rola do przejęcia)
Domain\username
Nazwa sesji roli w AWS
Amazon account ID
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ć ze sklepu osobistego za pomocą narzędzi takich jak mimikatz. Aby zebrać pozostałe wymagane informacje, można użyć snapinu Microsoft.Adfs.Powershell w następujący sposób, upewniając się, że jesteś zalogowany jako użytkownik ADFS:
Z całą tą informacją, możliwe jest zapomnienie ważnej SAMLResponse jako użytkownik, którego chcesz podszyć się używając shimit:
On-prem -> cloud
Możliwe jest również utworzenie ImmutableID użytkowników tylko w chmurze i podszywanie się pod nich
Referencje
Last updated