皆さんこんにちは。国井です。
だいぶ前に紹介したAADInternalsツール、覚えてますでしょうか？
その時はツールの危険性を考えて悪い方面での使い方を書かなかったのですが、やはり私たちは認識しておく必要があるのではないか、対策を考える必要があるのではないかと思い、紹介することにしました。
言っておきますが攻撃手法を解説することが目的ではなく、対策としてやるべきことを考える必要があるという話をしたいがために書いているのでそのことを忘れないでください。ここに書いてあることが原因で悪いことが起きても私はその責任を負えないですし、悪用した場合には法的な罰則を受ける可能性があることを覚えておいてください。
Azure AD Connectと同期アカウント
Azure AD Connect (もうじき名前が変わるけど) をインストールするときに Azure ADとオンプレミスADの管理者アカウントを指定します。これは同期に使用するAzure ADアカウントとオンプレミスADアカウントを作成することが目的だからです。
そうやって作られた同期アカウントは同期を行うときに勝手に使われるわけですが、AADInternalsツールを利用すると同期アカウントを同期以外の目的で利用できてしまうというのがこの先の話になります。
Get-AADIntSyncCredentialsコマンドレット
Azure AD Connectがインストールされたサーバーで、以前紹介した方法でAADInternalsのインストールとAzure ADへの接続を行い、Get-AADIntSyncCredentialsコマンドレットを実行する。これだけの操作でオンプレミスAD側のユーザーとAzure ADユーザーの資格情報を表示することができます。
同期アカウントでサインイン
そしたらゲットしたアカウントでサインインしてみましょう。
Microsoft Entra管理センターにサインインするとユーザーとしての権限を保有しているのでユーザー一覧などが参照できることがわかります。ただし、ユーザーを新規作成しようとするとゲストユーザーは作れるけど、メンバーは作成できないことがわかります。(ちなみにゲストユーザーの作成権限はExternal Identities > 外部コラボレーションの設定で定義されています)
ただ少なくともゲストユーザーは作成し放題なので、ゲストユーザーが作れてしまうリスクがあることがわかります。
同期アカウントでできることを探る
えっ待って！同期アカウントって同期するために使うアカウントなんだからAzure ADのユーザーを操作する権限あるんじゃないの？って思われるかもしれませんが、
同期ユーザーに対して割り当てられるロールである「ディレクトリ同期アカウント」ロールにはすべてのユーザーを操作する権限は含まれていないのです。
AADInternalsのコマンドレットで無理やりパスワードをリセットしようとしても..
cloud only userだからという理由でリセットできませんでした。
cloud only userだから？そう、ディレクトリ同期アカウントロールのユーザーは同期ユーザーに対する操作権限はあるので同期ユーザーのパスワードはリセットできてしまうのです。
実際にパスワードをリセットすると、同期ユーザーであるにもかかわらずオンプレミスADユーザーのパスワードとAzure ADユーザーのパスワードが異なるという状態が出来上がります。
それでもってパスワードライトバックの設定をしていなければオンプレミスとクラウドのパスワードが異なる状態がキープされてしまうのです。
攻撃シナリオとしては同期ユーザーのアカウントでAzure ADに侵入し、同期ユーザーを見つけてきて、パスワードリセットして攻撃者が利用可能な状態にする。こうして権限昇格が実現します。
「同じパスワードを入れているのにオンプレミスにはサインインできて、クラウドにはサインインできない」なんてユーザーから問い合わせがあったら、この攻撃に遭っているのかもしれません。もっとも管理者であれば監査ログを参照することでパスワードがリセットされたことはわかるわけだから、そこで気づけるかもと思うかもしれません。しかし監査ログに記録されるパスワードリセットのログはAADInternalsからリセットされたものとオンプレミスADからリセットされたものはまったく同じログの見え方なので判断ができません。
applications/createアクセス許可
ディレクトリ同期アカウントロールのアクセス許可一覧にはapplications/createというアクセス許可が割り当てられていました。このアクセス許可はアプリの登録へのアクセスだけが可能なもので、既存のアプリの登録へのアクセスやエンタープライズアプリケーションやアプリケーションプロキシに対する操作は一切行うことができませんでした。
どうやって対策しましょうか？
この攻撃に限って言えばAzure AD Connectのサーバーが乗っ取られていることが前提条件になっています。厳しい言い方をすればAzure AD Connectのサーバーが乗っ取られている時点で、もうそのシステムはゲームオーバーなのです。
MSさんの資料などではTier1のサーバー(セキュリティ上、最重要視すべきサーバー)なんて言い方をしますが、Azure AD ConnectがインストールされたサーバーはTier1扱いすべきサーバーなのです。そしてもっと言えばTier1サーバーをいくつも保有するようなリスクを負い続けなくても良いような策も考えていくべきなのではないかと思います。
Azure AD Connectからクラウド同期に切り替える(クラウド同期では同期専用ユーザーを作らず、gMSAだけを作成するためGet-AADIntSyncCredentialsコマンドレットで資格情報を取り出すことができない)とか、Azure AD Connectそのものを廃止するロードマップを考え始めるとか。
AADInternalsが怖いからAADInternals対策を.. ということではなく、もっと根本のところから考えていく必要があると考えています。
