【解説】ソフトウェアサプライチェーンのセキュリティリスク-セキュリティブログ

2021年5月12日、ジョー・バイデン米国大統領は、サイバーセキュリティ強化のための大統領令に署名した。

これは、アメリカ東海岸で消費されるガソリンや燃料の約45％を供給している石油パイプライン管理会社コロニアルパイプライン社がサイバー攻撃を受けたことに端を発する。
この大統領令は、今回被害を受けたSolarWindsのようなサイバー攻撃を防ぐために国家機関にサイバーセキュリティを向上する措置である。

大統領令については、別途紹介するが、今回はトレンドマイクロセキュリティブログより、ソフトウェアの開発プロセスを例にしたサプライチェーンの一連の流れについて解説し、これまでに確認されたソフトウェアサプライチェーン攻撃の事例を織り交ぜながら今後発生する可能性のある攻撃について解説する。

 

背景

昨年末、各方面で報じられたSolarWinds社製ネットワーク監視アプリケーション「Orion」を侵害した攻撃事例はサイバーセキュリティ業界や世間を震撼させたと同時に、サプライチェーン攻撃に対する注意を世界中で高めさせるきっかけとなった。
サプライチェーンとは「製品が作られて顧客に届くまでの一連の流れ」のことであるが、冒頭に例示したSolarWinds事例に当てはめた場合、「製品」とはSolarWinds社の「Orion」というソフトウェアであり、それが顧客に届くまでの一連の流れの中で侵害されたということになる。
サプライチェーン攻撃の中でも、このようなソフトウェアサプライチェーンを侵害する攻撃自体は何も目新しいものではなく、実際この種の脅威は以前から確認されているのである。

 

ソフトウェアサプライチェーンにおけるセキュリティリスク

ソフトウェア開発者はどのような方法を用いるにせよ、複雑なプロジェクトを簡単なタスクに分割する必要がある。これにより利用する問題追跡ソフトウェアの中でタスクが定義され、特定の開発者への割り振りが可能となる。
タスクが割り当てられた開発者はタスクに対するコードの一部を書き、作成されたコードは開発者によってテストされ、変更箇所はソースコード管理ソフトウェア内にアップロードされる。

図1：開発プロセスの概要

アップロードされたコードは、継続的インテグレーション/継続的デリバリ（CI/CD）パイプラインによって処理される。CI/CDパイプラインは、ビルド、テスト、または選択したプロジェクトへの最終的なデプロイメントを実施する特定のタスクを実行する。

トレンドマイクロが定義したソフトウェアのサプライチェーンにおける一連の流れの各段階にはそれぞれのセキュリティリスクおよび影響力が存在するという。

その一例として、問題追跡ソフトウェアを運用管理する関係者によってセキュリティが侵害される可能性がある。これは情報セキュリティの管理を担当する内部関係者の場合もあれば、ソフトウェアの脆弱性に携わる業務担当者の場合もある。
一方で、サプライチェーン内の他の段階が攻撃された場合と比較した場合、この事例での影響被害は比較的少ないと考えられる。なぜなら、サプライチェーン内の他の段階は多くの場合タスクが攻撃対象となるからである。そのため、この事例については割愛し、認証に関連するセキュリティ侵害についてを解説する。

サプライチェーン全体のセキュリティ強度は最も弱い部分によって左右されることは理解いただけることだろう。このため、セキュリティのベストプラクティスに準拠せずにパスワードを再利用したり、不適切な認証メカニズムを採用した場合、攻撃者によるシステムへのアクセスを許してしまう要因となり、情報漏えいによる多大な被害を受ける可能性があるのだ。

 

ソフトウェアサプライチェーンにおける開発者とソースコード管理

トレンドマイクロのソフトウェアサプライチェーンにおいて必須となるのが開発者であり、トレンドマイクロ製品のコードは開発者によって構成されている。よって、人的なセキュリティの弱点やセキュリティリスクの可能性について考慮することは重要である。
これは開発者を人工知能に置き換えるよう提案しているのではなく、開発者が直面しうるリスクについて事前に見識を備えさせることを推奨するものである。

最近では脆弱性リサーチャを標的とする攻撃事例が確認されている。技術的観点から得た興味深い事実は、この脅威がVisual Studioのプロジェクトファイルの中、特にprebuildイベント内部に隠蔽されており、PowerShellを悪用したペイロードを送り込んでいたことにある。この事例では２つ注目すべき点があった。1つ目は「仲間」間の信頼度、2つ目は開発者に最も当てはまる、より大きなソースコードを採用しサードパーティのプロジェクトと統合する点である。
故にどのソースコードとどのプロジェクトを統合するかについては深く考慮する必要がある。そのため、使用されているコード、ソフトウェア、プラグイン、コンテナなどのソースを十分に確認する必要があるのだ。
この問題については、オンラインコーディングプラットフォームにも関連している。

