地平線に迫る嵐:AJCloud IoTエコシステムの内部

はじめに

Wi-Fiカメラは、家庭、企業、その他の公共スペースで見られる最も一般的なIoTデバイスの一部です。それらは非常に手頃な価格である傾向があり、ユーザーは地球上のどこからでもモバイルデバイスでライブビデオストリームに簡単にアクセスできます。 IoTデバイスではよくあることですが、これらのカメラではセキュリティが見落とされがちで、重大な脆弱性にさらされています。これらの脆弱性が悪用されると、カメラとカメラが展開されているネットワークに壊滅的な影響を与える可能性があります。これらは、ユーザーの機密性の高いPIIの侵害につながる可能性があります。

先日開催された Elastic ON Week では、これらのタイプのデバイスの攻撃対象領域を調査し、デバイスがどのように侵害されているかをより深く理解する機会を得ました。私たちは主に、Amazonで販売されている最も人気があり手頃な価格のカメラの1つである Wansview Q5 (およびほぼ同じ Q6)の脆弱性調査の実施に焦点を当てました。 Wansviewは、中国の深センに拠点を置くセキュリティ製品のプロバイダーであり、AmazonのWi-Fiカメラの最も有名なディストリビューターの1つです。

Q5は、ほとんどのカメラに見られるのと同じ基本機能セットを提供します。

パン/チルト/ズーム
暗視
双方向オーディオ
SDカードへの動画撮影
スマートホームAIアシスタントとの統合(例: アレクサ)
ONVIF による他のセキュリティ製品との相互運用性
LAN内のビデオフィードに直接アクセスするためのRTSP
クラウドからの自動ファームウェア更新
リモートテクニカルサポート
他のアカウントとの共有デバイスアクセス
クラウドストレージとモーション検出のオプションの月額サブスクリプション

他のほとんどのWi-Fiカメラと同様に、これらのモデルは基本的な操作のためにベンダーのクラウドインフラストラクチャへのアクティブな接続を必要とします。インターネットへのアクセスがなければ、彼らは単に動作しません。カメラを稼働させるには、Wansview の公式モバイルアプリと標準の QR コードベースのセットアッププロセスを使用して、カメラを登録済みのユーザーアカウントとペアリングする必要があります。このプロセスが完了すると、カメラは完全にオンラインになり、動作可能になります。

AJCloud:簡単な紹介

Wansviewは 2009年から運営されていますが、現時点では主に、中国の南京に拠点を置く別の会社である AJCloudが製造したカメラ製品の再販業者のようです。

AJCloudは、ベンダーに製造されたセキュリティデバイス、必要なファームウェア、モバイルおよびデスクトップユーザーアプリケーション、クラウド管理プラットフォーム、およびすべてを接続するサービスへのアクセスを提供します。 AJCloudは2018年に設立されて以来、大小さまざまなベンダーと提携してきました。

AJCloudが Google Play、 AppleのApp Store、 Microsoft Store で開発および公開したモバイルおよびデスクトップアプリケーションをざっとレビューすると、これらの各ベンダーとの関係が明らかになります。表面的な企業ブランディングを除けば、これらのアプリケーションは形式と機能が同一であり、すべてAJCloud管理プラットフォームとの接続が必要です。

カメラに関しては、これらのベンダーがカメラのハウジングと基礎となるハードウェアにわずかな変更を加えただけで同様のモデルを販売していることは明らかです。

Faleemi 886とWansview Q6(1080p)の類似性は明らかです

ハードウェア製造とソフトウェア開発のリソースを再利用することで、AJCloudとその再販業者のコストを管理し、ロジスティクスを簡素化するのに役立つ可能性があります。しかし、この資産の合理化は、1つのカメラモデルで発見されたセキュリティの脆弱性が、AJCloudに関連するすべての製品に浸透する可能性が高いことも意味します。

これらのデバイスを消費者に提供する上で重要な役割を果たしているにもかかわらず、AJCloudの知名度は比較的低くなっています。しかし、IPVMの研究者は最近、AJCloudのGitLabリポジトリに重大な脆弱性に関する研究を発表しました (その後解決されました)。この脆弱性により、すべてのユーザーが認証を必要とせずに、ソースコード、資格情報、証明書、およびその他の機密データにアクセスできるようになります。

