Open VSXは、悪意ある拡張機能リストに掲載していた3件の拡張機能識別子を除外しました。なりすまされていた正規プロジェクト側が、自らの名前を取り戻す動きを開始したことを受けての措置です。
この対応により、影響を受けたメンテナーの公開権限は回復しましたが、サプライチェーン追跡における抜け穴が浮き彫りになりました。1つの拡張機能IDが、削除された悪意あるアーティファクトと、その後公開された正規リリースの両方を指し得るという問題です。
8月16日から8月20日にかけて、Open VSXはAlDuncanson.react-hooks-snippets、magne-sjaastad.opm-flow-editor-support、rumbledb.jsoniq-vscodeのブロックを解除しました。
これらの識別子は、正規のVS Codeマーケットプレイスの拡張機能をOpen VSXにコピーする「なりすまし(evil-twin)」キャンペーンで悪用された77件の名前の一部でした。悪用は権限を持たない発行者アカウントを通じて行われていました。
Manifold Securityが記録したこの当初のキャンペーンは、7月26日から8月1日にかけて実行され、Microsoftの VS Codeマーケットプレイスに既に存在していながら、Open VSX上では実際のメンテナーによってまだ登録されていなかった拡張機能名を標的にしていました。
Cloudsecurity services
攻撃者は、無関係のアカウントと複製した説明文を使い、概ねバージョン0.0.1として偽造版を公開していました。77件のサンプルはすべて、最近登録されたばかりの同一のmangorbit[.]comインフラと通信していました。
悪意ある拡張機能のうち19件には、拡張された偵察用ペイロードが仕込まれていました。ホストおよびエディタのメタデータ収集に加えて次のような挙動が確認されています。
このコードはGitの設定やリポジトリの情報にもアクセスしており、リモートリポジトリのホスト、組織名、コミットメールのドメイン、ブランチ、コミットハッシュ、ワークスペースのパス、インストール済み拡張機能、CI/CD識別子などを収集していました。
Socketの報告によれば、OPM Flow Editor SupportおよびRumbleDB JSONiq/XQueryの各プロジェクトは既に正規版パッケージを公開済みで、React Hooks Snippetsは名前空間を取り戻したものの、本レポート時点ではOpen VSX上での公式リリースはまだ行われていませんでした。
ビルドランナーやクラウド開発環境では、収集されたフィールドからGITHUB_REPOSITORYやCI_PROJECT_PATHといったプライベートリポジトリのパスが漏えいする可能性がありました。
なりすましマルウェアキャンペーン
Socketの研究者らによると、Open VSXは8月3日までに77件の悪意ある拡張機能をすべて削除し、それらのIDを公開の管理リストに追加していました。
しかし、その後の復旧プロセスにより、ID単位のブロックリスト運用の限界が明らかになりました。Open VSXの公開リストは、悪意ある拡張機能を単なる識別子として記録するだけで、パッケージのバージョン、VSIXハッシュ、発行者アカウント、リポジトリURL、公開日といった情報は含まれていません。
正規の所有者が同一のIDを取り戻した場合、ブロックを維持すれば正規の拡張機能が公開できなくなってしまいます。一方でブロックを解除すれば、かつて悪意あるパッケージがそのIDを使用していたという事実そのものが、現行の悪意あるリストから消えてしまうことになります。
この影響は、今回復元された3件の名前において既に現れています。悪意あるパッケージは報告によれば0.0.1のような低いバージョン番号のリリースを使用していましたが、現在の正規リリースには8月21日公開の[email protected]や、8月23日公開の[email protected]が含まれています。
拡張機能IDのみを記録するセキュリティツールや社内の資産インベントリでは、同一の識別子で解決される過去のマルウェアと、現在承認されているパッケージとを確実に区別することができません。
より広範な名前空間乗っ取り(namesquatting)の問題も深刻です。Socketのエンジニアであるジョン・タックナー(John Tuckner)氏は、過去1年間にVS Codeマーケットプレイスのプロジェクトに該当するOpen VSX IDを491件追跡しており、そのうち338件は2026年に確認されたものでした。
そのうち415件は、Microsoftのマーケットプレイスで人気上位1万件以内になりすましていたものであり、別々の拡張機能エコシステム間で存在する名前空間の隙間の規模の大きさを物語っています。
Open VSXは今後の法的証拠能力(フォレンジック上の可視性)を改善し得る対策をいくつか導入しています。
1.1.xリリースでは、拡張機能のバージョンを不変化する機能が追加され、発行者が既に公開済みのバージョンを改変できなくなりました。また、公開・非公開化・削除といったイベントを記録するプレビュー版のRegistry Changes Feed(登録変更フィード)も導入されています。
この追記専用のフィードは、セキュリティチームがライフサイクルの履歴を保持する上で役立つ可能性がありますが、悪用後に正規の所有者が識別子を取り戻した場合の取り扱いに関する公式な指針は、まだ確立されていません。
防御側にとって、今回の事案は拡張機能の名前だけでは信頼の十分な指標にならないことを改めて浮き彫りにしました。
組織は、拡張機能IDに加えて、正確なバージョン、VSIXハッシュ、発行者のアイデンティティ、ソースリポジトリ、インストール元、そして初めて確認された日付を保持しておくべきです。
過去の検知結果は、後に正規の所有者によって回復される可能性のある識別子全体に広く適用するのではなく、あくまで悪意あるアーティファクトそのものに紐づけたままにすべきです。
拡張機能のメンテナーもまた、レジストリがまだ主要な配布チャネルになっていない場合であっても、攻撃者に先んじて自らのOpen VSX名前空間を確保しておくべきです。
企業のチームにとっては、コピーされた.vscode/extensions.jsonやdevcontainerの設定、自動化された開発環境のプロビジョニングにおいて、見慣れた名前だけで拡張機能を解決するのではなく、発行者の所有権とパッケージの出所を検証する仕組みを取り入れるべきです。
★ どのセキュリティツールを削るべきか?1ページで採点 – 継承されたセキュリティスタック・ガイドをダウンロード
Cloudsecurity services
翻訳元: https://gbhackers.com/evil-twin-malware-campaign/
