根絶宣言から数週間後、GlassWormが再び不可視のUnicodeやブロックチェーンC2の手口でオープンソース拡張機能に蔓延。
根絶されたと考えられていた広範かつ回避的なマルウェアが、再び開発環境に侵入しています。
GlassWormがオープンソースのOpenVSXプロジェクトによって「完全に封じ込められ、終了」と宣言されてからわずか2週間余りで、この自己増殖型ワームは再びVisual Studio Codeの拡張機能、つまりオープンソースのVS Codeを強化し、新機能やデバッガ、その他のツールを提供して開発者のワークフローを向上させるアドオンを標的にしています。Koiの研究者は、新たな感染の波とさらに3つの侵害された拡張機能を発見しました。
10月に初めて発見されたGlassWormは、VS Code環境のコードエディタで悪意のあるコードを不可視にするために表示できないUnicode文字を利用します。このワームは現在、GitHubリポジトリにも侵入し、AI生成のコミットにペイロードを隠して、正当なコード変更のように見せかけています。
ロシア拠点の攻撃グループによってリリースされたこのマルウェアは、世界中の被害者を感染させています。これには米国、欧州、アジア、南米、そして中東の「主要な政府機関」を含む数十人の個人開発者や企業が含まれます。
「同じ攻撃者インフラが、今も完全に稼働中です」とKoiの研究者は指摘します。さらに「もはや侵害された拡張機能だけの問題ではありません。これは実際の被害者、リスクにさらされた重要インフラ、そして我々が警告した通りに動作するワームの問題です。開発者エコシステム全体に広がっています」と述べています。
GitHubリポジトリも侵害
Koiの研究者は、GlassWormを含む3つの新しいOpenVSXコード拡張機能を特定しました。これらは合計で少なくとも10,000回ダウンロードされています：
- adhamu.history-in-sublime-merge（4,000回ダウンロード）
- ai-driven-dev.ai-driven-dev（3,300回ダウンロード）
- yasuyuky.transient-emacs（2,400回ダウンロード）
これら3つすべてのGlassWorm拡張機能は「依然としてコードエディタ上で完全に不可視」であると研究者は指摘します。これらは人間の目には空白に見える表示不可能なUnicode文字でエンコードされており、JavaScriptとして実行されます。
攻撃者は、悪意のあるペイロード配布用の更新されたリモートコマンド＆コントロール（C2）エンドポイントを記載した新たなトランザクションをSolanaブロックチェーン上に投稿しています。しかし、これらのトランザクションは新しいものの、サーバー自体は変更されていないと研究者は述べています。
「これはブロックチェーンベースのC2インフラの耐障害性を示しています。たとえペイロードサーバーが停止されても、攻撃者はわずかなコストで新しいトランザクションを投稿でき、すべての感染マシンが自動的に新しい場所を取得します」と彼らは記しています。
開発者からは、自分のGitHubリポジトリが、通常の開発活動の一部として「プロジェクト固有」のAI生成コード変更のコミットで侵害されたとの報告も上がっています。これらのコミットにはVS Codeと同じ不可視Unicodeマルウェアが含まれています。さらに攻撃者はGitHubの認証情報を盗み、ワームの手法で他のリポジトリにもコミットをプッシュしています。
「GlassWormがこれほど早く再出現したことは非常に懸念すべきですが、驚くことではありません」と脅威インテリジェンス企業SOCRadarのCISO、Ensar Seker氏は述べています。
特に危険なのは、攻撃者がサプライチェーンワームを一度除去された後に再び表面化させた方法だと彼は指摘します。「いくつかの拡張機能を削除しただけでは不十分です。攻撃者が伝播メカニズムを制御し、複数のマーケットプレイスにまたがって拡散ポイントを活用している場合は特にそうです。」
「根本的な弱点」を浮き彫りに
興味深いことに、攻撃者は自らのインフラ管理がずさんだったようで、Koiの研究者がデータや被害者リストの一部を抽出できる公開エンドポイントを残していました。また、脅威アクターのキーロガーデータから、彼らがオープンソースのC2フレームワーク拡張機能RedExtを使用していることや、複数のメッセージングプラットフォームや暗号通貨取引所のユーザーIDにアクセスできたことも判明しました。
被害者リストはすでに法執行機関に引き渡され、被害者への通知と積極的な調査が進行中であるとKoiの研究者は述べています。
Beauceron SecurityのDavid Shipleyは、これらの攻撃は技術的なものだけでなく、プロセスや市場の仕組みにも起因すると指摘します。OpenVSXは、コミュニティとして提出されたコードを手動でレビューするリソースがないようで、自動ツールとパブリッシャー契約に頼っていると述べています。
この問題は、オープンソース市場モデルの「根本的な弱点」を浮き彫りにしています。無料または低コストのアプローチではリソースが不足し、今日の脅威環境に必要なセキュリティレベルを適用するためのインセンティブも整いません、とShipley氏は述べています。
「端的に言えば、手動コードレビューに十分な報酬がなければ、誰もやりません」と彼は指摘します。「巧妙なハックを見抜ける人間がいなければ、巧妙なハックは簡単に入り込むのです。」
OpenVSXの価値を問う
セキュリティチームはOpenVSXの価値提案を見直すべきだとShipley氏は助言します。もし手動でレビューし、オープンソースレジストリからのコードについてアラートを出す覚悟があるなら、リスクを軽減できます。そうでなければ、より厳格なレビュー管理がある厳選されたソースからコードを入手することを検討すべきです。
「サプライチェーンとオープンソースは今やサイバーセキュリティの鬼ごっこの“鬼”であり、しばらくその状態が続くでしょう」とShipley氏は述べます。これは、より多くのセキュリティを許容する経済バランスが取れるか、あるいはモデルが「不安定さの重みに耐えきれず崩壊する」まで続く可能性があります。
「これらの脅威を100％確実に防げる自動AIの魔法の粉など存在しません」と彼は言います。「自動スキャンが“十分良い”とされていたのは、攻撃者がこれを非常に有効な攻撃配布手段だと気付くまでの話です。」
SOCRadarのSeker氏も、根本的な問題はマルウェアそのものではなく、サプライチェーン脅威の「システム的な変化」にあると同意します。
「ソフトウェアサプライチェーンはもはや依存関係だけの問題ではありません」と彼は述べ、むしろツールチェーン、マーケットプレイス、開発エコシステム全体の問題だと指摘します。「開発者インフラを本番インフラと同じように扱う必要があります。」
開発者やセキュリティチームは、不可視Unicode文字を含む悪意のある拡張機能のアップロード、ブロックチェーンメモやGoogleカレンダーのような正規サービスを使った隠れたC2チャネルによるテイクダウン回避、感染した開発者マシンがプロキシノードとしてさらなる感染を拡大する、といった重要なシグナルに注目すべきです。
企業は、信頼できるパブリッシャーからのコンポーネントのみを許可し、可能な限り自動更新を無効化し、インストール済み拡張機能のインベントリを維持することで攻撃対象領域を減らすべきだとSeker氏は助言します。また、ワークステーションからの異常な外部接続、開発者レベルのトークン（npm、GitHub、VS Code）の認証情報収集活動、プロキシやVNCサーバーの作成も監視すべきです。さらに、サードパーティライブラリに対して行うのと同じ厳格さを自社の開発ツールチェーンにも適用すべきです。
「悪意ある攻撃者があなたのIDE（統合開発環境）を発射台として扱うと、サプライチェーンのリスクは劇的に拡大します」とSeker氏は述べます。
最終的に彼は警告します。「これは単一のライブラリをパッチして終わるような典型的なサプライチェーン攻撃ではありません。持続するよう設計されています。」
本記事は元々InfoWorldに掲載されたものです。
