前回のブログ記事「2/6 | 悪意ある拡張機能を暴く:VS Codeマーケットプレイスの衝撃的な統計」では、悪意ある拡張機能やリスクの高い拡張機能の実態を明らかにしながら、VSCodeマーケットプレイスに関する衝撃的な統計データを紹介しました。
マーケットプレイスを調査する中で、Microsoftが実装しているセキュリティ設計上の欠陥が驚くほど多く見つかり、それらが脅威アクターに信頼性と侵入経路を与える恰好の手段となっていることが判明しました。ここでは、その設計上の欠陥について説明します。そしてMicrosoftへ——もしこの記事を読んでいるなら、上場企業のすべてのCISOのために、本稿で指摘する問題に一刻も早く対処してほしいという手紙だと思ってください。
それでは、Microsoftさん、お話をしましょう。
VSCode拡張機能の内部構造
まず、VSCode拡張機能が内部でどのように動作しているかを見ていきましょう。VSCode拡張機能における最初にして最大のセキュリティ設計上の欠陥は、権限モデルが一切存在しないことです。
Microsoftは、インストール済みの拡張機能に対する権限管理や可視化の仕組みを一切実装していません。つまり、どの拡張機能もあらゆるAPI操作を実行できてしまいます。例えば、本来はIDEの配色を変更するだけのはずのテーマ拡張機能が、ユーザーの明示的な許可も可視性もないまま、コードを実行したりファイルの読み書きを行ったりできるのです。驚くべきことに、権限モデルを求めるGitHub上のフィーチャーリクエストは2018年から開かれたままになっており、Microsoftは今なお対応していません。
もう一つ懸念される問題は、拡張機能がデフォルトで自動的に、しかもユーザーに気づかれることなく最新版へ更新される点です。つまり、まず正規の拡張機能を公開して人気を獲得し、その後——たとえ特定バージョンの一時的なものであっても——悪意あるコードを紛れ込ませて初期アクセスを得るということが可能になります。これはChromeウェブストアでもこれまで何度も起きてきた手口で、脅威アクターが個人開発者から正規のChrome拡張機能を買い取り、後から悪意ある機能を仕込むというものでした。実は私たちも、この手法を今回の調査でのデータ収集強化に活用しました。VSCode拡張機能の内部を学ぶために独自の拡張機能を開発したのですが、その経緯は最初のブログ記事「偽のVSCode拡張機能を使って30分で数十億ドル規模の企業をハッキングした方法」でご紹介しています。
もう一つの設計上の欠陥は、VSCode拡張機能に対する制限がほぼ存在しないことです。VSCode拡張機能は事実上、ホストマシン上で動作する別のアプリケーションや実行ファイルのようなものです。Chrome拡張機能やGmailアドオンのような類似の仕組みとは異なり、VSCode拡張機能はホスト上で行えることに制限がまったくありません。子プロセスを生成できますし、システムコールを実行できますし、好きなNodeJSパッケージを何でもインポートでき、それが大きなリスクとなっています。拡張機能の開発者は、OSレベルのAPIと特定の方法で通信することを強制されておらず、さまざまな方法でコマンドを実行したりプロセスを生成したりできてしまいます。そのため、VSCode側でこの挙動を制御することは事実上不可能です。残念ながら、従来型のエンドポイントセキュリティツール(EDR)はこうした活動を検知できません(責任ある開示プロセスの中で、特定の組織向けにRCEの実例を実演して示しました)。VSCodeはもともと大量のファイルを読み込み、多くのコマンドを実行し、子プロセスを生成するように作られているため、EDRはそれが正規の開発者の活動なのか、悪意ある拡張機能によるものなのかを判別できません。VSCode拡張機能には制約もスコープの限定もなく、やりたい放題にふるまえてしまうのです。
恐ろしい話です。
VSCodeマーケットプレイスの管理体制、あるいはその欠如について
さて、拡張機能はホスト上で何でもできてしまうわけですが、もしかしたらVisual Studio Codeマーケットプレイス側には、そもそも悪意ある拡張機能のインストールを防ぐ管理体制が整っているかもしれません。結論から言えば、そんなものはなく、しかも想像以上にひどい状況です。
まず発行者(パブリッシャー)アカウントの作成について見ていきましょう。今回の調査では、マーケットプレイスに登録されている発行者は約45,000に上りましたが、そのうち検証済み発行者はわずか1,800にすぎません。検証済み発行者になると、拡張機能名の横に青い認証バッジが表示されます。ただし、ここに大きな落とし穴があります。検証済み発行者(発行者全体の上位4%)になるために必要なのは、DNS検証済みのドメインを発行者アカウントに追加することだけです。つまり、5ドルでドメインを買える人なら誰でも検証済み発行者になり、即座に信頼性のポイントを獲得できてしまうのです。私たちが実験用に作った拡張機能をご覧ください——
次に、リスティングページについてお話しします。VSCodeは、マーケットプレイスのリスティングページに表示される情報をすべて、拡張機能のコードに同梱されたpackage.jsonファイルから取得します。中でも重要なのが、リスティングページに表示されるGitHubリポジトリの情報です。お察しの通り、そのGitHubリポジトリを本当に自分が所有しているかを検証する仕組みは一切存在しませんし、アップロードされたコードが実際にそのGitHubリポジトリのコードと一致しているかを検証する仕組みもありません。つまり、見た目上はオープンソースの拡張機能のように装いながら、実際にパッケージ化されているコードはまったく別物ということもあり得るわけです。それだけでは終わりません。重複チェックの仕組みも存在しないため、オープンソースの拡張機能をそのままコピーし、そのGitHubリポジトリを自分の公式リポジトリとして登録することさえできてしまいます(!)。
今回の調査用拡張機能で注目を集める手段の一つとして、公開してからわずか1日でVisual Studio Codeマーケットプレイスのトップページのトレンド欄に掲載されたという事実があります。Microsoftがどのような基準でトレンド拡張機能を選定しているのかは定かではありませんが、Microsoftによって表示される拡張機能の多くはダウンロード数が非常に少なく、たいてい1,000件未満です。さらに検証を進めたところ、拡張機能をインストールするDockerファイルを作成し、それをループ実行するだけでインストール数を水増しできることも確認できました。つまり、いわゆるインストール数の水増し(インストールボム)によって、いとも簡単にトップページへ到達できてしまうのです(このトップページは月間450万件のアクセスを集めています)。
Microsoftさん、どうかこれらの問題を修正してください。これでは脅威アクターに、信頼性を獲得し開発者への露出を得るための、あまりにも容易な手段を提供してしまっています。
Microsoftへ
あなた方は素晴らしい製品を生み出し、数百万人もの開発者に愛され、使われています。しかし、その開発者たちは、あなた方が製品を安全に設計してくれると信頼を寄せているのです。本稿で取り上げたセキュリティ設計上の欠陥が、今後数カ月のうちに修正されることを願うばかりです。もしMicrosoftでVisual Studio Codeの開発に携わっている方をご存知でしたら、ぜひこの記事を共有してください。
ここで取り上げたのは、今回の調査で見つかった主要な設計上の問題の一部にすぎません。ほかにも小さな問題は数多くあり、さらに言えば、より大きな根本的な問題も存在します。それは、VSCodeが管理されていない(unmanaged)という点です。もっとも、現在ほとんどのIDEは管理されていない状態にあるため、これはMicrosoftだけを責めるべき話ではありません。しかし、この事実は一つのシンプルな解決策を示しています。もし組織が自社のIDEに対して可視性を持ち、評価し、統制する手段を持てていれば、この攻撃経路によるリスクと影響は最小限に抑えられていたはずです。
しかし、それが実現するまでの間、私たちは自らの手でこの状況に対処することを決め、不審なVisual Studio Code拡張機能を分析し、拡張機能というジャングルの中から有害なコードやリスクの高いアクセス、その他のセキュリティ脆弱性を検出できる無料のコミュニティツールを開発し、組織がこの脅威を軽減できるよう支援することにしました。
次回のブログ記事「「4/6 | ExtensionTotalのご紹介:VS Code拡張機能のリスクを評価する方法」(現在公開中!)」では、このニッチながらもリスクの高い問題に対する私たちのソリューションをご紹介します。今後もどうぞご期待ください。
追記: この問題の解決を支援する無料のコミュニティツールを公開しました。ぜひExtensionTotalをご覧ください
本編では触れなかった、ちょっと面白いセキュリティ設計上の欠陥
Microsoftが開発したvsceというユーティリティパッケージがあり、これは開発が終わった拡張機能のコードをパッケージ化する際に使用されます。Microsoftがあまり言及しない、ちょっとした事実があります。このユーティリティを使用すると、実は「build」や「dist」フォルダだけでなく、現在作業しているフォルダ全体がパッケージ化されてしまうのです。今回の調査では、ソースコードや機密情報が誤ってパッケージに含まれてしまっている拡張機能が数千件も見つかりました。その中には、AWSキー、GitHubのシークレット認証情報、Googleの認証情報、個人アクセストークン、SMTP、OpenAIキーなども含まれていました。
