Az - Federation
Informazioni di Base
Dai documenti:Federation è una raccolta di domini che hanno stabilito una fiducia. Il livello di fiducia può variare, ma tipicamente include autenticazione e quasi sempre include autorizzazione. Una federazione tipica potrebbe includere un numero di organizzazioni che hanno stabilito una fiducia per l'accesso condiviso a un insieme di risorse.
Puoi federare il tuo ambiente on-premises con Azure AD e utilizzare questa federazione per l'autenticazione e l'autorizzazione. Questo metodo di accesso garantisce che tutta l'autenticazione degli utenti avvenga on-premises. Questo metodo consente agli amministratori di implementare livelli di controllo degli accessi più rigorosi. La federazione con AD FS e PingFederate è disponibile.
Fondamentalmente, nella Federazione, tutta l'autenticazione avviene nell'ambiente on-prem e l'utente sperimenta SSO in tutti gli ambienti fidati. Pertanto, gli utenti possono accedere alle applicazioni cloud utilizzando le loro credenziali on-prem.
Security Assertion Markup Language (SAML) è utilizzato per scambiare tutte le informazioni di autenticazione e autorizzazione tra i provider.
In qualsiasi configurazione di federazione ci sono tre parti:
Utente o Cliente
Identity Provider (IdP)
Service Provider (SP)
(Immagini da https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)
Inizialmente, un'applicazione (Service Provider o SP, come AWS console o vSphere web client) viene accessa da un utente. Questo passaggio potrebbe essere bypassato, portando il cliente direttamente all'IdP (Identity Provider) a seconda della specifica implementazione.
Successivamente, lo SP identifica l'IdP appropriato (ad esempio, AD FS, Okta) per l'autenticazione dell'utente. Quindi crea una richiesta di autenticazione SAML (Security Assertion Markup Language) e reindirizza il cliente all'IdP scelto.
L'IdP prende il controllo, autenticando l'utente. Dopo l'autenticazione, l'IdP formula una SAMLResponse e la inoltra allo SP tramite l'utente.
Infine, lo SP valuta la SAMLResponse. Se convalidata con successo, implicando una relazione di fiducia con l'IdP, l'utente ottiene l'accesso. Questo segna il completamento del processo di login, consentendo all'utente di utilizzare il servizio.
Se vuoi saperne di più sull'autenticazione SAML e sugli attacchi comuni vai a:
Pivoting
AD FS è un modello di identità basato su claims.
"..le claims sono semplicemente dichiarazioni (ad esempio, nome, identità, gruppo), fatte sugli utenti, che sono utilizzate principalmente per autorizzare l'accesso alle applicazioni basate su claims situate ovunque su Internet."
Le claims per un utente sono scritte all'interno dei token SAML e sono poi firmate per fornire riservatezza dall'IdP.
Un utente è identificato da ImmutableID. È globalmente unico e memorizzato in Azure AD.
L'ImmutableID è memorizzato on-prem come ms-DS-ConsistencyGuid per l'utente e/o può essere derivato dal GUID dell'utente.
Golden SAML attack:
In ADFS, la SAML Response è firmata da un certificato di firma del token.
Se il certificato è compromesso, è possibile autenticarsi su Azure AD come QUALSIASI utente sincronizzato con Azure AD!
Proprio come il nostro abuso di PTA, il cambio di password per un utente o MFA non avrà alcun effetto perché stiamo falsificando la risposta di autenticazione.
Il certificato può essere estratto dal server AD FS con privilegi DA e poi può essere utilizzato da qualsiasi macchina connessa a Internet.
Golden SAML
Il processo in cui un Identity Provider (IdP) produce una SAMLResponse per autorizzare l'accesso dell'utente è fondamentale. A seconda della specifica implementazione dell'IdP, la risposta potrebbe essere firmata o crittografata utilizzando la chiave privata dell'IdP. Questa procedura consente al Service Provider (SP) di confermare l'autenticità della SAMLResponse, garantendo che sia stata effettivamente emessa da un IdP fidato.
Si può tracciare un parallelo con l'attacco golden ticket, dove la chiave che autentica l'identità e i permessi dell'utente (KRBTGT per i golden ticket, chiave privata di firma del token per il golden SAML) può essere manipolata per falsificare un oggetto di autenticazione (TGT o SAMLResponse). Questo consente l'impersonificazione di qualsiasi utente, concedendo accesso non autorizzato allo SP.
I Golden SAML offrono alcuni vantaggi:
Possono essere creati da remoto, senza la necessità di far parte del dominio o della federazione in questione.
Rimangono efficaci anche con Two-Factor Authentication (2FA) abilitata.
La chiave privata di firma del token non si rinnova automaticamente.
Cambiare la password di un utente non invalida un SAML già generato.
AWS + AD FS + Golden SAML
Active Directory Federation Services (AD FS) è un servizio Microsoft che facilita lo scambio sicuro di informazioni di identità tra partner commerciali fidati (federazione). Essenzialmente consente a un servizio di dominio di condividere le identità degli utenti con altri service provider all'interno di una federazione.
Con AWS che si fida del dominio compromesso (in una federazione), questa vulnerabilità può essere sfruttata per potenzialmente acquisire qualsiasi permesso nell'ambiente AWS. L'attacco richiede la chiave privata utilizzata per firmare gli oggetti SAML, simile alla necessità del KRBTGT in un attacco golden ticket. L'accesso all'account utente AD FS è sufficiente per ottenere questa chiave privata.
I requisiti per eseguire un attacco golden SAML includono:
Chiave privata di firma del token
Certificato pubblico IdP
Nome IdP
Nome del ruolo (ruolo da assumere)
Dominio\nome utente
Nome della sessione del ruolo in AWS
ID account Amazon
Solo gli elementi in grassetto sono obbligatori. Gli altri possono essere compilati a piacere.
Per acquisire la chiave privata, è necessario l'accesso all'account utente AD FS. Da lì, la chiave privata può essere esportata dal personal store utilizzando strumenti come mimikatz. Per raccogliere le altre informazioni richieste, puoi utilizzare lo snapin Microsoft.Adfs.Powershell come segue, assicurandoti di essere loggato come utente ADFS:
Con tutte le informazioni, è possibile ottenere una SAMLResponse valida come l'utente che si desidera impersonare utilizzando shimit:
On-prem -> cloud
È anche possibile creare ImmutableID di utenti solo cloud e impersonarli
Riferimenti
Last updated