リモートワークが多くなってきており、Zoom が注目を集めていますが、同時に Zoom の脆弱性も取りだたされ、使用を禁止しはじめた会社、組織も出てきています。
Zoom は、元Cisco のエンジニアが、Cisco の WebExより良いものを作りたいが、Cisco 内ではできないという事で、ドロップアウトして作ったソフトウェアだそうです。
Zoom の安定性は、ヘビーに使っているわけではないので、よくわかりませんが、最近は、Microsoft Teams だったり、Zoom だったり様々なツールを使う事がふえてきました。
リンクを送られるがまま Zoom のミーティングに参加してきましたが、世の中で騒がれている Zoom の脆弱性について調べて見ました。
この記事は、2020/04/12 時点での Zoon もセキュリティ脆弱性についての個人的なメモです。
目次
Zoom の８つの脆弱性とその対応
もちろん細かいのは他にもあるでしょうが、以下の脆弱性がネットで取り上げられています。
これ以外にも細かな脆弱性はあると思います画、ネット上で取り上げられている脆弱性のリストは以下のようなものです。
ネットで言及されている Zoom の脆弱性
- Windows の場合、悪意のあるハイパーリンクをクリックする事でログイン情報 (クレデンシャル情報) を抜かれる可能性がある（参考）
- Zoom のリンクが公開されている場合、誰でも参加できてしまい部外者が乱入できる (Zoom爆弾。Zoombombingと呼ばれる)
- iOS の Zoom アプリを使用している場合、Facebook に情報が送信される (Facebook にアカウントが無い場合でも）(参考)
- Mac OS クライアントで、URL をクリックする事で Webカメラを 外部から起動できる脆弱性。ローカルにインストールされる Webサーバーを経由してリモートコマンドが実行できる脆弱性 (参考)
- Mac OS クライアントで、 通常インストール方法を回避したマルウェア的なインストール方法を行う（参考)
- Mac OS 上の2つのバグ。これらのバグはユーザーの Mac 端末を物理的に操作する必用がある。1つは上記の特種なインストールを利用して他人のMacの管理者権限を利用する。2つ目はローカルアクセスできるユーザーが、他のユーザーの Webカメラとマイクへのアクセス権を取得する事ができる。これによって悪意のあるプログラムを仕込む事で、他のユーザーをこっそり録画する事も可能 (参考)
- Zoom の通信が End to End で、暗号化されていない (参考記事)
- Zoom の通信の暗号鍵が、ユーザーが中国にいない場合でも、中国のサーバーから送られてくる場合がある / AES 128 CBC が使われている/ Waiting Room に脆弱性がある(参考記事)
それぞれについて、現状どうなっているか調べて見ました。
- [修正済み] 修正済みです。
Windows の場合は、Zoomアプリを起動すると修正おしらせ画面がでます。(参考ページ) - [対策済み] 対策済みです。
無償版アカウントでもデフォルト設定を変更し、パスワード機能や待機室の機能を有効化した他、セキュリティの設定がわかりやすくなるように細かな改善を入れたそうです（参考記事1, 参考記事2 ) 。
使い方の問題なのでバグでは無いと言って良いと思いますが。販売パートナーから対策方法のページなどが公開されています。( 参考：Zoom-Bombing」と呼ばれる事象への対処方法について)
Cisco の WebEx でも、MS Teams でも UserId や Password を設定しない会議室も作れますし、この辺りは他社も同様です。Zoom が話題になっているので、過剰に反応されているのだと思います。
Zoom の場合は Room のリンクが数字だけで構成されているので、類推しやすいと言う記事も見かけましたが、私の Cisco WebEx のパーソナル点ルームのリンクも誰でも類推できますし Zoom に限った話では無いと思います。他のWeb 会議システムのベンダーも自分の所が指摘されないかビクビクしている所だと思います。
- [修正済み] 修正済みです。Facebook の SDK を使うのを止めたようです。
こういった他社提供の SDK が何をしているのかは細かく見てないとわからない所があるので、意図的なものでは無く、単純ミスかなと思います。セキュリティ委員会を設置し、外部のセキュリティコンサルタントとして、元 Facebook の人間を召集したそうです(参考記事) 。
ちなみに Zoom のプライバシー・ポリシーには、アカウントに Facebook アカウントを使用する場合は、個人情報が Facebook に送られるという記載はあったようです。
私はモバイルアプリの開発者では無く初心者と言う事もあると思いますが、まさか Facebook の SDK を組み込み、恐らく初期化しただだけで、Facebook に端末情報が送信されるとは考えなかったと思います。
法律的にはどうかわかりませんが、心情的には Facebook の責任もあると思います。
カルフォルニアは個人情報の取り扱いに厳しく、訴訟を起こされていますが、日本人としてはやり過ぎ感があります（今回、実際にデータを利用していたのは Facebook 側なので） - [修正済み]修正済みです。かなり古い脆弱性で、2019年7月頃のもので修正済みです。
- [修正済み]修正済みです。インストール時の利便性を上げるために行っていたとの事ですが、広く使われるソフトウェアでこういった事は望ましくないと思います。
- [修正済み]修正済みです。こちらはマルチユーザー環境で MAC が使われており、物理的にアクセスできるという状況になります (この問題を指摘したブログ記事）
- [もともと対応済] ここはグレーにしました。もし Zoom という企業を信頼するのであれば [もともと対応済] と言って良いと思います。仕組みとして暗号鍵が Zoom 側から提供される仕組みのようです。
ですので、Zoom 側は技術的にはユーザーの通信を復号化する事ができます。但しオプションで、この鍵をユーザーが作れるようにする予定があるようです。（但しその場合はこれまでサポートしていた Cisco Polycom 等のデバイスが Zoom に接続できないとう制限が出るとされています）
これらの問題については、別セクションで少し深掘りしてみました。 - [修正済み]
・中国のサーバーから暗号鍵が提供されていた：この不安が各国政府や企業が Zoom を禁止している一番の理由では無いかと思います。現時点では Zoom 社だけでなく、中国政府も通信内容を解読できる可能性があります。2020年2月のコロナによる急激な負荷への対応のためサーバーを増やした際に「ジオフェンシング」と呼ばれる地域アクセス制御を実装し忘れたため。一部のアクセスが中国に誘導されていたというのが見解です。この問題は修正済みとされています( 参考記事)。(2020/04/25 : 追記） Zoom 5.0 で、有料ユーザーは使用するデータセンターが選べるように、安心感をます設計が追加されました。(Zoom blog)
・AES128 EBC という弱い暗号化が使用されている件については、少しづつ AES-256 GCM に変更していくようです。(2020/04/25 : 追記）クライアント側は、Zoom 5.0 で対応。5/30に全体で有効になるそうです。
・Waiting Room の脆弱性については修正されているようです。(Zoom blog)
これらの問題については、別セクションで少し深掘りしてみました。
個人的な Zoom のセキュリティについての見解
2020年4月に入るまでの脆弱性などは、基本的に対処されており、最新の Zoom を使えば問題では無いと思いました。
有名になった「Zoom爆弾」につていは、他の Web会議ツールでも同様な事は可能で、むしろ Zoomが持っている待合室のような乱入を防ぐバッファーを持ってないツールもあります。
現在、注目されているせいで、セキュリティ研究者が精力的に調査しているせいでいろいろな問題が指摘されているのだと思います。
一方で、2020年3末～4月頭にかけて「The Intercept_」に指摘された共通暗号鍵が現在 Zoom 側で管理されている事を完全に信頼するかどうか、短い期間とは言え、アメリカでの通信が中国にルートされていた事をサーバー増強時の事故として受け止めるかどうかの判断は保留したいかなと思います。
Zoom 側の技術的な説明には納得感があり、もしそれが本当であれば、中国国外での通信は、中国の Data Center と切り離されているので問題は無いでしょう。
一方で、中国国内での Zoom の使用は、他の中国国内のサービスと同じく通信内容は傍受されている/その気になればいつでも傍受されると考えた方が良いと思います。
ここが技術的に不可能になっている可能性もありますが、基本的に中国政府は政府が通信を傍受できない中国国内、中国国内と海外の通信を許可しません。反対に Zoom が中国国内でもサービスを展開している事が個人的には驚きでした。
中国国内でのこの手のポリシーを受け入れられないため、外資系のチャットソフトが中国に進出してない事を考えると（中国発で海外に出るソフトはありますが）、中国国内に進出してしまっている Zoom の企業としてのセキュリティ・ポリシーが、確かなものかどうか判断を保留するのが避けられないと思います。ですので、大企業や政府機関が Zoom の使用を禁じるのは当然だと思います。
将来的には暗号用の鍵をユーザーが作る事ができたり、鍵管理システムだけをユーザー企業が独自に外だしで作る事もできるようになる。と言う話なので、企業ユースはそれを待った方が良いかと思いました。ただ、Zoom にこだわる必用もないかと思います。
End to End の通信の暗号化について (7番目の問題)
大規模な Web サービスで使用される中継サーバーの存在
小さなネットサービスであれば、クライアントとサーバーは、1対1で通信である事が多いですが、大規模なネットサービスになると、クライアントから受けた通信を、何らかの方法で負荷の少ないサーバーに割り振るような仕組みを設ける必用があります。
この時、通信中のユーザーの通信は、特定のサーバーに同じように割り振って上げないと、通信の継続性が失われる可能性があります（つまりセッションの維持が必用です）
ある通信がどのユーザーの通信であるかは、その通信の中のセッションIDだったりユーザー情報のフィールドを見て判断する必用があります。もし通信が暗号化されている場合、通信を復号化して誰の通信か判断した後、再度暗号化した上で特定のサーバーにフォーワードします。
この復号化と暗号化の処理は、通信を中継する ロードバランサーや Proxy サーバー、CDN (Content Delivery Network) と呼ばれるサーバーの中で行われます。種類によって使われ方の目的は違いますが、一旦暗号を解いて復号化するという作業は同じです。
ショッピング・サイトでのクレジットカード情報の暗号化
例えば、どこかの大手のショッピングサイトで、買い物をしたとします。
その Web サイトに HTTPS 通信を使ってクレジットカード情報を暗号化して送信したとします。
その時に、Webサイトまでの経路の途中に Proxy サーバーや、ロードバランサーが入って居た場合は、一旦、それらのサーバー上で、データは復号化されます。そして通信内容を見て宛先を確認した後、再び暗号化されWebサイトに対してデータがフォワードされます。
こう言った場合、Proxy サーバーや、ロードバランサーで、復号化と暗号化を行うには、暗号用の鍵が必用で、当然、その暗号鍵は、Proxy サーバーやロードバランサー上に保管 されています。
鍵は直接ファイルとして保管されている場合もあれば、別の鍵管理サーバーがあり、そこから鍵をダウンロードしてきてメモリ上だけに保持するなどの仕組みを持っている場合もあります。
いずれにしても、もしこれらのサーバーが外部の人間にハッキングされてしまった場合、通信の内容をのぞき見る事が可能になります。
こう言ったのぞき見が行われないように、クレジットカード情報を取り扱うインフラは、セキュリティの基準が厳しく決まっており、PCIDSS と言う厳格なセキュリティ基準を満たす必用があります。
鍵の管理は、Webサイトの管理者自身が行っている場合もありますし、インフラ提供事業者、CDN事業者などが行っている場合もあります。
もしインフラ事業者側に鍵の管理を任せている場合（ユーザー側が鍵を管理するのは面倒なものです）、そのインフラ事業者を信頼している事になります。Zoom も Zoom 側で暗号鍵を管理しているので、現在の Zoom もこれに当たります。
いずれにしても、こう言った場合でも、Web のインフラ屋の習わしでは「End to End の暗号化が行われている」と言います。
ただチャットソフト等の間では少し違った文化があり「End to End の暗号化」= チャットの参加者以外は解読できない通信。を意味する事があります。
これはチャットソフト自体が暗号化されていると思ったものの、実はプラットフォーム側が中身を監視していたという事が実際に起きていたため、Endユーサーが以外は技術的に絶対復号化できない。と言う少し違った意味で解釈されるようになったと思っています。
End to End 暗号化問題に対する Zoom の見解
Zoon は、「End to End で暗号化しているのか？」という質問に対して、まずは、以下のように回答したようです。(2020/3/31の The intercept の記事)
a Zoom spokesperson wrote, “Currently, it is not possible to enable E2E encryption for Zoom video meetings. Zoom video meetings use a combination of TCP and UDP. TCP connections are made using TLS and UDP connections are encrypted with AES using a key negotiated over a TLS connection.”
動画の場合は、UDPの通信にしないと通信のオーバヘッドが大きくなりすぎ遅延が発生したり、途切れやすくなるので一般的にUDP が使われています。もともと UDP というのは、TCP では音声のストリーミングが上手くいかなかったため、こう言った用途で開発されたプロトコルです (RFCの番号的には、TCP の方が先で、UDP の方が後になっています）
前述したように一般的な Webショッピングの世界でも一部のショッピングサイトへ送られている情報は、中間サーバーで一旦、復号化されているケースはかなりあります。PCIDSS 等のセキュリティ基準はありますが、一般の人は、そう言ったサービスを提供する事業者を無条件で信頼しています。
Zoom の場合は中間サーバーのようなものがあり途中でデータを復号化しているのではなく、そもそも暗号化の鍵が Zoom 側から渡されている。という仕組みのようです。この鍵はミーティングが終わると破棄されるようですが、鍵を管理している Zoom をどこまで信用するか。という問題になると思います。
3/31 の The intercept_ の指摘を受けた後の Zoom 側の回答
Zoom では、The intercept_ の「End to End で暗号化されてないのでは？」という指摘を受けて以下のようなブログを出しています。
Zoom でも同様の意味で、以下のケースの場合は、End to End の暗号化が行われていると言っています。
- Zoom App を実行している PC
- Zoom App を実行しているスマートフォン
- Zoom Room ( Zoom の企業向けの会議室ソリューション）
In this scenario, where all participants are using the Zoom app, no user content is available to Zoom’s servers or employees at any point during the transmission process.
全ての参加者がZoom app を使用しているシナリオでは、ユーザーコンテンツは、Zoom Server に対しても、Zoom の社員に対しても見えないようになっています。
ただし、レガシーのシステムとの接続の場合は、レガシーシステムと接続するコネクターまでが暗号化の範囲になります。ただし可能場合は、暗号化される場合もあるようです。
These connectors are effectively Zoom clients that operate in Zoom’s cloud. Content remains encrypted to each connector, and when possible we will encrypt data between each connector and the eventual destination (such as a non-Zoom room system).
これらの"コネクター"は、 Zoomのクラウド上で稼働しています。通信内容はそれぞれのコネクターまで暗号化されてままです。そして、可能な場合は、コネクターと目的地の間までも暗号化されます（例えば、Zoon 以外のルームシステムなどがあります）
また、Zoom は、鍵管理システムを持っている事について言及しており、Zoom 社内ではユーザーがシェアしたコンテンツについては、厳格なコントロールを行っている。と回答しています。
To ensure this entire process meets the needs of our customers around the clock and around the world, Zoom currently maintains the key management system for these systems in the cloud. Importantly, Zoom has implemented robust and validated internal controls to prevent unauthorized access to any content that users share during meetings, including – but not limited to – the video, audio, and chat content of those meetings.
（世界中にいる顧客の24時間の要求に応えるのを確実にするために、Zoon では、鍵管理システムをクラウド上に維持しています。重要なのは、Zoom は、ユーザーがミーティング中でシェアしたビデオやオーディオなどあらゆるコンテンツへの権限の無いアクセスを防ぐためのの、堅牢で、確認された内部コントロールを行っています）
Zoom has never built a mechanism to decrypt live meetings for lawful intercept purposes, nor do we have means to insert our employees or others into meetings without being reflected in the participant list.
(Zoom は、司法の要求に応えるためにライブのミーティングを復号化する仕組みを作った事はありませんし、Zoom の社員が参加者リストに反映されないにもかかわらず、ミーティングに参加できる手段を持っていません）
正確にこの文章から Live の復号化まではできないと言っています。確かに技術的には可能でも、実際にライブで流れてくるストリームを別途、復号化して見るには、ある程度の”システム”を持つ必用があるでしょう。
いづれにしても、「鍵管理システム」をもっており、そこから発行された鍵を使って、会話の参加者以外でも、会議中に共有した、ビデオやオーディオを含めたどんなコンテンツでも複合化ができる事はできるようです。
一方で、Zoom は、この鍵を管理するシステムについて、以下のような事も言っています。
For those who want additional control of their keys, an on-premise solution exists today for the entire meeting infrastructure, and a solution will be available later this year to allow organizations to leverage Zoom’s cloud infrastructure but host the key management system within their environment.
鍵に関してさらに管理を必用とするユーザー向けに、 Zoom 社が使っているインフラをオンプレで実現するソリューションが今日現在あります。そして、今年の後半には Zoom が持っているクラウドのインフラを使用しながら、鍵管理システムは、お客様環境でホストするソリューションが提供可能になります。
Zoom のインフラをオンプレで実現するのは、グローバルの大企業でなければ、ほぼ不可能だと思います。逆に言うと Zoom 社は 自身のアーキテクチャーを外部に公開しているという意味にも取れます(完全に自社システムと同じとは限りませんが）。公開してない他社に比べるとオープンで安心感はあると思います。
一方で後半で言及されている、インフラは基本、Zoom 社が構築したものを使用し、鍵管理システムだけを、ユーザー企業側が管理するというのは、セキュリティを気にする政府、法人には魅力的なソリューションに見えます。
企業ユーザーとしては、後者が出てから Zoom を導入するという選択肢がいいのでは無いでしょうか。
今後のセキュリティ方針について
4/8 のZoom のブログで以下のような事を発表しています。
“Today, the way we use AES encryption, the key is generated by our system.And we’re working on a feature so that the key will be generated from you, from our customers.
技術詳細がよくわかないので、何とも言えないのですが、恐らくもしこの記述がユーザーが作成した暗号鍵だけで、全ての通信を暗号化する事を意味する（つまり Zoom 側では通信の中身を見る事ができない）のであれば、安心して使う事ができるようなるのかもしれません。
ビデオも公開されていますが、ビデオではもうちょっと細かい話がされています。
中国のサーバーから暗号化鍵が送られてきている問題等 (8番目の問題)
2020/4/3 に The Intercept_ は以下の新たな記事を出します。
今度の問題は、
- 中国のサーバーから共通鍵が送られ来る場合がある
- AES 128 EBC が使われている（暗号化の強度が弱い）
- Waiting Room に脆弱性がある
というものです。
中国のサーバーから共通鍵が送られてきた
(2020/04/25 : 追記）この問題に関しては、中国国外のユーザーは中国を使わないように修正するとともに、有償ユーザーに対しては、データセンターを選択する事ができるように設定を広げる事で安心感を増す対策が追加されました。
ユーザが使用する暗号鍵が、アメリカとカナダのユーザーがチャットした場合でも、中国のサーバーから送られてきた。というカナダの研究者のレポートが元になっています。
73ある 鍵管理システムのサーバーのうち5つが中国にあるように見える事が指摘されています。さらに、チャットの参加者に中国の人間がいない場合でも、中国と思われるサーバーから暗号鍵が送られてくる場合があったと報告されています。
The two Citizen Lab researchers who authored the report, Bill Marczak and John Scott-Railton, live in the United States and Canada. During a test call between the two, the shared meeting encryption key “was sent to one of the participants over TLS from a Zoom server apparently located in Beijing,” according to the report.
この現象を報告した、二人の Citizen Lab の研究者、Bill Marczakと John Scott-Railiton は、アメリカとカナダに住んでいます。二人が電話した時、会議用の共通暗号鍵が、北京にあると思われる Zoom サーバーより TLS 経由で送られてきたと報告しています。
中国のサーバーに共通秘密鍵を保管しているという事は、中国政府が共通秘密鍵を手に入れれば通信の内容を復号化する事ができます。
この手の問題は、あまり大きくとりざされていませんが、セキュリティの懸念は中国にサーバーを置く全てのネットサービスに共通します。
中国に設置されているサーバーは、サーバーの管理者は中国政府に従う必用があり、中国国内にサーバーが設置されているというのは、そのサーバーに置かれている情報は、中国政府に開示する義務があると思っておいた方が良いです。
法律の運用が曖昧で、中国の省や都市によっても違うのですが、中国国内から海外のサーバーに通信をしている場合、中国国内にそのサーバーを移すように求められるケースも実際ありますし、ルールに従ってない場合は、通信を遮断されるケースも個人的に見てきました。
この問題に対して、Zoom 側はブログで以下のように回答しています。
However, in February, Zoom rapidly added capacity to our Chinese region to handle a massive increase in demand. In our haste, we mistakenly added our two Chinese datacenters to a lengthy whitelist of backup bridges, potentially enabling non-Chinese clients to — under extremely limited circumstances — connect to them (namely when the primary non-Chinese servers were unavailable). This configuration change was made in February.
けれども2月には、Zoom は急いで中国リージョンのキャパシティを追加しました。その中で間違って二つの中国のデータセンターをバックアップブリッジのホワイトリストに追加してしまいました。それは、中国国内のクライアントでないものに対して - 限りなく限定的な環境において- 中国のデータセンターに接続させるものです（中国のサーバーでは無い、プライマリのサーバーが使用不可だった場合）この構成変更は2月に行われました。
急激な需要増加に伴いサーバーを追加した時に、「ジオフェンシング」という機能を実装をし忘れたという事で、通常はユーザーの接続位置に近い DataCenter を使用するようです。この時は、アメリカ国内のサーバーへの接続が失敗して、バックアップとして中国のサーバー（間違ってアクセスできるようになっていた）に接続に行ったとしています。
動作の解説については、YouTube にビデオの方が Blog より詳しいので以下にはっておきます。
また、中国国内の DataCenter は、外資系企業である事を明らかにしています。
ensuring that users outside of China do not have their meeting data routed through Zoom’s mainland China datacenters (which consist of infrastructure in a facility owned by Telstra, a leading Australian communications provider, as well as Amazon Web Services).
中国国外のユーザーのデータが中国本土のデータセンターを通過しない事を保証しています（中国のデータセンターは、オーストラリアの会社の Telstra と AWS です）
ただ、中国国内の AWS が上げられていますが、中国国外と国内の AWS は中国の法律があるので別物だと考えた方が良いです。
中国は社会主義国なのでそもそも外資系企業が資産を持つ事はできないので、外資系企業は中国国内のサーバーについては自社の「資産」と言わず「我々のサーバーが中国にある(但し管理は中国の会社がやっている)」という言うような言い方をします。また、私も全ては試験した訳ではないですが、中国国内のユーザーは、日本の AWS へのアクセスはグレートファイヤーウォールによりブロックされます。そんな感じで AWSと言っても管理は別物です。
Zoom 側の説明は技術面では説得力がありますが、現時点では、政府機関やグローバルの企業など、機密情報を扱うような用途では Zoom の使用は少し様子を見た方が良いのでは。と個人的には思います。
日本の場合は、日本の DataCenter に誘導されるようですが、台湾等の場合は中国の DataCenter に誘導されているかどうかは非常にクリティカルな問題になると思います。
AES 128 ECB が暗号化に使われている
(2020/04/25 : 追記）Zoom 5.0 で、AES 256 GCM を使えるクライアントがリリースされました。システム全体で有効になるのは、5/30が目処だそうです。
他にも暗号強度の弱い AES 128 ECBを使っている等が指摘されています。これについては、AES-256 GCMに少しづつアップデートしていくようです（Zoom の Blog)
We’re upgrading our encryption from AES-256 ECB to AES-256 GCM. We’ve already enabled that for one customer, and over the next several months, we are going to roll this feature out to all of our customers. However, every client needs to be updated to the latest version to work so that may take some time. So I think that will be a focus over the next 45 days.”
私達は暗号化を AES-256 ECB から AES 256 GCM にアップグレードします。既にあるお客さんで有効化しました。今後数ヶ月にわたって、全ての顧客に適用します。ただ、全てのクライアントを最新のバージョンにアップデートする必用がありある程度の時間が必用です。次の 45日間に渡って注視して行く事になると思います。
(※ AES 128 ECB ではなく、 AES-256 ECB になっているのは、ビデオの書き起こしのため、発言時の言い間違いかもしれません）
Waiting Room に脆弱性がある
Waiting Room の脆弱性については、4/8 の発言で、サーバー側のアップグレードで、現状で修正されたと発言がありました。
さらに Zoom が使用するデータセンターのリージョンの不安に対応するために、追加の機能を出す事になったようです。
