Codecov社のセキュリティインシデント：CIポイズニング攻撃から得た教訓 #aqua #コンテナ #セキュリティ #CI #サプライチェーン攻撃
この記事は1年以上前に投稿されました。情報が古い可能性がありますので、ご注意ください。
本ブログは「Aqua Security」社の技術ブログで2021年5月3日に公開された「 Codecov Breach: Lessons Learned from the CI Poisoning Attack 」の日本語翻訳です。
Codecov社のセキュリティインシデント：CIポイズニング攻撃から得た教訓
Codecov 社が公開した最近のセキュリティインシデントにより、サプライチェーンへの攻撃に再びスポットライトが当てられました。このインシデントの詳細とシステムの運用方法を見ると、組織が継続的インテグレーション(CI)パイプラインの一部としてサードパーティのサービスを利用する場合の利用方法を見直すべきであることは明らかです。では、このような事態が発生するリスクを減らすためにはどうすればよいのでしょうか。
Codecov社に何が起きたのか
Codecov 社のインシデントレポートから、この攻撃がどのように発生したかを知ることができます。攻撃者は、Codecov が Docker イメージを構築する際のミスを利用してクレデンシャルにアクセスできました(これはコンテナ構築におけるシークレット管理の重要性を示す良い例です)。このクレデンシャルを利用すると、顧客が直接使用したり、Github Action などの他のアップローダを介して使用される bash アップローダースクリプトを変更できます。攻撃者は、この変更されたスクリプトを使用して、それを使用している顧客の CI 環境から認証情報を盗み出しました。
curl|bash の危険性
bash アップローダースクリプトの動作を見てみると、CI スクリプトに次のような一行のコードを追加することが推奨されていることがわかります。
bash <(curl -s https://codecov.io/bash)
これは、一般的に curl bashing と呼ばれる例で、URL から直接環境内でスクリプトを実行するものです。このようなソフトウェアの実行方法には、セキュリティ上の問題があります。これはソフトウェアを使用する際に、あなたが信頼したシステム構成に帰結します。この種のソフトウェアインストールのセキュリティ上の問題点は、以前から知られていました(OWASP Appsec EU 2015 での講演で、言及しています)。
一般的に、ソフトウェアをインストールする際は、作者が優れたセキュリティを実践しており、悪意がないという前提で行います。しかし curl|bash を使用する場合は、ソフトウェアを格納しているサーバと、そのサーバを管理している可能性の高いクラウドアカウントが安全に運用されていることも前提となります。今回のケースのように、ホスティングインフラへの不正なアクセスが発生していることが無いことも前提となります。
このように、「前提となる」ポイントが増えるほど、攻撃者がソフトウェアを改変したり、サプライチェイン攻撃される可能性が広がります。
取るべき行動
ここでは、Codecov を使用しているユーザがすぐにできることから、今後このような事態が発生するリスクを軽減するための戦略的なアクションまで、さまざまなことを行う必要があります。
まず最初に行うべきアクションは、Codecov がさらされているリスクを正しく評価することです。Codecov を使用していた場合、Codecov がアクセスできる環境に保管されているすべての情報は、漏洩する危険性があると考えるべきです。今回のケースでは、攻撃者の主な標的はクレデンシャルであると思われるので、CI 環境に露出していたクレデンシャルをすべてローテーションすることが必要です。
また、Codecov 社は、悪用の証拠となるログを確認する際に使用できる Indicators of Compromise(セキュリティ侵害インジケーター)のリストを公開しています。
2つ目のアクションは、CI 環境で Codecov のようなツールを使用している場所を確認し、それらのツールに対する攻撃のリスクを軽減する方法を検討することです。
セキュリティの観点からは、理想的には CI プロセス中にサードパーティのスクリプトを動的にダウンロードすることを避けるのが良いでしょう。実行、更新されるスクリプトのバージョンコントロールを行うことで、より詳細な制御ができるようになりますが、当然ながら手動で更新するためのオーバーヘッドも発生します。
スクリプトを動的に組み込む必要がある場合は、スクリプトを使用する前にスクリプトの整合性をチェックすることが有効な手段となります。使用しているツールがデジタル署名付きでリリースされているのが理想的です。そうであれば、署名のチェックをパイプラインに実装することで、不正な変更に対する効果的な対策となります。
署名入りのリリースがない場合でも、ダウンロードしたファイルのチェックサムにより検証可能です。Codecov 社は最近、bash アップローダを使用した Github Action を修正し、実行中のスクリプトのチェックサムを公開された値と照合し、一致しない場合は失敗するようにしました。
また、より戦略的な提案としては、CI の一環として使用しているサードパーティのサービスを見直し、そのセキュリティを評価プロセスの一部として考慮することです。OSSF Scorecard のようなプロジェクトは、利用しているオープンソースプロジェクトが一般的なベストプラクティスをどのように採用しているかを迅速に把握するのに役立つツールです。
まとめ
Codecov社のセキュリティインシデントは、増え続けるサプライチェーンへの攻撃手法の一例です。次にどのサービスが被害を受けるかはわかりませんが、攻撃者が組織のシステムやデータへのアクセスを試みる手法として、今後も継続的な課題であることは明らかです。
その結果、開発プロセスのすべての領域にサプライチェーンセキュリティ対策を組み込み、潜在的なリスクを明確に可視化し、そのリスクを低減するための対策をプロセスに追加する必要性が高まっています。
Aqua DTA がどのようにサプライチェーン攻撃から保護するかをご覧ください。
