AWS障害後にアカウントが侵害された

最近、AWSで発生したサービス障害の後、あるユーザーが自身のAWSアカウントが外部攻撃者によってハイジャックされる事故に遭遇した。

侵害経路および問題の状況

• 障害期間中、一部のセキュリティポリシーが正常に機能しない可能性があることが指摘された。
• 攻撃者は障害後にアカウントログに異常なアクセス痕跡を残し、一部のリソースが予期せず作成/削除される現象が発生した。
• ユーザーは障害に伴う権限変更または認証情報の流出の可能性について懸念を示した。

被害と対応

• コスト増加、データ流出などの実質的な被害が発生した。
• AWSサポートに連絡し、事案の詳細と対応方法を問い合わせた。
• コミュニティでは2段階認証の有効化、ロールベースアクセス権限の最小化など事前対策の重要性が強調された

[GN⁺]

Hacker News のコメント

• 普通は偶然だと思いたくなるが、私もクライアントアカウントが侵害された事例があった。顧客は小規模な組織で、5年以上使われていなかった2つの古いIAMアカウントで、急にコンソールログインとパスワード変更の履歴ができていた。調査の結果、現在までに判明したのは、AWS SES の本番アクセス有効化と1日あたり5万件へのメール送信上限引き上げのためのサポートチケットを残したことだけだった。5年以上放置されていたアカウントがまさにこの時点でアクティブになったのは、あまりに不自然だ

  • フィッシング攻撃の匂いがする。たとえばAWS障害のお知らせを装ったメールを受け取り、コンソールログインを誘導されてから悪意のあるラッパー経由で認証すると、アカウントのセキュリティが突破される可能性がある
  • ほぼ同じことを1年前に実際に経験した。非常に古いアカウントでログインし、SESアクセス後にメール上限の引き上げを依頼した。私たちが迅速に対応できたのは、上限引き上げチケットが必須だったからだ。まだ確認していないなら新しく作成されたRoleもチェックする必要がある。私たちは侵害されたアカウントを即時整理し、私はRole全体を確認して1か月未満で作成されたものとadmin権限を持つものをすべて削除した。一方で、侵害が実際に自分たちのキーから始まったことも確認した。最初のユーザーが作成された時点が実際のSESリクエストよりほぼ1か月前で、攻撃者がすでに侵入していた状態でAWS障害が起きたためこの機会を狙った可能性がある。別のAWSの問題と混ざっていて見えにくくなっていた

• 既にアクセス権を得た人物が、AWSインフラの混乱のような事件が起きるのを待って、そのタイミングで攻撃を仕掛け混乱に紛れ込む可能性はないだろうか。数週間や数か月前にトークンが流出していても、すぐ動くのではなく大きな事件が起きるまで待つ戦略かもしれない。私が攻撃者ならこのやり方を試してみたいと思う

  • 当然可能だ。監査担当者としてもこういう例を実際に聞いた。攻撃者は事前に準備を整えて、会社の売却など重要イベントが来るまで待って動くこともある。高度化した攻撃者ほど、このチャンスを狙って先回りして準備する
  • 同じチーム出身であることを明かしながら、実際に今日悪用されたキーに関する警告メールを2年前に無作為の人から受け取ったことがあった。しかし昨日までは一切悪用はなかった
  • むしろ、これは攻撃としては悪いタイミングだと思う。今はみんなAWSに注目しておりログインも多いので、何か不自然な点があればより敏感に注視されると考える。私たちの会社がAWSを使っているなら、こういう状況でさらに徹底して監視するだろう

• もし私が攻撃者なら、いつ攻撃するかを選ぶだろうが、ログ集計すらうまくされない大規模障害の状況は好機になりうる。実際、既に侵害された状態でこのタイミングを悪用したか、あるいはAWS障害に便乗して自分のリソースで別の攻撃を仕掛けていた可能性もある

