
2026/01/16 2:30
**サプライチェーン脆弱性:AWS の主要GitHubリポジトリが侵害され、AWS コンソールへの脅威となる**
RSS: https://news.ycombinator.com/rss
要約▶
Japanese Translation:
Wiz Researchは、ACTOR_ID Webhook フィルタにアンカーされていない正規表現(regex)があることから発見された重大なCodeBuild脆弱性を明らかにしました。この脆弱性により攻撃者は主要なAWS GitHubリポジトリ、特にAWS JavaScript SDK を乗っ取ることができました。フィルタを回避するボットユーザーを作成し、プルリクエストを送信することで、攻撃者はビルドを起動し、メモリをダンプして権限のあるGitHub Personal Access Token(PAT)を取得し、その後悪意あるコードを対象リポジトリにプッシュできました。侵害されたリポジトリには
aws/aws-sdk-js-v3、aws/aws-lc、corretto/amazon-corretto-crypto-provider、および awslabs/open-data-registry が含まれていました。
AWSは速やかに問題を修正し、regex をアンカー化、露出した PAT の取り消し、Pull Request Comment Approval ビルドゲートの追加、および CodeBuild における GitHub トークン用メモリ保護の強化を行いました。下流の利用者に対する影響は確認されず、AWS はすべての公開ビルド環境と CloudTrail ログを監査し、追加の悪用証拠は見つかりませんでした。
開示タイムライン:2025年8月25日(AWS への報告)、2025年8月27日(緩和策実施)、2025年9月(追加ハードニング)、2026年1月15日(公表)。顧客データは公開されていませんでしたが、本件は微妙な設定ミスを悪用した CI/CD パイプライン攻撃の広範な傾向を浮き彫りにし、すべての CodeBuild ユーザーが新しいビルドゲートチェックの実施、regex のアンカー化、細分化された PAT の生成、権限の制限、および CI 用に専用の非特権 GitHub アカウントを検討する必要性を強調しています。
本文
Wiz Research が CodeBreach を発見し、AWS Console のサプライチェーンを危険にさらした重大脆弱性が判明しました。
この問題は、特に AWS JavaScript SDK(AWS Console を動かす中核ライブラリ)という主要な AWS GitHub リポジトリ全体の完全奪取を可能にしました。CodeBreach を悪用すると、攻撃者はマルウェアコードを注入し、プラットフォーム全体で侵害を起こせるため、SDK に依存する膨大な数のアプリケーションだけでなく、Console 自体までが影響を受け、すべての AWS アカウントが危険にさらされます。
脆弱性は、リポジトリの AWS CodeBuild CI パイプラインがビルドトリガーを処理する際の微妙な欠陥から生じました。正規表現フィルタに 2 文字だけが欠けていたため、認証されていない攻撃者がビルド環境へ侵入し、特権付きクレデンシャルを漏洩させることができました。本稿では、この細かな誤設定をどのように利用して完全なリポジトリ奪取を実現したかを解説し、CodeBuild ユーザーが同様の攻撃から自身のプロジェクトを強化するための重要な推奨事項を提示します。
Wiz はすべての発見を AWS に責任ある形で報告し、AWS は迅速に問題を修正しました。さらに、CodeBuild サービス内で同様の攻撃を防止するためにグローバルな強化措置も実装されました。特に新しい Pull Request Comment Approval ビルドゲート は、組織が未検証ビルドを防ぐ簡単かつ安全な手段を提供します。AWS のアドバイザリはここでご覧いただけます。
今回の問題は、最近のサプライチェーン攻撃(Nx S1ngularity 事件など)で見られる典型的なパターンに従っています。CI/CD の誤設定が過度に影響力のある攻撃につながるケースです。昨年7月には、同様の CodeBuild 問題を悪用して Amazon Q VS Code 拡張機能ユーザーに対するサプライチェーン攻撃が行われました。この増加傾向は、組織が CI/CD パイプラインを強化する緊急性を示しています。
必要なアクションと軽減策
影響を受けた AWS GitHub リポジトリの下流消費者に対して直ちに行うべきことはありませんが、AWS CodeBuild ユーザーは以下の保護策を実装し、自身のプロジェクトを同様の問題から守ることを強く推奨します。
-
未検証 Pull Request が特権ビルドをトリガーするのを防止
- 新しい Pull Request Comment Approval ビルドゲートを有効化。
- あるいは、CodeBuild ホスト型ランナーを使用して GitHub ワークフロー経由でビルドトリガーを管理。
-
CodeBuild‑GitHub 接続のセキュリティ
- 各 CodeBuild プロジェクトに対し、ユニークかつ細粒度の Personal Access Token(PAT)を生成。
- PAT の権限は必要最低限に厳格に制限(ここで示すリスト)。
- CodeBuild 統合用に専用の非特権 GitHub アカウントを使用することも検討。
-
Wiz を使った脆弱な CodeBuild プロジェクトの検出
- Wiz 顧客は、事前構築済みクエリを利用して、未検証 Pull Request によってビルドがトリガーされる CodeBuild プロジェクトを Wiz Threat Intel Center で検索可能。
CodeBuild を監査した理由
Amazon Q VS Code 拡張機能に対するサプライチェーン攻撃の試みから、AWS CodeBuild の調査が始まりました。その事件では、攻撃者が誤設定された CodeBuild プロジェクトを悪用し、拡張機能の GitHub リポジトリを乗っ取り、マルウェアコードをメインブランチに挿入しました。このコードはリリースに含まれ、ユーザーがダウンロードした際に実行されました。攻撃者のペイロードは最終的にタイプミスで失敗しましたが、エンドユーザーマシン上で実行されたことは、CodeBuild パイプラインが誤設定されるリスクを明確に示しています。
CodeBuild は GitHub リポジトリと接続して新しい Pull Request などのイベントでビルドをトリガーするマネージド CI サービスです。GitHub と対話するために CodeBuild はデフォルトで GitHub 認証情報を保持し、ビルド環境のメモリ内に置きます。この構成は重大なリスクを孕みます:攻撃者が単一のビルドを乗っ取れば、強力な権限を持つ認証情報をメモリダンプで取得できる可能性があります。
ビルドを作るか否か: Pull Request の問題
CI ビルドを乗っ取る最も一般的な方法は Pull Request を介することです。攻撃者は対象リポジトリをフォークし、マルウェアコードを追加して元のプロジェクトに PR を開きます。CodeBuild が PR イベントでビルドを起動するよう設定されていれば、攻撃者側ブランチからビルドがトリガーされます。make や yarn など多くのビルドシステムでは、ビルドプロセスのソースコードを制御できるだけで任意コード実行が可能です——これは Amazon Q 拡張機能攻撃で利用された正確なメカニズムです。
この攻撃シナリオを防ぐために CodeBuild は Webhook フィルタ(イベントがビルドをトリガーする条件)を提供しています。2018 年以降、これらのフィルタは未検証 Pull Request に対する主な防御手段でした。その中で最も採用されたのは ACTOR_ID フィルタです:許可済み GitHub ユーザー ID のホワイトリストを作成し、信頼できるユーザーのみがビルドをトリガーできるようにします。
これは堅牢な防御のように思えましたが、ユーザー ID リストを維持することは面倒です。実際に組織がこのフィルタを正しく使用しているか疑問に思いました。
初期スキャン
公開 CodeBuild プロジェクトと接続された GitHub リポジトリを検索しました。公開設定の場合、CodeBuild プロジェクトはパブリックダッシュボードで設定を表示でき、ビルドがトリガーされるコミットのステータスに自動リンクします。このダッシュボードから誰でもビルドログと構成(使用中の正確な Webhook フィルタ)を閲覧できます。
初期スキャンでは期待通り結果が得られました。AWS が所有する 7 つのリポジトリに公開 CodeBuild ページがあり、うち 4 つはアクティブで PR に対してビルドを実行するよう設定されていました:
- AWS SDK for JavaScript (aws/aws-sdk-js-v3)
- AWS Libcrypto (aws/aws-lc)
- Amazon Corretto Crypto Provider (corretto/amazon-corretto-crypto-provider)
- The Registry of Open Data on AWS (awslabs/open-data-registry)
表面上はすべて安全に見えました。4 つのプロジェクトとも ACTOR_ID フィルタを実装し、ビルドを許可されたメンテナーリストに限定していました。
微妙な欠陥
フィルタの構文は典型的な ID リストとは異なり、コンマやスペースで区切る代わりにパイプ
| 文字で分割されていました。正規表現では | は「OR」を意味します。ドキュメントを確認すると、フィルタは単なるリストではなく正規表現パターンだったことが判明しました。そして致命的な欠陥が存在していたのです。
アンカー付けされていない正規表現
問題は簡潔ですが重要です:正規表現パターンに開始
^ と終了 $ のアンカーが無かったため、エンジンは完全一致ではなく「含む」文字列を探します。つまり、許可済み ID を部分的に含む GitHub ユーザー ID はフィルタをバイパスできます。
なぜ重要か
GitHub の ID は順序付けられています。2008 年の初期アカウントは 5 桁、近年では 9 桁に拡大しています。このシーケンスが増えるにつれて、短い古い ID が長い新しい ID 内に部分文字列として現れるようになります。毎日約 20 万件の新 ID が作成されるため、新たな長い ID が既存メンテナーの ID を含むものは数日に一度出現します。この「蝕み」ウィンドウを我々は “eclipse” と呼びました。
4 つの AWS リポジトリとも短いメンテナー ID(6〜7 桁)を持ち、頻繁に eclipse が発生し、それらすべてが有効ターゲットになりました。
Eclipse を捉える
特定 ID を取得する方法
多くの GitHub ユーザーを一度に作成する必要がありました。標準サインアップフローは reCAPTCHA で保護されているため自動化できませんでした。その代わり GitHub Apps を利用しました:
- マニフェストフローでアプリを作成 → ボットユーザー(例:
)が Pull Request と対話できます。app-name[bot] - 何百ものアプリ作成リクエストを事前に準備し、固有の確認 URL を保存。
- ターゲット ID が近づくと、すべての確認 URL に同時アクセスし、GitHub に新しいボットユーザー登録を一斉実行。
ターゲット ID は 226755743 で、
aws/aws-sdk-js-v3 の信頼メンテナー ID を含んでいました。
結果
ACTOR_ID フィルタをバイパスできるユーザー ID を取得しました。この方法は、4 つのターゲットリポジトリすべてに対して繰り返し可能でした。
奪取実行
ボットユーザーが ACTOR_ID フィルタを突破したため、
aws/aws-sdk-js-v3 を標的にしました:
- 正当な課題を修正する PR を準備し、ペイロード(ビルド環境で実行され GitHub クレデンシャルを抽出する新しい NPM 依存)を埋め込み。
- PR を送信 → ビルドがトリガー。
- ビルド環境内のプロセスメモリをダンプし、GitHub トークンを取得。
CodeBuild の以前の軽減策ではこの特定プロセスを保護していませんでした。報告後に CodeBuild はこのプロセスも保護対象に追加しましたが、GitHub クレデンシャルは依然としてビルドメモリに残り、Linux 権限昇格脆弱性を持つ攻撃者がメモリ保護を回避できるため、未検証ビルドの実行防止(ビルドゲート)が不可欠です。
爆風半径
取得したトークンは
aws-sdk-js-automation ユーザーの GitHub Classic Personal Access Token (PAT) でした。このアカウントはリポジトリと頻繁に対話し、GitHub に新バージョンを公開する完全管理者権限を持ちます。
タレントスコープ(リポジトリの共同作業者を管理できる)を悪用して、自身の GitHub ユーザーをリポジトリ管理者として招待。管理者になると、メインブランチへ直接コードプッシュ、PR 承認、シークレット漏洩が可能です。
JavaScript SDK は毎週 GitHub でリリースされ、NPM にも公開されます。この頻繁なリリーススケジュールを悪用すれば、攻撃者はリリース直前にマルウェアペイロードを注入し、下流ユーザー(AWS Console を含む)全体を危険にさらせます。驚くべきことに、クラウド環境の 66 % が JavaScript SDK を使用しているため、このライブラリは非常に重要です。
aws/aws-sdk-js-v3 のほか、トークンは JavaScript SDK 関連の複数のリポジトリ(プライベートミラーや AWS 社員の個人 GitHub アカウント)にも管理者権限を持っていました。示された奪取とその潜在的影響を踏まえ、さらなる調査は停止し、直ちに AWS に報告しました。
結論
この脆弱性は、CI/CD 環境が狙われる典型例です:表面上は簡単に見逃せる欠陥が大きなインパクトをもたらします。近年のサプライチェーン攻撃(Nx S1ngularity、Amazon Q)と同じパターンを目にしました。この傾向は偶然ではなく、攻撃者は CI/CD システムに魅了されます:
- 複雑 – 微妙な誤設定が発生しやすい
- 未検証データ – 外部寄稿者のコードをテストすることが多い
- 高権限 – アーティファクト公開やデプロイに強力なクレデンシャルが必要
この組み合わせは、事前アクセスなしで大きな被害をもたらす「天候の嵐」を生み出します。最近の攻撃成功例は重要な警鐘です:防御側はパイプライン権限を削減し、より厳格なビルドゲートを実装し、安全基準を簡単に採用できるようにする必要があります。セキュリティチームの第一歩は、「未検証寄稿が特権パイプラインをトリガーすべきではない」というシンプルで強力な原則を徹底することです。
AWS の声明
AWS は Wiz の研究チームによる「Infiltrating the AWS Console Supply Chain: Hijacking Core AWS GitHub Repositories via CodeBuild」レポートで指摘されたすべての懸念事項を調査しました。
その結果、AWS は Wiz によって発見された問題に対して多くの対策を講じるとともに、将来同様の可能性がある問題から保護する追加措置も実施しました。Actor ID バイパス(アンカー付けされていない正規表現)に関するコア課題は最初の報告から 48 時間以内に修正されました。さらに、GitHub トークンやその他クレデンシャルをメモリ内で保持しているすべてのビルドプロセスへの追加保護も実装しました。また、AWS は AWS オープンソース財産全体で同様の問題が存在しないことを確認するために他の公開ビルド環境を監査しました。最後に、すべての公開ビルドリポジトリおよび関連 CloudTrail ログを監査し、Wiz の研究チームが示したアンカー付けされていない正規表現問題を悪用した他のアクターは確認できませんでした。AWS は、この特定の課題が顧客環境または AWS サービスの機密性・完全性に影響を与えていないと判断しました。
Wiz の研究チームがこの問題を特定し、責任ある協力でお客様を保護し安全にするために取り組んだことに感謝します。
責任ある開示タイムライン
| 日付 | イベント |
|---|---|
| 2025 年 8 月 25 日 | Wiz Research が actor ID バイパスとリポジトリ奪取を AWS に報告。 |
| 2025 年 8 月 27 日 | AWS は脆弱な actor ID フィルタをアンカー付きにし、 の PAT を取り消す。 |
| 2025 年 9 月 | 非特権ビルドがプロジェクトクレデンシャルへアクセスできないよう追加強化策を実装。 |
| 2026 年 1 月 15 日 | 公開情報として公開。 |
ご連絡ください!
こんにちは!私たちは Nir Ohfeld (@nirohfeld)、Sagi Tzadik (@sagitz_)、Ronen Shustin (@ronenshh)、Hillai Ben‑Sasson (@hillai)、および Yuval Avrahami (@yuvalavra) の Wiz Research Team (@wiz_io) です。クラウドをより安全にするための単一の目標を持つベテランホワイトハットハッカー集団です。主に新しい攻撃ベクトルを発見し、クラウドベンダーやサービスプロバイダーの隔離問題を明らかにしています。
ぜひご連絡ください!X(Twitter)またはメールでどうぞ:research@wiz.io