開発者を標的とするサプライチェーン型攻撃について解説

渗透技巧 1年前 (2023) admin

262 0 0

トレンドマイクロでは2021年、サプライチェーン上のセキュリティリスクに関する調査結果を報告しました。当該の報告では、サプライチェーンを狙った攻撃の急増を踏まえ、攻撃者がいかにセキュリティ上の弱点を見出し、それを自身の利益と標的の損害に繋げようとしているかについて述べました。

本稿では、サプライチェーンの一部を担う「開発者自身」に着目します。まず、開発者を狙う攻撃モデルを適切に設定するため、開発者とは誰なのかを定義し、その上で、開発者が日常的に用いるツールや、頻繁に実施するワークフローについて述べます。次に、開発者の注意不足やツールの脆弱性が原因となってサプライチェーンが侵害されるさまざまな状況について解説します。最後に、開発者や企業、組織では、プロジェクトや自身の保護に関わる適切なトレードオフを見極める際に、今回述べる脅威シナリオがその判断材料として役立つことを示します。

開発者とは誰なのか

「開発者」の定義として、「コンピュータソフトウェアを開発する人」という辞書的な説明が挙げられます。本執筆者の認識では、特に「コードを書く人」がこれに該当します。「コード」とは、Java、JavaScript、TypeScript、Go、Python、C、C++といった多くのプログラミング言語に加え、Dockerfile、Kubernetes、Terraform HCLといったインフラやコンテナの設定用スクリプトも数多く含まれます。この定義に基づくと、全てのコード作成者に加えてセキュリティ担当者など、IT業界全般に関わるさまざまな人々が「開発者」に該当します。

開発者が実施するワークフローは個人または企業に応じて異なります。しかし、統合開発環境（IDE：Integrated Developer Environments）の利用形体に応じて、おおまかには下記に大別されると考えられます。

ローカルIDE：開発者は自身のローカル端末にIDEをインストールして使用している。この場合、当該開発者は、状況に応じて下記の作業を行う。
- ローカルとリモートリポジトリ間でコードを授受（プッシュ：Push、プル：Pull）する。デバッグやビルド作業はローカル端末上で行う。または、
- コードの変更をリモートリポジトリ側に反映し、「継続的インテグレーションとデリバリ（CI/CD：Continuous Integration / Continuous Delivery）」を発動させる。これにより、品質保証（QA：Quality Assessment）の検証や、場合によっては本番環境へのデプロイも行われる。
クラウドIDE：開発者は、クラウドサービスプロバイダ（CSP：Cloud Service Provider）が提供するAWS Cloud9、Visual Studio Online、GitHub CodespacesなどのクラウドIDEを使用している。この場合、当該開発者は、ローカル端末のブラウザなどを経由してクラウドIDEにアクセスし、そこで主要な作業を実施する。コードの実行についても、そのクラウドIDEのリモートホスト内部で行われる。

「開発者」の定義にはさまざまな専門領域が含まれるため、上述した事項の一部がワークフロー上に存在しない場合も考えられます。例えば、調査目的で概念実証を行う際には、全体的なCI/CDパイプラインを構築しないことの方が多いでしょう。しかし、開発におけるIDEの使用は、大半のワークフローに存在すると考えられます。今回の調査では、特にローカルIDEに焦点を当て、そのワークフローに関連するセキュリティリスクを分析しました。参考として、前回の調査では、オンライン上のコーディング用プラットフォームに関するセキュリティリスクを分析しました。

ローカルIDEのユースケース

ローカルIDEを用いる際のユースケースとして、開発者がコードをリポジトリからローカル端末に取り込む（プルする）場面が挙げられます。後に、このコードは実行形式にコンパイルされます。ここで、開発者の暗黙の了解として、リポジトリに元々格納されていたコードは期待通りに動作することが確認済みであり、コード編集の開始ポイントとして「信頼できる」と見なされる傾向にあります。こうした暗黙の了解に基づく「信頼」の対象は、ソースコードにとどまらず、プロジェクト内にあるビルド用スクリプトやライブラリ、依存関係、各種プロジェクト設定ファイルにまで及びます。以上を踏まえ、第一の脅威シナリオとして、「プロジェクトファイルやビルドスクリプトに不正な処理をインジェクトする（埋め込む）手口」について検討しました。

開発者は、リモートからプルしたコードを実行する前に、ビルドスクリプトの内容を確認するでしょうか。

今回は、著名なIDEやプログラミング言語を対象に、ビルドスクリプトやプロジェクト内に不正なコマンドをインジェクトするテストを行いました。実際に対象としたIDEのバージョンは、下記の通りです。

Eclipse 2022-09
Apache NetBeans 16
PyCharm 2022.2.4
IntelliJ IDEA 2022.03
Visual Studio 2022
Visual Studio Code 1.73.1

汎用的な脅威モデルを作る際には、制御されていない入力成分も全て考慮する必要があります。こうした入力成分としては、ソースコードだけでなく、プレビルドスクリプトやポストビルドスクリプト、さらにはIDE拡張機能も含まれます。弊社では2020年に、不正なIDE拡張機能の危険性について報告しました。

