前回のブログ記事「2/6 | 悪意ある拡張機能を暴く:VS Codeマーケットプレイスの衝撃的な統計」では、悪意ある拡張機能やリスクの高い拡張機能の実態を明らかにしながら、VSCodeマーケットプレイスに関する衝撃的な統計データをお伝えしました。
マーケットプレイスに関する調査の過程で、私たちはMicrosoftが実装したセキュリティ設計上の欠陥を数多く発見しました。これらは、脅威アクターが信頼性とアクセス権を獲得するための驚くべき手口を提供してしまっています。この記事では、それらの設計上の欠陥について解説します。そしてMicrosoft、もしこの記事を読んでいるなら、これは上場企業のすべてのCISOのために、本記事で指摘する問題に至急対処してほしいという私たちからの手紙だと受け止めてください。
それでは、Microsoftさん、少しお話ししましょう。
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拡張機能には境界も制限された権限範囲も存在せず、やりたい放題ができてしまいます。
恐ろしい話です。
VSCodeマーケットプレイスの管理体制、より正確に言えば、その欠如
さて、拡張機能はホスト上で何でもできてしまうわけですが、もしかしたらVisual Studio Codeマーケットプレイス側に、そもそも悪意ある拡張機能のインストールを防ぐ管理体制があるのではないか、と思うかもしれません。結論から言うと、そんなものは存在せず、実態は想像以上にひどいものでした。
まず発行者(パブリッシャー)アカウントの作成から見ていきましょう。私たちの調査では、マーケットプレイスに登録されている発行者は約45,000者にのぼりますが、そのうち認証済み発行者はわずか1,800者にすぎません。認証済み発行者になるということは、拡張機能名の横に青いバッジが輝くということです。しかし、ここに大きな落とし穴があります。認証済み発行者(発行者全体の上位4%)になるために必要なのは、発行者アカウントにDNS認証済みドメインを追加することだけです。つまり、5ドルのドメインを買うだけで誰でも認証済み発行者になり、瞬時に信頼性ポイントを獲得できてしまうのです。私たちの実験用拡張機能をご覧ください。
次に、リスティングページ(掲載ページ)について見ていきましょう。VSCodeは、マーケットプレイスの掲載ページに表示される情報を、拡張機能のコードとともにパッケージ化されたpackage.jsonファイルからすべて取得します。特に、掲載ページに表示されるGithubリポジトリの情報もそこから取得しています。お察しの通り、そのGithubリポジトリを実際に所有しているかどうかを検証する仕組みは一切なく、アップロードされたコードが本当にそのGithubリポジトリ上のコードと一致しているかを検証する仕組みも存在しません。つまり、見た目上はオープンソースの拡張機能に見えても、実際にパッケージ化されているコードはまったく別物である可能性があるということです。それだけでは終わりません。重複チェックの仕組みも存在しないため、オープンソースの拡張機能をそのままコピーし、そのGithubを自分の公式Githubリポジトリとして掲載することさえ可能なのです(!)。
私たちの調査用拡張機能が注目を集める要因の一つとなったのが、公開してからわずか1日でVisual Studio Codeマーケットプレイスのフロントページにトレンド表示されたことです。Microsoftがどのような基準でトレンド拡張機能を選んでいるのかは定かではありませんが、Microsoftによってフロントページに表示されている拡張機能の多くは、ダウンロード数が非常に少なく、通常1,000件にも満たない状態です。さらに私たちは、拡張機能をインストールするDockerファイルを作成し、それをループ実行するだけでインストール数を水増しできることも確認しました。つまり、インストール数を意図的に爆増させるだけで、いとも簡単にフロントページに到達できてしまうのです(このフロントページは月間450万ヒットを記録しています)。
Microsoftさん、どうかこれらの問題を修正してください。これは脅威アクターに対して、信頼性を獲得し開発者に露出する非常に容易な手段を提供してしまっています。
Microsoftへ
あなたがたは、何百万人もの開発者に愛用され支持される素晴らしい製品を作り上げました。しかし、その開発者たちは、あなたがたが安全な製品を設計してくれるだろうという信頼を寄せています。本記事で指摘したセキュリティ設計上の欠陥が、今後数か月のうちに修正されることを願うばかりです。もしMicrosoft社内でVisual Studio Codeに携わっている方とつながりがあれば、ぜひこの記事を共有してください。
今回の調査で見つかった大きな設計上の問題については、その一部しかご紹介できていません。ほかにも細かな問題が数多くあり、さらに言えば、より根本的で大きな課題も存在します。それは、VSCodeが「管理されていない」という事実です。もっとも、現在ほとんどのIDEは管理されていない状態にあるため、これはMicrosoft固有の問題というわけではありません。しかし、この事実はシンプルな解決策の必要性を浮き彫りにしています。もし組織がIDEに対する可視性を確保し、評価し、統制する手段を持っていれば、この攻撃経路によるリスクと影響は最小限に抑えられていたはずです。
とはいえ、それが実現するのを待ってはいられません。そこで私たちは自らの手でこの問題に取り組むことにしました。疑わしいVisual Studio Code拡張機能を分析し、有害なコードやリスクの高いアクセス、その他のセキュリティ上の脆弱性を見つけ出すための無料のコミュニティツールを開発し、拡張機能というジャングルを安全に進むための助けとなることを目指しています。
次回のブログ記事「「4/6 | ExtensionTotal登場:VS Code拡張機能のリスクを評価する方法」(現在公開中!)」では、このニッチながらもリスクの高い課題に対する私たちの解決策をご紹介します。ぜひ引き続きご注目ください。
追記:私たちはこの問題を解決するための無料のコミュニティツールをリリースしました。ぜひExtensionTotalをご確認ください
本編には収まりきらなかった、ちょっとした興味深いセキュリティ設計上の欠陥
Microsoftが開発したvsceというユーティリティパッケージがあり、これは拡張機能の開発が終わった後にコードをパッケージ化するために使われます。Microsoftがあまり言及しない興味深い事実として、このユーティリティを使用すると、「build」フォルダや「dist」フォルダだけでなく、その時点で作業中のフォルダ全体がパッケージ化されてしまいます。私たちの調査では、ソースコードや機密情報が誤ってパッケージに含まれてしまっている拡張機能が数千件見つかりました。その中には、AWSキー、Githubのシークレット認証情報、Googleの認証情報、パーソナルアクセストークン、SMTP、OpenAIキーなどが含まれるものもありました。