WansviewやWi-Fiカメラ業界の他のベンダーの総売上高を導き出すのは難しいですが、IPVMは、レポートの公開時点で少なくとも100万台のデバイスがAJCloudプラットフォームに接続されていると推定しています。カメラの売上が数億台に急増し続ける中、今後数年間、AJCloudのデバイスの多くは世界中の家庭で接続されると考えて間違いありません。

初期の脆弱性調査の取り組み

Wansview Q5のセキュリティ体制をより深く理解するために、さまざまな角度から攻撃しました。

当初、私たちの取り組みは主に、カメラとWansviewの公式モバイルアプリであるWansview Cloudの Androidバージョンのアクティブおよびパッシブネットワーク偵察に焦点を当てていました。開いているポートをスキャンしたり、MitM(Man-in-the-Middle)攻撃でネットワーク通信を盗聴したり、アプリの意図的な設定ミスでカメラから予測不可能な動作を強制しようとしたり、QRコード形式を悪用してカメラと物理的に対話したりしてカメラの動作を妨害しました。デバイスとそのインフラストラクチャは、この種の表面攻撃に対して驚くほど回復力があり、最初の取り組みでは目立った成功はほとんど得られませんでした。

特に驚いたのは、カメラとアプリの両方でネットワーク通信を傍受できなかったことです。堅牢なセキュリティ機能(証明書のピン留め、アプリとOSのバージョン制限、適切に保護されたTLS接続など)に繰り返し遭遇し、試みが中断されました。

リバースエンジニアリングツールにより、APKをより詳細に分析することができましたが、逆コンパイルされたJavaソースコード内で観察されるコードの難読化の複雑さにより、完全につなぎ合わせるには長い時間が必要でした。

当初の成功が限定的であったため、Q5とその運用方法についてより微妙な洞察を得るためのさらなる選択肢を模索する必要があります。

初期のハードウェアハッキング

カメラがどのように機能したかをより深く理解するために、カメラのファームウェアを詳しく調べることにしました。一部のファームウェアパッケージはオンラインで入手できますが、コードを直接確認し、カメラの実行中にコードと結果のログを監視できるようにしたいと考えました。そのために、まずシステム・オン・チップ(SoC)のハードウェア図を見て、活用できるハードウェア手段があるかどうかを確認しました。 Wansview Q5は Ingenic Xburst T31 SoCを使用しており、そのシステムブロック図を以下に示します。

その中でも特に印象に残ったのが、I2Cx3/UARTx2/SPIx2 SPI I/Oブロックです。アクセス可能な場合、これらのI/Oブロックは、多くの場合、デバッグやSoCとの対話に使用できるログ出力インターフェイスやシェルインターフェイスを提供します。有望に見えたため、カメラのハードウェア分解を行い、以下に示すように、SoCへのUARTシリアルインターフェースと思われるものを見つけました。

次に、ロジックアナライザを接続して、これらのピンでどのプロトコルが使用されているかを確認し、デコードすると、信号は確かにUARTでした。

公開されたUARTインターフェースにアクセスできるようになったので、次にUARTを介してSoCへのシェル接続を確立することを検討しました。これを行うにはさまざまなソフトウェアメカニズムがありますが、ここでは、ロジックアナライザから検出されたボーレートでUnixユーティリティ screen を使用しました。

ブートシーケンスを開いて監視すると、SoC でサポートされているにもかかわらず、セキュアブートが有効になっていないことがわかりました。次に、以下に示すように、初期化プロセスが実行される前にファームウェアを調べるために使用するルートシェルを提供して、シングルユーザーモードで起動するように設定を変更しました。

シングルユーザーモードになると、以下に示すように、 binwalk ユーティリティを使用して静的分析用のファームウェアファイルをプルできました。

