Zoomを使っても大丈夫？セキュリティ観点でどんな問題があったのか
昨今の新型コロナウィルスの影響による在宅ワークの推奨を受けて、ビデオ会議ツールの利用が進んできています。
その中でも利便性含め、多くの組織で使われ始めているソフトウェアがZoomです。
ただこのZoom、セキュリティ感度の高い方々からは、そのセキュリティ上のリスクについて連日話題になり始めていることにお気づきかと思います。
諸々の脆弱性については、随時対処していることをZoom側が公表しており、少しずつ改善されている様子です。
ただ、これまでにどのような問題が存在したのか、そして、今後もZoomを使い続けて問題ないかという点で不安を抱える方もいるかと思いますので、本記事にて、大まかにまとめてみようかと思います。
詳細については、各出典元のリンクも記載いたしますので、そちらをご参照いただくようお願いいたします。
目次
話題になっているいくつかの問題
まず、現時点で、CEOのEricよりZoom社のブログ記事にて、これまでに報告された問題とその対処について述べられています。
「What we’ve done」の部分ですね。
記載の通り、現在、これらの問題に対する対策はおおむね実施されています。
その中でも、特にここ数日、ニュース記事やベンダのブログ等での言及が多かった以下5つの問題について、取り上げていこうと思います。
それぞれの問題について、情報ソースとなったと思われる記事を集めたので、ご参考まで。
英語アレルギーの方や長文アレルギーの方は、以降の章で簡単に述べていますので、ご参照ください。 (とはいえ、本記事もなかなか長いですが。。。)
https://objective-see.com/blog/blog_0x56.html
- Zoom-bombing(会議の乗っ取り)
- Facebookへの情報送信
- エンドツーエンドでの暗号化
https://theintercept.com/2020/03/31/zoom-meeting-encryption/
Windows版クライアントの脆弱性
まずは、Windows版のZoomクライアントについてです。
チャット機能におけるUNCパスに係る脆弱性
Windows版クライアントのチャット機能にてUNCパスを入力すると、URL同様、図のようにハイパーリンクになります。
UNCはUniversal Naming Conventionの略で、Windowsネットワーク上のフォルダやファイルの位置を表記する手法です。
この手法により、ローカルの任意のプログラムの実行も可能になります。 以下はリンクをクリックすることで電卓が自動起動する様子です。
NTLM認証情報が送られてしまう
もう一つ大きな問題なのが、UNCパスに外部のサーバを指定した場合、アクセス時に、NTLM認証のユーザ名とパスワードのハッシュ値がサーバに送信されてしまう点です。
NTLMはWindowsネットワークにおける利用者認証方式なのですが、この認証情報を送る動作はデフォルトであることがわかっています。
以下の図は、ユーザ名とパスワードのハッシュが送信されている様子です。
また、このハッシュ化されたパスワードについても復号化が可能であり、Hashcatなどの無償ツールで復号できてしまうことがBleepingComputerの記事でも紹介されています。
所要時間はなんと16秒！
修正版のリリース
なお、本脆弱性は、4/2のリリースにて修正されています。
Mac版クライアントの脆弱性
続いて、Windows版のZoomクライアントについてです。
以前にもMacクライアントで動作する脆弱性について記事を書きました。 この時は、会議用のURLをクリックするとZoomが作動し、Webカメラが有効になるというもので、ユーザが無意識のうちに監視されてしまうというものでした。
そして今回、以下のブログ記事にて、新たに2つの脆弱性が公開されました。
https://objective-see.com/blog/blog_0x56.html
rootへの権限昇格
まず、このツイートにご注目ください。
If the App is already installed but the current user is not admin, they use a helper tool called “zoomAutenticationTool” and the AuthorizationExecuteWithPrivileges API to spawn a password prompt identifying as “System” (!!) to gain root (including a typo). pic.twitter.com/gp9DVCoVCm
— Felix (@c1truz_) 2020年3月30日
MacからZoomの会議に参加しようとした際、macOSのインストーラーが起動します。
どうやら管理者グループに所属している端末は、macに標準でインストールされたスクリプトを使うことにより、手動での解凍(7zip)およびインストールが実行されるとのことでした。
ツイートからもわかる通り、確認の画面は出てくるものの、多くの人はContinueをクリックしてしまうと思われます。
インストールされたアプリケーションは、zoomAuthenticationToolとAuthorizationExecuteWithPrivileges APIを呼び出し、アプリケーション更新のため認証用のポップアップを呼び出します。(いわゆる管理者の資格情報要求ですね)
ただ、問題は、このAuthorizationExecuteWithPrivileges APIがApple非推奨のAPIであること。 そして、パラメータに指定するファイルの検証を行わず、操作をrootで実行できてしまうことにあります。 以下の図でいうところの"/path/to/binary"の部分です。
もし攻撃者が、このファイルを改ざんした場合に、操作がrootで行えるため、事実上の権限昇格が行えてしまうわけです。
実際に攻撃の検証を行った様子も報告者のブログに乗っているので、興味ある方はご確認ください。
マイクやWebカメラへの不正アクセス
こちらは端的に述べますが、攻撃者が悪意を持って作成したライブラリを読み込ませることで、マイクとWebカメラを有効にするというものです。
通常であれば、有効にする前にアクセス確認画面が表示されるのですが、その表示を回避することができます。
仕組みとしては、アプリケーション自体のアクセス権にてマイクとWebカメラを一度有効に設定しているという条件下で、攻撃者が用意したライブラリが読み込まれた場合、アクセス継承が行われ、許可を求めることなく作動するというもののようです。
修正版のリリース
なお、これら2つの脆弱性についても、4/2のリリースにて修正されています。
Zoom-bombing(会議の乗っ取り)
続いてこちら、FBIのボストン支局より注意喚起もあったZoomBombingという会議の妨害行為です。
Web会議に招待されていないユーザが勝手に会議に参加し、差別コメントやアダルト動画の再生を行うなどの妨害行為が確認されています。
このような妨害行為が起きる要因として
- ミーティングIDが特定されてしまっていること
- 会議にパスワードがかかっていないこと
などが原因になっています。
ミーティングID自体は9~11桁のランダムな値で構成されます。
のですが、ブルートフォース攻撃でも有効なIDを発見することができてしまっており、CheckPointの検証では、4%の確率で有効なIDを発見できたとのことです。
ただ、個人的にはこの検証結果より的中率は高いと考えています。
というのも、このミーティングIDについて、
- 10桁もしくは11桁のID
- パーソナルミーティング、つまり、個人のアカウントに割り当てられるID
- 9桁のID
- インスタントミーティングまたはスケジュール済みミーティングで割り当てられるID
このような内容がヘルプセンターのページに記載されているからです。
現在の状況でおそらく多く使われているのは、インスタントミーティングだと個人的には想像しています。
対策としては、会議にパスワードをしっかりつけましょう！
というところだと考えてはいますが、この声がどこまでとどくか。。。
ちなみに、日本のヘルプセンターのリンクは以下なのですが、情報が古すぎる！
IDは9桁もしくは10桁と言っています。
facebookへの情報送信
先ほどは、Mac版クライアントについて記載しましたが、iOS版クライアントでも問題を抱えていました。
概要は以下です。
- Zoom利用者の情報をユーザの同意なしにFacebookに送っている
- iOSを搭載する機器iPadやiPhoneが対象
- Facebookアカウントを持っていなくてもデータを送ってしまう
- 送信情報
- iOS版クライアントにFacebookが提供するSDKを使用して実装していることに起因
- Facebookアカウントでログインできる目的で採用していたとのこと
修正版のリリース
なお、本脆弱性について、3/27のリリースにて修正されています。
エンドツーエンドでの暗号化
さらに、Zoomが謳っていたエンドツーエンドの通信について、実際はエンドツーエンドになっていないことが、誤解を招く表現だと述べる記事が公開されました。
概要は以下です。
- エンドツーエンドの暗号化の一般的な認識(報告記事やWikipedia参照)
- 暗号化を設定した本人のみが鍵を持つ
- データをやり取りする自分と相手の端末以外ではデータにアクセスできない
- たとえ第三者がデータを盗んでも解読できない
- Zoomの場合、HTTPS通信でZoomと利用者間の通信が暗号化されているが、Zoomサーバ自体が通信の復号化可能
他社の動画コミュニケーションツールにおけるエンドツーエンド実装状況
ちなみに、Zoomとの比較対象として例示されることの多いSlackやMicrosoft Teamsもエンドツーエンドの暗号化は実装できていなさそうです。(2019年8月6日時点)
一方で、WhatsAppおよびFacetimeやiMessageはエンドツーエンドの暗号化を実装しています。
エンドツーエンドを実装しない理由
WhatsAppはビデオ通話の上限が4人(2018年7月時点)、Facetimeは32人が上限だとされている一方で、Zoomは1000人、Teamsでは250ユーザ、Slackは15人がWeb会議の上限数になっています。
このことから、Slackはともかく、ZoomおよびTeamsのWeb会議における同時接続が桁違いであることがわかります。
今回結果的に叩かれてしまってはいますが、そもそも、提供する機能を考えれば、エンドツーエンドを実装することが現実的ではないことがわかるかと思います。
ここに関しては、少しかわいそう。。。
Zoomの利用を自粛する企業の登場
さて、これまでにZoomが抱える問題点について、ご紹介しました。
この影響でテスラのCEOが率いる宇宙産業ベンチャーであるSpaceXやNASA(アメリカ航空宇宙局)ではZoomの使用を禁止したことをロイター通信が報じました。
新型コロナウィルスの影響で利用者が急増したため対応が間に合っていないとも取れますが、さすがに多すぎるよ。。。
と思う気持ちもわかります。
まとめ
今回、Windows、Mac、iOSクライアントの問題に加えZoom-bombingなどを詳細に紹介しました。
とはいえ、Web会議を行う組織では何かしらのアプリケーションを使わざるを得ないと思いますし、利便性は高いと思うんですよね。Zoom。
こうなってくると、ブラウザで利用するしかないですかね。
今回紹介したことを踏まえ、しっかり会議にパスワードをつけて、ブラウザでアクセスして、快適なリモートワークを行うよう努めていくのが得策なのかな。
情報は情報としてとらえ、環境に適した対応をご検討いただければと思います。
