TP-Link Tapo C200：ハードコード鍵、バッファオーバーフロー、そしてAI支援リバースエンジニアリング時代のプライバシー

 (evilsocket.net)
1 ポイント 投稿者 GN⁺ 2025-12-21 | 1件のコメント | WhatsAppで共有
  • 低価格帯のTP-Link Tapo C200 IPカメラのファームウェアをAI支援リバースエンジニアリングで解析した結果、複数のセキュリティ脆弱性が見つかった
  • ファームウェアにはハードコードされたSSL秘密鍵が含まれており、同一ネットワーク内でHTTPSトラフィックの復号が可能
  • 解析過程では**AIツール（Grok、GhidraMCP、Clineなど）**を活用し、ファームウェア構造の把握と関数の意味解析を自動化した
  • 発見された主な脆弱性はバッファオーバーフロー（CVE-2025-8065）、整数オーバーフロー（CVE-2025-14299）、**WiFiハイジャック（CVE-2025-14300）**などで、一部は認証なしでリモート攻撃が可能
  • この事例は、AIがセキュリティ研究の効率を高める一方で、IoT機器の構造的脆弱性を浮き彫りにした例と評価される

ファームウェアの取得と復号

  • Tapo AndroidアプリをリバースエンジニアリングしてTP-Linkの公開S3バケットを発見し、すべての機器のファームウェアを認証なしでダウンロード可能
    • 例のコマンド: aws s3 ls s3://download.tplinkcloud.com/ --no-sign-request --recursive
  • tp-link-decryptツールを使ってファームウェアの復号を実施
    • RSA鍵はTP-LinkのGPLコード公開資料から抽出可能
  • 復号されたファームウェアはブートローダー、カーネル、SquashFSルートファイルシステム構造で構成されている

AI支援リバースエンジニアリング

  • Ghidra、GhidraMCP、Cline、Anthropic Opus/Sonnet 4などを用いてファームウェア解析を自動化
  • AIが関数の役割を説明し、変数名を意味のある名前に再命名してコード可読性を向上
  • この過程でHTTPハンドラー、ディスカバリープロトコル、暗号化ルーチンなどをマッピング
  • ファームウェア内のSSL秘密鍵が起動時に生成されるのではなく組み込まれていることが確認された
    • 同一ネットワーク内の攻撃者はHTTPSトラフィックを復号可能

主な脆弱性

  • CVE-2025-8065（ONVIF SOAP XMLパーサーのメモリオーバーフロー）

    • ポート2020の/bin/mainサーバーでXML要素数に対する境界チェックの欠如
    • 大量のXMLリクエスト送信時にメモリオーバーフローとカメラのクラッシュが発生
    • CVSS v4.0スコア 7.1（High）

  • CVE-2025-14299（HTTPS Content-Length整数オーバーフロー）

    • ポート443のHTTPSサーバーがContent-Lengthヘッダーを検証なしでatoi()に渡して処理
    • 32ビットシステムでオーバーフローによるクラッシュが発生
    • CVSS v4.0スコア 7.1（High）

  • CVE-2025-14300（WiFiハイジャック）

    • connectAp APIは認証なしでアクセス可能で、設定完了後も有効
    • 攻撃者はカメラを攻撃者ネットワークへ接続させて映像トラフィックを傍受可能
    • CVSS v4.0スコア 8.7（High）

  • 認証なしのWiFiスキャンAPI（scanApList）

    • 周辺WiFiのSSID、BSSID、信号強度、セキュリティ設定を返す
    • Apple BSSID Locatorなどにより正確なGPS位置追跡が可能
    • リモート攻撃者がカメラの実際の位置を特定可能

公開と対応の経緯

  • 2025年7月22日にTP-Linkセキュリティチームへ最初の報告を実施、PoCと動画を含む
  • 150日経過後（12月19日）に公開され、その後TP-Linkがセキュリティアドバイザリを発表
  • TP-Linkは独自にCVEを採番する権限（CNA）を持ち、自社製品の脆弱性に関する報告・公開手続きを直接統制
  • 自社サイトで競合他社より少ないCVE件数をマーケティング指標として利用しており、利益相反の構造が指摘されている

結論

  • AIツールはリバースエンジニアリングの効率を最大化し、セキュリティ研究へのアクセス性を高める
  • しかし、ハードコード鍵、認証なしAPI、脆弱なパーサー構造などはIoT機器の根本的なセキュリティ欠如を露呈している
  • TP-Linkの事例は、AI時代のセキュリティ研究とメーカー責任のバランス問題を象徴的に示す事例である

関連記事