開発者を標的とするサプライチェーン型攻撃について解説 — 図1：IDEに関する脅威モデル

今回の脅威モデルについて検証するため、各IDEについて下記のシナリオを定義しました。

開発者が信頼性の確認されていないオンラインリポジトリからコードをプル
開発者がIDE上でプロジェクトを開く
開発者がプロジェクトのコンパイルおよびビルドを試みる

Visual Studio Codeを使用している場合

Visual Studio Codeのバージョン1.57（2021年5月リリース）から、「Workspace Trust」と呼ばれる保護機能が導入されました。この機能は、ファイルやリポジトリの信頼性を確認できない場合に、そのコードの実行を禁止することで、開発者がそのソースやコード作成者に関わらずコードを閲覧または編集する際の安全性を確保します。本機能が導入された経緯として、当時、サードパーティ製の拡張機能から多くの脆弱性が発見されたことが挙げられます。そうした脆弱性の中には、信頼性の確認できないファイルを開いた際に、リモートコード実行（RCE：Remote Code Execution）を引き起こすものさえ含まれていました。Workspace Trustの仕組み自体は簡潔であり、ワークスペースの信頼性が確認されない限り、ビルド、デバッグといったタスクや拡張機能の使用は禁止されます。なお、ダウンロードしたコードの信頼性に関する判断は、開発者側に委ねられています。

ここで強調しておくべきことは、あらゆるワークスペースを不用意に信頼しないことです。

コードの信頼性を判断する際に、開発者は何に注意するべきでしょうか。不審なコードであることを示唆する危険な兆候として、特に下記が挙げられます。

ダウンロード件数が少ない
プロジェクトがフォーラム上で共有されている
グレーゾーンに相当する機能
一般的に検証されていない提供元
未知の提供元

開発者はVisual Studio Codeのタスクを実行する前に、プロジェクトのディレクトリ内にある設定ファイル「.vscode/tasks.json」を確認し、不審または不正なコマンドが含まれていないか検査するべきです。よく知られていない提供元からコードを取得した場合は、特にそのことが言えます。

不正なコマンドは、図3のような形式で、「tasks.json」内に正常なビルドコマンドを装って隠されている可能性があります。開発者がこうしたプロジェクトを不用意に信頼してビルドしようとすると、リモートに配備された不正なコードが実行されます。さらに攻撃者側は、不正なコマンドを正常なビルドコマンド中に紛れ込ませることでステルス性を高めるなど、開発者からの疑いの目を逸らそうとする可能性があります。

今回の概念実証では、リモートコードをテキスト共有サービス「Pastebin」上に配備しました。テキスト共有サービスは、攻撃者が不正なペイロードを標的端末に配布する際に用いる手段の1つです。その利点として、ペイロードの内容をリモートから自在に変更できる点が挙げられます。具体的には、標的端末を感染させた後で、ペイロードの内容を無害なものに書き換えるケースが考えられます。

Visual Studioを使用している場合

Visual Studio は、Microsoft社が提供する.NETおよびC++用のIDEです。先述したWorkspace Trustの機能は含まれていないため、使用する開発者は、信頼性の確認されていないプロジェクトファイルを読み込む際やビルドする際に十分注意する必要があります。プロジェクト内には不正なプレビルドタスクやポストビルドタスクが埋め込まれ、ビルド開始時にそれが起動する恐れがあります。

他のIDEを使用している場合

Eclipse IDEの場合にも、使用するファイルは異なりますが、ビルドコマンドのインジェクションは可能です。具体的には、設定ファイル「.project」に、実際に実行させたいコードを含む別ファイルへの参照を、ExternalToolBuilder型のビルドコマンドとして指定します。なお、この別ファイルは、フォルダ「.externalToolBuilders」内に配備されている必要があります。Visual Studio Codeの時と同様、複数のビルドコマンドを繋ぎ合わせることで、複数のコマンドを実行させることも可能です。

上述した「ExternalToolBuilder」によるコードインジェクションは、ベースとするIDEのスコープ内においてのみ稼働します。そのため、この手口を適用できるプログラミング言語は、コンパイルによるバイナリ形式への変換を伴うものに限られます。具体的にはJavaやC、C++が挙げられますが、ビルド工程のないPHPなどは対象外となります。

NetBeans IDEは主にJavaの開発に使用されますが、サードパーティ製の拡張機能を通して、PHPやHTML5、JavaScript、C、C++の開発にも対応しています。Javaの開発時は、依存関係の管理やビルドの自動化ツールとして、MavenやGradle、Antを使用できます。プロジェクトやビルドの定義法は、他のIDEと異なる場合があります。しかし、いずれのツールでも、プレビルドまたはポストビルド時のタスクとして、サードパーティの処理を実行させることが可能です。今回のシナリオでは、攻撃者が不正なコードをインジェクトし、開発者がそれに気づくことなく、意図せず実行する可能性を想定します。

開発者がビルドツールとしてAntを使用する場合、ファイル「nbproject/build-impl.xml」内にある任意の「targetタグ」配下に下記のコードを付加することで、コードインジェクションを実現できます。

