スマートホームデバイスのハッキング（2024）

• ESP32ベースのスマートホーム機器をリバースエンジニアリングして Home Assistant と統合
• モバイルアプリを分析し、クラウドサーバーとの接続を確認
• ネットワークトラフィックを傍受して 機器制御 を試行
• ESP32フラッシュをダンプして分析し、ファームウェア改変を試行
• パケット構造を分析して 暗号化とチェックサム を理解

---

紹介

• 最近、すべての機器を Home Assistant に接続しようとしている
• 特定の 空気清浄機 が独自アプリ以外では接続できないため、これをハックして統合しようとしている
• インターネット接続 と クラウドアカウント に依存する製品の問題点を指摘

計画

• モバイルアプリ がクラウドサーバーに接続されており、リモート制御が可能であることを確認
• ネットワークトラフィックを傍受して機器を制御できる方法を模索

モバイルアプリ分析

• Androidアプリを分析し、React Native で開発されていることを確認
• WebSocket を通じてクラウドサーバーに接続されていることを発見

ネットワーク検査

• Pi-hole を使って DNSクエリ を確認し、Wireshark でトラフィックを分析
• UDPパケット を通じて機器とサーバー間の通信を確認

パケット分析

• UDPプロキシ を使って機器とクラウドサーバー間のトラフィックを中継
• Wireshark を通じてパケット構造を分析し、暗号化 の可能性を確認

物理的分解

• ESP32 ベースの機器を分解し、フラッシュチップ からファームウェアをダンプ
• esptool を使って シリアル接続 でデータを読み出し

フラッシュ分析

• esp32knife を使ってフラッシュデータを分析し、パーティションテーブル を確認
• FATファイルシステム で重要なファイルを発見

初期静的解析

• Ghidra を使ってファームウェアの文字列を分析し、暗号化ライブラリ の使用を確認
• mbedtls ライブラリを使って ECDH および HKDF アルゴリズムを実装

ファームウェア改変

• Ghidra を通じて CapSense 機能を無効化し、ファームウェアを改変 して機器を起動
• チェックサム の問題を解決し、改変したファームウェアのフラッシュに成功

パケットヘッダー

• パケットヘッダー の構造を分析し、シリアル番号 と メッセージ識別子 を確認
• クライアント要求 と サーバー応答 のパターンを把握

パケットチェックサム

• CRCチェックサム を確認し、パケットデータの完全性を検証

[GN⁺]

Hacker Newsの意見

• 長期的な解決策は、ローカル制御を無視する家庭向け製品を買わないこと

  • WiFiパスワードが必須なら、その製品は返品する
  • セキュリティやプライバシーを犠牲にしたいなら個人の選択だが、機能を失わずに拒否できる選択肢が提供されるべき
  • RTSPをサポートしないドアベルカメラは買わない

• 空気清浄機が室内の空気質が悪化したときに動作を強めるのに、IoT機器、アプリ、無線通信、ハブは必要ない

  • 空気清浄機に空気質センサーと小さなLCDを取り付けて設定を調整すれば十分
  • 廊下の照明が自動で点灯するのは、クラウド、HomeAssist、WiFi、Zigbee、アプリ、バッテリー交換なしで動作する
  • この10年間、ネットワークがダウンしても問題なく動いてきた

• ESP32ベースのIoT機器の販売者へ:

  • スマートホームシステムと統合するためにスマート機器をアップグレードしても、他のインスタンスやクラウドサービスには影響しない
  • 機密性の高い製品データは難読化または削除される

• ESP32ベースのIoT機器の所有者へ:

  • スマートホーム製品のクラウド排除とデバッグのためのオープンソースプロジェクトを作成しており、技術面で多くを学んでいる
  • この投稿を書くのに多くの努力を費やしたので、形式についてフィードバックをもらえるとうれしい

• 機器のボードでどのピンが接続されているかを把握し、ESPHomeで完全にフラッシュしてカスタムyaml構成を書けるのか気になる

• IoT機器の設計チームにいるたびに、セキュリティ重視のエンジニアがブート保護を担当していた

  • ファームウェアをダンプして再フラッシュすることに耐性がなかったのは驚き
  • なぜフラッシュ暗号化をしないのか気になる

• 記事へのフィードバック:

  • デバイスキーの使用に関する注記は、デバイスごとにキーがあると書くのが最も明確
  • デバイスごとのキー管理の複雑さとリスクについてのフィードバックを共有したい
  • デバイス暗号化は工場で多くの問題を引き起こす可能性があり、製品が許容できるなら避けた方がよい

• 標準化されたソリューションを使わなかった理由が気になる

  • 独自ソリューションを作るより費用対効果が高そう

• ESP32 IoT機器でファームウェア暗号化が使われている例はほとんど見たことがない

  • ファームウェアが読めなければ証明書を作るのは難しかっただろう
  • しかし同時に印象的でもある

• サービスエンジニアがDTLSのような標準プロトコルを実装しないと決めたことについての意見

  • 各機器が固有の秘密鍵を持っているのか確信が持てない
  • すべての機器が同じファームウェア秘密鍵を共有しているなら、1台の機器をリバースエンジニアリングするだけで他の機器にMITM攻撃ができる

• スマート機器を使う人は、DD-WRT、OpenWrt、Tomato、Asuswrt-Merlinを使って、機器を個人ネットワークから分離したVLANに隔離すべき

• 購入した製品を使うためにハッキングが必要であってはならない

  • 「レントシーキング」経済は規制または禁止されるべき