【サイバーインテリジェンス】世界で広がるソフトウェアサプライチェーン攻撃の事例と対策

サプライチェーンの各段階で発生するソフトウェアサプライチェーン攻撃の種類と事例

サプライチェーン攻撃には次のようなタイプ^*1があり、1～3がソフトウェアサプライチェーン攻撃に該当します。

1. ソフトウェアのビルドツールまたはアップデートインフラストラクチャの侵害
2. 窃取したコードサイニング証明書または正規開発企業のアカウントを使用して署名した悪意のあるアプリケーション
3. ハードウェアまたはファームウェアのコンポーネントへの侵害したコードの混入
4. カメラ、USB、携帯電話などのデバイスへのマルウェアのプリインストール

ソフトウェアサプライチェーンの侵害は次のようなサプライチェーンの各段階で発生する可能性があり、サイバー攻撃者がソフトウェアの開発環境やアップデートプロセス、ソースコードを改ざんした事例が確認されています。

• 統合開発環境の侵害
• ソースコードリポジトリの侵害
• ビルド環境の侵害
• オープンソースのコードの侵害
• ソフトウェア配布サイトの侵害
• ソフトウェアアップデートプロセスの侵害

事例：ソフトウェアアップデートプロセスの侵害

2021年2月には、ソフトウェアのアップデートの仕組みを利用してトロイの木馬化したバージョンが配布された事例が報告されました。問題のソフトウェアは、起動時にサーバーに更新情報を問い合わせ、アップデートをダウンロードするためのURLを受信します。このダウンロードURLはソフトウェアベンダーの正規インフラストラクチャでしたが、攻撃者によって侵害されており、アップデートにはマルウェアが含まれていました。

正規ソフトウェアが改ざんされたバージョンに置き換えられていた事例としては、2020年に北朝鮮のサイバー攻撃グループ「Lazarus」が韓国のユーザーを標的とした攻撃があります。韓国では政府機関やオンライン銀行のウェブサイト訪問時に追加でセキュリティソフトウェアのダウンロードを求められる場合があり、この慣習を利用したLazarusは、正規サーバーを侵害し、マルウェアを含むセキュリティソフトウェアを配信していました^*2。

事例：ソフトウェアの依存性の侵害

ソフトウェアの依存性が侵害されたサプライチェーン攻撃としては、2018年にプログラミング言語「Node.js」のモジュールに仮想通貨を窃取するコードが仕込まれていた事例が挙げられます。サイバー攻撃者は数年間更新されていなかったモジュールの管理者に「メンテナンスを引き継ぎたい」という主旨のメールを送信し、プロジェクトの管理を任されていました。その後公開された新しいバージョンは、悪意のあるコードを含むモジュールに依存していました。悪意のあるコードは暗号化されていたため発覚まで約2カ月を要し、その間、数百万人のプログラマーによって問題のモジュールがダウンロードされていました。

また、あるサイバーセキュリティ研究者は、複数の大手IT企業のソースコードに偽のパッケージを読み込ませることに成功しています^*3。この研究者はまず、有名企業の公開リポジトリを検索し、依存するパッケージを記述したファイルの中から非公開のパッケージ名を特定しました。次に、当該パッケージと同名の偽のパッケージを作成し、オープンソースのリポジトリに公開しました。同一の名前を持つパッケージが複数存在する場合、バージョン番号が高いパッケージが優先される仕様になっていたため、正規のパッケージの代わりに偽のパッケージがインストールされる結果となりました。このような攻撃手法は「Dependency Confusion（依存関係かく乱攻撃）」と呼ばれています。

事例：統合開発環境の侵害

開発ツールが侵害されたサプライチェーン攻撃として、あるIT企業が配布する統合開発環境が改ざんされた事例も存在します。改ざんされた開発環境で作成されたアプリケーションには、端末情報のアップロードやクリップボードの読み書きといった機能を備えた不正コードが含まれるようになり、中にはその状態で公開されていたものもありました。

ソフトウェアサプライチェーン攻撃への対策