開発者はサプライチェーンの次の段階で利用するソースコード管理ソフトウェアにもアクセスできる。ソースコード管理ソフトウェアにアクセスするには認証情報の入力が必要であるが、アクセスするたびに認証情報を入力するのを省くために認証情報を保存されている場合もあるであろう。認証情報を保存することは情報漏洩のリスクを高めることと言える。
さらに保存した認証情報が暗号化されていない場合、情報漏洩による影響被害が大きくなるのだ。

トレンドマイクロのDevOpsコミュニティ内では共通するパターンが確認できている。DevOpsコミュニティを利用する開発者の多くは認証情報を暗号化されていない状態（テキストベースの設定ファイルまたは環境変数）で保存している。そして、これらの認証情報にはサービストークン、ユーザ名、電子メールアドレスなども含まれている。

図2：「セキュア」な環境内に平文で認証情報やトークンを保存している例

これらのセキュリティリスクに対する認識は些か過剰であるかのように思われるが、「A chain is no stronger than its weakest link. （鎖の強さは最も弱い輪によって決まる。）」という英語のことわざがあることも事実である。
よって、パスワード管理ソフトウェアを利用するなどリスクを下げるための予防策は検討するに値するといえよう。

図3：ソースコード内にハードコードされた平文の認証情報を使用した場合の例

開発者はハードコードした認証情報をソースコード管理ソフトウェアにアップロードするべきではありません。例えば、IaC（Infrastructure as Code）を使用する場合は一般的に認証情報の保存方法について考慮する必要があります。

 

CI/CDパイプライン

サプライチェーンにおける次の段階は、CI/CDパイプラインである。ソフトウェアベンダ間の競争は激しく、一般にJenkins、GitLab、TeamCity、Azure DevOpsなどが知られている。

CI/CDパイプラインは以下のように分けることができる。

図4：CI/CDパイプラインの例

システムへのアクセス

セキュリティの観点からこれらのシステムへのアクセス権は制限する必要があり、誰もがアクセスできる状態にあってはならない。
システムへのアクセス権は企業ネットワーク内部に隠匿されているべきであり、特定の役割、つまり特別にアクセス権限が付与されたユーザだけがアクセスできるようにする必要がある。またインターネット上に露出しているだけでもセキュリティリスクとなる。

過去の事例でも確認されているように、利用するソフトウェアやポートに内在する脆弱性がサイバー犯罪者によって侵害される可能性があるからだ。

システム構成

上記の他にセキュリティリスクの要因となるのが構成不備である。特定の環境にはその環境に適したシステム構成を構築することが推奨される。
例えばある企業では複数のユーザがシステムにアクセスする必要があると同時に全ユーザが異なる役割を担当しているとする。このような状況下ではロールベースのセキュリティを構成する必要がある。しかしながら、オープンソースの自動化サーバ「Jenkins」の初期設定をそのまま利用するなどしている場合は、結果としてセキュリティ問題につながる可能性がある。
ソフトウェアの複雑さと構成オプションの増加に伴い、一般的なソフトウェアの構成不備によるセキュリティリスクについては事前にテストすることが強く推奨される。

ソースコードの取得

この段階では2つのパターンに分けることができる。

Azure DevOpsサーバの場合のように、ソースコード管理ソフトウェアがCI/CDに統合されている場合：
上記の場合ソースコード管理ソフトウェアは異なる環境で動作しているため、アクセストークンあるいは認証情報をシステム内部に保存する必要がある。
ソフトウェアのソースコードに認証情報が混入した状態で公開された場合、攻撃者によって悪意のあるソースコードに改ざんされる可能性が指摘される。よって、ソースコード内の認証情報をどのように保管するかは非常に重要である。
しかし、CI/CDツール内部で用いられているセキュアではない保存方法が確認されていたり、Jenkinsプラグインの事例で解説したような一部のサードパーティの拡張機能の中には認証情報を暗号化せずに平文形式で保存してしまうものがあるなど情報漏洩につながる脆弱性が発見されたことは特筆すべき点と言える。

ビルド環境の構成