この段階では、ファイルシステムは通常読み取り専用です。ただし、必要に応じてファームウェアの初期化の特定の部分のみを編集し、インスタンス化できるようにしたかったため、シングルユーザーモードのアクセスを超えて追加の永続性を確保するために、いくつかのクイックセットアップを行いました。これにはいくつかの方法がありますが、主に 2 つの方法があります。一般的に言えば、どちらのアプローチでも、既存の構成に対する変更はできるだけ少なくする必要があります。これは、実行時環境への影響が最も少ないため、可能であれば動的解析を実行する場合に一般的に推奨されます。このアプローチに使用した方法の 1 つは、メモリ内に読み取り/書き込みアクセス用の tmpfs パーティションを作成し、それを fstab経由でマウントすることです。私たちの場合、 fstab はこれを裏付けるような方法ですでに考えられていたため、非常に最小限の変更で済みました。このアプローチのコマンドと結果を以下で参照してください。

別の方法は、既存のユーザー資格情報を取得し、それらを使用してログインを試みることです。このアプローチも成功しました。 rootユーザーのパスワードハッシュは etc/passwd ファイルにあり、John the Ripperなどのツールを使用して復号化できます。上記の例では、データとファイルを完全にシリアル接続で転送していました。また、SDカードスロットも用意されており、取り付けてファイルの転送に使用することができます。今後は、帯域幅が転送をより速く、より簡単にするため、ファイルの移動にはSDカードまたはローカルネットワークを使用します。ただし、必要に応じて、ハードウェアのセットアップとデバッグのすべての通信にシリアルを引き続き使用できます。

これで、カメラへのルートレベルのアクセス権があり、ソフトウェアの実行中にファームウェアとdmesgログにアクセスできるようになりました。次に、ファームウェアとログの両方を参照として、カメラのユーザーインターフェースをさらに調査し、さらなる洞察を得るために使用できる適切なエントリポイントがあるかどうかを確認しました。

Windows用のWansview Cloud

モバイルアプリが当初の予想よりも安全であることが証明された後、Windows 7用に構築された古いバージョンのWansview Cloudアプリケーションに焦点を移しました。このアプリはまだダウンロード可能で、AJCloudプラットフォームに接続されたカメラに関連するネットワーク通信についての直接的な洞察を提供します。

開発者に代わって過度に甘やかされたデバッグログのおかげで、Windowsアプリは、商用ソフトウェアではめったに見られない無謀な放棄でその秘密をこぼします。問題の最初の兆候は、ユーザーのログイン資格情報がクリアテキストで記録されていることです。

メインの実行可能ファイルとDLL(Wansview Cloud APKとは異なり、パックされていない)のリバースエンジニアリングは、一意の文字列を含む詳細なログメッセージを頻繁に使用するおかげで迅速化されました。基盤となるコードベース内の特定のファイルや行への参照を特定することで、アプリケーションのコアコンポーネントを迅速にマッピングし、高レベルの制御フローを確立することができました。

Androidでは傍受が難しかったネットワーク通信は、クリアテキストでディスクに記録されるのに便利ですが、依然としてTLSを介して送信されています。すべてのHTTP POSTリクエストとレスポンスデータ(JSONオブジェクトにパックされている)へのフルアクセスにより、アプリケーション側でMitM攻撃を追求する必要がなくなりました。

POSTの応答には、公開されている画面キャプチャへのリンクや、カメラの位置、ネットワーク構成、ファームウェアバージョンに関する情報など、機密性の高いメタデータが見つかりました。

ログデータ内で見つかったすべてのPOSTリクエストとレスポンスを文書化した後、カメラやアカウントに関連付けられていないデータにアクセスするために、各リクエストで異なるフィールドを操作する実験を開始しました。最終的には、デバッガーを使用して、deviceId を現在ログインしているアカウントとペアリングされていないターゲットカメラの deviceId に変更します。カメラの deviceId はシリアル番号を兼ねており、カメラの背面または底面にあるステッカーラベルに印刷されています。

この攻撃に最も適したターゲットは、deviceId が https://sdc-us.ajcloud.net/api/v1/dev-config への POST リクエストで最初に送信されるコードセクションで見つけました。

