動画を保存できる人気の Chrome 拡張機能「Screencastify」に潜むリスク

** 本記事は、Who’s watching your webcam? The Screencastify Chrome extension story… の翻訳です。最新の情報は英語記事をご覧ください。**

ソフォスでは Chrome のみならず、あらゆるブラウザの拡張機能に潜むリスクについてたびたび警告してきました。

ブラウザの拡張機能は、 Web ページからダウンロードするコンテンツほど厳密に管理することはできません。もしできるのであれば…

…それは拡張機能ではなく、ただのローカルにキャッシュされた Web ページです。

たとえばアドブロッカーやパスワードマネージャーを 1 つの Web サイトでしか動作しないようにロックしたり、同時に 1 つのタブまたは Web サイトしか管理できないようにタブマネージャーを設定したりするのはあまり意味がなく、ツールの利便性を損なうだけです。

Web ページは、ブラウザ自体の制御を無効化することはできません。そのため、アドレスバーに偽のサーバー名を表示したり、Word 文書をハードディスクにダウンロードする際に出現する「本当に実行しますか?」というダイアログをスキップしたりするように Web ページ側から操作することはできません。

一方、ブラウザ拡張機能は、ブラウザ自体の動作を拡張したり変更したりできるようになっています。

ブラウザ拡張機能は、たとえば以下のことができます。

• ページを復号化した後、各タブに何が表示されるかを確認する。
• 実際に表示される内容を改変する。
• 入力した、あるいはアップロードした内容が送信される前に確認し、変更する。
• ローカルハードディスク上のファイルを読み取る、あるいは書き込む。
• 他のプログラムを起動、あるいは監視する。
• Web カメラやマイクなどのハードウェアにアクセスする。

Screencastify は、画面の一部または全部をキャプチャして他のユーザーと共有できる、人気のブラウザ拡張機能の一つです。上述の通り、この機能は Web サイトからは提供できません。

この拡張機能は「10,000,000 人以上」(いくら人数が増えても、これ以上のカテゴリは存在しないようです) のユーザーを誇っており、ストアページには以下のような 宣伝文句が並んでいます。

セキュリティ研究者の Wladimir Palant 氏は、自身も拡張機能の開発者であることからScreencastify の人気に興味を持ち、調査を行いました。

今週の初めに、彼は調査結果を公表しました。

彼の報告は、ある企業 X のアプリやサービスを利用する際に必要な「信頼の網」において、関係者を特定することの難しさを端的に示しています。

サプライチェーンに潜むリスクの再検討

たとえば A 社のソフトウェアをインストールしたとしましょう。そのソフトウェアは B 社からライセンスを受け、C 社がアップデートを行い、D 社の追加モジュールを導入します(同様の仕組みが内部にいくつもあるかもしれません)。

このような Web ベースのサービスのリスクは、サービスの提供プロセスに関与する他の多くのベンダーやプロバイダーを暗黙のうちに信頼していることから生じます。ソースコードのサプライチェーンに潜むリスクと同様です。

Palant 氏はまず、Screencastify の Chrome マニフェストファイルを調査しました。マニフェストファイルは、すべての拡張機能に存在する JSON データファイルで、拡張機能の名前、バージョン情報、セキュリティポリシー、更新用 URL、必要な権限などの重要情報を指定します。

Chrome マニフェストファイルのエントリの中には externally_connectable と題されたリストがあります。このリストでは、拡張機能との連携を許可する他の拡張機能、アプリ、Web サイトが指定されています。

通常、システムにインストールされている他の拡張機能やアプリはデフォルトで連携を許可できますが、セキュリティ上の理由により、外部の Web サイトから連携を許可することはできません。

つまり、何の気なしに Web サイトを開いたところ、訪問先のサーバーが勝手に拡張機能を制御していた、ということは起こり得ないのです。

