リビングのスマートTVはAIスクレイピング経済のノード

 (blog.includesecurity.com)
1 ポイント 投稿者 GN⁺ 3 시간 전 | 1件のコメント | WhatsAppで共有
  • コンシューマー向けアプリに組み込まれる Bright Data SDK は、ユーザーの同意のもとで携帯電話やスマートTVを住宅用プロキシの出口ノードに変換し、顧客のWebスクレイピングトラフィックを家庭用IP経由でルーティングする
  • 住宅用プロキシ は、Cloudflare、DataDome、HUMAN などが既知のクラウドIPからのリクエストを制限または遮断する環境で、有料の住宅契約者のIPを使って対象サイトに到達するための迂回手段
  • コネクテッドTVは、バッテリー制約がなく常時Wi-Fiに接続され、待機状態のまま24時間365日動作するため、携帯電話よりも 常時性 と 放置されやすさ の面でプロキシに適した条件を備える
  • iOS SDK は、認証のない設定エンドポイントからアイドル基準・帯域幅上限・パートナー一覧を取得し、WebSocketピアトンネル を開いてデバイス状態のテレメトリと cmd_tun スクレイピング作業を処理する
  • 防御策は proxyjs.* と clientsdk.* のDNSブロック、SNIフィルタリング、TLS証明書フィンガープリント検知、MDMによるアプリバイナリスキャンが中心であり、iOSの use_netifs はVPNベースの可視性を回避する制約となる

概要

  • AI能力向上のためのデータセンター建設に対するコミュニティレベルの反対とは別に、家庭内の機器がAI学習向けの分散データ収集に使われうる構造がある
  • Bright Data は、顧客がWebスクレイピングトラフィックをルーティングするための4億超の家庭用IPアドレスから成る住宅用プロキシネットワークへのアクセス権を販売しており、その供給源はコンシューマー向けアプリに組み込まれるSDKである
  • 当該SDKは、ユーザーの同意のもとで携帯電話やスマートTVを出口ノードに変換し、ここでの分析対象はSDKの動作方式、配布プラットフォーム、そしてインターネット接続TVがAIモデル向けWebスクレイピングプロキシに適している理由である

今重要な理由

  • AI企業は、事前学習、検索・検索拡張、エージェントのグラウンディング、検索機能のためにWebスクレイピングされたコンテンツに依存している
  • 現代のWebはデータセンターから容易にスクレイピングできる環境ではなく、Cloudflare, DataDome, HUMAN などが既知のクラウドIPからのリクエストを制限または遮断している
  • 代替手段は、Comcast や T-Mobile 加入者の接続のように、有料の住宅契約者のIPから対象サイトへ到達する 住宅用プロキシ である
  • 2025年10月の Krebs 報道の引用では、「Aisuruやその他の供給源からのプロキシ過剰供給が、複数のAIプロジェクトに結び付いた大規模なデータ収集の取り組みを後押ししている」と述べられている
  • 2019年までさかのぼる 学術的測定 では、この種のネットワークは圧倒的に悪用されているとの結果が示されており、FBIも今年初めに 公式勧告 を発している
  • 既存報道の大半は、Aisuru や Kimwolf のようなボットネット、PROXYLIB のようなトロイの木馬化アプリ、IPIDEA のような事前感染済みIoTハードウェアなど、違法な住宅用プロキシ供給に焦点を当ててきた
  • 合法的供給の側面は比較的検証が少なく、Bright Data は自社マーケティング基準で世界最大の住宅用プロキシネットワークとして、パートナーアプリに組み込まれた同意ベースSDK由来の「150M+ IPs」を宣伝している

コネクテッドTVが理想的なプロキシである理由

