本日,我々は新たなセキュリティカメラの脆弱性の発見と責任ある開示を発表した.これは,Nozomi Networks IoT セキュリティに関する一連の研究発見の最新版である.
この特定の脆弱性は,ThroughTekという会社のソフトウェア・コンポーネントに影響する.このコンポーネントは,コンシューマーグレードのセキュリティカメラやIoT デバイスを製造する多くの OEM(相手先商標製品製造会社)のサプライチェーンの一部となっている.ThroughTek社は,同社のソリューションは数百万台の接続されたデバイスで使用されているとしている1.
ThroughTekのP2Pソフトウェア開発キット(SDK)は,インターネット経由でオーディオ/ビデオストリームへのリモートアクセスを提供するために使用されます.P2Pは,複数のカメラベンダーによって使用されており,本日の情報公開は,お使いのCCTVソリューションにこの機能があるかどうかを確認するもう一つの理由です.
脆弱なカメラを使用するリスクは,機密のオーディオ/ビデオ・カメラ・フィードへの不正アクセスです.重要なインフラ事業者にとっては,ビジネス,生産,従業員の機密情報が漏れる可能性があります.
この記事では,ThroughTekの脆弱性,セキュリティ・カメラ・システムのリスクを評価することの難しさ,そして将来的にソフトウェアのセキュリティが向上すると楽観視している理由について説明する.
IoT セキュリティカメラ用P2P機能
新しい発見を掘り下げる前に,ReolinkセキュリティカメラのP2P実装に関する以前の発見を思い出してみよう.セキュリティ・カメラの文脈でP2Pといえば, クライアントがインターネットを通じてオーディオ/ビデオ・ストリームにアクセスできる機能を指す .
Reolinkのブログでは,典型的なP2Pアーキテクチャの以下の3つの構成要素について説明し,示している:
- NVRは,セキュリティカメラに接続され,オーディオ/ビデオストリームを生成するローカルP2Pサーバーを表す.
- カメラ・ベンダーまたはP2P SDKベンダーが管理するオフサイトのP2Pサーバー.このサーバーが仲介役となり,クライアントとNVRが互いに接続を確立できるようにします.
- インターネットからオーディオ/ビデオストリームにアクセスする,モバイルまたはデスクトップアプリケーションのソフトウェアクライアント.
Reolinkは独自のP2P機能を開発しているが,多くの防犯カメラメーカーやIoT デバイスメーカーは,ThroughTekのようなサードパーティプロバイダーからP2P機能を調達している.しかし,P2P SDKの特殊性は,OEMが単にP2Pソフトウェア・ライブラリのライセンス供与を受けているわけではないことだ.クライアントとサーバーを認証し,オーディオ/ビデオストリームを処理するためのインフラサービス(オフサイトのP2Pサーバー)も提供している.
ThroughTek社のウェブサイトには,同社の技術がIPカメラ,ベビー・ペット監視カメラ,ロボット・バッテリー機器を製造するOEMメーカーによって使用されていることが示されている1.
このことを念頭に置いて,ThroughTekの脆弱性の詳細を見てみよう.
ThroughTek P2P SDKの脆弱性の発見
Nozomi Networks 私たちのラボ環境には,PLCからIoT ,医療機器に至るまで,継続的に機器が入ってきます.新しいデバイスを受け取ると,最初に行う作業の1つは,そのネットワークトラフィックを分析することです.
私たちのラボは最近NVRを受け取り,私たちのチームはすぐにそれがP2P機能を持っていることを突き止めました.そして,P2Pを通じてNVRに接続するWindowsクライアントによって生成されたネットワークトラフィックを分析しました.その結果,ThroughTekのP2Pプラットフォームのクライアントがアクセスするドメイン名であるiotcplatform.comに接続するパケットがいくつかあることに気づきました.

その後,クライアントの実装を調査し始め,すぐにP2Pライブラリの異なるセットが組み込まれていることに気づきました.ソフトウェア・クライアントは基本的にホワイトラベル製品であり,このため,複数のP2Pベンダーとの完全な相互運用性を提供する必要がある.

適切な場所にブレークポイントをいくつか設定した後,ネットワークのパケットペイロードが難読化されている興味深いコードを特定することに成功した.その後,コードを解析して,どのタイプのコマンドが含まれているかを理解した.
私たちは「難読化」という言葉を,このプロトコルが安全な鍵交換を欠き,代わりに固定鍵に基づく難読化スキームに依存していることを示すために使っている.