私たちの計画は、上のスクリーンショットで強調表示されている命令にブレークポイントを設定し、メモリ内のdeviceIdを入れ替えてから、アプリの実行を再開できるようにすることでした。

驚くべきことに、この素朴なアプローチは、ターゲットカメラとそれが関連付けられているアカウントに関連付けられたAJCloudプラットフォームに保存されている機密データを取得するだけでなく、カメラ自体にも接続するのに機能しました。これにより、ビデオとオーディオのストリームにアクセスし、自分のカメラのようにアプリを介してリモートで制御できるようになりました。

この脆弱性を悪用し、さまざまなベンダーの複数のモデルに対してテストを行った結果、AJCloudプラットフォームに接続されているすべてのデバイスにリモートアクセスし、この方法で制御できると判断しました。このプロセスを自動化し、AJCloudのインフラストラクチャ内のこのアクセス制御の脆弱性を簡単に悪用できることを効果的に示すために、PoCエクスプロイトスクリプトを作成しました。

ネットワーク通信の探索

AJCloudプラットフォームの重大な脆弱性に対するエクスプロイトを構築し、確実にトリガーすることはできましたが、アプリ、カメラファームウェア、およびクラウドインフラストラクチャの内部動作をより深く理解するためには、さらに掘り下げる必要がありました。

サインインプロセス全体で観察されたPOSTリクエストとレスポンスを超えて調査すると、さまざまなIPからのUDPリクエストとレスポンスが大量にあることに気づきました。これらの通信では、識別可能なプレーンテキストデータはほとんど見つからず、アウトバウンドリクエストのターゲットUDPポート番号は異なるように見えました。その後、さらなる調査により、このUDPアクティビティは、 DEF CON 28でのPaul Marrapesse氏のプレゼンテーションで広範囲に分析および実証されたIoTピアツーピア(P2P)プロトコルであるPPPPを示していることが明らかになりました。後に、私たちが発見した脆弱性を悪用した方法は、修正されたP2Pリクエストによって促進されたと結論付け、それがAJCloudプラットフォームでP2Pが果たす重要な役割をさらに調査することにつながりました。

P2Pの主な目的は、関連するネットワーク構成に関係なく、アプリケーションとIoTデバイス間の通信を容易にすることです。 P2Pは、主に UDPホールパンチングに基づくアプローチを利用して、リクエストが直接またはよりアクセスしやすいネットワーク環境にあるリレーサーバーを介してターゲットに到達できるようにする一時的な通信経路を作成します。 AJCloudのアプリに統合されたP2Pコマンドのコアセットは、ビデオとオーディオストリームへのアクセス、マイクとパン/チルト/ズームを提供します。

高度なハードウェアハッキング

P2P通信についての理解が深まったので、これらのP2P会話中に、デバッガでのカメラソフトウェアの実行など、カメラ自体をより詳しく調べる時が来ました。まず、以下に示すように、前に確立したUARTシリアル接続を介したライブロギング出力を使用してカメラを設定します。

これにより、アプリケーションからのログメッセージと、必要な追加のログソースをライブで確認することができました。この情報から、カメラとクラウド間の通信を確立するために使用されるプライマリバイナリと、P2P経由でカメラにアクセスするためのインターフェースを提供するために使用されるプライマリバイナリを特定しました。

このバイナリはローカルでinitAppと呼ばれ、カメラが完全に初期化され、ブートシーケンスが完了すると実行されます。これを考慮して、このバイナリをデバッガーで実行して、ローカル関数をより適切に評価することにしました。これを試みたところ、initAppが実行されていないことを検出し、問題を検出した場合はカメラを強制的に再起動するカーネルウォッチドッグに遭遇しました。このウォッチドッグは、 /dev/watchdog への書き込みをチェックし、これらの書き込みが停止すると、書き込みが再開されない場合はカメラを再起動するタイマーをトリガーします。これにより、initAppの実行を一時停止すると、watchdogへの書き込みも一時停止するため、デバッグがより困難になります。この停止動作の例を次に示します。