しかし、Screencastify は自社の Web サイトからあらゆる種類のクラウドベースの追加機能を提供しているので、当然ながらその Web サイトは externally_connectable リストに含まれています。

Palant 氏が最初に調査した際、信頼する Web サイトのリストは以下のような形式で示されていました。

{ 
   ...
   "externally_connectable": { 
      "matches": [
         "https://*.screencastify.com/*" 
      ]
   },
   ...
}

特殊文字 * は「任意の文字列」を意味するので、上記の仕様では、screencastify.com ドメイン下のあらゆる Web サイトの URL に Screencastify 拡張機能を介したブラウザとのリモート通信が自動的に許可されることになります。

つまり、拡張機能の用途からすると当然ですが、Web カメラへのアクセスも提供されるということです。

Palant 氏は、externally_connectable リスト内の Web サイトがブラウザに送るリクエストの 1 種が bg:getSignInToken とタグ付けされており、このリクエストを行うと Google Drive ファイルに紐づけられた Google アクセストークンが返されることを発見しました。(ソフォスで行ったテストでは、Google アカウントにログインした状態でない限り、Screencastify は機能しませんでした。)

興味深いことに、Palant 氏によると、Screencastify が Google Drive へのフルアクセスを要求する (拡張機能は本来、関連するディレクトリへのアクセスのみを要求することができます) のは、フルアクセスなしには Screencastify に関連するファイルのリストを表示できないからだそうです。つまり、アップロードされたファイルを保存し、後で閲覧するためには、拡張機能にフルアクセスを許可し、ファイルを保存するディレクトリを作成した上で、そのディレクトリに保存したファイルを表示する必要があるということです。

さらに、Screencastify の機能がスクリーンキャプチャと Web カメラストリーミングを組み合わせたものであることから予想されるように、externally_connectable 内の Web サイトは、Chrome の desktopCapture API (スクリーン上の任意の場所のピクセルコンテンツを読み込みます)、tabCapture API (ブラウザ自体の内部からコンテンツを抽出します)、WebRTC API (「Web リアルタイムコミュニケーション」の略、Web カメラにアクセスします) へのアクセスを要求できます。

デスクトップやブラウザのタブをキャプチャするリクエストは、常に許可を求めるポップアップダイアログを目立つように生成するため、それほど問題にはなりません。

どうやら、画面キャプチャの際には、Chrome は毎回確認するようです。1 回のセッションで何度も画面キャプチャをオンにした場合さえ、確認を省略することはありません。

しかし、Web カメラの許可は Screencastify のセットアップ時に一度だけ要求すればよく、その後はポップアップを表示せずして省略できます。

また Palant 氏は、Screencastify のデフォルトの録画設定では、何らかのキャプチャを有効にすると、Google Drive に動画をアップロードする権限が自動的に与えられることを発見しました。

また、前述したように、externally_connectable 内の Web サイトは Google Drive に接続し、動画をダウンロードするためのアクセストークンを入手できます。Web カメラ映像のキャプチャを開始したのがその Web サイトでなくとも、です。

問題点

この時点では、何が問題なのかと思われるかもしれません。Screencastify のコードと Web サイトを信頼している以上、上記の出来事は起こり得るからです。Screencastify に動画をキャプチャして保存させている以上、Screencastify が動画をダウンロードできるのは当然のことです。

しかし、上記のリストに https://*.screencastify.com/* (上記を参照してください) という URL が含まれていることが問題です。

Palant 氏が調査時に発見したように、少なくとも 6 件の Screencastify のサブドメインが、第三者によって運営されていました。

• Webflow が www.screencastify.com サブドメインを、
• Teachable が course.screencastify.com を、
• Atlassian が status.screencastify.com サブドメインを、
• Netlify が quote.screencastify.com を、
• Marketo が go.screencastify.com を、
• ZenDesk が learn.screencastify.comをそれぞれ運営していました。

