Az - Federation
基本情報
ドキュメントから: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から)
最初に、ユーザーがアプリケーション(Service ProviderまたはSP、例えばAWSコンソールやvSphereウェブクライアント)にアクセスします。このステップは特定の実装によってはクライアントを直接IdP(Identity Provider)にリダイレクトすることもあります。
次に、SPはユーザー認証のために適切なIdP(例:AD FS、Okta)を特定します。SPはSAML(Security Assertion Markup Language)AuthnRequestを作成し、クライアントを選択したIdPにリダイレクトします。
IdPはユーザーを認証します。認証後、IdPはSAMLResponseを作成し、ユーザーを介してSPに送信します。
最後に、SPはSAMLResponseを評価します。信頼できるIdPから発行されたものであると確認されれば、ユーザーにアクセスが許可されます。これでログインプロセスが完了し、ユーザーはサービスを利用できるようになります。
SAML認証と一般的な攻撃についてもっと知りたい場合は、以下を参照してください:
ピボット
AD FSはクレームベースのアイデンティティモデルです。
"..クレームは単にユーザーについての声明(例えば、名前、アイデンティティ、グループ)であり、主にインターネット上のどこにでもあるクレームベースのアプリケーションへのアクセスを認可するために使用されます。"
ユーザーのクレームはSAMLトークン内に書かれ、IdPによって機密性を提供するために署名されます。
ユーザーはImmutableIDによって識別されます。これはグローバルに一意であり、Azure ADに保存されます。
ImmutableIDはオンプレミスではms-DS-ConsistencyGuidとしてユーザーに保存されているか、ユーザーのGUIDから派生することができます。
Golden SAML攻撃:
ADFSでは、SAML Responseはトークン署名証明書によって署名されます。
証明書が漏洩すると、Azure ADに同期された任意のユーザーとしてAzure ADに認証することが可能になります!
PTAの悪用と同様に、ユーザーのパスワード変更やMFAは影響を与えません。なぜなら、認証応答を偽造しているからです。
証明書はDA権限を持つAD FSサーバーから抽出でき、その後、インターネットに接続された任意のマシンから使用できます。
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スナップインを使用します:
すべての情報を使用して、shimit を使用して偽装したいユーザーとして有効な SAMLResponse を忘れることができます**:**
オンプレミス -> クラウド
クラウドのみのユーザーのImmutableIDを作成し、それらを偽装することも可能です
参考文献
Last updated