これを回避するには、initAppが停止するたびにウォッチドッグに書き込んでみて、再起動を防ぐこともできます。ただし、別のよりクリーンなオプションは、 LinuxカーネルウォッチドッグドライバーAPIのマジッククローズ機能を利用することです。要するに、特定の魔法の文字「V」と書くと、ウォッチドッグは無効 /dev/watchdog 。ウォッチドッグを倒す方法は他にもありますが、これはウォッチドッグを自由に有効または無効にするのが簡単なため、研究のために選択した方法です。

ウォッチドッグが無効になっているため、initAppをデバッグするための設定は非常に簡単です。可能であれば、エミュレータを使用するのではなく、カメラ上で直接コードを実行したいと考えました。カメラのアーキテクチャはリトルエンディアンMIPS(MIPSEL)です。幸いにも、ビルド済みの GDB と GDBServer のバイナリは、変更なしで機能することができました。しかし、最初はこのことを知らなかったので、カメラ専用のGDBServerをコンパイルするためのツールチェーンも設定しました。同様の状況に陥った場合に役立つ可能性のある手法の 1 つは、gcc などのコンパイルツールを使用して、疑わしいターゲットアーキテクチャにソースコードをコンパイルし、それが実行されるかどうかを確認することです。以下の例を参照してください。

私たちの場合、SoCは私たちに知られていたので、ターゲットアーキテクチャはかなり確信していました。ただし、特定の状況では、これを見つけるのはそれほど簡単ではない可能性があり、Hello Worldバイナリから作業することは、最初の理解を確立するのに役立ちます。バイナリをコンパイルできたら、カメラ用にGDBServerをコンパイルし、それを使用してinitAppをアタッチして起動しました。次に、カメラと同じローカルネットワーク上の別のコンピューターから接続しました。この例を以下に示します。

上記の例の注意点として、便宜上、 -x パラメータを使用して一部のコマンドを渡していますが、デバッグには必要ありません。ファイルやコマンドの詳細については、 elastic/camera-hacks GitHubリポジトリをご覧ください。 initApp を適切にロードするためには、バイナリで使用されるライブラリが PATH 環境変数と LD_LIBARY_PATH 環境変数を介してアクセス可能であることも確認する必要がありました。この設定により、必要に応じてバイナリをデバッグすることができました。以前にウォッチドッグを倒す魔法のキャラクターの方法も使用したため、ウォッチドッグを再度有効にできるインスタンスを制御する必要もあります。ほとんどの場合、このようなことは望ましくありません。そのため、次に示すように、デバッグ中にウォッチドッグが再度有効にならないように、initAppのウォッチドッグ呼び出しを上書きしました。

次のビデオは、GDBServer の起動から実行までの完全なセットアッププロセスを示しています。このビデオでは、新しい initApp プロセスも開始するため、元のプロセスと、強制終了された場合に新しい initApp プロセスを生成する daemon.sh シェルスクリプトの両方を強制終了する必要があります。

P2Pクライアントの構築

P2PがAJCloud IoTデバイスに提供する機能の全容と、それらが攻撃者によってどのように悪用される可能性があるかをさらに調査するために、独自のスタンドアロンクライアントの構築に着手しました。このアプローチにより、Wansview Cloud Windowsアプリを操作するオーバーヘッドがなくなり、カメラにすばやく接続して、ファームウェアのリバースエンジニアリングから派生したコマンドをテストできるようになります。

以前に Windows アプリのログから取得した構成データから、クライアントが接続プロセスの一部として最大 3 つの異なるサーバーに要求を発行することがわかりました。これらのサーバーは、特定のカメラにアクセスするためにトラフィックをどこにルーティングする必要があるかについて、クライアントに指示を提供します。これらのサーバーをオープンにさらに検出したい場合は、ポート 60722で次の 4 バイトの UDP ペイロードを使用してインターネットをスキャンできます。ポール・マラペーゼは、この手法を彼の研究の一部として大きな効果を発揮しました。

