愛犬を見守ろうとしたら、TP-Linkを監視することになった

• 室内の犬を観察するために Tapoカメラ を購入したが、思いがけず TP-Link機器とアプリの動作原理 を逆解析することになった
• オンボーディング過程 と 暗号化API通信 の構造を分析するため、MITM、APKデコンパイル、復号スクリプト作成などさまざまな手法を用いた
• 初期管理者パスワード の発見とセッションキー導出過程を通じて暗号化メッセージを復号し、デバイスとクラウドアカウント間の信頼性のない同期問題を把握した
• オンボーディング全体の流れ を分析し、主要なAPI呼び出し、アカウント作成、パスワード変更、Wi‑Fi接続過程などを Bash スクリプトで自動化した
• Tapoファームウェアのセキュリティ設計上の欠陥、洗練されていない暗号化実装、不規則なアカウント同期など、低価格IoTデバイスの特徴を指摘している

---

プロジェクト概要

• 筆者は室内で犬を見守るために 低価格のTapoカメラ を購入して使用した
• 使用する中で 設定の不便さ とオンライン情報の不足により、製品の動作原理を深く掘り下げる動機を持つようになった
• frigate 連携や 2way audio の有効化などで予想外の問題が発生し、クラウド連携なしの 直接オンボーディング の方法に関心を持った

オンボーディングと認証構造の分析

• Tapoカメラの接続手順を分析するため、MITM proxy と frida の動的フックツールを使ってアプリとカメラ間のトラフィックを傍受した
  • 最新のアプリはプロキシ無視や certificate pinning などの耐回避機能を備えているため、動的ツールを用いる手法が有効だった
• このような回避構成を整えた後、カメラのオンボーディングフローで デフォルト管理者アカウントのlogin 過程を正確に確認した
• デフォルトlogin API はクラウドアカウントのパスワードとは別に、デバイス固有の デフォルトパスワード で動作することを発見した

暗号化構造とデフォルトパスワードの探索

• APKデコンパイル（JADX使用） とコード分析を通じて、admin アカウントの デフォルトパスワード（TPL075526460603）を入手した
• クラウドのパスワードを変更しても、すでに連携済みのカメラ機器は変更を認識できない点から、アプリとカメラ間の パスワード同期が不正確 であることを確認した
• デフォルトパスワードが判明したため、セッションキー（lsk, ivb）の導出ロジックを実装し、暗号化APIメッセージ をリアルタイムで復号できるようにした

mitmproxyスクリプティングとAPI分析

• PyTapo オープンソースプロジェクトを参考に、実際の Tapoオンボーディング手順のAPIフロー を詳細に分析した
• tapo_decrypt_pretty.py スクリプトを通じて
  • loginハンドシェイクの検出
  • セッションキーの抽出
  • 暗号化APIの復号と可読性の高い出力、JSON保存
• オンボーディング全体のAPI呼び出し履歴のうち、有意な主要過程だけを抽出して自動化ワークフローを作成した
  • Wi‑Fi一覧取得（scanApList）
  • RTSP/ONVIFアカウントの有効化
  • 管理者パスワードの変更
  • Wi‑Fi接続

自動化と結果

• Bashスクリプト（tapo_onboard.sh）で上記のオンボーディング過程を 自動実行 できるよう構成した
  • デフォルトadmin login
  • Wi‑Fiの選択と接続
  • カメラフィードのロゴ削除
  • RTSP/ONVIFの使用許可
  • 管理者パスワードの再設定
• カメラのファームウェア構造上、次のような特徴と欠陥を発見した
  • 一部のAPIは SHA-256ハッシュ を使う一方、いくつかは MD5 など旧式の暗号方式を維持している
  • 公開鍵 が2つ存在し、どの状況でどの鍵を使うべきか不明確である
  • アプリとデバイス間の パスワード同期 が非常に不安定である

結論と所感

• TapoカメラのファームウェアとAPIのセキュリティ構造は その場しのぎで洗練されていない設計 に感じられた
• 低価格IoT機器の セキュリティ上の欠陥 と不完全なオンボーディングシステムの現実を間接的に体験した
• プロジェクトの最終目標だった犬の見守りには成功し、犬はたいていソファかベッドで寝ていることを確認した