ソフトウェアサプライチェーン攻撃は1. ソフトウェアサプライチェーンの侵害、2. 標的企業への侵入という2段階に分けられるため、その対策もソフトウェアベンダーが取るべきものとユーザー企業が取るべきものに分けられます。以下に順に紹介します。

ソフトウェアベンダー向けの対策：ITインフラとソフトウェアライフサイクル全体の保護

ソフトウェアベンダーが取るべき対策として、まずはITインフラストラクチャのセキュリティ強化が挙げられます。特にVPNやRDP（Remote Desktop Protocol）などのリモートアクセス用のシステムを保護するために、多要素認証（MFA）の実装が推奨されます。また、脆弱性を利用した攻撃に迅速に対処するために、IT資産を管理し、脅威・脆弱性情報を収集することが求められます。全社的なITインフラストラクチャについてはIT部門がセキュリティ対策を含めて管理しているものの、開発用については事業部主管となっており、対策レベルにギャップが存在するケースも散見されるため、注意が必要です。

次に、ITインフラストラクチャと同様に、ビルド環境を含めたソフトウェアライフサイクル全体を保護する必要があります。これに関しても、一般に開発環境とセキュリティ製品は相性が悪く、正常動作の阻害、誤検知などを引き起こしやすいため、IT環境に比べて縮退した対策になっていることがあります。ソフトウェアベンダーにとってソースコード管理、ビルド環境などは事業継続上重要なシステムであることを認識し、対策のレベルを引き上げることが求められます。

永続化されたマルウェアがビルドプロセスを監視しており、コンパイル前にソースコードを置き換えるといった事例も実際に発生しています。そのため、スケジュールに登録された不正なタスクやビルドプロセスによってトリガーされるプロセスの検知、および侵入を前提とした脅威ハンティングの実施が対策となると考えられます。

リリース後のソフトウェアについては、改ざんや配布元のなりすましを防ぐために、コードサイニング証明書の保護、失効プロセスの確認、漏えい調査の実施などの対策が求められます。

また、近年ではコンテナ技術の導入が進んでいるため、そうした環境を利用している場合、「NIST Special Publication 800-190 アプリケーションコンテナセキュリティガイド」^*5に従うことが推奨されます。

利用しているオープンソースソフトウェアについては、ソフトウェアコンポジション解析ツールを利用するなどして、自組織が利用するソースコードの脆弱性に対処することが求められます。新しい取り組みとして、オープンソースで開発されているソフトウェアの脆弱性をデータベース化するプロジェクトが始まっています^*6。このデータベースには脆弱性の影響を受けるバージョンなどの詳細情報が含まれており、オープンソースソフトウェアの利用者は自身が開発したソースコードへの影響の有無を確認することができます。

ユーザー企業向けの対策：サイバーインテリジェンスの強化

ソフトウェアを利用するユーザー企業が取り得る対策としては、NISTや日本政府が定めたガイドラインに従って、サードパーティーのリスクアセスメントを実施することが挙げられます。

米連邦政府のセキュリティ基準を定めた文書「NIST Special Publication 800-53 revision 4」^*7では、サプライチェーンの保護策として供給業者に対するレビューを行うことを推奨しており、実践的なガイドラインとして「NIST Special Publication 800-161」^*8も公開しています。

経済産業省の「サイバーセキュリティ経営ガイドライン Ver 2.0」^*9では、サイバーセキュリティ対策の内容を明確にした上で契約を交わす、サイバーセキュリティ対策状況の報告を受け把握する、SECURITY ACTIONの実施や情報セキュリティマネジメントシステム（ISMS）などのセキュリティマネジメント認証を取得していることを確認する、といった対策が推奨されています。

ソフトウェアサプライチェーン攻撃は、特にユーザー企業にとって対策が困難な攻撃手法だと言えます。上記のようなリスクアセスメントに加え、変化するサイバー脅威への関心を強く持って、定期的な情報収集と評価を行うと共に、請負・供給業者やビジネスパートナーが扱う「ユーザー企業が本来管理すべき情報やプロセス」の可視性を高めるといった対応を通じて、問題が発生することを前提とした対処態勢を通常時に整えておくことが重要です。これを実現するには、組織としてのサイバーインテリジェンスの強化が必須となります。