公開されたTravis CI ログ：ユーザをサイバー攻撃の危険に #aqua #セキュリティ #argon
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2022年6月13日に公開された「 Public Travis CI Logs (Still) Expose Users to Cyber Attacks 」の日本語翻訳です。
公開されたTravis CI ログ：ユーザをサイバー攻撃の危険に
Aqua のセキュリティ研究チームである Team Nautilus は、最新の調査において、Travis CI API を通じて、何万ものユーザトークンが公開されていることを発見しました。これにより誰もが過去のログに平文でアクセスすることができます。無料層ユーザの 7億7000万件 以上のログが公開されており、そこから GitHub、AWS、Docker Hub といった人気のクラウドサービスプロバイダーに関連するトークン、シークレット情報、その他の認証情報を容易に抽出できます。攻撃者はこの機密データを使って、大規模なサイバー攻撃を仕掛けたり、クラウド内で横移動したりできます。
Aqua はこの調査結果を Travis CI に開示しましたが、Travis CI はこの問題が「設計によるもの」であると回答しており、現在すべての機密情報が利用可能になっています。すべての Travis CI 無料ユーザは、潜在的に暴露されているので、すぐにシークレット情報をローテーションすることをお勧めします。
また、各サービスプロバイダーにも調査結果を報告しました。ほぼすべてのサービスプロバイダーは、警告を発し、迅速に対応しました。あるプロバイダーはシークレット情報のローテーションを開始し、またあるプロバイダーは Aqua の調査結果の少なくとも 50% がまだ利用可能であることを確認しました。また、いくつかのベンダーは、調査結果の公開に対して報奨金を提供してくれました。
このブログでは、クラウド上の横移動フローに光を当てた私たちの研究成果を紹介します。
Travis CI API：過去と現在の調査内容
この問題は、過去に Travis CI へ報告され、2015年と2019年にメディアで発表されましたが、完全に修正されることはありませんでした。2015年、Travis CI はインシデントレポート上に以下のような通知を公開しました。
「現在、GitHub 認証トークンの漏洩を狙ったと思われる公開 API への分散攻撃を受けています。対策は保留しており、適宜更新します。」
Travis CI はこの問題を解決すると、次のように公表しました。
「最近導入した適応型アクセス制御とブロック機能によって正しく実行されています。」
2019年、研究者のチーム(Justin Gardner、Corben Leo、EdOverflow)は、Travis CI API とそれがトークン、シークレット情報、認証情報を抽出するために悪用される方法についてブログを書きました。彼らの研究は、バグバウンティとハッカーがどのように Travis CI ログのシークレット情報を利用するかに焦点を当てたものです。
Aqua の研究では、彼らの手順の一部を再現しましたが、さらにいくつかの他の手順と生データの詳細な分析も追加しました。目標は、CI プラットフォーム上のデータがサイバー攻撃を仕掛けるために使用できるか、またクラウド上でもっともらしい横方向の動きを観察できるかを理解することでした。
継続的インテグレーション、継続的デプロイメント、アクセストークン
最近では、継続的インテグレーション(CI)と継続的デリバリー/デプロイメント(CD)は、最新の開発およびクラウドネイティブアプリケーションのパイプラインの主要な部分となっています。アプリケーションに変更を加えるたびに、コードは定期的にビルド、テストされ、共有リポジトリにマージされます。そのため、これらの環境では通常、クラウドやパイプラインの他の部分に自動的に到達するためのアクセストークンなどの多くのシークレット情報が保存されています。場合によっては、これらのアクセストークンには、読み取り、書き込み、管理などの高い権限が設定されています。このようなアクセストークンが漏洩した場合、データ漏洩やアカウントの乗っ取り、さらには複数のクラウドアカウントをまたがる横移動につながる可能性があります。
Travis CI 調査：主なステップ
CI/CD とアクセストークンが何であるかが分かったところで、調査の詳細に入りましょう。
目的は、CI パイプラインを分析し、CI サービスを利用することで発生しうるリスクのレベルをより良く理解することでした。Travis CI に焦点を当て、その API が認証されていない匿名ユーザに7年前までの履歴ログを平文でレンダリングする可能性についての既存の研究を基にしています。
ログの取得
クラウドにおける潜在的な攻撃ベクトルを検証したいと考え、以下のAPIを調査に使用しました。
https://api.travis-ci.org/v3/job/[4280000-774807924]/log.txt
以下は使用例です。
https://api.travis-ci.org/v3/job/5248126/log.txt
Travis CI API のマニュアルに基づき、平文のログを取得するための有効な API 呼び出しには、ログ番号が必要であることを発見しました。この場合、0から無限大の間の利用可能なすべてのログを取得する列挙型スクリプトを簡単に適用できます。他のベンダーでは、アプリケーション ID または顧客 ID (あるいはその両方) を URL に記述する必要があるため、ログを列挙することが容易ではありません。
今回の調査では、ログを取得するための様々な API コールを検討しました。今回上記の方法で調査しましたが、ドキュメント化された API を経由して、https://api.travis-ci.org/logs/XXX のURLで、以前はアクセスできなかった新しいログにアクセスできる別の API コールも見つけました(おそらく削除された過去のログです)。
「XXX」は、1～数億の範囲にある特定のログ番号を示しています。この API コールは、Travis CI の S3 バケットを指しながら、そのバケットへのワンタイムトークンを生成して、アーカイブされたログを取得するためのものです。いくつかの API コールを実行した後、この方法は認証されていない匿名ユーザがすべてのログを取得することを可能にすると推測されます。
この API コールを送信すると、散発的なログにアクセスできることがわかりました。
https://api.travis-ci.org/logs/1
上記にアクセスすると、下記 URL にリダイレクトされます。
https://s3.amazonaws.com/archive.travis-ci.org/jobs/4670478/log.txt?X-Amz-Expires=30&X-Amz-Date=202206...
この同じログを、対応するログ番号でこの API から取得できます。
https://api.travis-ci.org/v3/job/4670478/log.txt
興味深い発見は、これまで利用できなかったログを https://api.travis-ci.org/v3/job/
https://api.travis-ci.org/logs/6976822
上記アクセスすると、下記 URL にリダイレクトされます。
https://s3.amazonaws.com/archive.travis-ci.org/jobs/13575703/log.txt?X-Amz-Expires=30&X-Amz-Date=202206…
しかし、同じログ番号を用いた以下URLでは、API経由でログを取得できません。
https://api.travis-ci.org/v3/job/13575703/log.txt
実験を行った結果、最も古いログは2013年1月、最も新しいログは2022年5月で、ログの有効範囲は 約428万件～7億7千480万7,924件 であることがわかりました。つまり、潜在的に 約7億7千万件 のログが公開されていることになります。
ログからシークレット情報を抽出する
次の段階として、2つのランダムサンプルを作成しました。まず、2万件 のログをランダムにサンプリングし、この範囲のログがすべて利用できるわけではないですが、平文で返ってくるものもあれば、アクセストークンやシークレット情報を明らかにするものもあることが判明しました。次に、約800万 リクエスト(約1%)の別のサンプルを作成し、データをクリーニングした結果、これらのログファイルには 約73,000件 のトークン、シークレット情報及びさまざまな認証情報が含まれていることが判明しました。これらのシークレット情報は、GitHub、AWS、Docker Hub など、さまざまなクラウドサービスに関連するものでした。
以下はその例です。
Travis CI は API 呼び出しの速度を遅くし、API のクエリ機能を阻害することで、対策をしていました。しかし、今回のケースでは、これでは不十分でした。熟練した攻撃者は、これを迂回する回避策を見つけることができます。さらに、履歴ログのデータの一部はマスクされており、かつては平文のシークレット情報があった場所に、文字列「[secure]」を表示することがあります。
Travis CI が、ログに表示されるシークレットやトークンを難読化する努力をしていることは間違いありません。実際、ログに表示されるトークンのほとんどが検閲されていました。さらに、Travis CI は、ビルドログを手動で削除したり、定期的にシークレット情報をローテーションするなど、漏洩を避けるための推奨事項を提供しています。
しかし、API 経由のログへのアクセスのしやすさ、不完全な検閲、「制限された」ログへのアクセス、API へのアクセス制限やブロックのプロセスの弱さ、そして潜在的に公開されるログの多さが相まって、結果として危機的状況に陥っているのです。
とはいえ、ログにシークレット情報やパスワード、トークンを出力する規約は多く、そのほとんどが平文で残っていました。例えば、「github_token」はマスクされているケースが多く、シークレット情報が開示されていないことがわかりました。しかし、Travis CI ではこのトークンがマスクされていないパターンが20種類ほど見つかりました。
Aqua Trivyを使ってログをスキャンし、シークレット情報を探る
開発者がコーディングのベストプラクティスに従っていても、パスワードなどのハードコードされたシークレット情報を無意識のうちに公開したり、それを持ち込む可能性のあるサードパーティのコードやコンテナイメージを使用することがあります。Trivy Open Source を使用すると、ハードコードされたシークレット情報をターゲットに簡単にスキャンできます。Trivy は、あらゆるコンテナイメージ、ファイルシステム、Git リポジトリをスキャンして、公開されているパスワード、API キー、トークンを検出します。私たちは Trivy を使って、取得したログをスキャンしました。
データによれば、ランダムな API コールの後、42% のケースで有効なログを取得することができます。つまり、100回 の API コールに対して、42回 の有効なログを取得できることになります。これらのログから、シークレット情報を抽出できます。
これらのシークレット情報を整理した結果、様々な環境に対するアクセストークンが多く見つかりました。以下はその例です。
- GitHub のアクセストークン(コードリポジトリへの特権的なアクセスを許可する場合があります)
- AWS アクセスキー
- MySQL や PostgreSQL などのデータベースへのアクセスを許可する、電子メールやユーザ名とパスワードなどの認証情報のセット
- Docker Hub のパスワード多要素認証が有効でない場合、アカウントを乗っ取られる可能性があります。
クラウドでの攻撃：複数のユースケース
Aqua はこの研究を、「クラウドの横移動をどうやって検出するか」と考えることから始めました。CI/CD 環境を分析しましたが、ではどうやってその中にシークレット情報を見つけることができるのでしょうか。私たちは、Travis CI API を経由した平文ログに関する過去の発表を見て驚き、Travis CI に問題が開示された後もこれが可能であることを知り、驚きを隠せませんでした。
調査中に入手したトークンを使って、クラウド上での横移動の攻撃シナリオをいくつかシミュレーションしてみました。以下、主なシナリオを紹介します。
ユースケース：クラウドにおける横移動
GitHub OAuth トークンは 数千件 見つかりました。特に最近のログで見つかったものは、少なくとも 10% から 20% は利用可能なものと考えてよいでしょう。私たちはクラウドで、以下の初期アクセスシナリオに基づく横移動の攻撃シナリオをシミュレートしました。
- 公開された Travis CI ログを経由した GitHub OAuth トークンの抽出
- 公開されたトークンを利用したプライベートコードリポジトリ内のシークレット情報(AWS アクセスキーなど)の発見
- AWS S3 バケットサービス内の AWS アクセスキーによる横移動の試行
- バケット列挙によるクラウドストレージオブジェクトの発見
- ターゲットの S3 から攻撃者の S3 へのデータ流出
ユースケース：発見と情報収集
ログには、コードパッケージやその依存関係の名前など、制限されたシークレット情報が含まれていることがよくあります。攻撃者は、コードパッケージの名前を収集し、不足しているコードパッケージや問題のあるコードパッケージ、またはその依存関係を探すことができます。そして、攻撃者はこれらのコードパッケージを要求し、パッケージマネージャに仕込んで、ユーザに悪意のあるコードパッケージをダウンロードさせることができます。
Travis CI ログの一部には、攻撃者がさらなる資産を発見するのに役立つ IP レンジが見つかりました。さらに、内部のドメインネームシステム(DNS)の表示も確認されており、これも熟練した攻撃者であれば、攻撃対象領域を拡大するために悪用可能です。
さらに、アクセストークン付きの S3 バケットへの URL もいくつか発見されました。ネットワークルールでバケットへの受信トラフィックを制限していない場合、これらの特定のバケットからのデータ漏えいにつながる可能性があります。
ユースケース：コードリポジトリやレジストリを利用したソフトウェアサプライチェーン攻撃
特定のコンテナイメージのレジストリに対する 何十件 ものシークレット情報が見つかりました。その中のいくつかは、大規模な組織や人気のあるオープンソースプロジェクトに属している可能性があります。これらの認証情報は、セキュリティのベストプラクティス(長いパスワード、大文字、特殊文字、数字)に沿っています。平均的な攻撃者にとって、これらのパスワードの推測は困難です。しかし、これらの認証情報が悪用された場合、攻撃者は公開および非公開のレジストリに特権的にアクセス可能になります。
考えられるシナリオの1つは、プライベートレジストリから専有データを盗むことです。より邪悪な目的としては、コンテナイメージにバックドアやマルウェアなどの悪意のあるコードを仕込んで、それらが配置された環境へのアクセス許可を得ることが考えられます。人気のあるオープンソースプロジェクトの場合、これは、より広いコミュニティに感染させることを目的とした大規模な攻撃につながる可能性があります。
ユースケース：ソースコードの盗難
2022年4月15日、GitHub は、Travis CI と Heroku に発行した OAuth トークンを盗まれ、一部のリポジトリに攻撃者がアクセスできたとして、厳重警告を発しました。ほとんどの場合、攻撃者はユーザの全組織をリストアップしているだけであることがわかりました。その後、攻撃者はターゲットを選択し、関心のあるユーザアカウントのプライベートリポジトリをリストアップしました。最後に、攻撃者はこれらのプライベートリポジトリのいくつかをクローンすることを進めました。
MITRE ATT&CKフレームワークへの攻撃のマッピング
ここでは、上記の攻撃における構成要素を、MITRE ATT&CK フレームワークの対応する技術にマッピングしています。
緩和策
このようなリスクを軽減し、CI 環境を保護するために、いくつかの推奨事項があります。
- シークレット、トークン、その他の情報のローテーションポリシーを確立する
- シークレットやトークンに最小特権原則を適用する
- シークレット、トークン、認証情報をログに出力しない
- 定期的にアーティファクトをスキャンし、シークレットを確認する
- シークレットのローテーションを行う最適なタイミングを示すクラウドセキュリティポスチャーマネジメント(CSPM)ソリューションを使用。自分のアカウントをスキャンし、ローテーションの周期を確認し、最小特権ポリシーを適用したかどうかを確認可能になる。
- Argon などのサプライチェーンセキュリティソリューションで CI/CD 環境をスキャンし、公開されたシークレット、トークン、シークレット情報を見つけ、アカウント構成がベストプラクティスに沿っていることを確認する
