あるS3バケットのAWSアカウントIDを見つける方法

 (tracebit.com)
2 ポイント 投稿者 GN⁺ 2024-02-27 | 1件のコメント | WhatsAppで共有

S3バケットのAWSアカウントIDを見つける

  • 2021年にBen Bridtsが、公開されたS3バケットのAWSアカウントIDを見つける独創的な方法を発表した。
  • この記事では、非公開および公開S3バケットの両方についてアカウントIDを見つける手法を説明する。

S3バケットからAWSアカウントIDへ

  • シェル出力を通じて、bucket-alphaというバケットの、これまで不明だったAWSアカウントIDを見つける手法を示す。

この手法は正確にはどのように動作するのか？

  • Benの手法が機能する理由を分析し、次の3つの重要な要素を組み合わせている:
    • IAMポリシーをリクエストに適用できる能力
    • IAMポリシーがリクエストを許可したかどうかを推測できる能力
    • s3:ResourceAccount 条件キーにワイルドカードマッチを適用できる能力

解決策

  • S3向けVPCエンドポイントを使用し、CloudTrailでリクエストが拒否されたときの挙動の違いを利用する解決策を見つけた。

ステップごとに見ていく

  • バケット bucket-alpha のアカウントIDを見つけたい場合の手順:
    • バケットのリージョンを特定する
    • 同じリージョンにVPCとVPCエンドポイントをデプロイする
    • VPC内でEC2インスタンスを起動し、S3へのVPCエンドポイントが使われていることを確認する
    • 対象バケットのアカウントIDが「0」で始まるかどうかを判定するためにVPCエンドポイントポリシーを変更する
    • 対象バケットにリクエストする
    • CloudTrailにリクエストが現れるか確認する
    • 結果に応じてVPCエンドポイントポリシーを変更し、アカウントIDに関する情報をさらに見つける

結果

  • このプロセスを自動化するスクリプトを書き、バケットのアカウントIDを信頼性高く見つけられるようにした。
  • 各桁について二分探索を行い、必要なテスト回数を減らした。

高速化

  • VPCエンドポイントポリシーが反映されるまでの時間と、CloudTrailで結果を個別に待つ時間を短縮するためにVPCエンドポイントポリシーを変更した。
  • これにより、アカウントIDの特定にかかる時間を10分未満まで短縮した。

所感

  • AWSセキュリティチームと相談したうえで、このブログ記事を公開した。
  • AWSアカウントIDを機密情報と見なすべきかどうかについて、興味深い議論があった。
  • この手法はS3以外の他のサービスにも適用できる可能性がある。
  • これらの手法が可能なのは、s3:ResourceAccount に対して StringLike 条件を使えるためである。
  • VPCエンドポイントポリシーによって拒否されたイベントがCloudTrailに記録されると有益かもしれない。

謝辞

  • Ben Bridtsの元の手法がこの作業の着想源となった。
  • Chris Farrisの支援と助言に感謝する。

GN⁺の見解

  • この手法は、クラウド環境でセキュリティ監査を行う際に非常に有用であり、特にAWS S3バケットの所有権確認に役立つ可能性がある。
  • この手法が提供する情報の機微性に関する議論は、クラウドサービス提供者と利用者の間で続くデータセキュリティとプライバシーに関する対話を反映している。
  • 類似の機能を提供する別のツールとしては、AWS自身のサービスであるCloudTrailがあり、これはユーザーのAWS環境で発生するすべての活動を記録・監視するために使われる。
  • この手法を導入する前に、利用者はその手法がAWSのポリシーおよびセキュリティのベストプラクティスに沿っていることを確認する必要がある。
  • この手法を使うことで得られる利点は、効率的なセキュリティ監査と迅速なデータ所有権確認だが、潜在的なプライバシー露出のようなリスクも考慮すべきである。

関連記事

1件のコメント

 
GN⁺ 2024-02-27
Hacker Newsのコメント

  • AWSのs3:ResourceAccount条件キーにワイルドカードマッチを適用できる機能

    • この機能で驚くべきなのは、部分的なアカウントIDの一致に基づいて権限を許可または拒否することに、正当な理由がないという点です。AWSアカウントIDはIPアドレスのように機微情報になり得ますが、作業を進めるためには誰かがそれを知る必要があります。

  • AWSアカウントID == あなたのIPアドレス。機微情報になり得るが、物事を進めるには誰かがそれを知る必要がある。

    • 例: 投稿者は、マネーロンダリング対策手続きのために統合しなければならない第三者との取引で、開放されたsftpポートより一般的に安全な privatelink 設定を望んでいました。しかしその会社は、アカウントIDを隠すことがセキュリティ上重要だとして拒否しました。結果として、投稿者のチームはその会社が使用する公開IP範囲をポート22でホワイトリストに登録しました。
    • この話の教訓: IDを隠すことは賢明に見えるかもしれませんが、人々があなたに連絡できるアドレスがなければ、実際にはビジネスを運営できません。

  • 通常、アカウントIDを公に配布することはないが、いずれ一部は公開されると想定すべきだ。

    • サードパーティベンダーやSaaSプラットフォームが、IAMユーザーとアクセスキーよりもロール引き受け(role assumption)を好む統合方式へ移行するにつれて、統合ポイントとして使うアカウントのアカウントIDは相手方に知られることになり、しかも相手方は独自の依存関係や脆弱性を抱えています。

  • グローバルネームスペースを持つ他の公開AWSリソースも、AWSアカウントIDを明らかにする。

    • 興味のある人向けに、そのコードをここにオンラインで公開しています: find-s3-account

  • 関連: AWSキーID(シークレットキー部分ではない)はアカウントIDを含んでおり、1か所分ビットシフトされている。

    • このキーIDはS3の事前署名付きリンクのURLに含まれるため、すでにアカウントIDを公開している可能性が高いです。

  • 興味深い発見だが、タイトルを見てもっと簡単な方法があるのかと期待した。

    • AWSで管理者アカウントとして「Xリソースがどこにあるか」を尋ねられる簡単な方法があればよいのにと思います。特に、特定のS3バケットがどのアカウントにあるかを素早く教えてくれる機能が必要です。これは主に、コードで定義される前から存在していたレガシーバケットに関する問題です。AWSアカウントを多数持っている場合、未知のアカウントと考えられるリージョンをまたいでリソースを探すのは煩雑になり得ます。

  • 実際のハッキングが、「1文字ずつパスワードを『ハック』する」という古いクリシェや誤解を持ち出すシナリオになるのは、いつでも面白い。

  • より懸念される攻撃ベクトルは、今やアカウント番号を使って別アカウントのプリンシパルを自分のアカウントポリシーの許可リストに追加しようとする場合だ。

    • その別アカウントに該当プリンシパルが存在しなければ、ロール/ユーザーが見つからないというエラーになります。これを利用すると、他アカウントの実在するプリンシパルを見つけられます。

  • これがなぜ重要なのか? 明白な理由のひとつは、本番バケットが与えられると、同じ組織の開発バケットも見つけられるようになることで、これは想定外の挙動だ。