サプライチェーン攻撃を分析する #aqua #コンテナ #セキュリティ #動的解析 #DTA #サプライチェーン攻撃

本ブログは「Aqua Security」社の技術ブログで2021年7月8日に公開された「 Innovation in the Hands of Threat Actors: Analyzing Supply Chain Attacks 」の日本語翻訳です。

サプライチェーンへの攻撃を分析する

---

Solarwinds 社や Codecov 社のような大規模な攻撃を受けて、企業はソフトウェアサプライチェーンセキュリティに積極的に取り組んでいます。しかし、クラウドネイティブアプリケーションに組み込まれた大量のアーティファクトを効果的に保護するためには、まず敵を理解する必要があります。この記事では、悪意のある攻撃者がソフトウェアサプライチェーンに侵入し、無数の組織に影響を与えるカスケードを開始するために使用している、最も一般的な攻撃タイプをいくつか紹介します。

クラウドネイティブ時代のサプライチェーン攻撃

現代のアプリケーションは、コンテナ、カスタムコード、オープンソースコンポーネント、サードパーティのアーティファクトなど、複雑なマルチレイヤー構造で定義されることが多くなっています。この新しいソフトウェア構成は、ソフトウェア開発ライフサイクルの初期段階では見られなかった新しい DevOps プロセス、CI/CD ワークフロー、自動化をもたらしました。このような進化に刺激された攻撃者たちは、開発・デプロイの加速化を利用してソフトウェアのサプライチェーンに侵入し、従来のアプリケーションセキュリティテストでは検出されない高度な攻撃をしています。

ソフトウェアの脆弱性は、依然として組織の防御を突破する役割を果たしています。それに加えソフトウェアのサプライチェーンには、悪意のあるアーティファクトを導入したり、内部から不正な活動するための新たな機会が圧倒的に多く存在していることも覚えておきましょう。※マルウェアは脆弱性ではないので、同じ方法では検出、対処はできません。

これらの攻撃は多種多様で、非常に複雑なものもありますが、その多くは基本的な原理が類似しており、開発者の見落としや CI/CD パイプラインのセキュリティ上の制限を利用しています。いくつかの例を挙げて、これらをさらに分析してみましょう。

タイポスクワッティング

これは人気のあるオープンソースや公開されているライブラリの様々な誤字を使って悪意のあるファイルの名前を付けるという手口です。その一例が Jellyfish ライブラリで、攻撃者が最初の "L(エル)"を大文字の "I(アイ)"に置き換えた、人気のあるライブラリのタイプミスバージョンを使用していました。発見された時点で、この悪意のあるパッケージは入手可能になってから1年が経過していました。そして別の人気のある Python Package Index(PyPI)ライブラリと関連づけられ、その関連づけによって悪意のあるパッケージとなり、元の悪意のあるパッケージの影響範囲を広げていました。

このようなタイプミスは、巧妙に偽装されていることが多く、開発者が厳しい納期の中で素早くコンポーネントをプロジェクトに組み込もうとしているときには、非常に見落としやすいものです。このようなタイプミスには注意してください。多くの組織にとって、この問題に対処する最も直接的な方法は、プロジェクトに組み込むライブラリやパッケージを選択する際に注意を促す、適切な開発者教育とセキュリティ意識向上のためのトレーニングです。

依存関係かく乱(dependency confusion)攻撃

これは今年2月に発表された Alex Birsan の研究で流行した、ソフトウェアのサプライチェーンに潜入するための興味深いアプローチです。Birsan 氏は、JavaScript ファイルや GitHub のコードなどに含まれるプライベートライブラリ名を見つけ出し、そのプライベートライブラリ名に一致するパブリックライブラリを自分で作成するという試みを行いました。

この研究により、自動化されたビルドプロセスでは、プライベートリポジトリではなく、npm や PyPI などの場所からパブリックライブラリを優先的にプルすることが多いことを証明しました。これは、多くの DevOps 専門家や開発者がパイプラインに組み込んでいる自動化手法や CI/CD へのハンズオフアプローチを悪用した手法です。このような問題は、いつまでも発見されないことがあります。そのため多くの場合、データ漏洩が発生したり、他人のマイニング作業のために不注意でリソースを過剰消費したとして、クラウドプロバイダーから驚くほど高額の請求が来たりして初めて発見されます。