ビルドツールとしてMavenを使用している場合も、攻撃者はプロジェクトフォルダ内のpom.xmlを書き換えることで、同じ目的を達成できます。今回の場合、buildタグ内のプラグイン「org.codehaus.mojo」を使用します。なお、スクリプトの文法は、Antの場合と類似します。

Gradleの場合、ビルドの定義はファイル「app/build.gradle」内にGroovy言語で記述されます。当該ファイル中のtaskセクション内で、実行コマンドを表す文字列から関数「execute()」を呼び出すことで、そのコマンドを実行できます。

NetBeansにおける「Open Project（プロジェクトを開く）」のメニューには、「Trust Project Build Script（プロジェクトのビルドスクリプトを信頼する）」のオプションがありますが、この制御はGradleプロジェクトに対してのみ有効です。開発者が本オプションでOFF（信頼しない）に設定していると、プロジェクトの読み込み時にGradleスクリプトが自動実行されないように制御されます。この結果、不審なコードの実行は阻止されます。本制御は、脆弱性「CVE-2020-11986」への対応として導入されたものです。しかし依然として、開発者が手動でビルドを実行した場合は、ダイアログが表示されることもなく、ビルドスクリプトは信頼されたものと見なされます。

IntelliJ IDEAは、JavaやKotlin、Groovyに加え、Java仮想マシン（Java Virtual Machine）で動く他の開発言語もサポートするIDEであり、Antのビルドスクリプトにも対応しています。Antのビルドスクリプトを含むプロジェクトを読み込む際には、不正なコードの可能性を警告するダイアログが表示され、取得元の信頼性を確認できない場合はセーフモードを使用するように促されます。開発者がセーフモードのままビルドしようとしても、プロジェクトを信頼しない限り当該操作は実行できない旨のダイアログが表示されます。

最後にPyCharmは、Pythonでの開発をサポートするIDEです。Pythonスクリプトは通常、コンパイル操作なしで実行されます。しかし、実行およびデバッグ時のタスクを開発者側で独自に追加することも可能です。この仕組みによって、Pythonスクリプトの実行前に、サードパーティのバイナリを起動させることが可能です。実際の用途としては、スクリプト実行前のデータ準備などが挙げられます。

スクリプトの実行前に起動させるタスクは、プロジェクトの内部から参照されます。しかし、タスクの内容自体はプロジェクトの外部に存在し、具体的には以下に格納されています。

~/.config/JetBrains/PyCharmXXXX/tools/External Tools.xml

本パスは、ユーザのホームディレクトリ配下に相当します。PyCharmに対してコードインジェクションを行う場合は、このローカルファイルシステム領域を書き換える必要が生じます。そのため、PyCharmは今回の脅威モデルに対して比較的保護されていると言えるでしょう。

結論

本調査では、不正なビルドスクリプトを実行させる脅威シナリオに基づいて各IDEを評価しました。また、概念実証を通して、不正なコマンドが各種ビルドスクリプトにインジェクトされる危険性を示しました。上で述べたように、一部のIDEは、不正な動作の可能性について開発者に警告し、プロジェクトの信頼性が明示的に確認されない限り、ビルドなどのタスクを禁止する機能を備えています。その一方、開発者がプロジェクトを開いたり、ワークスペースにコピーしたりした時点で、当該プロジェクトを信頼されたものと見なし、それ以上の確認を要求しないIDEも存在します。

いかなるIDEを用いる場合でも、セキュリティとユーザビリティのトレードオフは常に存在します。開発担当の方は、インターネットから入手したオープンソースプロジェクトを不用意に信頼しないことを推奨します。また、各種ビルド関連の操作を開始する前に、最低でも、攻撃の可能性について考慮し、ビルドスクリプトの内容を検査することを推奨します。

特記事項として、今回の脅威シナリオは、ローカルIDEに限定するものではありません。セキュリティ上のリスクは、用いるワークフローやワークスペースの信頼性自体に内在しています。これは、開発者がコンテナや仮想マシン（VM：Virtual Machine）上のオンラインIDEを用いてビルドやコンパイルを行う場合についても同様です。不正なビルドスクリプトを含むワークスペースをひとたび信頼すれば、望ましくないコードがIDEの環境内および権限内で実行されるリスクがあります。今回の脅威シナリオによってサプライチェーンが侵害されるリスクを軽減するため、開発担当の方は、下記のベストプラクティスについて検討されることを推奨します。

セキュアな設定が施されたCI/CDプラットフォームを使用する。ビルドに際しては、ロールベースのアクセスコントロール（RBAC：Role Based Access Control）機能を持つ外部デバイスやサービスを使用し、承認した担当者のみがビルドスクリプトを変更できるように設定する。
外部から取得したソースコードやビルドスクリプトについては、プロジェクトに追加する前に、その信頼性について検証する。
発見、入手したばかりのツール類を、未検証のまま不用意に利用しない。そのツールが開発コミュニティ内でよく知られていない場合や、入手元の信頼性を確認できていない場合は、特に注意する必要がある。
コードの変更に対する定期的な監視とレビューを実施する。