序章
FireEye の Mandiant Red チームは最近、Logitech Harmony Hub Internet of Things (IoT) デバイスに存在する脆弱性を発見しました。この脆弱性は悪用される可能性があり、SSH 経由でデバイスへのルート アクセスが可能になります。 Harmony Hub は、ユーザーの家のさまざまなデバイスに接続して制御するように設計されたホーム コントロール システムです。ローカル ネットワークからこれらの脆弱性を悪用すると、攻撃者がハブにリンクされたデバイスを制御したり、ハブを実行スペースとして使用してローカル ネットワーク上の他のデバイスを攻撃したりする可能性があります。 Harmony Hub デバイス リストには、スマート ロック、スマート サーモスタット、その他のスマート ホーム デバイスなどのデバイスのサポートが含まれているため、これらの脆弱性はユーザーに非常に高いリスクをもたらします。
FireEye は 2018 年 1 月にこれらの脆弱性を Logitech に開示しました。Logitech は受容的であり、FireEye と調整して、これらの調査結果に対処するためのファームウェア アップデート (4.15.96) と併せてこのブログ投稿をリリースしました。
レッド チームは、次の脆弱性を発見しました。
- 不適切な証明書の検証
- 安全でない更新プロセス
- 製品ファームウェア イメージに残された開発者のデバッグ シンボル
- 空白のルート ユーザー パスワード
Red Team は、これらの脆弱性の組み合わせを利用して、Harmony Hub への管理アクセスを取得しました。このブログ投稿では、発見と分析のプロセスについて概説し、消費者向けデバイスの厳格なセキュリティ テストの必要性を示しています。特に、ホーム ネットワークに接続されているだけでなく、多くの詳細情報にアクセスできるデバイスに対する一般の人々の信頼が高まっているためです。ユーザーの日常生活について。
デバイス分析
デバイスの準備
公開されている調査によると、Harmony Hub の一部のテスト ポイントにユニバーサル非同期受信機/送信機 (UART) インターフェイスが存在することが示されています。ジャンパー線をテスト パッドにはんだ付けしたので、TTL から USB へのシリアル ケーブルを使用して Harmony Hub に接続できました。ブート プロセスの最初の分析では、Harmony Hub が U-Boot 1.1.4 を介して起動し、Linux カーネルを実行したことが示されました (図 1)。
ブート プロセスのこの時点以降、カーネルがコンソール インターフェイスで構成されていなかったため、コンソールは出力を返さなくなりました。 U-Boot のカーネル ブート パラメータを再構成して完全なブート プロセスを検査しましたが、有用な情報は回復されませんでした。さらに、UART インターフェイスは送信のみに設定されているため、このインターフェイスで Harmony Hub とのやり取りを行うことはできませんでした。そのため、Harmony Hub で実行されている Linux オペレーティング システムと関連ソフトウェアをよりよく理解することに焦点を移しました。
ファームウェアの回復と抽出
Harmony Hub は、初期設定のために Bluetooth 経由でコンパニオン Android または iOS アプリケーションとペアリングするように設計されています。 hostapd を使用してワイヤレス ネットワークを作成し、テスト Android デバイスに Burp Suite Pro CA 証明書をインストールして、Harmony モバイル アプリケーションからインターネットおよび Harmony Hub に送信されるトラフィックをインターセプトしました。最初のペアリングが完了すると、Harmony アプリケーションはローカル ネットワーク上で Harmony Hub を検索し、HTTP ベースの API を介して Harmony Hub と通信します。
接続されると、Harmony アプリケーションは 2 つの異なる要求を Harmony Hub の API に送信します。これにより、Harmony Hub は更新をチェックします (図 2)。
Harmony Hub は、現在のファームウェア バージョンを Logitech サーバーに送信して、アップデートが利用可能かどうかを判断します (図 3)。更新が利用可能な場合、Logicool サーバーは、新しいファームウェア バージョンの URL を含む応答を送信します (図 4)。 Harmony Hub が送信する HTTPS トラフィックを傍受するために自己署名証明書を使用しているにもかかわらず、Harmony Hub が無効な SSL 証明書を無視することを示すこのプロセスを観察することができました。
このファームウェアを取得し、ファイルを調べました。アーカイブのいくつかのレイヤーを抽出した後、ファームウェアは Harmony-image.squashfs ファイルで見つけることができます。このファイルシステム イメージは、組み込みデバイスの一般的な形式である lzma で圧縮された SquashFS ファイルシステムです。ただし、ベンダーは、最近の squashfstools ビルドと互換性のない古いバージョンの squashfstools を使用することがよくあります。私たちは、 firmware-mod-kitに含まれているunsqashfs_all.shスクリプトを使用して、正しいバージョンの unsquashfs を見つけてファイルシステム イメージを抽出するプロセスを自動化しました (図 5)。
ファイルシステムの内容を抽出して、Harmony Hub のオペレーティング システムの構成の詳細を調査しました。検査の結果、ストリップされていないカーネル モジュールなど、さまざまなデバッグの詳細が製品イメージで利用可能であることが明らかになりました (図 6)。
/etc/passwd を調査すると、root ユーザーにはパスワードが設定されていないことがわかりました (図 7)。したがって、dropbear SSH サーバーを有効にできれば、パスワードなしで SSH 経由で Harmony Hub への root アクセスを取得できます。
ファイル システムにファイル /etc/tdeenable が存在する場合、dropbear SSH サーバーのインスタンスが初期化中に有効になることがわかりました (図 8)。
ハイジャック更新プロセス
初期化プロセス中に、Harmony Hub は Logitech API のGetJson2Urisエンドポイントにクエリを実行して、さまざまなプロセスに使用する URL のリストを取得します (図 9)。これには、ファームウェアの更新を確認するときに使用する URL や、ファームウェアに関する情報を取得する URL などがあります。アップデートの追加ソフトウェア パッケージ。
サーバーからの応答に含まれる JSON オブジェクトを傍受して変更し、 GetUpdatesメンバーが独自の IP アドレスを指すようにしました (図 10 参照)。
ファームウェアの更新プロセスと同様に、Harmony Hub はGetUpdatesによって指定されたエンドポイントに POST 要求を送信し、その内部ソフトウェア パッケージの現在のバージョンが含まれます。図 11 に示す要求には、 HEOSパッケージのサンプル要求が含まれています。
POST 要求本文のsysBuildパラメーターが、サーバーが認識している現在のバージョンと一致しない場合、サーバーは、新しいパッケージ バージョンに関する情報を含む初期応答で応答します。理由は不明ですが、Harmony Hub はこの最初の応答を無視し、2 番目の要求を送信します。 2 番目の応答には、更新されたパッケージを指す複数の URL が含まれています (図 12 参照)。
応答オブジェクトにリストされている.pkgファイルをダウンロードして調査しましたが、実際には ZIP アーカイブにすぎません。図 13 に示すように、アーカイブには単純なファイル階層が含まれています。
manifest.jsonファイルには、Harmony Hub の更新プロセスにアーカイブのコンテンツの処理方法を指示するために使用される情報が含まれています (図 14)。
Harmony Hub の更新プロセスは、アーカイブ内に存在する場合、マニフェストのインストーラーパラメーターによって提供されるスクリプトを実行します。図 15 に示すように、このスクリプトを変更して/etc/tdeenableファイルを作成しました。これにより、前述のように、ブート プロセスで SSH インターフェイスが有効になります。
適切な.pkg拡張子を持つ新しい悪意のあるアーカイブを作成し、ローカル Web サーバーでホストしました。 Harmony Hub が次に変更されたGetJson2URIs応答で提供された URL に対して更新をチェックしたときに、この更新を指すように変更された応答を送信しました。 Harmony Hub は悪意のある更新パッケージを取得し、Harmony Hub を再起動した後、SSH インターフェイスが有効になりました。これにより、図 16 に示すように、ユーザー名rootと空白のパスワードでデバイスにアクセスできるようになりました。
結論
テクノロジーが私たちの日常生活にさらに組み込まれるにつれて、さまざまなデバイスに対する私たちの信頼は、知らず知らずのうちに指数関数的に増加しています。 Harmony Hub は、多くの IoT デバイスと同様に共通のプロセッサ アーキテクチャを使用しているため、侵害された Harmony Hub に悪意のあるツールが簡単に追加され、標的型攻撃の全体的な影響が増大する可能性があります。ただし、Logitech は私たちのチームと協力して、現在のファームウェア 4.15.96 で脆弱性に迅速に対処しました。私たちが信頼するデバイスの開発者は、エンド ユーザーをセキュリティ リスクにさらす可能性のある潜在的な攻撃ベクトルを排除する際に注意を払う必要があります。また、レッド チームによる研究と作業に関する Logitech の声明を共有したいと思います。
「Logitech では、お客様のセキュリティとプライバシーを非常に重視しています。2018 年 1 月下旬、セキュリティ調査会社の FireEye は、Logitech Harmony Hub ベースの製品に影響を与える可能性のある脆弱性を指摘しました*。
悪意のあるハッカーが既にハブ ユーザー ネットワークへのアクセス権を取得していた場合、これらの脆弱性が悪用される可能性があります。 FireEye のようなプロのセキュリティ調査会社が、IoT デバイスのこの種の脆弱性を特定する際に提供する作業に感謝します。
FireEye が調査結果を私たちと共有するとすぐに、私たちは社内でレビューを行い、すぐにそれに対処するためのファームウェアの開発を開始しました。 4 月 10 日の時点で、特定されたすべての脆弱性に対処するファームウェアをリリースしました。ファームウェア バージョン 4.15.96 にまだ更新していないお客様には、MyHarmony ソフトウェアを確認し、ハブベースのリモコンを同期して受け取ることをお勧めします。ファームウェアの更新に関する完全な指示は、ここで見つけることができます。
*ハブベースの製品には、Harmony Elite、Harmony Home Hub、Harmony Ultimate Hub、Harmony Hub、Harmony Home Control、Harmony Pro、Harmony Smart Control、Harmony Companion、Harmony Smart Keyboard、Harmony Ultimate、および Ultimate Home が含まれます。
Comments