Rob Wright, シニアニュースディレクター, Dark Reading
2025年7月3日
読了時間：5分
出典：tofino, Alamy Stock Photo経由
統合開発環境（IDE）は、生成AI時代においてますます人気が高まっていますが、セキュリティ専門家は、ソフトウェアサプライチェーンへの攻撃が拡大し続ける中で、IDEが対処すべき隠れたリスクを抱えていると警告しています。
IDEは、開発者がソフトウェアコードをプログラム、編集、テストするために必要な基本的なツールや機能をまとめて提供します。これらはオンプレミスのソフトウェアスイートとして、またはクラウドプラットフォームとして提供されることがあります。そして、組織がソフトウェア開発を簡素化・効率化・高速化しようとする中でIDEの導入が急増していますが、近年、セキュリティ研究者はソフトウェアサプライチェーンを危険にさらすいくつかの脆弱性やリスクを発見しています。
今週、アプリケーションセキュリティベンダーのOX Securityが発表した最新の調査では、認証済みIDE拡張機能の隠れた危険性が明らかになりました。IDEはさまざまな開発ツールや機能を提供しますが、追加機能を持つサードパーティ製の拡張機能も多く、公式マーケットプレイスや外部ウェブサイトで入手可能です。
OXによると、研究者は重大な脆弱性を発見しました。これは、Visual Studio Code、Visual Studio、IntelliJ IDEAといった人気IDEが、公式マーケットプレイスで提供される拡張機能の認証ステータスをどのように扱っているかに関するものです。
認証済みの脅威？
OXのセキュリティ研究者であるMoshe Siman-Tov Bustan氏は、同社の調査チームがIDE拡張機能がブラウザ拡張機能と同様のリスクを持つのではないかと考えたとDark Readingに語っています。「例えばChromeには多くの悪意あるブラウザ拡張機能が公式ストアに紛れ込み、最終的にブラウザにインストールされています。同じことが開発者とIDE拡張機能にも当てはまるのではないかと考えました」と彼は述べています。
この仮説を検証するため、研究者たちはVisual Studio Code用の新しい拡張機能を作成し、MicrosoftのVisual Studio Marketplaceに提出しました。調査記事によると、コミュニティメンバーは拡張機能をストアに公開でき、Microsoftのパブリッシャー認証プロセス（パブリッシャーと拡張機能の両方を審査）を経ると、青いチェックマークアイコンが付与されます。
しかしOXの研究者は、認証済み拡張機能に後から機能を追加しても、チェックマークアイコンが維持されることに気付きました。Visual Studio Codeのトラフィックを分析したところ、拡張機能が認証済みかどうかを判定するマーケットプレイスへのサーバーリクエストがあり、そのリクエスト内の値を変更することで、承認済み拡張機能の悪意あるバージョンを作成しても認証ステータスを維持できることが分かりました。
「私たちは既に認証済みの拡張機能と同じ検証可能な値を持つ“悪意ある”拡張機能を開発しました。これには概念実証として電卓を開くコマンドも含まれており、クライアントワークステーション上でコマンドを実行できることを示しました」とSiman-Tov Bustan氏とOXの研究者Nir Zadok氏はブログ記事で述べています。
研究者たちは同じ手法をVisual Studio、Cursor、JetBrainsのIntelliJ IDEAなど他のIDEにも試しました。ファイル構造や認証メカニズムは異なっていましたが、攻撃手法は有効でした。彼らは認証用の個別サーバーリクエストを特定し、拡張機能の関連値を見つけて修正しても認証を失いませんでした。
ソフトウェアサプライチェーンへの脅威
この攻撃手法を使えば、攻撃者は認証済みで一見安全な拡張機能に悪意あるコードを注入し、認証ステータスを維持することができます。「これにより、拡張機能が信頼されているように見えるため、開発者のワークステーション上で知らぬ間に任意のコードが実行される可能性があります」とSiman-Tov Bustan氏とZadok氏は述べています。「したがって、拡張機能の認証マークだけに頼るのは推奨できません。」
Siman-Tov Bustan氏は、このような攻撃は組織にとって深刻な影響を及ぼす可能性があると述べています。なぜなら、開発者はしばしば特権認証情報を持っており、攻撃者はそのアクセス権を利用して企業環境の深部まで侵入できるからです。また、悪意あるIDE拡張機能は、より基本的な脅威レベルでも、攻撃者が拡張機能を使って機密コードを読み取るだけで深刻な結果をもたらす可能性があると強調しています。
「これらの拡張機能のうち1つを1人の開発者がダウンロードするだけで十分です」と彼は言います。「しかも、ラテラルムーブメント（横展開）をする必要もありません。拡張機能は複雑なことをする必要はなく、単に拡張機能が許可されている範囲のコードを読み取るだけでも非常に恐ろしいことです。」
Siman-Tov Bustan氏によれば、これは特にIDEを生成AIプロジェクトに利用している組織にとって壊滅的な事態を招く可能性があります。
これらのリスクにもかかわらず、IDEベンダーはこの攻撃経路を深刻とは見なしていないようです。OXのレポートにはMicrosoft、JetBrains、Cursorからの回答が含まれています。Microsoftは、この調査は同社の即時対応基準を満たしていないと述べました。
一方Cursorは、拡張機能の署名を全く検証していないと述べています。同社はまた、セキュリティポリシーにも言及し、Visual Studio Codeは最近になってMicrosoftのマーケットプレイスからダウンロードした拡張機能の検証を始めたばかりであり、インストール時のみ検証を行い、継続的な検証はしていないとしています。
JetBrainsは、OXの概念実証攻撃で使われた悪意ある拡張機能はJetBrains Marketplaceから提供されたものではなく、したがって信頼できないソースからコードをダウンロード・インストールする場合は個々のユーザーが責任を負うと回答しました。
Siman-Tov Bustan氏は、3社の主張を理解し、ユーザーは公式アプリストアやマーケットプレイスからのみソフトウェアをインストールすべきだと考えています。しかし、悪意あるコンテンツはしばしばセキュリティチェックをすり抜けてマーケットプレイスに入り込むことが多いと強調します。また、ソフトウェアサプライチェーン攻撃が増加する中、正規の拡張機能開発者自体が侵害され、攻撃者が既に承認済みのIDE拡張機能を武器化する可能性もあります。
さらに、開発者に公式ストアやマーケットプレイスからのみコードをダウンロードさせるのは現実的ではないとSiman-Tov Bustan氏は指摘します。GitHubのような公式ではないが信頼されているプラットフォームにも多くのアプリケーションやツールが提供されており、攻撃者はこうした認証の脆弱性を悪用することができます。
全体として、Siman-Tov Bustan氏はIDEにはさらなる保護が必要であり、認証の問題は「氷山の一角に過ぎない」と述べています。
OXはIDEを利用する開発者に対し、拡張機能署名の多要素認証の導入、市場で承認された署名付き拡張機能のみのインストール、拡張機能の各ファイルごとにハッシュ値を検証することを推奨しています。また、拡張機能ベンダーにはコード署名の整合性検証や証明書検証の実装による中間者攻撃の防止を勧めています。