[helio]

CVE-2022-37255 は 7.5 点ですね

[GN⁺]

Hacker Newsのコメント

• 自分の Frida スクリプトが使われていて面白いと感じた。そのスクリプトはここで確認できる。実環境でうまく動いているようでうれしい。もし追加や修正した点があれば聞きたい

  • HTTP Toolkit は本当に良いツールだと思う。Tim の素晴らしい仕事だ
  • 自分が使った中では Http toolkit が最高だと思う。mitmproxy、proxyman、charles proxy も使ったが、httptoolkit が一番良く、しかもオープンソースだ

• ちなみに、双方向オーディオを frigate で使うには、通常の rtsp:// ではなく tapo:// の go2rtc 設定をメインストリームに適用する必要がある。TP-Link は独自 API でしか双方向オーディオを提供していない。この設定をすると ONVIF（オープンソースツールによるカメラのパン/チルト制御）が使えなくなるので面倒だ。両方の機能を使うには、tapo:// ストリームの読み取り停止 → onvif クライアント実行/パン・チルト調整 → onvif 終了 → tapo:// 再起動、というかなり強引なワークフローを繰り返す必要がある

• IoT セキュリティは全体的にひどいと思う。特に、一般向けルーターがすべてのネットワークトラフィックを処理する監査不能なブラックボックスである点が心配だ。ほとんどの人は、ルーターのファームウェアが何年も更新されておらず、既知の脆弱性が残っていることを知らないことが多い。ネットワーク機器のサプライチェーンにおける信頼モデルは完全に壊れていると思う

  • IoT セキュリティがいまひとつなのには同感だ。自分としては IoT 機器は単につながれば十分で、オンライン専用の制約を破るためのエクスプロイトさえ使いたいこともある。ただ、クラウド連携 IoT を求める本当のユースケースもある。だから初回設定時に、機器がユーザーにどう使いたいかを尋ね、選ばれたモードでのみ動作すべきだと思う。クラウド MFA が必要ならそれを選べるし、単にプログラムから操作したいならオフラインのままにできるべきだ
  • ユーザーと宛先の間には数え切れないほどのルーターがあり、それらを全部監視することはできない。エンドデバイスはどうせルーターが侵害されている前提で、すべてのデータを検証し、暗号化して送るので、ルーターが DDoS や暗号資産マイニングのような不正行為に使われない限り、セキュリティ自体にはそれほど意味がないと思う
  • ほとんどの人は ISP が提供して設定したルーターを使っているので、実質的にはブラックボックスを別のブラックボックスにつないでいるようなものだと感じる。Wi-Fi 接続時に ISP が指定した SSID とパスワードを渡されてそのまま使う例をよく見かけるが、ISP に権限を与えすぎていることに驚く
  • 一般消費者向け製品はそうだが、Ubiquiti や Mikrotik のような prosumer 向けハードウェアに行けば、迅速なセキュリティ更新と安定したファームウェアサポートが期待できると思う

• このブログ記事は非常によく書かれていると感じた。最近はこういうスタイルの記事が LLM 生成であることも多く、読みにくい場合が少なくないが、この記事は技術的でありながら読みやすいバランスがうまく取れていて印象的だ。（表紙画像は AI 生成だと分かるが、記事の本質とは無関係だと思う）

  • 自分は uBlock Origin で大きなメディアファイルをデフォルトでブロックしてリソース消費を抑えている。表紙画像はそもそもブロックされることが多いし、ほとんど役に立たない。最近は、そんなものを生成するためにわざわざ資源を使うのが残念に感じる

