Az - Federation
Last updated
Last updated
Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
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)
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.
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.
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.
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:
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 da 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-prem como ms-DS-ConsistencyGuid para o usuário e/ou pode ser derivado do GUID do usuário.
Ataque Golden SAML:
No ADFS, a SAML Response é assinada por um certificado de assinatura de token.
Se o certificado for comprometido, é possível autenticar no Azure AD como QUALQUER usuário sincronizado com o Azure AD!
Assim como nosso abuso de PTA, a mudança de senha para um usuário ou MFA não terá efeito porque estamos forjando a resposta de autenticação.
O certificado pode ser extraído do servidor AD FS com privilégios de DA e, em seguida, pode ser usado de qualquer máquina conectada à Internet.
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 dourados, 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.
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
_ Apenas 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:
Com todas as informações, é possível esquecer uma SAMLResponse válida como o usuário que você deseja personificar usando shimit:
Também é possível criar ImmutableID de usuários apenas na nuvem e se passar por eles.
Aprenda e pratique Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE) Aprenda e pratique Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)