Zoom は、悪意のある人物が、見知らぬ人のプライベートな会話にアクセスするために必要なパスコードを解読するために悪用される可能性のある脆弱性を修正したことを確認した。
ビデオ会議サービスを提供するZoomは、英国在住のバグハンター、トム・アンソニー氏によってこの問題が発見され非公開で報告された後、システムの脆弱性を修正したと発表した。アンソニー氏の話によると、Zoomは、犯罪者がブルートフォース攻撃によって特定の会議のパスコードを発見するのを防ぐのに十分な保護対策を講じていなかったという。
デフォルトでは、Zoom は電話会議を保護するために 6 桁のパスコードを作成するようにユーザーに求めるため、盗聴者は特定の会議に正しい組み合わせを見つけるまで、000000 から 999999 までのすべての可能な組み合わせを素早く試すことができました。
「ズームアプリを調べてみたところ、デフォルトのパスワードが6桁の数字であることに気づいた。つまり、パスワードの最大数は100万個ということだ」とアンソニー氏は今週の記事で説明した。
通常、これ自体は大きな問題にはなりません。ほとんどのアプリケーションやサービスでは、ユーザーがロックアウトされるまでに入力できるパスコード入力の試行回数を制限しているか、少なくとも推測できる回数を制限しているからです。100万通りの組み合わせをすべて試して初めて、ブロックされたり制限されたりするなどということはあり得ません。
しかし、アンソニーはZoomの場合、レート制限がないことを突き止めました。しかし、問題がありました。パスコードの確認ごとにZoomのサーバーに2つのHTTPリクエストを送信する必要があり、自動クラッキングは非現実的なほど長いプロセスになっていました。このオーバーヘッドにより、悪意のあるユーザーがすべてのパスコードを調べて正しいパスコードを見つける頃には、会議はとっくに終了しているでしょう。
しかしその後は…
ここからが面白いところです。2つのHTTPリクエストのうち、1つ目はパスコードを送信し、2つ目はそれが成功したかどうかを確認します。これらのリクエストでは、Zoomサーバーから一意のID番号（GUID）を取得して使用する必要があります。Anthonyは、事前に大量のGUIDをリクエストし、このプールを使用してパスコードチェックのバッチを並列実行することで、すべてのコードを実行するのに必要な時間を短縮できることを発見しました。
マイクロソフト、団結を保とう：ビデオチャットアプリTeamsの新モードは、Zoomがなぜ主流なのかを改めて認識させてくれる
続きを読む
「パスワードの繰り返し試行にはレート制限がありませんでした。各試行は2つのHTTPリクエストで構成されており、1つはパスワードの送信、もう1つはサーバーに受け入れられたかどうかを確認するためのリクエストです」とアンソニー氏は述べた。「しかし、速度はHTTPリクエストの送信速度によって制限されます。HTTPリクエストには自然な遅延があり、パスワードの解読は遅いプロセスになります。サーバー側の状態により、2つ目のリクエストを送信する前に最初のリクエストが完了するのを待つ必要があります。」
ただし、状態は提供されたGUIDに対して保存されており、CookieなしのHTTPリクエストを送信することで、サーバーに任意の数のGUIDを要求できることに留意する必要があります。つまり、複数のGUIDを一括でリクエストし、100万通りのパスワードをそれらのGUIDに分割して、複数のリクエストを並列に実行できるということです。
アンソニー氏によると、概念実証用のパスコードクラッカーは、1台のコンピューターから会議の6桁のパスワードを約25分で解読できたとのことで、より多くのコンピューターを使用すれば、この時間はさらに短縮できると考えている。「スレッド処理を改善し、4～5台のクラウドサーバーに分散させれば、パスワード空間全体を数分でチェックできるでしょう」と彼は述べた。
アンソニー氏は調査ではウェブクライアントに焦点を当てていましたが、この問題はZoomクライアントのあらゆるバージョンに存在すると考えていました。4月にウェブ版Zoomが1週間オフラインになったのはなぜかと疑問に思う方もいるかもしれませんが、それは彼がZoomにセキュリティ上の欠陥を報告した後、まさにこの問題を修正するためでした。
この問題を知ると、私たちはユーザーのセキュリティを確保するためにすぐにZoomウェブクライアントを停止しました。
Zoomの広報担当者は今週、 The Registerへの声明で次のように述べています。「4月1日にこの問題を認識した時点で、ユーザーのセキュリティを確保するため、Zoomのウェブクライアントを直ちに停止し、対策を講じました。その後、レート制限を改善し、CSRFトークンの問題に対処し、4月9日にウェブクライアントを再起動いたしました。」
これらの修正により、問題は完全に解決され、ユーザーによる操作は必要ありませんでした。この脆弱性が実際に使用されている事例は確認されていません。この問題を報告してくださったTom Anthony氏に感謝します。
もちろん、これはZoomのセキュリティとプライバシー危機がピークを迎えていた時期に起こった出来事です。パンデミックによるロックダウンで、何百万人もの人々が自宅待機を余儀なくされ、それまでは主に企業向けのビデオ会議サービスだったZoomに頼らざるを得なくなったことで、Zoomは突如として脚光を浴び、情報セキュリティ担当者から厳しい監視を受けることになりました。
実際、Zoom がウェブクライアントを削除したとき、同社の CEO はセキュリティを強化することを公に約束していました。
6月までに、Zoomは防御とプライバシー対策を強化したようで、今後脆弱性を非公開で報告した人に報奨金を出すバグ報奨金プログラムを運営するためにHackerOneを雇った。
セキュリティ上の欠陥が修正された後、少しコミュニケーションが途絶えました。4月中旬、アンソニーはZoomが前述のHackerOneが運営するバグ報奨金プログラムを立ち上げる計画を知り、報奨金獲得に成功した場合、詳細を公開してもよいかとビデオ会議会社に問い合わせました。報奨金プログラムの規則により、情報を公開してはいけないのではないかと心配していたアンソニーは、この欠陥は世間の注目を集めるべきだと考えました。
アンソニーは何も返事をもらえなかったため、今週の水曜日に上記の詳細を自身のウェブサイトに掲載した。
しかし、Zoomはその後も彼と連絡を取り合っていると聞いています。El Reg宛のメールで、アンソニーは次のように述べています。「Zoomからは、私の連絡先へのフォローアップが不十分だったことを謝罪する、とても丁寧なメールをいただきました。また、今後、研究者とのコミュニケーションを改善するために行っている取り組みについてもいくつかお知らせいただきました。また、今後のフィードバックやバグ報告も歓迎するとのことでした。」®