ReolinkとThroughTekの脆弱性がもたらす結果は似ている.このトラフィックはインターネットを横断するため,アクセスできる攻撃者はオーディオ/ビデオストリームを再構築することができる.
以下は私たちが開発した概念実証スクリプトで,ネットワークトラフィックからオンザフライでパケットの難読化を解除する.XYEUで始まる文字列は,P2Pネットワーク内でデバイスを一意に識別するUIDである.

我々は2021年3月にこの脆弱性を責任を持って公表し,ThroughTekは速やかにこの問題を認めました.同社はまた,顧客への通知を進め,"DTLS ECDSA-PSKに基づく暗号化レイヤー "を追加することで脆弱性を修正することを約束した.このSDKの脆弱性に対処したThroughTekのウェブページでは,顧客にセキュリティ機能を有効にするか,最新バージョンにアップグレードするよう勧告している.
最終的にICSA-21-166-01がこの脆弱性を追跡するために割り当てられ,CVSS v3の基本スコアは9.1(AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N)でした.
この脆弱性のリスク評価は難しい
ThroughTekのP2Pライブラリは,長年にわたって複数のベンダーによって様々なデバイスに統合されてきたため,第三者が影響を受けた製品を追跡することは事実上不可能である.この種の脆弱性が悪用可能な脅威モデルが,実際の影響を制限する要因となっている.
要するに,シナリオによってはP2Pサードパーティサーバープロバイダーを含め,NVRとエンドユーザー間のネットワークトラフィックにアクセスできるアクターは誰でも,機密のオーディオ/ビデオストリームにアクセスし,閲覧することができる.
P2Pプロトコルを実装するDLLには,IOTC_Get_Versionというエクスポートがあり,その名の通り,内部のバージョン番号を返す.下のスクリーンショットでは,バージョン番号3.1.4.35が示されている.この特定のバージョンはかなり古く,他のP2P実装でも見られるハードコードされたキーを使用している.

さらに調査を進めるうちに,難読化スキームやパラメーターのセットが異なる,より新しいバージョンのライブラリに出くわした.新しいバージョンのプロトコルを実行しているデバイスを見つけることは,脆弱性を見つけることよりも大きな課題であることが判明したため,これらのライブラリの動的解析を実行することはできなかった.
まとめると,ThroughTekは自社のソフトウェアは数百万台の機器で使用されており,P2P機能はベンダー間で普及していると述べているが,特定の防犯カメラのリスクを評価することは難しい.
P2Pによる防犯カメラの評価も難しい
一般的に,購入者が様々なセキュリティカメラの技術的な詳細を見ても,P2Pプロバイダーを特定したり,プロトコルの適切な説明を見つけることはできません.私たちの経験では,この情報を得るための最善かつ唯一の方法は,クライアント/サーバーの実装を直接見ることです.残念なことに,ほとんどのバイヤーはこのようなスキルを持ち合わせていません.
したがって,撮影されたオーディオ/ビデオコンテンツがインターネット経由で見知らぬ人に閲覧されるのを防ぐ最善の方法は,P2P機能を無効にすることです.
P2Pを有効にするのは,ベンダーが,その製品で使われているアルゴリズムがなぜ安全なのかについて,徹底的な技術的説明を提供できるまれな状況においてのみとすることを,私たちは推奨する.
さらに考慮すべき点としては,カメラ・ベンダーと,そのベンダーが所在する司法管轄区の両方のセキュリティおよびプライバシー・ポリシーを評価することが挙げられる.
言い換えれば,徹底的な技術的デューデリジェンスを行い,ベンダーのセキュリティとプライバシーの慣行に安心感がない限り,インターネット経由でカメラのフィードを見るチャンスを得ることはない.
より安全なソフトウェア・サプライチェーンへの希望
ソーラーウィンズ後の世界では,ソフトウェアのサプライチェーンリスクに対する認識レベルが高まっている.世界最大の買い手の1つである米国連邦政府は,間もなくサプライヤーに対し,購入するソリューションのソフトウェア部品表(SBOM)を提供することを義務付ける.この要件は,より多くの商業的購入者にも導入されつつあり,時間の経過とともに,すべてのソフトウェアのセキュリティ・レベルを引き上げることになる.
その間に,特に重要なインフラ組織がセキュリティカメラを購入する際には,セキュリティとベンダーの評価を慎重に受ける必要がある.
ThroughTek の脆弱性に対する具体的な緩和策および推奨される制御システムのセキュリティのベストプラクティスについては,ICS-CERT Advisory を参照してください.
参考文献