グループメールの設定ミスによるAWSアカウントの乗っ取りと対策
はじめに
オフェンシブセキュリティ部ペネトレーションテスト課の安里 悠矢です。
普段は組織内の社内ITインフラやクラウド環境上に構築されたインフラに対するペネトレーションテストをしています。
皆様はAWSやGoogle Workspaceなどのクラウドサービスは活用されているでしょうか。弊社で実施するペネトレーションテストでも、「AWSアカウントの乗っ取りが可能か」ということを目的に様々なスコープでテストを行うことがあります。
AWSにおけるrootユーザは、AWS上に展開されたすべてのリソースへのアクセス権を所有し追加のリソースの作成も可能です。攻撃者にとってみてもrootユーザを奪取することは、企業・組織が所有する重要な資産に対してアクセスを行うための攻撃目標になります。
そして、攻撃者にrootユーザの奪取がなされないためにも、多要素認証(MFA)の設定等を行い、AWSアカウント全体を保護することは、セキュリティチームやエンジニアリングチームの重要な任務です。
AWS Organizationを利用しているいくつかの組織では、AWSメンバーアカウントを払い出し後、rootユーザのMFAを有効化していない場合があります。
グループメールの設定ミスが原因で、rootユーザの乗っ取りができてしまい、結果として、AWSアカウント内のリソース全てへのアクセスができてしまうことがあります。
本記事を参考にAWS OrganizationのメンバーアカウントがMFAを設定していないケースにおいて、どのようにrootユーザの乗っ取りができるのかを知り、クラウドサービス上の設定ミスを修正するきっかけになれば幸いです。
AWS Organizationとは？AWSメンバーアカウントの払い出しの流れ
実際の攻撃シナリオを解説にあたり、登場するAWSサービスやそのサービスを利用するまでの流れについて解説します。
AWS Organizationとは？
企業・組織において、AWSアカウントを1つのみ利用しているケースは稀であり、複数のAWSアカウントを利用するケースが数多く存在します。
これは、AWS上で展開するサービスによっては、開発環境やテスト環境の用意をしたり、複数のAWSアカウントをまたいでサービスを展開するケースがあるためです。
AWS Organizationは、複数のAWSアカウントを一元管理するためのサービスです。
AWS Organizationを使用することで、組織内で新たにAWSアカウントを作成する際に、新規で一から契約作業を行わずとも、Organizationの機能から新しくメンバーアカウントを払い出して利用することが可能です。
参考: AWS Organizations – Amazon Web Service
AWSメンバーアカウントの払い出しの流れ
AWS organizationからメンバーアカウントを払い出すには、メンバーアカウト所有者のEメールアドレスが必要となります。
図1: AWS OrganizationでのAWSアカウントの作成
ここで指定するEメールアドレスは、個人のメールアカウントではなく、メーリングリスト機能を持つグループメールが使用されるケースが殆どです。
グループメールの例として、Google WorkspaceのGoogleグループサービスやMicrosoft 365グループの共有メールボックスなど、SaaSのメールサービスのグループ機能が挙げられます。
グループメールを使用する理由として、AWSアカウントごとに個人のメールアカウントを払い出してしまうと、AWSアカウントの数だけメールアカウントの認証情報の管理まで必要になり管理コストが増大してしまうという理由があります。
実際にAWSメンバーアカウントを払い出すまでには図2のように流れになります。
まず初めにメールサービスの管理者がグループメールを作成し、AWS Organizationの管理者にグループメールの発行を通知します。AWS Organization管理者はそのグループメールアドレスを使用しAWSメンバーアカウントを払い出します。
図2: AWSメンバーアカウント発行の流れ
メールサービス管理者とAWS Organization管理者が同一部門であるケースが多いものの、ある程度大きな規模の組織になるとクラウドサービスごとに管理部門が分かれ、管理責任の範囲が分散されるようになります。
そのため、AWS Organization管理者がグループメールの設定がどのようにされているかを把握していない場合もあります。
AWS OrganizationのメンバーアカウントでrootユーザのMFAが設定されない理由
AWSメンバーアカウントを払い出し後、実際にAWSアカウントへアクセスするには、AWS SSOの機能を使用しIAMロールを用いてアクセスします。
IAMのダッシュボードを確認するとレコメンデーションの項目に「rootユーザのMFAを追加する」が記載されています。
図3:作成したメンバーアカウントのIAMダッシュボードのレコメンデーション
しかし、AWS Organizationからメンバーアカウントの払い出しを行うタイミングで、rootユーザのMFAを設定する項目は存在しません。
そのため、実際にrootユーザにMFAを設定するには、rootユーザで一度マネジメントコンソールにログインする必要があります。
ですが、AWSメンバーアカウントの払い出しを行う過程において、rootユーザのパスワードを設定する項目が無く、アカウント払い出し時点ではAWS Organization管理者はパスワードも所有していません。
rootユーザでマネジメントコンソールにアクセスするにはどのようにすれば良いでしょうか？
ちなみにAWS公式ドキュメントには以下のように記載されてます。つまり、rootユーザのパスワードはシステム側で自動的にセットされているものの、利用者が初期パスワードを知る術はなく、rootユーザでのアクセスには一度パスワードリセットを行う必要があります。
新しいアカウントを作成すると、AWS Organizations ではまず、文字長が最低でも 64 文字のパスワードを root ユーザーに割り当てます。すべての文字はランダムに生成され、特定の文字セットが登場する保証もありません。この初期パスワードを再び取得することはできません。root ユーザーとしてアカウントに初めてアクセスする場合は、パスワード復旧プロセスを行う必要があります。
参考: ルートユーザーとしてのメンバーアカウントへのアクセス - AWS Organizationユーザーガイド
上記のことから、rootユーザにMFAを設定するためには、以下の手順を踏む必要があります。
- マネジメントコンソールのパスワードリセット機能からrootユーザのパスワードの再設定する
- 1で再設定したパスワードでマネジメントコンソールへログインする
- rootユーザにMFAデバイスを割り当てる
ここまでの情報を整理しておくと、rootユーザのMFAを設定するまでに少しのハードルがあります。さらに、通常のAWSアカウントへのアクセスは、SSO経由でのIAMロールベースのアクセスとなるためrootユーザをあえて使用する理由がありません。
rootユーザのパスワードを誰も知らない状態であることから、悪意のある第三者がrootユーザでマネジメントコンソールへログインするといった危険性は無いようにも思えるため、あえてパスワードを再設定してパスワードとMFAデバイスの管理を前向きに実施する理由が無いようにも見えます。
そのため、AWS Organizationで払い出されたメンバーアカウントはMFAが設定されてないケースがあるのです。
グループメールの設定ミスを悪用したrootユーザの乗っ取り
組織においてグループメールの利用用途は多岐に渡ります。組織内のユーザであればグループメールの内容を閲覧できるように設定されている場合もあれば、組織外のユーザとの連携用に使用されることもあります。
メールサービスの管理者は、利用用途に応じてグループメールにユーザを追加することになります。
Google WorkspaceのGoogleグループ機能では、組織のユーザが管理者に依頼することなく自由にグループを作成できるほか、図4のようにグループ内のメールの閲覧権限や詳細な項目を作成者が自由に選択することが可能です。
「ビジネス向けGoogleグループ」を有効化した状態で、特にGoogle Workspaceの管理者設定を変更していなければ、アクセスタイプの初期値が「公開」になっており、グループに参加できるユーザが「組織内のすべてのユーザーが参加できる」になっています。
グループの作成時に設定するアクセスタイプは組織内のユーザのみ閲覧が可能であり、外部に公開されないため、一見問題が無いようにも見えます。この設定は安全なのでしょうか。
図4: Google グループのアクセスタイプ設定画面
ここまででGoogleグループのアクセスタイプの設定について紹介しましたが、「公開」設定が問題になるケースを考えていきます。
図5では、組織内のユーザ「sales-user-1」がマルウェアに感染し、メールアカウントが乗っ取られたことを想定したものになります。
Googleグループには、AWSアカウントのrootユーザとして使用しているグループ「vuln-root-account-1」が存在します。さらにアクセスタイプが「公開」設定となっているため、組織内のユーザが自由にグループメールを閲覧することができます。
図5: AWSアカウントrootユーザの乗っ取り概要図
※本記事では、マルウェア感染後のメールアカウントの詳細な窃取方法については割愛しますが、ブラウザのCookie等を取得してGoogle Workspaceへアクセスすることが可能です。また、マルウェアに感染しなくとも、組織内部のユーザが悪意を持った場合は同様の手順でAWSアカウントの乗っ取りが可能です。
攻撃者は、メールアカウント「sales-user-1@gmo-cybersecurity.com」を窃取後、Google Workspace組織内で作成されたグループを表示することが可能です。
URL: https://groups.google.com/ にアクセスすることで図6のように、実際に自分が参加しているグループ(マイグループ)を閲覧することができます。
ユーザは、参加しているグループは存在せず、どのグループのメールも閲覧できません。
図6: 「sales-user-1@gmo-cybersecurity.com」が参加するグループの一覧
次に、グループに参加せずともメールの閲覧が可能なグループや参加が可能なグループが無いかを確認していきます。
URL: https://groups.google.com/all-groups にアクセスすることで、図7のようにGoogle Workspace組織に存在するグループの一覧が確認できます。
グループの概要を見る限り表示された2つのグループはAWSアカウントのrootユーザ用のグループであることが確認できます。
図7: Google Workspace組織に存在するグループの一覧
グループの読み取り権限が存在する場合、グループ名を押下することで、グループに送信されたメールの内容を閲覧することが可能です
さらに「グループに参加」の文字が表示されており、当該グループのメンバーになることも可能です。
図8: 「vuln-root-account-1」のグループに送信されたメールの一覧
実際に当該グループのアクセス権の設定を確認してみましょう。会話を閲覧できるユーザーとして「組織全体」に設定されています。
さらにグループに参加できるユーザとして「組織内の全てのユーザーが参加できる」とされています。
図9: Googleグループのアクセス権の設定画面
この設定ミスにより、攻撃者はメールの内容を自由に閲覧することが可能であるため、ここでAWSアカウントのrootユーザのパスワードリセットを行います。
パスワードリセットのメール本文に記載されたリンクを押下し、パスワードを自由に設定することができます。
図10: パスワードリセット機能の使用
図11: パスワードリセット用のメールを受信
図12: パスワードの再設定
パスワードのリセット後は、実際にrootユーザとしてログインに成功しました。
図13: rootユーザのログイン確認
rootユーザにMFAが設定された場合のパスワードリセットの挙動
ここまでで、Googleグループのアクセスタイプの設定ミスを悪用しAWSアカウントのrootユーザの乗っ取りに成功しました。
では、rootユーザにMFAが設定されている場合は、どのような挙動になるのでしょうか。
図14: rootユーザに設定されたMFA
MFAが設定されている場合であっても、rootユーザのパスワードをリセットは可能です。ただし、リセット時に設定したパスワードを使用した場合でも、ログインの過程でMFAの認証コードが要求されるようになります(図15)。そのため、rootユーザでのログインはできなくなります。
図15: rootユーザでのパスワード認証後にMFAコードを要求
では、攻撃者がrootユーザのMFAをリセットすることはできるのでしょうか？
これは非常に困難なものとなります。理由としては、MFAをリセットする際に、AWSから連絡先の電話番号に対し架電された電話に応対する必要があるためです。
さらに、本人確認のため、画面に表示された番号を、通話中にキーパッドから入力する必要があります。連絡先として設定された電話番号は基本的に組織の代表番号であることが多いため、パスワードのリセットは行えても、MFAのリセットのために電話に応対することは非常に困難であるためです。
※ 組織内部の従業員が悪意を持って実行した場合は、組織の代表番号を扱う可能性があるため、電話に応対できる可能性はあります。
図16: MFAのリセットの失敗
rootユーザの乗っ取りの対策
本記事で紹介した攻撃手法の対策について、Google WorkspaceとAWSの設定に分けて解説します。
Google Workspaceでの対策
- Googleグループのアクセス権を見直し、グループに参加しないユーザがグループメールを閲覧できないように変更する。
- グループオーナーが招待したユーザのみGoogleグループへ参加できるようにする。
- Googleグループの作成を管理者のみが行うようにし、利用用途に応じて適切なアクセスタイプを設定する。
「ビジネス向け Google グループ」の設定から「グループの作成」の項目で「組織の管理者だけがグループを作成できる」に変更することで、管理者のみがグループを作成できます。
図17: 「ビジネス向けgoogleグループ」の設定
4.今後新たに作成されるグループは、意図せず公開設定にならないようにグループの参加者のみがメールを閲覧できるようにデフォルトの設定を変更する。
「ビジネス向けgoogleグループ」の設定から会話のデフォルトの閲覧権限を「グループのメンバー全員」に変更
図18: 「ビジネス向けgoogleグループ」の設定
AWSでの対策
- AWS Organization機能で発行されたメンバーアカウントであっても、rootユーザにMFAを設定する。
- rootユーザの乗っ取りに備えてSCP(Service Control Policy)でrootユーザの操作を拒否する。
SCPでは、AWS OrganizationのメンバーアカウントのrootユーザがAWSリソースを操作できる範囲を制限することが可能です。SCPで制限できない項目もあるため、詳細はAWS公式のユーザガイドをご確認ください。
参考: サービスコントロールポリシー (SCP) – Amazon Web Service ユーザガイド
まとめ
AWSのセキュリティ対策は、AWSのみに焦点が当たりがちですが、rootユーザに使用されるメールアドレスの保護や認証情報のリセット経路の把握についてもセキュリティ対策の重要性が高いものになります。
今回は、AWSアカウントのrootユーザの乗っ取りを中心に記事を解説しましたが、グループメールの内容が閲覧できてしまう以上は、そのグループメールで登録したその他のクラウドサービスのパスワードのリセットもできてしまうことになります。
本記事を参考にグループメールの権限設定の見直しやクラウドサービスのMFAの設定等、アカウントを保護するための対策の見直しのきっかけになれば幸いです。
宣伝
弊社では、ペネトレーションテストによってお客様の利用する環境の脆弱性や運用上の問題点を様々な観点で調査・ご報告しています。
自組織のセキュリティ対策の有効性がどの程度なのか、テストを通して擬似インシデントが発生した際にSOCやCSIRTが適切に動けるかといった観点での評価も実施しております。
弊社のペネトレーションテストにご興味がありましたら是非お問い合わせください。
・ペネトレーションテストサービスページ
https://gmo-cybersecurity.com/service/pentest/
・レッドチーム演習サービスページ
https://gmo-cybersecurity.com/service/redteam/