要素 携帯電話 スマートTV / CTV
電源 1日の大半がバッテリー駆動 常時電源接続
ネットワーク Wi-Fi + セルラー 常時Wi-Fi、高速
稼働時間 断続的 待機状態で24時間365日
帯域幅上限 低い、セルラー制限あり 実質無制限
ユーザーの注意 能動的に使用 放置されがち
同意UI 携帯画面上のテキスト TVリモコンの方向キーで移動するテキスト
企業・家族による監督 MDM、モバイルEDRなどで比較的高い 事実上ない
  • TVはバッテリー残量1%に達することがなく、Wi-Fiネットワーク間を頻繁に移動せず、ユーザーが眠っている間にもロックされない機器である
  • 一部のパートナー配信事業者はプライバシーポリシーで Bright Data との関係を開示しており、PlayWorks のプライバシーポリシー がその一例である
  • プライバシーポリシーでの開示はTVに適した統制ポイントではなく、リモコンの方向キーで法的文書をスクロールするのは難しく、アプリ内同意ダイアログも、有料の Bright Data 顧客がユーザーの家庭用インターネットを通じてスクレイピングトラフィックをルーティングすることを伝えられない構造になっている
  • The Verge が記録した Roku アプリ Petflix のオプトイン画面では、「広告を減らして無料で楽しむため、Bright Data がデバイスの余剰リソースとIPアドレスを時折使用して、インターネット上の公開Webデータをダウンロードすることを許可する」という文言が使われている
  • Petflix のダイアログでは「時折」という表現が使われているが、公開参照可能なSDK設定の max_bw_monthly_wifi: 200,000,000,000 は、月間のデフォルトWi-Fi予算が200GBであることを示す

Bright Data がパートナーとして名指ししている対象

  • Bright Data は、認証なしで誰でも取得できるパートナー manifest エンドポイントを公開している
  • 公開情報ベースで信頼度の高い識別項目
Partner ID Entity 規模
playworks_digital PlayWorks Digital Ltd CTVゲームタイトル400本超、Comcast・Sky・Cox・LG・Samsung・Vizio・Roku を通じてTV世帯約2.5億に到達
cloudtv CloudTV TVブランド125超およびOEM 15社超に統合
longvision_media_hong_kong_co_limited Longvision Media HK (LongTV) 香港・マレーシア全域でOTTユーザー500万
viber_media_s_r_l Viber Media S.à r.l. (Rakuten) Viberメッセンジャーの月間ユーザー2.5億〜8.2億
supercent_inc Supercent 2023年ダウンロード基準で韓国モバイルパブリッシャー1位
moonfrog_labs_private_limited Moonfrog Labs Teen Patti Gold 単独で約1000万MAU、9000万ドルで買収
hola_networks Hola Networks Bright Data の系譜上の親会社であり、Hola の過去マーケティング基準でのピークユーザー数は数千万から約1億超の範囲
  • desoline、free_time、ott_studio、global_microtrading、m_m_media、easystaff_lp は manifest に存在するものの、公的な出典では特定しにくい項目
  • bright_screensavers、bright_videos、brightdata は Bright Data 自身のアプリ
  • Bright Data の設定に名称があるという事実は、ある時点で統合があった可能性を意味するが、特定の配信事業者の現在配布中のアプリが本番環境で SDK を搭載している直接的な証拠ではない
  • パートナー一覧が直接示しているのは、Bright Data が認証のない公開エンドポイントでこの名簿を配布していること、そして PlayWorks・CloudTV・Longvision など少なくとも3社の CTV 中心事業者がユーザー端末を住宅用プロキシの出口ノードとして収益化していたという点
  • PlayWorks は自社マーケティング資料に基づき、主要 TV プラットフォームと ISP 全般での CTV 配信、および数億世帯規模への到達を示している
広告