1件のコメント

 
GN⁺ 2025-12-21
Hacker Newsのコメント

  • こうした記事が、本当の失敗事例とFAANGですら苦労している問題を混ぜて批判しているのは残念
    特に「TP-Linkのファームウェア保管庫が認証なしで公開されたS3バケットにあった」という点を批判的に扱うのは、間違ったアプローチ
    むしろ セキュリティ・スルー・オブスキュリティ を避けた良い事例だと思う
    こうした記事は、かえって経営陣に誤った「施錠強化」の指示を出させるかもしれない

    • 記事自体は読みやすかったが、LLMが書いたようなトーンを感じた
      AIが書いた文章は微妙なニュアンスが不足し、何でも過剰に新しいもの、あるいは善悪ではっきり断定する傾向がある
      悪い文章ではないが、読むときは注意が必要。最近HNに上がる記事の大半はAIの助けを借りているように見える
    • 「ファームウェア保管庫が公開されている」という話に対して、「Linuxの話はやめておこう」という冗談が出ていた
    • こうした リバースエンジニアリング系ブログ は、単純に面白くて教育的な物語の伝え方だと思う
      自分もこういう記事を何度も書いてきたが、今回の記事は本当に興味深かった
      実際、「どうやってファームウェアを手に入れたか」は、この話では最も重要でない部分だ
    • ファームウェアが公開されていることに、否定的なニュアンスはまったく感じなかった。そう感じた人がいるのか気になる
    • ファームウェアは常に公開されるべきだと思う。それが正しい方向だ

  • 他の多くのカメラモデルも、同様の セキュリティ脆弱性 を共有している可能性が高い
    TP-Linkコミュニティページ によると、C200の最新ファームウェアは1.4.4と表示されているが、記事では1.4.2に言及している
    つまり、いくつか更新はあったものの、セキュリティパッチ は反映されていないようだ

    • 以前Zyxel製品を分析したときも、同じ結論に達した
      多くのメーカーは、共通ハードウェアをブランドだけ変えて販売する構造になっている
      関連する分析記事: Part 1, Part 2
    • こうしたカメラはローカル接続には向いているが、一般ユーザーにとっては依然として 使い勝手の問題 が大きい

  • こういう理由から、IoTネットワーク分離（segmentation） は必須
    すべてのスマートカメラとIoT機器を別個のVLANに置き、インターネットアクセスはファイアウォール経由で制限すべき
    TP-Linkカメラ利用者に勧める設定:

    1. ルーターでUPnPを無効化
    2. VLANでIoT機器を分離
    3. 必要なエンドポイントへのアウトバウンドだけ許可
    4. 可能なら オープンファームウェア に置き換える
    5. 定期的に更新を確認
      ハードコードされた鍵の問題は特に深刻で、製品ライン全体に影響している
    • 友人宅のネットワークをテストしたことがあるが、PoEインターホンシステム を通じて内部ネットワーク全体にアクセスできた
      彼はIoT機器をVLANで分離しておらず、通知システムもなかった
      結局その日に、VLAN分離とアクセス制限の重要性を身をもって学ぶことになった
      多くの人が同じような形で内部ネットワークをさらしている気がする
    • VLAN設定を段階的に説明した ガイド があるのか尋ねる人もいた。技術的には可能だが、具体的な手順が必要だ

  • Thingino がC200をサポートしているとのこと

    • ただし実際には、C200の 5つのバージョンのうち一部だけをサポート している
      正確なチップセットを確認するには OpenIPC を参照する必要がある
    • Thinginoコミュニティが作ったファームウェアは本当に驚異的
      互換性のあるカメラがあるなら、ぜひ試す価値がある

  • 私はすべてのカメラを インターネット遮断されたVLAN に置いて使っている
    HomeKit経由でローカルアクセスが可能なので、別アプリなしでも問題なく動作する

  • このレベルのずさんなセキュリティは、意図的 とすら思える
    何百万台も売りながら基本的な脆弱性検査すらしないのは理解しがたい
    150ドル以下のWi‑Fiカメラの大半は同様の問題を抱えていると思う
    本当に安全に使うには、非独自仕様のWi‑Fi ↔ Ethernetアダプター を自作して使うしかない

    • このカメラは公式サイトで17.99ドルで販売されている
      ハードウェア、梱包、物流、テスト、返品などを差し引けば、残るのは 1台あたり5ドル以下の利益 だ
      ここに追加の開発費として100,000ドルを使うのは、20,000台分を燃やすようなもの
      TP-Linkのように製品群が多い会社では、こうしたコストは年間で数千万ドル規模に膨らむ
      結局、最小限の開発だけで出荷 する構造になる
    • 一部のUSB給電カメラは USBネットワークアダプター に対応している
      技術に詳しい人なら、Thinginoファームウェアでローカル専用環境を構築できる
    • こうしたカメラを 信頼できないネットワーク に絶対置いてはいけない。あまりに自明な原則だ
    • 「すべてのWi‑Fiカメラが同じような問題を抱えている」という意見には全面的に同意する

  • TP-Linkの S3ファームウェア保管庫 がいつまで開いているのかわからない
    約990GiBほどのデータなので、誰かがアーカイブやtorrentでバックアップしておくとよさそうだ

  • 私はこのカメラを Unifi + ONVIF で重要でない用途にだけ使っている
    別VLANに置いてインターネットを遮断しているが、幸い正常に動作している

  • カメラを調べるときは drmnsamoliu.github.io のサイトを参考にした

  • Ghidraと AWS Amazon Q を使って、おもちゃのドローンの映像フィードをリバースしてみた
    GhidraMCPを使っていたら、もっと速くできたと思う