P2P 接続を適切に確立するには、クライアントはまず単純な hello メッセージ (MSG_HELLO) を送信する必要があります。これは、ピアツーピアサーバーによって ACK'd (MSG_HELLO_ACK) される必要があります。次に、クライアントはサーバー (MSG_P2P_REQ) に対して特定の deviceId を照会します。サーバーがそのデバイスを認識している場合、ターゲット IP アドレスと UDP ポート番号のペアを使用してクライアントに応答 (MSG_PUNCH_TO) します。その後、クライアントは、MSG_PUNCH_PKT UDP ホールパンチングルーチンの一部として、あらかじめ決められた範囲内の他のポートと共に、IP とポートのペアに接続 () を試みます。成功した場合、ターゲットは、接続が確立されたことを確認するための最終メッセージ(MSG_P2P_RDY)とともにメッセージ(MSG_PUNCH_PKT)をクライアントに送り返します。

カメラに接続した後、主にさまざまな MSG_DRW パケットを送信し、その動作を観察することに関心があります。これらのパケットには、カメラを物理的に操作したり、ビデオストリームとオーディオストリームを表示して聴いたり、カメラに保存されているデータにアクセスしたり、カメラの構成を変更したりするためのコマンドが含まれています。私たちが始めた最も簡単なコマンドは、カメラを反時計回りにパンすることで、これは 1 つのメッセージ送信として簡単に識別できました。

カメラ上のデバッグログメッセージにより、このコマンドがファームウェア内のどこで処理されたかを簡単に特定できました。

この特定のメッセージのソースを特定すると、MSG_DRWメッセージの処理を処理するメインルーチンに配置され、このコマンドがどのように呼び出されるか、ファームウェアでサポートされている他のコマンドについて重要な洞察を得ることができました。

広範なリバースエンジニアリングとテストにより、ユーザーがdeviceIdにアクセスできる場合、AJCloudプラットフォーム上の任意のカメラに接続できる PoC P2Pクライアントを構築することができました。クライアントでサポートされている基本的なコマンドには、カメラのパンとチルト、再起動、リセット、オーディオクリップの再生、さらにはファームウェアのクラッシュが含まれます。

実装できた最も危険な機能は、コアデバイスの設定ファイルを変更するコマンド /var/syscfg/config_default/app_ajy_sn.iniでした。テストカメラでは、ファイルの内容はもともと次のとおりでした。

[common]
product_name=Q5
model=NAV
vendor=WVC
serialnum=WVCD7HUJWJNXEKXF
macaddress=
wifimacaddress=

これには基本的なデバイスメタデータが含まれているように見えますが、このファイルはカメラが自身を識別する方法を知る唯一の手段です。起動時に、カメラはこのファイルの内容を読み取り、さまざまなAPIエンドポイントへの一連のcurlリクエストを通じてAJCloudプラットフォームへの接続を試みます。これらの curl リクエストは、INI ファイルから抽出された製品名、カメラモデル、ベンダーコード、およびシリアル番号の値をクエリ文字列引数として渡します。クライアントを使用して、次のように内容を上書きするメッセージを配信しました。

