*本ブログは自動翻訳です。
もしIAMユーザーが制限なく自由にAWS APIキーを生成できるとしたら？もしセキュリティ管理者がAPIキーの作成を可視化できず、誰がAPIキーを使用したかを監査できないとしたら？
このシナリオはAWSには当てはまりませんが、Google CloudのHMACキーにとっては厳しい現実です。このブログでは、Google Cloudがユーザー関連のHMACキーを処理する方法から浮上した3つの脆弱性について概説します。
1.脆弱性その1 - 不十分なロギング
2.脆弱性その2 - 管理不能な長期クレデンシャル
3.脆弱性#3 - 監査不能な長期クレデンシャル
TLDR；
- HMACキーは実用的な目的を果たす。これは、Cloud Storage XML APIに対する認証に使用されるSigv4署名付きヘッダーの作成に使用できる
- Googleクラウド監査ログは、ユーザーアカウントに関連付けられたHMACキーの作成または削除イベントを記録しない
- 管理者はGoogle Cloud APIを利用できないため、ユーザーアカウントに関連するHMACキーの存在を監査できない
- HMACキーの作成、削除、使用を制限するクラウドIAMパーミッションはない
- この問題はGoogleの脆弱性報奨プログラムを通じて報告されており、報告された動作が意図したとおりに動作しているとして、修正プログラムを提供せずに問題をクローズした
HMACキーの使用
ユーザーアカウントに関連付けられたHMACキーの作成と削除のためのAPIは、外部からはアクセスできません。これらの操作は、ストレージコンソールの相互運用性タブからアクセスできるクラウドコンソールプライベートAPIサービス（cloudconsole-pa）を通してのみ実行できます。以下のURLは、有効なログインクッキーが添付されている場合に、ユーザー関連HMACキーの作成と削除に使用されるクラウドコンソール内のエンドポイントを示しています。
- v3/entityServices/StorageEntityService/entities/STORAGE_USER_HMAC/CREATE`へのPOSTリクエストは、Sigv4署名プロセスで使用されるHMACキーを作成する。
- v3/entityServices/StorageEntityService/entities/STORAGE_USER_HMAC/DELETE`へのPOSTリクエストはユーザーに関連付けられたHMACを削除する。
Google Cloudのユーザーは、リソースタイプを無限に作成することができます："type.googleapis.com/google.internal.cloud.console.clientapi.storage.UserHmac"
テストではHMACキーの上限は確認されず、レーティングの制限も発生しませんでした。
脆弱性その1 - 不十分なロギング
クラウド監査ログは、クラウドコンソールプライベートAPIサービス (cloudconsole-pa) を介したアクションをキャプチャしません。その結果、ユーザーアカウントに関連する HMAC キーの作成または削除のログが記録されません。このログの不在は、ユーザーアカウントに対する HMAC キーの作成を警告または監視する防御者の能力を妨げ、永続性リスクを引き起こします。
脆弱性その2 - 管理不能な長期クレデンシャル
Google CloudにアクセスできるユーザーはHMACキーを作成でき、少なくともリソース resource manager.projects.get権限が必要です。しかし、クラウド IAM には自己または他のユーザーの HMAC キーを管理する権限がないため、管理者が HMAC キーの作成を制御することができません。その結果、本アドバイザリでは、パーミッションの割り当てを制限することでHMACキーの暴露リスクを軽減するための推奨事項は提供していません。
脆弱性その3 - 長期間のクレデンシャルを監査できない
クラウド管理者は、組織内で HMAC キーを管理する際に、どのユーザ アカウントがこれらのキーを生成し、それらがストレージ オブジェクトへのアクセスにアクティブに使用されているかどうかを可視化することができないという課題に直面しています。さらに、他のユーザーに関連付けられているキーを取り消す機能がないため、セキュリティ ポリシーを効果的に実施する能力が制限されています。
インシデント対応チームは、Cloud Storageオブジェクトへのアクセスを監視するためにCloud Loggingに依存していますが、HMACキーがこれらのアクセス試行で利用されているかどうかを判断する具体的な指標がありません。侵害されたユーザーアカウントの一時停止や削除など、さまざまな封じ込めアクションは、以前に作成されたSigv4署名ヘッダーを拒否することで、当初は効果的に見えるかもしれませんが、同じユーザーを再アクティブ化または再作成すると、有効期限が切れていない限り、認証情報の再利用が可能になります。
さらに、クラウドIAMロールを削除すると、影響を受けるストレージリソースへのアクセスを取り消すことができます。ただし、ロールを再割り当てしても、以前に作成されたSigv4署名付きヘッダーは無効にならないため、ロールの変更後も機能し続けることができることに注意することが重要です。
HMACキー悪用事件
GoogleクラウドプロジェクトにアクセスできるGoogleユーザーアカウントを所有し、最低限`resource manager.projects.get`権限を持つ攻撃者は、ストレージコンソールの相互運用性タブでHMACキーを生成することができます。
HMAC鍵を利用した攻撃経路は以下のようになる：
1.攻撃者がGoogleユーザーアカウントを侵害
2.ユーザーのHMAC鍵を生成する
3.HMAC鍵を使用して、7日間有効の一連のSigv4署名付きヘッダーを生成する
4.ヘッダー署名の有効期限が切れるまで、Google Cloud Storageからデータを流出させる
5.上記の脆弱性#1、#2、#3により、悪意のあるストレージへのアクセスやレスポンス の特定が妨げられる
封じ込めの試みは、侵害されたユーザーのパスワードを変更するなどの効果がないか、影響を受けたユーザーが一時的に停止され、後で再アクティブ化される可能性がある
概念実証
GoogleクラウドSDKには、Sigv4署名プロセスを通じてユーザー関連のHMACキーを使用可能なクレデンシャルに変換する機能は公開されていません。 そのため、それを行うためのシンプルなpython ヘルパースクリプトを用意しました。このスクリプトは、アクセスキー ID、シークレット、オブジェクト、バケット名を受け取り、XML API を介して対象の GCS オブジェクトを取得するために使用される、署名された認可ヘッダを持つ curl リクエストを返します。
この概念実証は、Google Cloudの認証にHMACを使用するというRosy Parmarの記事に大きく影響を受けています。
推奨事項
ユーザー固有のHMACキーに関連する多数の悪用に鑑みて、GCP HMACキーの管理、ロギング、およびライフサイクルを強化する一連の推奨事項を示します。
1.パーミッションとAPI
- 管理者に権限を与えるAPIと関連権限を導入し、必要に応じてユーザー固有のHMAC鍵を作成・削除する権限を与える
- Googleワークスペース管理者が、組織内の全ユーザーのHMACキーの監査、使用状況、他のユーザーのキーの削除ができるAPIと関連する権限を作成する
2.組織政策の制約
- ポリシー管理者がユーザー関連HMACキーの作成を防止できるように、組織ポリシー制約を作成する
3.ロギング
- 管理者アクティビティへの書き込み 管理者は、ユーザーに関連するものも含め、すべてのHMAC鍵の作成と削除を記録する
- Sigv4ヘッダークレデンシャルを使用してCloud Storage XML APIにアクセスした場合、Cloud Logsに表示される
4.クレデンシャル管理
- ユーザーが作成できるHMAC鍵の数を最大2つに制限する
- HMAC鍵にユーザが設定した有効期限データを導入する
- HMACキーは、作成時に一度だけユーザーに表示し、それ以降のリクエストではUIに秘匿しない
情報開示のタイムライン
2/07/24 [Kat Traxler]：GoogleのVulnerability Reward Programに "HMAC keys generated for users pose security risks, especially due to the absence of logging events upon their creation or deletion "という見出しで報告。
2/07/24 [グーグル]：報告書の受領を確認
2/08/24 [グーグル]：詳細が不明なため、問題をクローズすることを示唆。 攻撃シナリオとコンセプトの証明を要求
02/09/24 [Kat Traxler]： HMACキーの特性を考慮した攻撃者の行動のより詳細なウォークスルーとPoCを書く約束で回答
2/12/24 [グーグル]：ステータスが「割り当て済み、再開、トリアージ済み」に変更された
2/16/24 [Google]：Google Bug Hunter Team は、報告された脆弱性の詳細を要約し、Sigv4 署名ヘッダの例を要求し、Google Cloud Storage XML API 以外へのアクセスに認証情報が使用できるかどうかを尋ねた。
2/18/24 [Kat Traxler]：一連の質問に回答し、HMACキーから生成された認証情報はGoogle Cloud Storage XML APIへのアクセスにのみ使用できることを確認した。
2/19/24 [Kat Traxler]：Google Bug Hunter TeamにGithubでホストされているPoCへのリンクを提供し、HMACキーで署名されたヘッダーを生成できるようにした。
2/28/24 [グーグル]：この問題は「虐待のリスクとして特定され、信頼と安全チームにトリアージされた」。
2/28/24 [グーグル]：報告書へのお礼と、チームが提出された報告書を分析中であることを示す返信。
04/01/24 [Kat Traxler]：「このレポートのフォローアップです。 最後にお話してから4週間ほど経ちました。念のためお伝えしておきますが、私はこの問題を6月の第1週頃に公表する予定です。その間にサービスチームと調整し、不足しているロギングとIAMコントロールを実装したいと思います。新しいイベントのロギングと新しいIAMコントロールがなければ、開示には永続化メカニズムの詳細が記載されるだけで、それを防止または検出する方法について顧客向けのガイダンスは何もありません。誰もそのような開示ブログを好みません。*この問題の提起や責任当事者との調整をどのように手伝えばよいか教えてください。」
4/02/24 [Google]：「🎉ナイスキャッチ！あなたの報告に基づいて、担当の製品チームにバグを報告しました。製品チームと協力してこの問題に確実に対処します。問題が修正されたらお知らせします。」
4/11/24 [Google]：「Google脆弱性報奨プログラム委員会は、この問題のセキュリティへの影響は、金銭的な報奨の基準を満たさないと判断しました」
6/04/24 [Google]：「私たちのシステムによると、あなたの報告に基づいて私たちが作成したバグは、修正を提供することなくクローズされました。これは様々な理由で起こったかもしれません。リスクインパクトが小さすぎて修正が必要でない、他の緩和要因がある、あるいは単に製品がもう保守されていないなどです。正確なステータスは INTENDED_BEHAVIORです。この決定は関連する製品チームによって下されたものであり、VRPの報酬額やリーダーボードの順位には影響しません。この自動通知では詳細をお知らせできませんが、この決定に関するご質問には喜んでお答えします」