この手法に対する認識が高まっているにもかかわらず、多くの組織は CI/CD ツールの「適切な」設定と、意図した結果を検証するための一連の「チェックアンドバランス」に頼る傾向があります。成功するかどうかは、ツールを管理する人の技術的能力と、セキュリティの熟練度に依存します。

信頼の悪用(exploiting trust)

私はこの次の攻撃タイプを、より広い概念である「信頼の悪用」と定義していますが、これは様々な形で現れます。例えば、人気のあるライブラリがマルウェアを含むように改変されている例は数多くあります。これは、悪意のある開発者がボランティアでプロジェクトを引き継いだ場合や、セキュリティ意識の低いコミュニティがプロジェクトを維持している場合などが考えられます。また、悪意のある攻撃者がボットを使って悪意のあるパッケージの評価や統計情報を人為的に誇張することで、開発者が自分のプロジェクトに使用するコンポーネントを探す際に、悪意あるライブラリを信頼するように仕向けたりする例もあります。

また、開発者用ツールが危険にさらされている例も数多く見受けられます。最初は信頼されていたものの、悪用されたり感染した結果、悪意のあるソフトウェアパッケージが意図的に採用された場合に起こるであろう結果と同じになります。この好例が 4月 に公開されました。Codecov 社は、何者かが Codecov 社の Docker イメージ作成プロセスのエラーを利用して認証情報を抽出し、同社の Bash Uploader スクリプトを改変したと発表しました。その後、攻撃者はこの修正されたスクリプトを使用して、このスクリプトを使用している顧客の CI 環境から認証情報を盗みました。

どんなに開発者のセキュリティ教育をしたりツール側で設定をしても、第三者が「信頼されている」状態から逸脱することを説明できないため、開発者ツールへの攻撃は組織にとって克服が最も難しい場合もあります。信頼を疑う指標として、潜在的な障害が増えたり、開発からデプロイまでの流れが遅くなるという傾向があります。そして、ひとつだけ確かなことは、組織のセキュリティ対策をサードパーティのセキュリティ能力に依存させないということです。

ソフトウェアサプライチェーンのセキュリティリスクの管理

多くの場合、ソフトウェアのサプライチェーンにおけるセキュリティリスクは、コンテナがアクションを実行したり、ネットワーク通信が行われたりするランタイムになって初めて顕在化します。先に述べたように、静的分析(SAST)、動的分析(DAST)、ソフトウェア構成分析(SCA)などの従来のソフトウェアセキュリティテストでは、これらのリスクを検出できません。マルウェアやその他のサプライチェーンのリスクは脆弱性ではありませんが、サプライチェーンを通じて得られるアーティファクトには、脆弱性などが含まれている可能性が十分にあります。

つまり、このような悪意のあるパッケージや異常なアクティビティを最も確実に検出する方法は、アプリケーションやコンテナが稼働中の状態であることです。

もちろん、アプリケーションをいきなり本番環境で実行してはなりません。本番環境へ昇格する前に、CI/CD プロセスの一環として、まずは安全なテスト用サンドボックスでアプリケーションを起動するような、自動化された方法を確立することをお勧めします。その際には、コンテナのアクティビティやネットワーク通信などの動作を分析し、潜在的な攻撃が行われていないかを検知することが重要です。ソフトウェアサプライチェーンのセキュリティリスクを管理するための、これらのベストプラクティスについては、今後のブログでさらに詳しく説明します。

それまでは、Aqua Dynamic Threat Analysis(DTA)の概要動画をご覧ください。Aqua DTA は、安全なサンドボックス環境で実行中のソフトウェアを完全に分析します。完全な攻撃のキルチェーンを文書化し、自動化された CI/CD プロセスの一部として DTA スキャンに失敗したアーティファクトのプロモーションをブロックするポリシーを確立する、信頼性の高い安全な方法を提供します。