[common]
product_name=
model=OPQRSTUVWXYZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~HH01
vendor=YZ[\]^_`abcdefghijklmnopqrstuvwxyz{|}~HH01
serialnum=defghijklmnopqrstuvwxyz{|}~HH01
macaddress=
wifimacaddress=

カメラをリセットすると、スタートアップルーチンの一部としてAJCloudプラットフォームAPIエンドポイントに発行されたすべてのcurlリクエストは、INIファイルに含まれる不正なデータが原因で失敗します。これらのリクエストは引き続き定期的に送信されますが、成功することはなく、カメラは非アクティブのままで、どのアプリからでもアクセスできなくなります。残念ながら、カメラのリセット、ファームウェアの更新、または工場出荷時の設定の復元を通じて、以前のファイルの内容を復元する簡単な方法はありません。このコマンドを介して実行されるファイルの変更により、カメラは効果的にブリックされ、役に立たなくなります。

app_ajy_sn.iniに格納された値を上書きする逆コンパイル関数(syscfg_setAjySnParams)を詳しく見ると、MSG_DRWコマンドから抽出された入力パラメータを使用して、ファイル内のモデル、ベンダー、およびシリアル番号フィールドを上書きするために使用される文字列データを渡すことがわかります。memset は、これらの入力文字列を格納するための 3 つのグローバル変数を null バイトで上書きするために使用されます。その後、strcpy を使用して、入力パラメーターをこれらのグローバルに転送します。いずれの場合も、これにより、null 文字が検出されるまで、 MSG_DRW コマンドバッファーからバイトが直接コピーされます。

コマンドから抽出されたこれらの入力パラメータの長さには検証が強制されないため、バッファオーバーフローをトリガーするのに十分な長さのメッセージを作成するのは簡単です。この脆弱性を攻撃の一部としてカメラをブリックするために利用したわけではありませんが、これは、攻撃者がカメラ上でリモートコード実行を実現できるエクスプロイトが開発される可能性がある例のようです。

インパクト

これらの脆弱性や欠陥は、AJCloudと提携している複数のベンダーや複数の異なるファームウェアバージョンの幅広いデバイスが影響を受けることを確認しています。全体として、Wansview、Galayou、Cinnado、Faleemi の 15 種類のカメラ製品に対する攻撃のデモンストレーションに成功しました。私たちの調査結果に基づくと、AJCloudファームウェアを操作し、AJCloudプラットフォームに接続するすべてのデバイスが影響を受けると想定しても安全です。

これらの脆弱性と欠陥を開示するために、AJCloudとWansviewの両方に連絡を取ろうとしたすべての試みは失敗に終わりました。

ベンダーは何を正解しましたか?

以前に発見し、議論した脆弱性にもかかわらず、AJCloudとカメラベンダーがうまく実装したセキュリティ制御がいくつかあります。このような低コストのデバイスには、多くのベストプラクティスが実装されました。まず、ネットワーク通信は、証明書ベースのWebSocket認証を使用して適切に保護されます。暗号化を追加するだけでなく、多くのAPIエンドポイントを証明書認証の背後に配置すると、中間者攻撃が非常に困難になります。さらに、モバイルアプリのAPKは署名され、難読化されているため、これらのアプリの操作に非常に時間がかかりました。

さらに、ベンダーはカメラのハードウェアとファームウェアについてもいくつかの健全な決定を下しました。カメラのローカルOSは事実上制限されており、製品に必要な機能のみに焦点を当てています。ファイルシステムは、ロギングの外部で読み取り専用になるように構成されており、カーネルウォッチドッグは、稼働時間を確保し、障害状態に陥るリスクを軽減する効果的な方法です。 Ingenic Xburst T31 SoCは、セキュアブート、パワーオンリセット(POR)ウォッチドッグ、カメラ入力で基本的な機械学習を実行できる独立したRISC-Vプロセッサなど、幅広いサポートを備えた有能なプラットフォームを提供します。

ベンダーは何を間違えたのでしょうか?

残念ながら、これらの利用可能な機能では多くの機会を逃しました。最も悪質なのは、認証されていないクラウドアクセスです。多くのエンドポイントに対してAPIアクセス制御が確立されていることを考えると、カメラユーザーが認証なしでシリアル番号を介してエンドポイントにアクセスできるようにすることは、非常に大きな失敗であり、回避可能な問題です。 P2Pプロトコルも、先ほど紹介したように脆弱ですが、すぐに修正できるはずのAPIアクセスと比較すると、プロトコルの修正にはさらに時間がかかる可能性があります。これは非常に危険な脆弱性ですが、発見と修正の両方にかなりの時間投資が必要なため、少し理解しやすくなっています。

アプリケーション側から見ると、主な問題は、一般公開する前に削除されるべきだった広範なデバッグログを持つWindowsアプリにあります。ハードウェアに関しては、物理的なアクセス(露出したリセットボタンなど)で簡単に操作できます。これは、ターゲットとする消費者層を考えると、それほど問題ではありません。セキュリティよりもユーザビリティの面で誤りを犯すことが予想され、特にデバイスへの物理的なアクセスを考えると、その傾向が強くなります。同様に、セキュアブートは、特にT31 SoCがサポートしていることを考えると、有効にする必要があります。厳密には必要ではありませんが、これにより、デバイスのソースコードとファームウェアを直接デバッグするのがはるかに困難になり、存在する可能性のある脆弱性を発見することがより困難になります。理想的には、ブートローダが未署名の OS を読み込んで、いじくり回しや開発を容易にするように実装されますが、ブートローダの設定が復元されるまでは、署名された OS が読み込まれないようにします。ただし、現在のファームウェアの重大な欠陥の 1 つは、システムの実行中に読み取り専用のマウントポイントに格納されない元のシリアル番号に依存していることです。シリアル番号を操作しても、デバイスが永続的にブリックされるわけではありません。シリアル番号が上書きされた場合に新しいシリアル番号を要求する (または元のシリアル番号を復元する) メカニズムを持つか、シリアル番号を不変にする必要があります。

対策

攻撃が発生した場合に攻撃対象領域を減らし、潜在的な悪影響を制限するために、特定の措置を講じることができますが、その有効性は異なります。

Wi-Fiカメラやその他のIoTデバイスをネットワークの他の部分から切り離すことは、攻撃者がより重要なシステムに横方向にピボットするのを防ぐための強く推奨される対策です。ただし、このアプローチでは、攻撃者がAJCloudプラットフォームで発見したアクセス制御の脆弱性を悪用して、機密性の高いユーザーデータを取得するのを防ぐことはできません。また、P2Pを介してカメラにリモートでアクセスして操作する方法を簡単に示すことができたことを考えると、AJCloudプラットフォームに接続されたデバイスは、ローカルネットワーク構成に関係なく、依然として侵害の大きなリスクにさらされています。

これらのカメラとの間のすべてのネットワーク通信を制限することは、AJCloudプラットフォームへの接続がそれらの操作にどれほど重要であるかのために実行可能ではありません。前述のように、起動時にさまざまなAPIエンドポイントに接続できない場合、デバイスは単に動作しません。

実行可能なアプローチは、最初の起動ルーチンを超えて通信を制限することです。しかし、これではモバイルアプリやデスクトップアプリによるリモートアクセスや制御が妨げられ、そもそもこれらのカメラの目的全体が台無しになってしまいます。この分野でのさらなる研究については、無数のIoTデバイスやベンダーを対象にこのアプローチをより深く掘り下げた「Blocking Without Breaking: Identification and Mitigation of Non-Essential IoT Traffic」を参照してください。

ベンダーに関係なく、コア機能を維持しながらWi-Fiカメラを保護するための最善のアプローチは、 OpenIPC や thinginoなどの代替のオープンソースファームウェアでフラッシュすることです。オープンソースファームウェアに切り替えると、デバイス構成とリモートネットワークアクセスをきめ細かく制御できるため、ベンダーのクラウドプラットフォームへの強制的な接続に関連する頭痛の種を回避できます。ファームウェアソースへのオープンアクセスは、重大な欠陥や脆弱性を迅速に特定し、熱心なプロジェクト貢献者によってパッチを適用するのに役立ちます。

この記事のポイント

私たちの調査では、プラットフォームに接続されているAJCloudファームウェアを操作するカメラのすべての側面にまたがるいくつかの重大な脆弱性が明らかになりました。同社のプラットフォームとPPPPピアプロトコルのアクセス制御管理に重大な欠陥があるため、世界中の何百万ものアクティブデバイスに影響を与える広範な攻撃対象領域が提供されています。これらの欠陥や脆弱性を悪用すると、機密性の高いユーザーデータが公開され、攻撃者はAJCloudプラットフォームに接続されているカメラを完全にリモート制御できます。さらに、主要な設定ファイルへの任意の書き込みアクセスを意図的に提供する組み込みのP2Pコマンドを利用して、カメラを永久に無効にしたり、バッファオーバーフローをトリガーしてリモートコードの実行を容易にすることができます。

GitHubリポジトリにアクセスして、セキュリティ研究コミュニティに最も利益をもたらすと思われるデータやメモとともに作成したカスタムツールとスクリプトをご覧ください。

地平線上の嵐:AJCloud IoTエコシステムの内部