거실의 스마트 TV는 AI 스크래핑 경제의 노드입니다

Include Security에서의 업무는 저희가 매일같이 AI와 함께 작업하게 만듭니다 (해킹하기, 사용하기, 학습시키기 등).

최근 AI 역량 향상을 목표로 구축되고 있는 데이터 센터에 대해 커뮤니티 차원의 반대가 일어나고 있다는 점은 우리 모두가 알고 있습니다. 여러분이 인지하지 못하고 있을 수도 있는 사실은, 여러분의 집 안에 있는 기기들을 사용하여 AI를 학습시키려는 분산된 노력들이 존재한다는 점입니다.

이 포스트에서 우리는 Bright Data라는 회사가 자사의 주거용 프록시 네트워크 (residential proxy network)를 사용하여 현대적 AI 모델들이 인터넷에서 학습 데이터를 스크래핑 (scraping)하는 과정을 어떻게 용이하게 만드는지 탐구할 것입니다.

Bright Data는 데이터 수집 기업으로, 고객들이 웹 스크래핑 트래픽을 경유할 수 있도록 자사가 세계 최대 규모라고 마케팅하는 4억 개 이상의 홈 IP 주소로 구성된 주거용 프록시 네트워크에 대한 접근 권한을 판매합니다. 해당 네트워크의 공급원은 SDK (Software Development Kit)에서 나옵니다. 이는 소비자용 앱에 내장된 소프트웨어 조각으로, 사용자의 동의하에 사용자의 휴대폰이나 스마트 TV를 그러한 출구 노드 (exit nodes) 중 하나로 변환합니다.

우리는 일반 사용자인 여러분이 모바일 휴대폰이나 스마트 TV와 같은 여러분의 시스템에서 이 회사의 SDK가 무엇을 하는지에 대해 알아야 할 내용을 기록할 것입니다. 우리는 그들의 SDK가 어떻게 작동하는지, 어떤 플랫폼들이 이를 배포했는지, 그리고 왜 인터넷에 연결된 여러분의 TV가 인터넷에서 스크래핑된 데이터로 학습하려는 AI 모델들에게 궁극적인 프록시 (proxy)가 되는지를 탐구할 것입니다.

이것이 지금 중요한 이유

AI 기업들은 사전 학습 (pre-training), 검색 증강 생성 (retrieval), 에이전트 그라운딩 (agent grounding), 검색을 위해 웹 스크래핑된 콘텐츠에 의존합니다. 하지만 현대의 웹은 데이터 센터에서 스크래핑할 수 없습니다. Cloudflare, DataDome, HUMAN 등은 알려진 클라우드 IP로부터의 요청을 제한하거나 차단합니다.

대부분의 기존 언론 보도는 불법적인 주거용 프록시 공급에 초점을 맞추어 왔습니다: 봇넷 (botnets) (Aisuru, Kimwolf), 트로이 목마화된 앱 (HUMAN Security의 PROXYLIB 공개), 사전 감염된 IoT 하드웨어 (Google/Mandiant의 IPIDEA 차단). 이들은 악의적인 행위자들입니다.

반면, 합법적인 공급 측면은 훨씬 적은 조사를 받았습니다. 오늘날 Bright Data는 자체 마케팅을 통해 파트너 앱에 내장된 동의 SDK (Software Development Kit)를 통해 확보한 "1억 5천만 개 이상의 IP"를 광고하며, 세계 최대의 주거용 프록시 (Residential Proxy) 네트워크라고 주장합니다. 본 연구는 해당 SDK가 어떻게 작동하는지, 어떤 플랫폼들이 이를 탑재했는지, 그리고 왜 커넥티드 TV (Connected TV, CTV)가 궁극적인 주거용 프록시인지에 대해 기록합니다.

왜 커넥티드 TV (CTV)가 이상적인 프록시인가

커넥티드 TV, 일명 스마트 TV (Smart TV)는 거의 완벽한 주거용 프록시입니다. 휴대폰과 비교하면 다음과 같습니다:

| 요소 | 휴대폰 | 스마트 TV / CTV |
| :--- | :--- | :|
| 전력 | 하루 중 대부분 배터리 사용 | 항상 전원 연결됨 |
| 네트워크 | WiFi + 셀룰러 | 항상 WiFi, 고속 |
| ... | |

