Az - Federation
基本情報
ドキュメントから: フェデレーションは、信頼を確立したドメインの集まりです。信頼レベルは異なる場合がありますが、通常は認証を含み、ほぼ常に承認を含みます。典型的なフェデレーションには、共有アクセスのために信頼を確立した複数の組織が含まれる場合があります。
オンプレミス環境を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から)
最初に、ユーザがアプリケーション(Service ProviderまたはSP、例:AWSコンソールまたはvSphere Web Client)にアクセスします。特定の実装によっては、このステップをバイパスして、クライアントを直接IdP(Identity Provider)にリダイレクトすることがあります。
次に、SPはユーザ認証のために適切なIdP(例:AD FS、Okta)を特定します。その後、SAML(Security Assertion Markup Language)AuthnRequestを作成し、クライアントを選択したIdPにリダイレクトします。
IdPが引き継ぎ、ユーザを認証します。認証後、IdPによってSAMLResponseが作成され、ユーザを介してSPに転送されます。
最後に、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ユーザとしてログインしていることを確認します。
すべての情報を持っていると、shimitを使用してなりすまししたいユーザーの有効なSAMLResponseを忘れる可能性があります:
オンプレミス -> クラウド
ImmutableIDを作成し、クラウド専用ユーザーを偽装することも可能です。
参考
最終更新