ソフトウェアサプライチェーン攻撃の事例分析と対策

はじめに

2020年のSolarWindsへの攻撃以降、CI/CDパイプライン、つまり開発環境をターゲットとした攻撃が拡大しています。ソフトウェアサプライチェーン攻撃と呼ばれるこの種の攻撃では、ハッカーはどのようにサプライチェーンに侵入し、自社または複数の組織を攻撃するのでしょうか。また、攻撃を防ぐ為にはどのような対策を取るべきなのでしょうか。

当記事は2021年8月4日に行われたウェビナー「GitGuardian サプライチェーン攻撃の検証、攻撃者はいかにソフトウェアサプライチェーンに侵入するのか？」における、GitGuardian社のプレゼンテーションを基に再構成したものです。都度、最新情報を追加しております。

動画での視聴はこちら

GitGuardianについては以下のページをご覧ください。

GitGuardian

ソフトウェアサプライチェーン攻撃とは

サプライチェーン（supply chain）とは、一般的には「供給連鎖」と訳され、原材料・部品の調達から製造、在庫管理、配送、販売を経て消費者の元へ届くまでの、複数の企業や生産者が絡む一連の流れを大きなひとつのシステムとして捉えることを意味します。まず最初に、サプライチェーン攻撃とソフトウェアサプライチェーン攻撃について定義してみます。

サプライチェーン攻撃とは、基本的にはハッカーが悪意のあるコード、あるいはコンポーネントをソフトウェアやハードウェアに組み込む手法と定義できます。攻撃の対象となるのは、ハードウェア、ソフトウェア、サービス、そして人です。

ソフトウェアサプライチェーン攻撃は、サプライチェーン攻撃のひとつです。 アプリケーション内のソフトウェアやサービスを標的にしてエクスプロイトを実行する攻撃を指します。

今日のアプリケーションやソフトウェアの作り方を考えると、これは非常に大きな問題です。最新のアプリケーションは、何百、時には何千もの異なるコンポーネントやビルディングブロックを使用して構成されています。
これはSaaSアプリケーション、マネージドサービス、そしてOSSコンポーネントにも当てはまります。現在のアプリケーションの90％以上が何らかのオープンソースコンポーネントで構成されていると言われています。

ハッカーや悪意のあるアクターは、オープンソースソフトウェアのコンポーネントの脆弱性を分析していて、アプリケーションのソースコードを開発者よりもよく知っているのです。

サプライチェーンへの攻撃が近年いかに大きな問題になっているかを示すために、2021年にはアメリカ・ホワイトハウスが国家のサイバーセキュリティを改善する大統領令を出しました。この大統領令は、SolarWindsへの攻撃や、その他の膨大な数の攻撃を受けてのものでした。この法案の大部分は、特にソフトウェアサプライチェーンのセキュリティに関するもので、近年この問題がいかに深刻化しているかを示しています。そしてその問題は、残念ながらますます大きくなる一方です。

アプリケーションの依存関係（Dependency）とソフトウェアサプライチェーン攻撃

ソフトウェアサプライチェーンへの攻撃では、アプリケーションとの依存関係（Dependency）が大きく影響します。これは先ほど述べたオープンソースのソフトウェアやサービスです。また、アプリケーション内のこれらの依存関係は、それ自体がさらなる依存関係を持つこともあります。これが本当に怖いのは、依存関係があるコンポーネントのさらにその先の依存関係のあるコンポーネントに何らかの形で悪意のあるコードが仕掛けられてしまえば、それがどんどん連鎖反応という形で影響し、依存関係から依存関係へ、そして最終的に皆さんのアプリケーションまで波及してしまうことがあるのです。

ソフトウェアサプライチェーン攻撃の事例

事例1：Event Stream

非常に人気のあるEvent Streamというパッケージに対する攻撃の事例をご紹介します。これはオープンソースのコンポーネントに関わるものでした。最初の数年は非常によくメンテナンスされていましたが、2013年頃からはほとんど更新されていませんでした。つまり、このパッケージはメンテナンス性が低下し始めていたのです。

それにより次に何が起こったかというと、ユーザーがEvent Streamのメンテナンスを始め、Event Streamの中にflatMapという新たな依存関係を追加しました。これは最初は悪意のあるものではありませんでしたが、最終的にはその新しい依存関係であるflatMapがバックドア攻撃のターゲットになってしまったのです。flatMapがEvent Stream内にあったため、この依存関係の中にあるすべてのアプリケーションにバックドアが追加されました。

このバックドアが設置されている間に、Event Streamは実際に800万回もダウンロードされました。ダウンロードした人たちは、使用しているEvent Streamパッケージにバックドアが設置されていることに全く気がつかなかったのです。同様のケースもたくさん確認されています。ほとんど同じような攻撃が、electron-native-notifyという別のパッケージでも起こりました。

この事例を見ただけでも、今日のアプリケーション構築方法がいかに危険で問題であるかお分かりいただけるかと思います。

事例2：Codecov ーCI環境におけるサプライチェーン攻撃ー

