本サイトは、快適にご利用いただくためにクッキー(Cookie)を使用しております。
Cookieの使用に同意いただける場合は「同意する」ボタンを押してください。
なお本サイトのCookie使用については、「個人情報保護方針」をご覧ください。
Web診断をしております。山本と申します。
2023/8/5〜2023/8/10 に開催されていたBlackhat USA 2023に参加してきました。私はブリーフィングの他、トレーニングにも参加しました。トレーニングの内容は大ボリュームであることや、公開しても差し支えの無い情報の精査に手間取ってしまい、ブログ執筆が遅れてしまいましたが今回はトレーニングについてのレポートをお送りしたいと思います。
ABUSING & SECURING AZURE SERVICES
今回受講したトレーニングは「ABUSING & SECURING AZURE SERVICES」です。
これはMicrosoft Azure Active Directory(Azure AD)の運用上で起こりうるミス、それによる攻撃方法や権限奪取方法をハンズオン形式で学べる講義となっており、Azure ADをあまり触っていなくても受講可能な初心者向けの内容です。
Azure ADの概要や提供機能の紹介から始まり、Azureの様々な設定不備を足がかりに、情報収集の方法、Azure権限の奪取の方法、ハードニングの考え方までをツールなどを使用して2日間かけて行います。
受講したトレーニングの進行表
フェーズ | 大項目 | 小項目 |
Day1 | Introduction |
|
Recon & Enumeration |
|
|
Initial Access |
|
|
Persistence |
|
|
Privilage escalation |
|
|
Day2 | Activity Log |
|
Identity |
|
|
Conditional Access Review |
|
|
Policy |
|
Day1
Azure ADはオンプレミスのADとは異なりクラウドベースのIDソリューションという側面があります。Azure ADでユーザを作成しそのユーザを用いてクラウドアプリにログインできるようになります。
調査(Recon)、列挙(Enumeration)、初期アクセス(Initial access)、永続化(Persistence)、権限昇格(Privilege Escalation)の順で演習が進みます。
Recon / Enumeration
AD テナントのドメイン名はデフォルトでAdminのメールアドレスをベースに作成されます。もちろんカスタムドメインを設定できます。カスタムドメインを設定するほうが一般的ですね。AD ドメイン名がわかると、Microsoft ログイン画面で使用されるAPIを活用することで "テナントID" を手に入れることができます。今後、ターゲットのテナントIDは重要なパラメータなので、初期段階で調査を進めていきます。
AAD Internals というツールを使い、様々な調査を行います。このツールはAzure ADのテストを目的に作られたCLIツールです。ADのドメイン名を入力すると、テナントで利用されている他のドメインを調査することができますが、他にも様々な調査、Azure ADの操作が可能です。
このツールを使って以下の情報を調査し初期アクセス(Initial access)へと繋げます。
- 利用サービスの調査
- テナントIDの調査
- サブドメインの列挙
- ユーザの列挙
演習ではすでにユーザリストが配布されており、このリストを使ってAzure ADに登録されたユーザの存在可否を調査しますが、現実世界では他のサービスから漏洩したメールアドレスなどを使って調査することになるでしょう。
Initial Access
ADへのアクセスを試みるフェーズです。アクセス方法やターゲットのユーザの権限によってアクセスできる範囲が限定されます。
OAuth Phishing
Microsoftは「同意フィッシング」と呼んでいるようです。攻撃者は自身のテナント上で過剰な権限を要求するようなアプリを作成し、ターゲットのADアカウントにAcceptしてもらうものです。実際に受講者が作成したテナントで不正なアプリを登録し、ターゲットのテナントアカウントでアクセスしてAcceptすることで過剰な権限が付与されたトークンを取得することが出来ました。同意したユーザのメールアドレスなどの情報はもちろん、強力な権限を不正なアプリに与えてしまった場合はメール本文や連絡先リストの取得なども可能になってしまいます。
フィッシングですから、アプリ連携したあとのコンテンツもフィッシングに使えます。講義ではMaliciousなコンテンツのかわりに任意のURLにリダイレクトすることで攻撃が有効であることを確認しました。
Password Spray
ユーザがパスワードを使いまわしている場合、他のサービスで漏洩したパスワードなどを用いてログイン試行が行われます。また、脆弱なパスワードなども同様です。他のサービスで漏洩したというシナリオのもとで、とある脆弱なパターンとして扱われる文字列をつかって列挙したユーザへログイン試行したところ、2ユーザでログインが成功しました。これで攻撃者はターゲットのAzure ADインターフェースへアクセスができるようになりました。
Persistence
ログインに成功したユーザはあくまでそのユーザに設定されている権限の範囲内でしかADの機能を扱うことが出来ません。また、被害者が攻撃に気付いてセッションを破棄してパスワードを変更したり、アプリの連携を解除してトークンを無効化したり、簡単にアクセス権が失われます。より強固なアクセス、より広範囲な権限を手に入れるためにアクセスの永続化を行います。
Guest Inviter
Guest Inviter は外部ADユーザを招待できる機能、及びその権限です。この権限が付与されているユーザを探し、攻撃者のADユーザを招待することで、乗っ取ったユーザや一時的なトークンではなく攻撃者自信がコントロール可能なユーザアカウントの取得に至ります。初期アクセスでログインできたユーザを調査すると、1アカウントだけGuest Inviterが有効でした。
Privilege Escalation
初期アクセスで手に入れたユーザやトークン、ゲストユーザを用いてさらなる権限を求めます。権限昇格というと、SuperAdminのような強力なロールにスイッチすることや、その権限を付与するようなイメージですが、ここで言う Privilege Escalation は、水平移行の考え方も含まれます。あるリソースの操作範囲を拡大できるようにする権限昇格は「垂直移行(拡大)」となります。水平移行(拡大)とは、攻撃者が保有していない他のリソースへのアクセス権を手に入れるという意味合いがあります。今回は1つだけご紹介します。
VM Managed ID
AzureではもちろんVMを扱うことが出来ます。AWSでいうEC2です。このVMには実は内部から叩けるAPIが存在し、そのAPIからVMに付与されたManaged IDを取得することが出来ます。Managed IDは システムが勝手に付与するものと、ユーザが明示的に付与するものがあります。VMからストレージにアクセスしたい場合などはその権限をVMのManaged ID に付与する必要があるからです。このIDはユーザが保有する権限よりも、自由度がある場合が多く、攻撃に利用しやすいです。VMで稼働しているアプリケーションの脆弱性を利用してVM内部のAPIを実行するか、Azure ADから取得するようにします。VM内部のAPIを実行する場合は、Server Side Request Forgeries などのリクエストを送信させる脆弱性が存在するかどうかが重要となってきそうですね。
Day2
Day2 ではハードニングになります。かなり割愛しましたが、Day1での様々な攻撃テクニックに対応した設定の確認などが演習ベースで紹介されました。
ログの確認
Activity Log
Activity Log はリソースへのアクセスや操作などの履歴をログに記録することが出来ます。例えば、データの登録、編集、VMの起動、ログインの失敗状況などです。こういった様々なアクティビティを「ワークスペース」という領域を作成してログ監査ができるようにする必要があります。
WorkBook
Workspaceへ記録したログをビジュアライズ出来ます。ログだけを追っても異常に気付きにくいケースもあるためこういった可視化の施策は有効です。ログインの試行失敗回数が局所的に多くなっているなど異常がすぐ判別できます。
ユーザのパスワードポリシー変更
Day1では使い回されたパスワードを用いて特定のユーザへログインしADの侵害を行いました。こういった事が起きないようにするため、以下のような対策が必要になってきます。
- 通常と異なるロケーションやIPからのログインはBAN、又はアラートを記録する
- MFA (他要素認証)をすべてのポリシーで強制する。※プラットフォームによって部分的にMFAを無効化するポリシーの場合、簡単にMFAをバイパスできます。
- アカウントロックアウトの厳格化
- パスワードポリシーを変更し、十分な長さ文字種が含まれているかを確認する
- パスワードを使い回さないよう、ユーザを教育する
- 定期的な攻撃テストをする
連携アプリの定期チェック
ADアカウントは様々なアプリを連携することが出来ますが、不正なアプリが連携されないよう、ポリシーを見直します。
- ユーザ同意の設定を変更し、検証済みのパブリッシャーからのアプリを許可する
- アプリとその権限を定期的に監査する
- 悪質なアプリを削除する
- ユーザーを教育する
- 定期的な攻撃テストをする
ポリシーの再確認
ユーザやトークンに紐づくポリシーを見直し、過剰な権限をつけないようにしていく必要があります。特にGuest Inviter は外部ADユーザを招待できる機能で悪用された場合のインパクトが絶大です。クラウドプラットフォームはポリシーやロールが膨大で確認するだけで一苦労ですが、これをおろそかにしてはいけません。また、デフォルト設定を盲信しないことが強調されていました。デフォルト設定は事業者のおすすめ設定ではないことは肝に銘じておきましょう。
ポリシーは運用者だけでなく、ユーザの教育、定期的な攻撃テストが必要である旨も言及されていました。
全体を通して
かなりかいつまんだ内容になってしまいましたが、クラウドで利用できるサービス全体から様々なアプローチでAzureが侵害できることを演習を通じて確認することが出来ました。Blackhat のトレーニングということで、難易度が高くついていけなくなるんじゃないかと少し心配していましたが、講師はとてもフレンドリーで資料や環境を充実させることによって理解を取りこぼすことが少なかったように感じます。一つひとつは調べれば資料はヒットするような内容も含まれますが、シナリオに沿って攻撃を体感できるという意味では非常に貴重な経験でした。
山本 健太
おすすめ記事