Bright Data SDKがユーザーのデバイスを住宅用プロキシの出口ノードに変える仕組み

  • Bright Data SDKは、パブリッシャー向けのSDK統合ドキュメントと、Web向けのJavaScript variantを備えた公開文書化済みの商用製品

  • 分析は、配布中のiOSフレームワークのリバースエンジニアリングと30日間のランタイムトラフィック計測に基づいて構成

  • SDKはパートナーアプリ内のiOSフレームワークbrdsdk.frameworkの形で配布される

  • 認証のない設定

    • SDKは起動のたびに次のリクエストを呼び出す
    • GET https://clientsdk.bright-sdk.com/sdk_config_ios.json/…;
    • このエンドポイントは意味のある認証なしで動作し、サーバーはアプリのバンドルIDであるappidとSDKバージョン文字列であるverの2つのクエリパラメータだけを確認する
    • パートナーアプリのApp Store掲載情報で見つかるバンドルIDとSDKバージョン文字列、任意生成UUIDを与えると、実機が受け取る応答と同一の設定が返る
    • 応答には、機能フラグ、バッテリー比率・CPU/メモリ上限・Wi‑Fi/セルラー規則のようなアイドル検知しきい値、国別帯域幅階層、パートナーmanifestを含む構造が入っている
    • 設定内には、デバイスがトラフィック中継資格を得るアイドル規則、VPN周辺でピアトラフィックをルーティングするフラグ、クロスプラットフォームのインストールを1つのIDに結び付けるmap、国別の帯域幅上限が存在する

  • ピアトンネル

    • 設定を取得した後、SDKは次のアドレスに永続WebSocketを開設する
    • wss://proxyjs.brdtnet.com:443
    • このホスト名は執筆時点でAWS Global AcceleratorのIP 3.33.193.183, 15.197.193.114に名前解決される
    • TLS証明書はCN=*.luminatinet.comで、Luminati NetworksはBright Dataの2018年以前の社名
    • 2018年のリブランディング後もアクティブなSDKインフラはlegacy証明書を使用しており、luminatinet.comまたはbrdtnet.comへのトラフィックは、顧客側のBright Data利用ではなくピアトンネルplaneを識別する手掛かりである
    • 現在の顧客向けプロキシサービスはbrightdata.comブランドドメインで動作しているため、ネットワーク上のluminatinet.com・brdtnet.comトラフィックはピアトンネルplaneである
    • サーバーは自身をuWebSockets: 20として識別する
    • ピアエンドポイントはアップグレード時に認証を要求せず、TLSが有効なWebSocketアップグレードを受け入れた後、クライアントのグローバルIPを返すアプリケーション層フレームを即座に送信する
    • ハンドシェイクの流れ
      1. サーバー → クライアント tunnel_init: セッションを作成し、クライアントのグローバルIPを返す
      1. サーバー → クライアント cid_set: <IP>-<token>/ls<N>c<M>p443_<IP>_<counter>形式のセッション追跡識別子を割り当て、実機テレメトリのcidフィールドと一致することを確認
      1. サーバー → クライアント status_get: デバイスのアイドル状態、バッテリー、ネットワーク種別、利用可能帯域幅をポーリングし、デバイスはidle, wifi_connected, mobile_connected, mobile_type, roaming, battery_level, using_battery, screen_on, on_call, cpu_usage, mem_usage, raw_bw, bw, ipv6_supported, appid, sdk_version, platform, cidなどの継続テレメトリで応答する
      広告
      1. ハンドシェイク完了後、デバイスが有利な状態を報告すると、サーバーのジョブマッチング層がcmd_tunフレームをプッシュでき、SDKはこれをユーザーの住宅用IPを送信元とするサードパーティーサイトへのHTTPリクエストとして実行する
    • WebSocketのすべてのフレームは固定envelopeを持つplain JSON
    • {"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error","cmd": <command>, "cookie": <correlation-id>,"err_code": 0, "msg": { ...payload... }}
    • バイナリから抽出し、実際の通信で確認したコマンド
    • | 方向 | cmd | 目的 |
    • |---|---|---|
    • | Server → Client | tunnel_init | セッション開設、グローバルIP echo |
    • | Server → Client | cid_set | セッション識別子の割り当て |
    • | Server → Client | status_get | デバイスのアイドル・バッテリー・帯域幅のポーリング |
    • | Server → Client | cmd_tun / tun | スクレイピングジョブの配信 |
    • | Server → Client | dns | 対象DNS解決の要求 |
    • | Server → Client | consent | 同意状態の要求 |
    • | Client → Server | status_send | デバイス状態の定期heartbeat |
    • | Client → Server | tun_report / tun_ack / tun_fin | 中継ジョブのライフサイクル応答 |
    • | Client → Server | tunnel_init_decline | セッション拒否 |
    • | Client → Server | logs | 診断ログをサーバーへ送信 |
    • メッセージ署名、HMAC、クライアント証明書、デバイスattestationはなく、実際のジョブを受け取るピアを分ける要素はTLS層とサーバーのIPレピュテーションフィルタだけという構造
    • 商用マルウェアのプロトコル設計に慣れた読者の基準では、典型的なC2より実質的に低いセキュリティ水準

  • SDKが「アイドル」と見なす条件

    • 設定は、他人のトラフィックを中継できるデバイス状態ルールを明示する
    "idle_metrics": {
  "ignore_screen_on": true,
  "ignore_on_call": true,
  "max_bw_ratio": 1,
  "min_battery": 0.2,
  "wifi_on_battery": true,
  "min_battery_wifi": 0.2,
  "max_cpu_usage": 70,
  "max_mem_usage": 90,
  "mem_screen_off": true,
  "idle_timeout": 30,
  "not_idle_timeout": 10
}
    • ignore_screen_onとignore_on_callフラグのため、「アイドル」とはユーザーがデバイスから離れていることではなく、CPU・メモリ・バッテリーがSDKのしきい値内にあることを意味する
    • ユーザーが通話中であったり、画面を積極的に読んでいる状態でも、中継目的のアイドル状態と見なされる

  • クロスプラットフォームのID連携

    • 設定には次のdual_pairing mapが存在する
    広告
    "dual_pairing": {
  "ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"]
}
    • このmapは、同一ブランドのiOS、Windows、macOSインストールを1つのエンティティとして束ねるサーバー側の連結構造
    • http3_enabled: trueフィールドはQUICベースのピア転送のためのフラグで、将来のバージョンではピアトンネルがTCP/443からUDP/443へ移行する可能性がある
    • TCP接続追跡でWebSocketを検知する防御側は、UDP/443への移行時に検知方式が破綻する可能性がある

  • 検査回避

    • SDK設定のuse_netifs: trueフラグは、SDKバイナリコードがシステム既定経路ではなく特定の必須インターフェースでNWConnectionを構成する条件になる
    • 必須インターフェースはWi‑Fiのen0またはセルラーのpdp_ip0
    • iOSではこの方式が構成済みVPNのtun0インターフェースを完全に迂回し、アプリの他のHTTPSトラフィックがVPNを通っていても、ピアトンネルはユーザー構成VPNを通過しない

  • 透過的なTLSインターセプト研究環境はSDKのすべてのHTTPS呼び出しをキャプチャしたが、ポート443が明示的にインスペクタへリダイレクトされていたにもかかわらず、proxyjs.brdtnet.com:443 のピアトンネルはキャプチャできなかったという結果

    • バイパスにはAppleが文書化している NWParameters.requiredInterface APIを使用
    • SDKは2つの独立したインスペクション回避を使用
    • Control plane: 設定取得とテレメトリpingは、URLSession・NSURLConnection ではなくCFNetworkの CFHTTPMessage プリミティブを基盤としており、モバイルアプリのセキュリティツールで一般的な URLSession レベルの計測、swizzling、network extension、URLProtocol subclassを無効化しつつ、システムプロキシは尊重するため、TLSインターセプト研究者には可視性が維持される
    • Data plane: ピアトンネルは、物理インターフェースを必須インターフェースとして設定した NWConnection ベースで、VPNを無効化し、スクレイピングが住宅向けIP上で実行されることを保証
    • MDM、企業VPNベースのトラフィック検査、家庭用ルーターのペアレンタルコントロールを使うセキュリティチームにとって最も敏感なチャネルは、可視性レイヤーを回避するよう設計された状態