この段階で懸念されるセキュリティ事項は、渡される認証情報に関連している。ビルドする際に暗号化されていない認証情報を渡してしまったり、ビルドのアーティファクトとして認証情報が混入した状態で保存されてしまったりするリスクがある。
基本的に一部の構成要素の前提条件には機密情報が含まれており、通常はビルド後にも残されるのである。

ビルド

この段階では実際のソースコードをターゲットのバイナリ形式にコンパイルする。この段階を狙った攻撃はSolarWinds社の事例やCCleanerの事例が確認されている。

攻撃者がこの段階を狙うのには論理的な理由が2つある。
第一にこの段階はサプライチェーンにおける最終段階の1つであり、この段階を通過すればその後の検証があまり行われないことにある。
第二に、最近の傾向として作成された実行バイナリには一般的にデジタル署名が付与されており、署名後にコードの修正作業を行うとデジタル署名が無効化される。署名を再付与しようとしても、攻撃者が署名に使われた秘密鍵を保有していない場合は正しい署名を生成することができない。そのため攻撃者にとってビルドの段階で悪意のあるコードを埋め込むことは、デジタル署名の検出を回避できるため好都合なのである。
これらを理由にビルドプロセスはソフトウェアサプライチェーン攻撃を遂行するために攻撃対象となる。

ただし、すべてのソフトウェアがデジタル署名付きで出荷されるわけでもない。
デジタル署名について言及する場合、デジタル証明書と紐づく秘密鍵を公開しないよう注意する必要がある。デジタル署名に用いた秘密鍵が公開されてしまった場合、攻撃者はその証明書を悪用してデジタル署名を有効化させたいソフトウェアに署名を付与することができてしまい、デジタル証明書を失効させなければならなくなるからだ。

 

デプロイメントまたはプロダクトデリバリ

CI/CDツールに含めることが可能なサプライチェーンの最後の段階はデプロイメントである。まず初めにデプロイメントプロセスをCI/CDツール内で指定させ、ビルドやテストが成功したときに起動させることができる。
このためアーキテクチャ情報は認証情報やその他の機密情報とともに混入する可能性があり、それらを適切に管理する必要がある。

攻撃者にとって最も簡単にソフトウェアを改ざんする方法は、ソフトウェア全体を置き換えることだ。また、デジタル署名がされていないソフトウェアの場合、悪意のあるコードを注入するコードインジェクション攻撃の手口も確認されている。
実例として、WordPress使用サイトへのコードインジェクション攻撃などがある。この事例ではWordPress本体やプラグインの脆弱性あるいはセキュリティ上の弱点を侵害したのちに悪意のあるコードスニペットが注入され遠隔操作が実行されたほか、SEOポイズニングやフェイクニュースを拡散するために悪用されていた。

実行バイナリへのコードインジェクション攻撃も可能だが、上記の攻撃と比較した場合、コンパイルされたバイナリおよび攻撃者のスキルに依存する。
また、バイナリがデジタル署名されている場合、改ざんした事実が簡単に発見されてしまうため効率的ではない。このため攻撃者にとっては単純にバイナリを置き換える方が好都合なのである。
しかし、バイナリが格納されている配信サーバをハッキングし正規ソフトウェアを改ざんすることは容易ではなく、実行するにしても多大なリソースを必要とする。

上記以外にもフィッシングやネット詐欺キャンペーン、DNSスプーフィングの手法に正規ソフトウェア企業の知名度を利用して正規アカウントを乗っ取り不正なリンク先を拡散し、悪意のあるプログラムやPUA（潜在的に迷惑なアプリケーション、Potentially Unwanted Application）をダウンロードさせようと試みる攻撃手口が確認されているほか、セキュリティベンダを騙る偽サイト上で正規ソフトウェアを配信していると偽り、不正プログラムやPUAをインストールさせようと試みる手口も確認されている。気が抜けない状況と言えよう。

 

まとめ

今回、ソフトウェアサプライチェーンにおける基本的なセキュリティリスクについて紹介した。この問題は複雑ではあるものの喫緊の課題でもある。トレンドマイクロは2021年セキュリティ脅威予測でも述べているように、企業は2021年末までにワークロードの大半をクラウド上で実行すると予想されている。
企業は新型コロナウイルスのパンデミックに対応するために、サイバーセキュリティリスクを考慮せずに新しいソフトウェアを導入してしまっていることも考えられる。新しいソフトウェアを導入する場合は、セキュリティリスクを考慮し、適切な対策を講じる必要があるといえよう。

---

本記事は、トレンドマイクロ様の許諾により「トレンドマイクロ・セキュリティブログ」の内容を元に作成しております。
ソース：https://blog.trendmicro.co.jp/archives/27740