• Frida や mitmproxy のようなツールを Android アプリで今後も使い続けられるのか気になる。来年から署名要件が適用されたらどうなるのか知りたい

  • 全体としては可能だろうが、attestation が必要なアプリはずっと難しくなるはずだ。今でも Pixel のように OEM unlock と root 化が可能な端末は、開発者向けとして使い続けられる。ただしこの場合、端末は unlock 済みとしてマークされ、Google attestation に失敗する。アプリを展開して Frida を注入し、開発者アカウントで sideload する方法（iOS のように）も可能だと思うが、これもやはり attestation 失敗や anti-tampering / anti-debugging 攻撃にさらされる
  • 実際には、その変化の直接的な影響はそれほど受けないと思う。リバースエンジニアリングの大半は root 化された端末やエミュレーターで行われるからだ。より珍しいが、root 化されていない端末で Frida を APK に gadget 方式で注入するケースでは難しくはなるものの、開発者モードで APK をビルド・インストールする道はまだ残ると思う。これを完全に塞ぐと Android アプリ開発自体が不可能になるので、おそらく sideload は一般ユーザー端末では制限しつつ、開発者証明書の追加のような手段は残すのではないか。結局いちばん難しくなるのは実際のアプリ配布で、開発やリバースエンジニアリング用途は可能だと思う。ただ、より大きな脅威は device attestation の拡大だ。root 化端末や非公式端末で、未改変デバイスかどうかの検査に執着するアプリが今後さらに増えるかもしれない。現時点では主に大手金融アプリだけだし、気にする必要がある人（GrapheneOS ユーザー）も少なく、追加サーバー構築などのコストもあるため簡単には広まらないだろうが、今後は変わる可能性がある
  • 実際、Frida の活用はすでに簡単ではないと感じる。Frida を使うには root が必要だが、その root 自体がますます不可能なモデルが増えているし、非常に強力な root 検知 SDK や Play Integrity 対策も存在する

• ちなみに、関連事例としては The Tapo C200 research project と PyTapo: Tapo カメラ向け Python ライブラリ がある

• もう1つの関連資料として、（TP-Link ファームウェアの復号化と C210 V2 クラウドカメラのブートローダー解析）がここにある

• OP の犬がベッドから床に移動するのは、もしかすると暖房機（ラジエーター）がついたからではないかと推測する。追加のセンサーデータが必要そうだ

  • あるいは、単に寒いと感じているだけかもしれない

• もう、ハードコードされた管理者パスワードが見つかっても大した話ではない時代に来た気がする

  • それは恒久的なバックドアではなく、単なるハードコードされたデフォルトパスワードだと理解している。記事の説明どおりなら、オンボーディング時にユーザーがパスワードを変更する仕組みだ。ほとんどのアプリはそういう動きをする
  • セットアップ後の通常の流れでパスワードを変えるのだから問題ないと思う。この5年間、家にできるだけ多くの IoT / スマートホーム機器を導入して感じたのは、ほぼすべての企業が機能性に疑問の残る製品ばかり売っており、1社で統一しない限りスマートホーム全体の構築がとても難しいということだ。そして、まだまともな企業であっても個々のニーズをすべて満たしてはくれない。自分のスマートフォンには Ecobee、Lutron、Hue、複数のカメラベンダー、Meross、Smart Life などさまざまなアプリが入っているが、このうち Lutron と Hue だけはハブ / HomeKit で直接制御できるのでアプリを開く必要がない。Matter と Thread の標準化はずいぶん前からあるのに、今でも互換機器より安価な Wi-Fi ベース製品があふれており、その大半は出来が悪く、アプリ経由でしか管理できず、しかもクラウドサービスへ誘導するように作られている。カメラを4台も買ったのは自分の責任でもあるが、実際にはベンダーごとに強みが違うので、消費者が分散して買わざるを得ないのも仕方ないと思う
  • 変更しないと使えないハードコード済み管理者パスワード自体は、特に大きな問題ではないと思う
  • 正直、この技術に対してただイライラしていただけな気がする。ここでは問題とは言えない
  • むしろスマートフォンこそが元祖の敵対的デバイスだという見方もある。ネットワーク機器は少なくとも状況把握や発見がこうして可能だという点が違う

• Tapo カメラのうち RTSP をサポートするモデルをまとめたリファレンスが欲しい。C210 はそこそこうまく動いていて（クラウドキャプチャは不可）、frigate と連携して使っている。今日 C402（屋外向け）を買ったのだが、こちらは advanced 設定に camera account がなくて残念だった。価格の安さは魅力だが、機能の統一性が足りないと感じる。安価で RTSP ストリーム対応、しかもソーラーパネル付きの良い屋外カメラがあればおすすめを知りたい

  • カメラが rtsp:// をサポートしていなくても、tapo:// の go2rtc ストリームソースを使うことはできるはずだ。自分の frigate 設定を参考までにここに置いてある