国別の階層

  • 設定には国別の帯域幅しきい値が存在する
広告
国 リレーの最小バッテリー 1日あたりの上限 月間上限
Uzbekistan 1% 1GB 30GB
Oman 1% 1GB 30GB
Qatar 20% 40MB 250MB
UAE 20% 40MB 250MB
default, worldwide 20% 50MB 500MB
  • Uzbekistan と Oman の端末では、バッテリー 1% までリレーが許可され、1日あたりの上限はデフォルト値の20倍、月間上限はデフォルト値の60倍
  • Qatar と UAE の端末は、デフォルト値より低い上限に制限される
  • 国別の階層がこのように構成されている理由は確定できず、推測しかできない
  • 世界共通のデフォルト許容量でも、ユーザーの家庭用インターネット経由で毎月ほかの人のトラフィック 500MB を許容する

テスト設定と方法論

  • 30日間にわたり、同意してインストールされたパートナーアプリを実行した iOS 端末で TLS インターセプトプロキシによるキャプチャを実施し、例として Bright SDK を組み込んだ XYO COIN を含む
  • brdsdk.framework version 1.532.120、iOS arm64 バイナリに対する静的解析を実施
  • Bright Data の特定ホスト名、証明書フィンガープリント、TLS インフラは、同じリクエストを実行する誰にでも公開観測可能
  • 研究フリートや研究クライアントのセッション別識別データは文書にない