TV는 배터리가 1%가 되거나, WiFi 네트워크 사이를 이동하거나, 사용자가 잠든 사이에 잠기지 않습니다. 일부 파트너 퍼블리셔(Publisher)들은 개인정보 처리방침 (Privacy Policy)에 Bright Data와의 관계를 공개하기도 합니다. PlayWorks가 그 한 예입니다. 하지만 개인정보 처리방침 공개는 TV에 있어 잘못된 통제 지점 (Control Surface)입니다. 리모컨의 방향키로 탐색하는 법적 문서를 스크롤하기는 어렵고, 앱 내 동의 대화 상자 (Consent Dialog)는 Bright Data의 유료 고객이 사용자의 가정용 인터넷을 통해 스크래핑 (Scraping) 트래픽을 라우팅하려 한다는 사실을 제대로 전달하지 못합니다.

The Verge가 기록한 Roku 앱인 Petflix는 대표적인 사례입니다. 이 앱의 선택 동의 (Opt-in) 화면에는 다음과 같이 적혀 있습니다: "더 적은 광고와 함께 Petflix를 무료로 즐기기 위해, 귀하는 Bright Data가 인터넷에서 공개 웹 데이터를 다운로드할 수 있도록 귀하의 기기 자원과 IP 주소를 가끔 사용하는 것을 허용하게 됩니다. Bright Data는 승인된 비즈니스 관련 사용 사례를 위해서만 귀하의 IP 주소를 사용할 것입니다. 귀하의 IP 주소를 제외한 어떠한 개인 정보도 접근하거나 수집하지 않습니다. 끝." Petflix의 대화 상자는 "가끔"이라고 말합니다. 하지만 SDK의 공개적으로 쿼리 가능한 설정 (Config)에는 max_bw_monthly_wifi: 200,000,000,000 바이트 — 즉, 기본 월간 WiFi 예산이 200GB로 설정되어 있습니다.

Bright Data가 파트너로 명시하는 곳

Bright Data는 파트너 매니페스트 (partner manifest) 엔드포인트를 공개합니다. 이 엔드포인트는 인증이 필요하지 않으며 누구나 가져올 수 있습니다. 공개된 소스를 통해 높은 신뢰도로 식별할 수 있었던 매니페스트 내의 이름들은 다음과 같습니다:

기타 항목들(desoline, free_time, ott_studio, global_microtrading, m_m_media, easystaff_lp)도 존재하지만, 공개된 소스로부터 식별하기가 더 어렵습니다. bright_screensavers, bright_videos, 그리고 brightdata는 Bright Data 자체 앱입니다.

파트너 목록이 증명하는 바에 대한 참고 사항: Bright Data의 설정(config)에 목록이 포함되어 있다는 것은 특정 시점에 통합(integration)이 존재했을 수도 있음을 의미합니다. 이것이 특정 퍼블리셔(publisher)의 현재 배포 중인 앱에 SDK가 실제 운영 환경(production)에서 포함되어 있음을 그 자체로 증명하는 것은 아닙니다. 이름이 명시된 모든 퍼블리셔에 대해서는 앱별 검증이 필요합니다.

파트너 목록이 직접적으로 증명하는 것:

Bright Data는 이 명단을 **인증되지 않은 공개 엔드포인트 (unauthenticated public endpoint)**를 통해 배포합니다.
최소 3개의 CTV 중심 엔티티(PlayWorks, CloudTV, Longvision)가 사용자의 기기를 주거용 프록시 출구 노드 (residential proxy exit nodes)로 수익화했습니다. 특히 PlayWorks는 자체 마케팅 자료에 따라 주요 TV 플랫폼 및 ISP 전반에 걸쳐 CTV 배포를 보고하고 있으며, 도달 범위는 수억 가구에 달합니다.

Bright Data SDK는 어떻게 사용자의 기기를 주거용 프록시 출구 노드로 전환하는가?

Bright Data SDK는 공개적으로 문서화된 상용 제품으로, Bright Data의 SDK 통합 문서(웹을 위한 JavaScript 변형 포함)를 통해 퍼블리셔에게 제공됩니다. 다음 내용은 배포된 iOS 프레임워크를 역공학 (reverse-engineering)하고 30일간의 런타임 트래픽을 계측 (instrumenting)하여 얻은 결과물을 바탕으로 해당 공개 영역을 확장하여 설명합니다.

SDK는 파트너 앱 내부에 iOS 프레임워크 (brdsdk.framework) 형태로 포함되어 배포됩니다. 저는 이 바이너리를 역공학 (reverse-engineered)하였으며, 동의를 거쳐 설치된 파트너 앱 내에서 SDK를 실행하는 연구용 플릿 (research fleet)으로부터 30일간의 트래픽을 캡처했습니다.