攻撃者はオープンソースのコンポーネントだけでなく、アプリケーション内で使用するサービスも狙っています。今日ではCI/CDパイプラインの導入により、アプリケーションのデプロイとアップデートのスピードが格段に上がりました。しかし攻撃者からすると、CI/CDパイプラインは格好の攻撃対象となっているのです。

特にCIパイプラインにおいて、コードリポジトリの中に機密情報が入っていることが多く、そのようなサービスに侵入さえできれば、攻撃者は複数の組織やアプリケーションを標的にすることができるのです。

CI環境におけるサプライチェーン攻撃の一例を紹介したいと思います。今年起こったCodecovの事例です。Codecovは、アプリケーションのどの部分がテストされているかをチェックするコードカバレッジツールです。攻撃者にとっては、Codecov自体が非常に価値の高いターゲットだった訳ではありませんでした。しかし、攻撃者は侵害と攻撃を実行するためにCodecovを利用したのです。

攻撃者はCodecovが持っていたDockerのイメージの中を経由して、Gitリポジトリに含まれていた複数のシークレットを窃取しました。攻撃者はGitリポジトリにアクセスすると、Codecov社の従業員を装い、悪意のあるセグメントコードを挿入しました。

彼らが実際に侵害したファイルには何千行ものBash Uploaderスクリプトが書かれており、その中から何かを見つけ出すのは非常に困難です。しかし、たった一行だけ、悪意のあるコードが埋め込まれたのです。
そのコードはCIパイプラインから環境変数を取り出し、攻撃者の個人サーバーに送信していました。

たった一行のコードを挿入しただけで、当時Codecovを使用していた23000人の顧客のCI環境内のシークレットを流出させることができるのです。攻撃者は複数の異なる組織に侵入することができましたが、これはほぼ3か月間検出されませんでした。この件で興味深いのは、ハッカーの狙いはCodecovユーザー顧客のプライベートコードリポジトリへのアクセスだったということです。プライベートコードリポジトリ、つまり、プライベートなGitリポジトリは非常に多くの機密情報を含んでいるため、攻撃者にとって極めて価値の高いターゲットであることが知られているからです。個人情報をリポジトリに登録してはいけないとわかっていても、世界中、複数の大企業でこのような事態は起きています。ご紹介した2つの事例における侵害は、twillio、RAPID7、メルカリといった企業に影響を与えました。
ソフトウェアサプライチェーン攻撃は小さなスタートアップから大規模な組織に至るまで、すべての人が影響を受ける可能性があるのです。

事例3： Twitch

2021年の初め、Twitchに属する全てのソースコードが4chanフォーラムに公開され、その中には6,000に及ぶGitの内部レポジトリと、解凍後の合計サイズが200GBに達する3,000,000のドキュメントが含まれていました。

この漏えいには、Twitchの様々な製品、シークレットプロジェクト、子会社、内部ツール、従業員のリポジトリなどのソースコードが含まれていました。また、ストリーマーの収益などのデータベース情報も流出しました。

GitGuardianは、6,000のGitリポジトリにあるシークレットや機密情報について時間をかけて調査しました。流出したストリーマーの収入に注目が集まっていますが、調査の結果、より深刻な問題があることがわかりました。

脆弱性としてのソースコード – Twitchの情報流出がもたらす真のセキュリティ脅威を究明

事例4：Samsung（サムスン）

2022年、Samsung（サムスン）のソースコード約200GB分とNvidiaの最新テクノロジー、DLSSのソースコードがハッキンググループLapsus$によりネット上に公開されました。

GitGuardianは、流出したサムスンのソースコードをスキャンし、シークレット等の機密情報の有無を確認したところ、ソースコード内に6,695件のシークレットを検出しました。この結果は、各々シークレットのタイプ別に固有の情報を検索する、350を超えるDetector（検出ロジック）を使い、高い精度が期待できるスキャンで得られたものです。

ランサムウェア攻撃で漏洩したソースコードには何が含まれていたのか？サムスンの事例を分析

事例5：Microsoft

2022年、サムスン・Nvdiaのケースに続き、Lapsus$はマイクロソフトのプロジェクト250件に不正アクセスし、内部ソースコードが外部に流出しました。Lapsus$によると、流出したソースコードのうち90%がBingのもので、45%はBing MapsとCortanaのものだということです。

Lapsus$が標的としているのは管理者アカウントですが、それ以外に企業のプライベートソースコードも積極的にターゲットにしていることが当社の分析からわかっています。こうしたソースコードの価値は、アプリケーションの脆弱性を見つけることができるという以外に、シークレットのような機密情報が高頻度で含まれているという理由もあります。

Lapsus$の最新情報：マイクロソフトの情報流出事案について精査する

なぜGitリポジトリが攻撃者のターゲットとなるのか？

ここで、なぜ複数のソフトウェアサプライチェーン攻撃においてGitリポジトリがターゲットとなっているのか説明します。
重要な点は、Gitリポジトリが私たちが行った全ての作業のコピーを保存している、ということです。

