ビデオ会議の素晴らしい世界へようこそ!そして、そのセキュリティ上の欠陥についてもご紹介します。Web会議のセキュリティの問題は、盗聴だけだと思っていませんか?いや、問題はもっと広範囲にわたっており、まだかなり秘密が多い。
一言で言えば、ビデオ会議はワークステーションやネットワークのセキュリティを著しく低下させます。!
Journal du Net – 2021年11月03日 – Francois Caron
私の話を聞いてくれる人?
ビデオ会議やウェビナーのセキュリティ上の問題点を理解するためには、「WebRTC」(Web Real Time Communication)の仕組みを理解する必要があります。
WebRTCは、Googleが主導してW3CとIETFがサポートする新しいWeb規格です。Peer to Peer技術を用いて、コンピュータ同士の切り替えを可能にします。
端末間のオーディオ・ビデオ通信は、推奨される方法に従って、SDPとDTLSがデータを保護し、SRTPが交換を保護します。
しかし、通信が安全でない場合は、オーディオ・ビデオのストリームを聞くことができます。さらに、多くのソリューションでは、参加者の身元が十分に保護されておらず、ハッカーがなりすますことが可能であると、Polytechnic Cataloniaの論文(PDF)は述べています。
すべてのビデオ会議システムが同じではないため、データなどのスパイ行為が可能な場合があります。
私たちは、2020年11月に、ジャーナリストがZoomでアクセスした欧州委員会の「機密」会議を覚えています。
しかし、本物のハッカーは、自分の悪行を報告するためにあなたに連絡しないこと、そして、既知および未知のいくつかの方法とセキュリティの抜け穴があることを覚えておきましょう。
何が問題なのか?
ウェビナーのセキュリティ上の欠陥の中で、最も問題なのは、WebRTCがネットワークを棚卸しして、ファイアウォールの背後にあるエンドポイントにアクセスすることです。
巨大な?いいえ、これは標準的な手順です。エンドポイントのインベントリは、エンドポイントを1つまたは複数のセキュアなネットワークに関連付けるために必要なものです。
具体的には、ビデオ会議で3台のワークステーションをPeer to Peerで接続する場合、WebRTCシステム(Teams、Zoom、Jitsiなど)が端末の情報を棚卸しします。
ファイアウォールを回避するために、WebRTCはセキュアなネットワーク内の端末にアドレスを割り当てます。これらの手順は複雑で、出版社からもあまり知られていません。
このデータは、セキュアネットワーク内の端末へのアクセスを可能にするもので、お客様が所在、セキュリティ、適用される法律を知らないサーバーを介して送信されます。
このようなことはよくあることですが、ビデオ会議の出版社が、その技術が外国の下請け会社によって運営されていることをユーザーに知らせることはほとんどありません。
ほとんどの場合、これらの情報はあなたの手に負えません。端末を接続するためのWebRTC通信サービス(Turn, Stun, ICE for “Interactive Connectivity Establishment“)の在庫がありません。
この複雑さが、ビデオ会議やウェビナーのセキュリティの弱点になっています。
使いやすさのために、多くのベンダーがRGDP対応を謳っています。しかし、それだけでは十分ではありません。特に、システムがコンプライアンスやセキュリティを謳っている場合はなおさらです。
本当のリスクとは?
この記事の情報を疑っていますか?確かに、「データはハッキングされる!」ということを証明する証拠が必要ですね。
まず、インターネットユーザーが自宅でビデオ会議に参加した場合、たとえVPNを装備していても、パブリックIPが公開され、攻撃の対象となる可能性があることを明記しておきます。これは、悪意のあるスクリプトが存在する場合のブラウザの標準的な動作によるものです。
しかし、話をICE(Interactive Connectivity Establishment)に戻そう。ICEは、WebRTCビデオ会議にどのコンピューターが接続されているかを認識する。
ICEはTurn技術を用いてセキュアなネットワークを経由し、ビデオ会議に参加しているコンピュータを保護されたネットワークから切り替える.
これはネットワークエンジニアが「NAT解決」と呼ぶもので、イントラネット内のワークステーションへのアクセスを可能にする
ターンサーバーと端末のセキュリティを確保する方法はあるが、出版社はこの点についてあまり積極的ではない。
最近のハッキングについて?
すでに2014年にエリクソン社のエンジニアがTurnプロセスのセキュリティ上の欠陥を研究しています。「クライアントとサーバー間のメッセージ交換を聞くことができる攻撃者がパスワードを決定することができる」これはZatazがVPNのセキュリティに影響を与える欠陥として確認したものです。
2018年12月、SecureCommカンファレンスにおいて、「Webブラウザを悪用して隠しコンテンツを保存・配信する」ための手法が公開された
2020年4月、Future of Internet Forumは「WebRTCを使って外部の攻撃者からイントラネットのトポロジーをマッピングする問題」を指摘し、よくわかる分析結果を示しています(PDF)。
2020年6月、セキュリティフォーラムでは、Jitsiの発行元である米国の8×8社によるTurnサービスの悪用について報告され、このエクスプロイトにより「リモートの攻撃者がサーバー自体の内部サービスやAWSの内部ネットワークに到達することができる」と述べられています。
2021年9月、セキュリティ専門家のRTSECが、SlackのTurnサーバー(1日1200万ユーザー)が「内部サービス」へのアクセスに悪用された可能性があると発表。
そのため、WebRTCのセキュリティは伝説ではなく、ホットな話題となっています。
どのソリューション?
まとめてみましょう。これらのWebRTCビデオ会議のセキュリティ問題は、ネットワークや端末などのセキュリティを露呈する可能性があります。
だからこそ、ビデオ会議ソリューションは、強力なセキュリティを保証するものでなくてはならないのです。
もはや議論の余地はなく、通信の機密性のレベルに関わらず、WebRTCビデオ会議技術はITセキュリティを暴露する可能性があります。
オーディオ・ビデオフローとそのトランスポートを保護するための手順(SDP、DTLS、SRTP)、通信コンポーネント(ICE、Stun、Turn)に加えて、高レベルのセキュリティを保証するためには、「エンド・ツー・エンドのセキュアなアーキテクチャ」という言葉が必要です。
e2ee」(End to End Encryption)とも呼ばれるエンド・ツー・エンド・セキュリティは、WebRTCアーキテクチャのすべての交換ポイント(端末とサーバー)を暗号化し、リソースと通信を保護することを目的としています。
そのため、「このビデオ会議アプリケーションはエンド・ツー・エンドで暗号化されているのか」ということが重要な問題となります。
どのような基準を要求するか?
エンド・ツー・エンドの暗号化は、お客様のセキュリティの重要な指標となります.
2021年4月、Front Line Defenders Foundationによるガイドでは、多くのビデオ会議システムがまだエンド・ツー・エンドで暗号化されていないと結論づけています。
ガイドによると、Jitsi Meetでは(まだ)この問題に取り組んでおり、Teamsでは「これらのサーバーにアクセスできる人は、あなたのメッセージを傍受できる可能性がある」としています。
Zoom、Skype、Telegram、WhatsAppなどのツールは含まれていません……これらを使用する際のリスクの幅が大きすぎます。
エンド・ツー・エンドの暗号化は必須条件です。しかし、セキュリティ認証は開発やホスティングの手法を検証するものであり、範囲外の危険性の目録を作るものではないことも強調しておきましょう…必要な精度です。
フランスでは、Empreinte.comのWebinarPlease、Tixeo、AlcatelLucentのRainbowソフトウェアソリューションがエンドツーエンドで暗号化され、安全なシステムへの道を開いています。
最後に、Empreinte.comは、ユーザーやCIOの生活を簡素化するために、端末にソフトウェアをインストールしないことを明記しています。これは、ティム・バーナーズ・リーの「ウェブの究極の目的は、我々の生活をサポートし、強化することであり、複雑にすることではない」という言葉を完結させるためです…。
CIOであろうと、インターネットユーザーであろうと、このゲームのルールを知っています。
それはあなた次第です。
____________
(1) https://www.journaldugeek.com/2011/06/15/google-webrtc-chat-video-audio-navigateur/
(2) https://www.w3.org/TR/webrtc/
(3) https://www.rfc-editor.org/rfc/rfc8835.html
(4) https://tools.ietf.org/id/draft-nandakumar-rtcweb-sdp-01.html
(5) https://fr.wikipedia.org/wiki/Datagram_Transport_Layer_Security
(6) https://upcommons.upc.edu/bitstream/handle/2117/98113/TJCF1de1.pdf
(8) https://w3c.github.io/webrtc-ice/
(9) https://www.monpetitforfait.com/vpn/aides/fuite-webrtc
(10) https://en.wikipedia.org/wiki/Traversal_Using_Relays_around_NAT
(11) https://www.rfc-editor.org/rfc/rfc7376.html#page-4
(12) https://www.zataz.com/fuite-de-donnees-pour-vpn-votre-ip-cachee-pas-cachee/
(13) https://link.springer.com/chapter/10.1007%2F978-3-030-01704-0_19
(14) https://www.mdpi.com/1999-5903/12/5/92/pdf
(15) https://vulners.com/hackerone/H1:843256
(17) https://www.rtcsec.com/article/slack-webrtc-turn-compromise-and-bug-bounty/
(18) https://fr.wikipedia.org/wiki/Chiffrement_de_bout_en_bout
(20) https://www.al-enterprise.com/fr-fr/rainbow/telecharger-app
(21) https://www.ssi.gouv.fr/entreprise/certification_cspn/tixeoserver-version-11-5-2-0/