タイムライン

  • 2026年5月11日、privacy@brightdata.com 宛てに公開予定通知メールを送信
  • 公開時点まで、この通知に対する応答はなかった

防御アプローチ

  • トラフィックはネットワーク境界で明確な fingerprint を残し、SDK はアプリバイナリに識別可能なシンボルを残す構造
  • アプローチ1、DNS ブロックは、ネットワーク経由でルーティングされる端末に対してシンプルかつ効果的な方式
    • proxyjs.brdtnet.com
    • proxyjs.luminatinet.com
    • proxyjs.bright-sdk.com
    • clientsdk.bright-sdk.com
    • clientsdk.brdtnet.com
  • proxyjs.* のブロックはピアトンネルを中断させるが、別ドメインで動作する Bright Data 顧客向けプロキシサービスを正当に利用している顧客には影響しない
  • アプローチ2、TLS SNI フィルタリングは、server_name が *.brdtnet.com、*.luminatinet.com、*.luminati.io と一致する TLS ハンドシェイクをブロックまたは警告する方式
  • SNI フィルタリングは TLS 検査なしでネットワーク境界で動作する
  • アプローチ3、TLS 証明書フィンガープリント検知は、次のフィンガープリントに基づいてブロックまたは警告する
    • .brdtnet.com → SHA256 313ce4ec7d5a51e5…
    • .luminatinet.com → SHA256 5028612e625befea…
  • 証明書フィンガープリントは Sectigo の証明書更新まで安定しており、現在の証明書は 2026年半ばまで有効
  • use_netifs 関連の制約により、3つの階層はいずれもトラフィックがネットワーク境界を通過するときにのみ機能する
  • iOS 端末がセルラー通信を使う場合、SDK の use_netifs バインディングによって、ピアトラフィックが企業 Wi-Fi を完全に迂回する条件が生まれる
  • 管理対象端末フリートの補完的統制としては MDM ベースのアプリバイナリスキャンがあり、インストール済みアプリから Swift シンボル BrdWebSocketFacade と BrdNetwork.DNSResolver を検索し、これらのシンボルを持つアプリを会社支給端末で禁止する方式
  • 特定のスマートTVやモバイルアプリが懸念される家庭のユーザーは、ルーターの DNS 設定で上記ホスト名をブロックする方法を利用できる
  • ブロックツールの例としては、Pi-hole、NextDNS、Cloudflare Gateway、ISP の同等機能がある

関連記事

1件のコメント

 
GN⁺ 3 시간 전
Lobste.rsの意見

  • このプロトコルについて語るついでに、すべてのリクエストに対してランダム生成したゴミデータを自発的に返す逆ハニーポットを作れば、余ったトークンを持っている誰かにとって面白いバイブコーディングのプロジェクトになるかもしれない

    • わざわざプロトコルを実装する必要はなさそう。ログを見ると、こうした住宅用プロキシのかなりの部分は自分を隠すことに完全に失敗していて、単に簡単にゴミデータを返せる
      バイブコーディングすら不要で、すでにこういうことができるツールは数十個ある。その多くは1年以上にわたって、こうしたプロキシに延々とゴミデータをうまく提供してきた

  • なぜTVであれ他の家電であれ、インターネットに接続するのかまったく理解できない。そうしなければならない良い理由がない

    • 人々はTVでストリーミングサービスを見る。TVをインターネットに接続するのが、それを行う最も簡単な方法だ