• クラウド環境で何か変なリソース（EC2など）が作成された場合、そのイベントが何だったかはCloudTrailで確認できる。代表例としてRunInstancesイベントを確認すればよい

  • 最近AWSを使っていないため、コンソールの直接確認はできないが、同様の状況に遭遇した場合はだいたい次の手順を推奨する:
    1. EC2を作ったアカウント/主体を確認 (eventSource:ec2.amazonaws.com, eventName:RunInstances)
    2. userIdentityを基準に追跡し、後続アクションを確認
    3. コンソール直接ログイン履歴の確認 (eventSource:signin.amazonaws.com, userIdentity.type:[Root/IAMUser/AssumedRole/FederatedUser/AWSLambda], eventName:ConsoleLogin)
    4. Security Token Serviceによる認証リクエスト履歴の確認 (eventSource:sts.amazonaws.com, eventName:GetSessionToken)
    5. STSセッションを通じたAssumeRoleの使用可否確認 (eventSource:sts.amazonaws.com, eventName:AssumeRole)
    6. 新規IAM Role/Account作成など永続性維持のための試みを確認 (eventSource:iam.amazonaws.com, eventName:CreateUser/ DeleteUser)
    7. 既存Role/Accountがより高い権限へ変更されたか確認 (eventSource:iam.amazonaws.com, eventName:CreateRole/DeleteRole/AttachRolePolicy/DetachRolePolicy)
    8. Access Keyの作成/削除履歴を確認 (eventSource:iam.amazonaws.com, eventName:CreateAccessKey/DeleteAccessKey)
    9. 本番EC2のIAMInstanceProfile変更でバックドアの可能性を点検 (詳細は AWS Docs サンプル を参照) もし深刻な侵害が疑われるなら、専門家による環境監査を受けることを推奨する
  • 有益な情報だったのでログを調べる予定だ。追加で観測した点を並べると:
    1. ルートアカウントの下に20件以上の組織が作成され、いずれも同じドメイン(co.jp)のメールアドレスを使用していた
    2. 攻撃者が複数のfargateテンプレートを作っていた
    3. 16〜17のAWSリージョンにリソースを作成していた
    4. SES、WS Fargateのリソース割り当て増加リクエスト、SageMakerノートブックのメンテナンス依頼など不要なリソース要求が発生し、それに関する通知メールを複数受信した
    5. いくつかのメールで新しい名前（ランダムネーム@outlook.com）が追加されているのを確認した
  • RunInstancesイベントがまさにそれだった

• いくつかのReddit利用者が、AWS障害中にリフレッシュすると別のユーザーとして一時的にログインされる経験をしたという話をしていた

  • 以前私が働いていた会社でも似たことがあった。顧客が異なる顧客データにアクセスしてしまう現象だったが、原因は本番環境でライブデバッグを試みた誤ったスタッフだった（面接時に採用反対の意見を述べたことがあるが）。この問題を追跡して解決するのは本当に大変だった
  • 障害時間帯にDynamoDBが一時的に不一致状態になり、IAM資格情報まで崩れたのではないかと疑われる。もし本当なら本当に重大な問題だ。関連事例を見られるリンクがあるなら知りたい
  • 関連する証拠があれば共有してほしい。まさに衝撃的だ
  • 最近ChatGPTでも似たような問題が起きていなかったか思い出す。少し似た感覚がある
  • この種のセキュリティ事故は、単なる一時的サービス障害と比較にならないほど深刻なもの

• 普段ならこの種の事件はただの偶然だろうが、概ね原因は露出したアクセスキー。MFAを使っていないコンソールアカウントのパスワード露出による問題もあるが、かなりまれなケース

• パニックの状況では、人はフィッシング攻撃に最も弱くなる。全面的にパスワードをリセットし、AWS担当者に状況を伝えるべきだ。通常は信頼ベースで協力的に対応してくれる

• us-east-1リージョンは想像以上に大きい。最近の公開情報では159のデータセンターがあるとされる。ここに数百万アカウントが集中している可能性がある。この現象がAWS障害と関連していた可能性もあるが、個人的には偶然の可能性のほうが高いと思う

  • 159個もいるとは驚きだ。参考になりそうな情報源があれば共有してほしい

• 変に聞こえるかもしれないが、もしAPIキーを送ってくれれば、流出リストに入っているか確認できるかもしれない

  • 冗談だと分かっているが、それでも重要な話として慎重に知らせる。冗談であってもAPIキーや認証情報を共有する話は控えるべきだ。誰かが真剣に受け取る可能性もあるため注意が必要