上のグラフにおいて、緑はリポジトリへの追加、赤は削除を示していて、追加とほぼ同じだけ削除をしているということが分かります。つまり、何らかの被害を与えるようなセンシティブな情報も含め、Gitリポジトリの中にある情報量というのは、今表面に見えているものだけではなく、過去に削除されたものも含む膨大なものだということです。攻撃者はこれを利用し、削除されたコードを含めた履歴の中に隠された機密情報を探し出します。この機密情報には、誰かが話した秘密、個人を特定する情報、アプリケーション構成の洞察など、様々な情報が含まれます。

2020年、GitGuardianはGitHubのすべてのパブリックコードリポジトリをスキャンしました。アプリでスキャンしたコミットは合計で10億件を超え、その結果、1年間で200万件以上のシークレットを発見しました。1日に5000件という計算になります。例年に比べて増加していますが、この結果が示すのはGitリポジトリに埋もれ、ソースコードとしてハードコーディングされているシークレットの量です。これはパブリックリポジトリのデータなのです。より機密性の高い情報が含まれるプライベートコードのリポジトリが、なぜ攻撃者の格好のターゲットになるのかが理解できるかと思います。

GitGuardianが実施したスキャンに関するレポートの最新版は以下の記事と動画をご覧ください。

GitHub上に不用意に公開されたSecretを攻撃者はどのように収集し、攻撃に利用するかについての興味深い実験結果がポーランドのセキュリティー企業社長、アンジェイ・ディアック氏により2020年11月に公開されています。同氏の許可を得て、同氏がTwitterに投稿した内容を翻訳しました。

GitHub（ギットハブ）の公開リポジトリにはどのような危険があるのか ーソフトウェアサプライチェーンリスクに関する実験ー

ソフトウェアサプライチェーン攻撃を防ぐために

このようなソフトウェアサプライチェーン攻撃を、我々はどのように防ぐことができるでしょうか。

この種の攻撃を100％防ぐことはほぼ不可能です。私たちが自分で制御できる範囲があるからです。
自分たちが開発したアプリケーションはコントロールできます。そのアプリが利用するパッケージに対して持つ依存関係も、ある程度は制御できます。しかし、そのパッケージが持っている依存関係まで何らかのコントロールをすることは、ほぼ不可能です。

よって、できることは自分たちがコントロールできる範囲において最善を尽くすことです。攻撃を100％防ぐことを考えるのではなく、「被害をいかに最小限に抑えるか」ということです。まずGitリポジトリについてはコントロールはできますし、アクセスコントロールについても自らでマネジメントできます。サービスを細分化することで、1つのサービスが侵入されても、それがすべてのサービスに連鎖することはありません。また、データや個人情報、その保存方法についても管理すること。直接の依存関係があるパッケージはある程度のコントロールが可能かと思います。スキャンして既知の脆弱性を調べ、定期的にUpdateするようにします。また、ハッシュを使って依存関係を検証し、正しいパッケージを持っているかどうかを確認することができます。

ソフトウェアサプライチェーンのセキュリティ対策のためにやるべきこと

これは実際にアクション可能な事をリストにしてまとめたものです。

コードリポジトリ

• シークレットに該当するものや、PII（個人情報を含む情報）が絶対に含まれないように徹底する
• 「もし明日あなたのコードのソースがオープンソースになったとしたら」それによりセキュリティ上の問題が起こらないかを考えてみる

このようなプロセスをGitリポジトリに適用することにより、攻撃者にアクセスされたとしても、その被害は最小限に抑えられるでしょう。

アプリケーション

• 全てのサービスを細分化し、攻撃者がラテラルムーブメントできないようにしっかりしたチェックポイントを作っておく
• スコープを限定する。
• アプリケーション内の実際の通信・トラフィックについてもモニタリングし、何か異常があった場合にはアラートが上がるような設定をする

依存関係（Dependency）

定期的なチェックを行う事によって、インシデントがあっても被害を最小限におさえるようにします。

• ちゃんとメンテナンスされていないようなコードや、頻繁にメンテナンスがされていないようなコードに対して絶対に依存関係を持たない
• 定期的にパッチ適用やアップデートをすることはもちろんですし、既知の脆弱性に対してはスキャンを行う
• 利用するサービスに関して、ソフトウェアサプライチェーン攻撃を防ぐためにどのようなポリシーを持っているのか聞いておく
• SBOM=ソフトウェアの部品表（Bill of Materials）の作成

SBOMとは、アプリケーションやサービスを実行するためのパーツのリストです。例えば、利用しているサービス等が可視化され、それらが持っている依存関係をユーザーが把握できるようになるということです。これは長い間望まれていた、素晴らしい取り組みです。冒頭でお話したホワイトハウスの大統領令では、その一部として、特定のソフトウェアプロバイダーにSBOMの作成を義務付けています。

最後に

ソフトウェアのサプライチェーン攻撃を100％防ぐことはできませんが、そのダメージを最小化することはできる、ということです。このような脅威のためにソフトウェアの開発方法を変える必要はありません。しかし、この種の攻撃を念頭に置いて、より安全なアプリを構築するためこの脅威を認識する必要があります。

ソフトウェアサプライチェーンリスクやGitGuardianに関するお問い合わせは、以下からお願いいたします。