인증되지 않은 설정 (The Unauthenticated Config)

SDK는 실행될 때마다 다음을 호출합니다:

GET <https://clientsdk.bright-sdk.com/sdk_config_ios.json>?appid=<bundle>&ver=<sdk-version>&uuid=sdk-ios-<32hex>

이 엔드포인트는 유의미한 의미에서의 인증 과정을 거치지 않습니다. 서버는 오직 두 가지 쿼리 파라미터인 appid (파트너 앱의 App Store 등록 정보에서 찾을 수 있는 앱 번들 ID)와 ver (SDK 버전 문자열)로만 게이트를 유지합니다. 이 값들과 무작위로 생성된 UUID를 제공하면, 서버는 실제 기기가 받는 것과 동일한 응답을 반환합니다: 기능 플래그 (feature flags), 유휴 상태 감지 임계값 (배터리 %, CPU/메모리 상한선, WiFi 대 셀룰러 규칙), 국가별 대역폭 계층 (bandwidth tiers), 그리고 앞서 보여드린 파트너 매니페스트 (partner manifest)입니다. 이 각각의 분기들은 그 자체로 조사할 가치가 있습니다: 기기가 릴레이 (relay)할 자격이 있는지 결정하는 유휴 규칙, 피어 트래픽 (peer traffic)을 VPN 우회하여 라우팅하는 플래그, 여러 플랫폼에 걸친 설치 정보를 하나의 ID로 엮어주는 맵, 그리고 국가별 대역폭 제한 (bandwidth caps) 등이 있습니다.

피어 터널 (The Peer Tunnel)

설정 값을 가져온 후, SDK는 다음 주소로 지속적인 웹소켓 (WebSocket)을 엽니다:

wss://proxyjs.brdtnet.com:443

이 호스트 이름은 AWS Global Accelerator IP (이 글을 쓰는 시점 기준으로 3.33.193.183, 15.197.193.114)로 해석됩니다. TLS 인증서는 CN=*.luminatinet.com입니다. 이는 Bright Data의 2018년 이전 법인명인 Luminati Networks의 도메인입니다. 리브랜딩은 2018년에 공개적으로 발표되었습니다. 현재 활성화된 SDK 인프라는 여전히 레거시 (legacy) 인증서로 실행되고 있으며, 이는 유용한 탐지 피벗 (detection pivot)이 됩니다. 즉, 현재 고객 대상 프록시 서비스는 brightdata.com 브랜드 도메인에서 운영되므로, 네트워크상의 luminatinet.com 또는 brdtnet.com 트래픽은 고객 측의 Bright Data 사용이 아닌, 구체적으로 피어 터널 (peer-tunnel) 평면 (plane)에 해당합니다. 서버는 자신을 uWebSockets: 20으로 식별합니다.

피어 엔드포인트 (peer endpoint)는 업그레이드를 위해 어떠한 인증도 요구하지 않습니다. 서버는 TLS가 유효한 모든 WebSocket 업그레이드를 수락하며, 연결된 클라이언트에게 클라이언트의 공인 IP (public IP)를 에코 (echo)하여 애플리케이션 계층 프레임 (application-layer frame)을 즉시 푸시 (push)합니다. 그 지점부터 핸드셰이크 (handshake)가 전개됩니다:

Server → client: tunnel_init
세션을 설정하고 클라이언트의 공인 IP를 반환합니다.

Server → client: cid_set
서버는 클라이언트에게 <IP>-<token>/ls<N>c<M>p443_<IP>_<counter> 형식의 세션 추적 식별자 (session-tracking identifier)를 할당합니다. 우리는 이 형식이 실제 기기에서 캡처된 SDK의 텔레메트리 (telemetry) 트래픽에 존재하는 cid 필드와 일치함을 확인했습니다.

Server → client: status_get
서버는 기기의 유휴 상태 (idle state), 배터리, 네트워크 유형, 사용 가능한 대역폭 (bandwidth)을 폴링 (poll)합니다. 기기는 다음과 같은 연속적인 텔레메트리 피드 (telemetry feed)로 응답합니다:
idle, wifi_connected, mobile_connected, mobile_type (LTE/5G), roaming, battery_level, using_battery, screen_on, on_call, cpu_usage, mem_usage, raw_bw, bw, ipv6_supported, appid (호스트 앱), sdk_version, platform, 그리고 할당된 cid.
이는 호스트 앱 발행자가 선택한 텍스트로 구성된 동의 대화 상자 (consent dialog)를 통해 제3자에게 전달되는 물리적 기기 상태의 연속적인 피드입니다.