つまり、Web カメラと Google Drive に「秘密裏に」アクセスできるのは Screencastify 拡張機能や Screencastify のサーバーだけではありません。少なくとも上記の第三者のプロバイダーすべてにも権限が与えられていることになります。

さらには、拡張機能に権限を与えることは、拡張機能が接続するすべてのサブドメインにクロスサイトスクリプティング (XSS) などのバグがまったく存在しないと考えていることにもなります。

XSS バグを利用すると、たとえば example.com といった Web サイトを改変して、単純なテキスト文字列ではなく JavaScript コードの一部を平文で含む検索結果など、任意の危険なコンテンツを含む Web ページを生成し、表示できます。

たとえばある Web サイト上で Luap Nilkcud と検索した時に、<bold>Luap Nilkcud</bold> not found, try again (「Luap Nilkcud と一致する結果は見当たりませんでした、再度検索してください」) という文字列を含む HTML ページが返ってきたとしましょう。この場合は最も無害であり、生成された HTML は単に「タグがつけられた文字列を太字で、残りを通常のフォントで表示する」という意味しか持ちません。しかし、たとえば <script>alert("Oops")</script> と検索し、この HTML タグを含んだ形で HTML ページが返ってきたとしましょう。この場合、ブラウザはタグを含めてその文字列を正確に表示するため、script タグ内のコードを解釈して実行します。(これらの山括弧は本来削除されるか、<、> といった特殊なコードに変換されなくてはいけないはずです。) これらの「エスケープされていない」スクリプトコードは、検索した Web サイトのコードと同じ権限で実行されるので、Web サイトのサーバーをハッキングしなくても、Web サイトの提供する HTML に JavaScript を注入することが事実上可能になってしまいます。

最終的に、Palant 氏は Screencastify のプロパティの 1 つに XSS のバグを発見し、2 月に報告しました。

幸いなことに、Screencastify は同日中にこのバグを認め、翌日までに修正しました。

多くの関係者

いずれにせよ、Palant 氏の調査結果は、たとえば V 社から製品 P やサービス S を購入する際には、想像よりも多くの関係者が存在しており、想像よりも大きなリスクに晒されていることを示す良い教訓です。

興味深いことに、Palant 氏の報告が公表されたのを受けて、Screencastify は externally_connectable リストで信頼する Web サイトを制限することを決定し、現在は数を減らした一連のサブドメインを明確に記載しています。以下が現在信頼されているサブドメインの一覧です。

{ 
   ...
   "externally_connectable": { 
      "matches": [
         "https://captions.screencastify.com/*",
         "https://edit.screencastify.com/*",
         "https://questions.screencastify.com/*",
         "https://watch.screencastify.com/*",
         "https://www.screencastify.com/*"      
      ]
   },
   ...
}

第三者が運営している www.screencastify.com サブドメインがまだリストに含まれていますが、リストの記載を明確にしたことにより、SecOps (セキュリティオペレーション) 研究者がこの拡張子の全体的なリスクを定量化するのがはるかに容易になりました。

最小権限の原則

今回の事例はどんなに信頼できる人でも、必要のないリソースにはアクセスさせるべきではないという「need-to-know (知る権限) の原則」、または「最小権限の原則」と呼ばれるものの価値を再認識させるのに最適な事例です。この原則は、セキュリティの設定は暗黙のルールに任せるのではなく、明確に指定した方が間違いが起きにくいという考えに基づいたものです。

また、need-to-know の原則を遵守することで、信頼したユーザーが誤ってミスを犯した際に、自分と相手の双方に損害を与えるのを防止できます。

たとえば、root や Administrator の権限でのログインを強いられる場合でも、電子メールを読んだり、Web ページを閲覧するのにそれほどの権限は必要ありません。したがって、必要な時だけこれらの強い権限を利用し、必要ないときには権限を放棄できるようにアカウントを設定すべきです。

サイバーセキュリティの分野では、「より少ない」ことにしばしば大きな意味があります。