핸드셰이크 완료 (Handshake complete).
기기가 유리한 상태를 보고하면, 서버의 작업 매칭 계층 (job-matching layer)은 cmd_tun 프레임을 푸시할 수 있는 상태가 됩니다. 이는 SDK가 사용자의 주거용 IP (residential IP)를 소스로 사용하여 제3자 사이트에 대해 HTTP 요청으로 실행하는 개별 스크래핑 작업 (scraping-job) 지침입니다.

WebSocket 상의 모든 프레임은 고정된 엔벨로프 (envelope)를 가진 일반 JSON입니다:

{"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error", "cmd": <command>, "cookie": <correlation-id>, "err_code": 0, "msg": { ...payload... }}

바이너리에서 추출되어 네트워크 상에서 검증된 전체 명령 어휘 (command vocabulary)는 다음과 같습니다:

SDK가 사용자를 "유휴 (idle)" 상태로 간주할 때

설정 파일에는 장치가 타인의 트래픽을 중계 (relay)할 자격이 생기는 시점에 대한 명시적인 규칙서 (rulebook)가 포함되어 있습니다:

`"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 플래그(flag)는 주목할 만합니다. 여기서 "유휴 (idle)" 상태란 사용자가 장치 앞에 없다는 것을 의미하지 않습니다. 이는 장치의 CPU, 메모리, 배터리가 SDK의 임계값 (thresholds) 내에 있음을 의미합니다. 통화 중이거나 화면을 활발히 읽고 있는 사용자라도 중계 목적상으로는 "유휴" 상태로 간주됩니다.

교차 플랫폼 신원 연결 (Cross-Platform Identity Linkage)

설정 파일에는 dual_pairing 맵 (map)도 포함되어 있습니다:

"dual_pairing": {

"ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"]

}

이는 동일한 브랜드의 iOS, Windows, macOS 설치본을 하나의 엔티티 (entity)로 묶는 서버 측 맵입니다. 이는 공개된 설정 파일 내에 문서화된 교차 플랫폼 신원 스티칭 (identity stitching)입니다. 미래를 내다보는 필드가 하나 더 있습니다: http3_enabled: true. 이 SDK는 이미 QUIC 기반의 피어 전송 (peer transport)을 위한 플래그를 배포하고 있습니다. 향후 버전에서는 피어 터널 (peer tunnel)을 TCP/443에서 UDP/443으로 이동할 수 있으며, 이는 WebSocket을 탐지하기 위해 TCP 연결 추적 (connection tracking)에 의존하는 방어자들의 탐지를 무력화할 것입니다.

검사 우회 (The Inspection Bypass)

SDK의 설정에는 use_netifs: true라는 플래그가 포함되어 있습니다. 이 플래그는 SDK 바이너리 내의 코드를 트리거하여, 시스템 기본 경로(system default route)를 사용하는 대신 특정 필수 인터페이스(en0 (WiFi) 또는 pdp_ip0 (cellular))를 사용하여 NWConnection을 생성하도록 합니다.

iOS의 경우, 이는 설정된 모든 VPN의 tun0 인터페이스를 완전히 우회합니다. 앱의 나머지 HTTPS 트래픽이 VPN을 통과하더라도, 피어 터널(peer tunnel)은 사용자가 설정한 VPN을 가로지르지 않습니다.

우리는 이를 경험적으로 관찰했습니다. 저의 연구 환경에는 투명 TLS 인터터셉션(transparent TLS interception)이 포함되어 있습니다. 포트 443이 검사기(inspector)로 명시적으로 리다이렉션되었음에도 불구하고, SDK가 수행하는 모든 HTTPS 호출 중 proxyjs.brdtnet.com:443으로 향하는 피어 터널을 제외한 모든 호출을 캡처했습니다. 이 우회 방식은 Apple의 문서화된 NWParameters.requiredInterface API를 사용합니다.

이 SDK가 각 평면(plane)마다 하나씩, 총 **두 개의 독립적인 검사 우회(inspection bypasses)**를 사용한다는 점을 강조할 가치가 있습니다:

거실의 스마트 TV는 AI 스크래핑 경제의 노드입니다

요약

핵심 포인트

댓글