สมาร์ตทีวีในห้องนั่งเล่นคือโหนดหนึ่งของเศรษฐกิจการสแครปข้อมูลด้วย AI

 (blog.includesecurity.com)
1 คะแนน โดย GN⁺ 3 시간 전 | 1 ความคิดเห็น | แชร์ทาง WhatsApp
  • Bright Data SDK ที่ฝังอยู่ในแอปผู้บริโภค จะเปลี่ยนมือถือหรือสมาร์ตทีวีให้เป็นโหนดทางออกของพร็อกซีที่อยู่อาศัยภายใต้ความยินยอมของผู้ใช้ และส่งทราฟฟิกเว็บสแครปของลูกค้าผ่าน IP ภายในบ้าน
  • พร็อกซีที่อยู่อาศัย คือวิธีอ้อมเพื่อเข้าถึงเว็บไซต์เป้าหมายด้วย IP ของลูกค้าที่อยู่อาศัยแบบชำระเงิน ในสภาพแวดล้อมที่ Cloudflare, DataDome, HUMAN และรายอื่น ๆ จำกัดหรือบล็อกคำขอจาก IP คลาวด์ที่รู้จัก
  • Connected TV ไม่มีข้อจำกัดเรื่องแบตเตอรี่ เชื่อมต่อ Wi-Fi ตลอดเวลา และทำงานในสถานะสแตนด์บายได้ 24/7 จึงเป็นเงื่อนไขของพร็อกซีที่มี ความพร้อมใช้งานตลอดเวลา และ ถูกปล่อยทิ้งไว้ได้ มากกว่ามือถือ
  • iOS SDK รับเกณฑ์สถานะว่าง ขีดจำกัดแบนด์วิดท์ และรายชื่อพาร์ตเนอร์จาก endpoint การตั้งค่าที่ไม่มีการยืนยันตัวตน แล้วเปิด WebSocket peer tunnel เพื่อจัดการเทเลเมทรีสถานะอุปกรณ์และงานสแครป cmd_tun
  • แนวทางป้องกันเน้นที่การบล็อก DNS ของ proxyjs.* และ clientsdk.*, การกรอง SNI, การตรวจจับลายนิ้วมือใบรับรอง TLS และการสแกนไบนารีแอปผ่าน MDM โดย use_netifs บน iOS เป็นข้อจำกัดที่หลบเลี่ยงการมองเห็นแบบอิง VPN

ภาพรวม

  • นอกเหนือจากการคัดค้านระดับชุมชนต่อการสร้างดาต้าเซ็นเตอร์เพื่อเพิ่มขีดความสามารถด้าน AI ยังมีโครงสร้างที่ทำให้อุปกรณ์ภายในบ้านสามารถถูกใช้เพื่อเก็บรวบรวมข้อมูลแบบกระจายสำหรับการฝึก AI ได้
  • Bright Data ขายสิทธิ์เข้าถึงเครือข่ายพร็อกซีที่อยู่อาศัยซึ่งมี IP ภายในบ้านมากกว่า 400M+ รายการ สำหรับให้ลูกค้าใช้ส่งทราฟฟิกเว็บสแครป โดยแหล่งที่มาคือ SDK ที่ฝังอยู่ในแอปผู้บริโภค
  • SDK ดังกล่าวจะเปลี่ยนมือถือหรือสมาร์ตทีวีให้เป็นโหนดทางออกภายใต้ความยินยอมของผู้ใช้ โดยการวิเคราะห์นี้มุ่งดูวิธีการทำงานของ SDK, แพลตฟอร์มที่ใช้กระจาย และเหตุผลที่ทีวีเชื่อมต่ออินเทอร์เน็ตเหมาะกับการเป็นพร็อกซีเว็บสแครปสำหรับโมเดล AI

ทำไมเรื่องนี้สำคัญตอนนี้

  • บริษัท AI พึ่งพาคอนเทนต์จากการทำเว็บสแครปสำหรับการพรีเทรน การค้นหา/การดึงข้อมูลเสริมการค้นหา agent grounding และฟีเจอร์ค้นหา
  • เว็บสมัยใหม่เป็นสภาพแวดล้อมที่สแครปจากดาต้าเซ็นเตอร์ได้ไม่ง่าย โดย Cloudflare, DataDome, HUMAN และรายอื่น ๆ จำกัดหรือบล็อกคำขอจาก IP คลาวด์ที่รู้จัก
  • ทางเลือกคือ พร็อกซีที่อยู่อาศัย ที่เข้าถึงเว็บไซต์เป้าหมายจาก IP ของลูกค้าที่อยู่อาศัยแบบชำระเงิน เช่น การเชื่อมต่อของสมาชิก Comcast หรือ T-Mobile
  • คำพูดที่อ้างจากรายงานของ Krebs ในเดือนตุลาคม 2025 ระบุว่า “พร็อกซีล้นเกินจาก Aisuru และแหล่งอื่น ๆ กำลังกระตุ้นความพยายามเก็บเกี่ยวข้อมูลขนาดใหญ่ที่เชื่อมโยงกับโครงการ AI หลายโครงการ”
  • งานวัดผลเชิงวิชาการ ย้อนหลังไปถึงปี 2019 พบว่าเครือข่ายลักษณะนี้ถูกใช้ในทางที่ผิดอย่างท่วมท้น และ FBI ก็ออกคำเตือนอย่างเป็นทางการเมื่อต้นปีนี้
  • รายงานส่วนใหญ่ก่อนหน้านี้มุ่งไปที่แหล่งจัดหาพร็อกซีที่อยู่อาศัยผิดกฎหมาย เช่น บอตเน็ตอย่าง Aisuru และ Kimwolf, แอปที่ถูกทำให้เป็นโทรจันอย่าง PROXYLIB, หรือฮาร์ดแวร์ IoT ที่ติดเชื้อมาก่อนอย่าง IPIDEA
  • ฝั่งอุปทานที่ถูกกฎหมายได้รับการตรวจสอบค่อนข้างน้อยกว่า โดย Bright Data โฆษณาว่าเป็นเครือข่ายพร็อกซีที่อยู่อาศัยใหญ่ที่สุดในโลกตามเกณฑ์การตลาดของตนเอง และโปรโมต “150M+ IPs” ที่อิงจาก SDK แบบยินยอมซึ่งฝังในแอปพาร์ตเนอร์

ทำไม Connected TV จึงเป็นพร็อกซีในอุดมคติ

ปัจจัย มือถือ สมาร์ตทีวี / CTV
พลังงาน ใช้แบตเตอรี่เกือบทั้งวัน เสียบไฟตลอดเวลา
เครือข่าย Wi-Fi + เซลลูลาร์ Wi-Fi ตลอดเวลา, ความเร็วสูง
เวลาทำงาน เป็นช่วง ๆ 24/7 ในสถานะสแตนด์บาย
ขีดจำกัดแบนด์วิดท์ ต่ำ, ถูกจำกัดโดยเซลลูลาร์ แทบไม่จำกัด
ความใส่ใจของผู้ใช้ ใช้งานอย่างใกล้ชิด มักถูกปล่อยทิ้งไว้
UI การยินยอม ข้อความบนหน้าจอมือถือ ข้อความที่ต้องเลื่อนดูด้วยปุ่มทิศทางบนรีโมตทีวี
การกำกับดูแลจากองค์กร·ครอบครัว สูงกว่า เช่น MDM, mobile EDR แทบไม่มี
  • ทีวีเป็นอุปกรณ์ที่แบตเตอรี่ไม่มีวันเหลือ 1%, ไม่ย้ายไปมาระหว่างเครือข่าย Wi-Fi บ่อย ๆ และไม่ถูกล็อกขณะผู้ใช้หลับ
  • ผู้เผยแพร่พาร์ตเนอร์บางรายเปิดเผยความสัมพันธ์กับ Bright Data ในเอกสารนโยบายความเป็นส่วนตัว โดย นโยบายความเป็นส่วนตัวของ PlayWorks เป็นหนึ่งในตัวอย่าง
  • การเปิดเผยในนโยบายความเป็นส่วนตัวไม่ใช่จุดควบคุมที่เหมาะกับทีวี เพราะการเลื่อนเอกสารกฎหมายด้วยปุ่มทิศทางบนรีโมตทำได้ยาก และหน้าต่างยินยอมในแอปก็มีโครงสร้างที่ไม่สามารถสื่อได้ว่าลูกค้า Bright Data แบบชำระเงินกำลังส่งทราฟฟิกสแครปผ่านอินเทอร์เน็ตภายในบ้านของผู้ใช้
  • หน้าจอ opt-in ของแอป Roku ชื่อ Petflix ที่ The Verge บันทึกไว้ ใช้ข้อความว่า “เพื่อให้เห็นโฆษณาน้อยลงและใช้งานฟรี โปรดอนุญาตให้ Bright Data ใช้ทรัพยากรส่วนเกินของอุปกรณ์และที่อยู่ IP ของคุณเป็นครั้งคราว เพื่อดาวน์โหลดข้อมูลเว็บสาธารณะจากอินเทอร์เน็ต”
  • แม้หน้าต่างของ Petflix จะใช้คำว่า “เป็นครั้งคราว” แต่ max_bw_monthly_wifi: 200,000,000,000 ในการตั้งค่า SDK ที่เปิดให้ดูสาธารณะระบุว่างบ Wi-Fi เริ่มต้นต่อเดือนอยู่ที่ 200GB

เป้าหมายที่ Bright Data ระบุว่าเป็นพาร์ตเนอร์

  • Bright Data เปิดเผย endpoint manifest ของพาร์ตเนอร์ที่ใครก็เข้าถึงได้โดยไม่ต้องยืนยันตัวตน
  • รายการระบุตัวตนที่เชื่อถือได้สูงตามแหล่งข้อมูลสาธารณะ
Partner ID Entity ขนาด
playworks_digital PlayWorks Digital Ltd มีเกม CTV มากกว่า 400 รายการ เข้าถึงครัวเรือนที่มีทีวีราว 250M ผ่าน Comcast·Sky·Cox·LG·Samsung·Vizio·Roku
cloudtv CloudTV ถูกรวมเข้ากับแบรนด์ทีวี 125+ แบรนด์และ OEM 15+ ราย
longvision_media_hong_kong_co_limited Longvision Media HK (LongTV) ผู้ใช้ OTT 5M ทั่วฮ่องกงและมาเลเซีย
viber_media_s_r_l Viber Media S.à r.l. (Rakuten) ผู้ใช้รายเดือนของ Viber Messenger 250M–820M
supercent_inc Supercent ผู้เผยแพร่มือถือเกาหลีอันดับ 1 ตามจำนวนดาวน์โหลดในปี 2023
moonfrog_labs_private_limited Moonfrog Labs Teen Patti Gold เพียงแอปเดียวมี MAU ราว 10M และถูกซื้อกิจการด้วยมูลค่า 90 ล้านดอลลาร์
hola_networks Hola Networks เป็นบริษัทแม่ตามลำดับเครือของ Bright Data และฐานผู้ใช้สูงสุดของ Hola ตามเกณฑ์การตลาดในอดีตอยู่ในช่วงหลายสิบล้านถึงราว 100M+
  • 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 เผยแพร่รายชื่อนี้ผ่าน public endpoint ที่ไม่มีการยืนยันตัวตน และมีผู้ประกอบการฝั่ง CTV อย่างน้อยสามราย ได้แก่ PlayWorks, CloudTV และ Longvision ที่นำอุปกรณ์ของผู้ใช้ไปสร้างรายได้ในฐานะ residential proxy exit node
  • PlayWorks อ้างในเอกสารการตลาดของตนเองว่ามีการกระจาย CTV ครอบคลุมทั้งแพลตฟอร์มทีวีหลักและ ISP พร้อมตัวเลขการเข้าถึงในระดับหลายร้อยล้านครัวเรือน
โฆษณา

Bright Data SDK เปลี่ยนอุปกรณ์ของผู้ใช้ให้เป็นโหนดทางออกของพร็อกซีที่อยู่อาศัยอย่างไร

  • Bright Data SDK เป็นผลิตภัณฑ์เชิงพาณิชย์ที่มีเอกสารสาธารณะ พร้อม เอกสารการผสานรวม SDK สำหรับผู้เผยแพร่ และ JavaScript variant สำหรับเว็บ

  • การวิเคราะห์นี้อ้างอิงจากการรีเวิร์สเอนจิเนียร์ริง iOS framework ที่กำลังแจกจ่ายอยู่ และการวัดทราฟฟิกขณะรันไทม์เป็นเวลา 30 วัน

  • SDK ถูกแจกจ่ายในรูปของ iOS framework ชื่อ brdsdk.framework ภายในแอปพาร์ตเนอร์

  • การตั้งค่าที่ไม่มีการยืนยันตัวตน

    • ทุกครั้งที่เริ่มทำงาน SDK จะเรียกคำขอต่อไปนี้
    • GET https://clientsdk.bright-sdk.com/sdk_config_ios.json/…;
    • เอนด์พอยต์นี้ทำงานโดยแทบไม่มีการยืนยันตัวตนที่มีความหมาย และเซิร์ฟเวอร์ตรวจสอบเพียงพารามิเตอร์คิวรีสองตัวคือ appid ซึ่งเป็น App bundle ID และ ver ซึ่งเป็นสตริงเวอร์ชันของ SDK
    • หากระบุ bundle ID ที่หาได้จากหน้า App Store ของแอปพาร์ตเนอร์ พร้อมสตริงเวอร์ชัน SDK และ UUID ที่สุ่มขึ้นมา ก็จะได้การตั้งค่าชุดเดียวกับที่อุปกรณ์จริงได้รับ
    • คำตอบประกอบด้วยฟีเจอร์แฟล็ก, ค่า threshold สำหรับตรวจจับการว่างงาน เช่น สัดส่วนแบตเตอรี่, เพดาน CPU/หน่วยความจำ, กฎ Wi‑Fi/เซลลูลาร์, ระดับแบนด์วิดท์แยกตามประเทศ และโครงสร้างที่มี manifest ของพาร์ตเนอร์
    • ภายในการตั้งค่ามีกฎ idle ที่กำหนดว่าอุปกรณ์จะมีสิทธิ์รีเลย์ทราฟฟิกเมื่อใด, แฟล็กสำหรับ route ทราฟฟิกของเพียร์ผ่านบริเวณรอบ VPN, map ที่เชื่อมการติดตั้งข้ามแพลตฟอร์มให้เป็นตัวตนเดียวกัน และขีดจำกัดแบนด์วิดท์รายประเทศ

  • Peer tunnel

    • หลังดึงการตั้งค่าแล้ว SDK จะเปิด WebSocket แบบคงอยู่ไปยังที่อยู่นี้
    • wss://proxyjs.brdtnet.com:443
    • ชื่อโฮสต์นี้ ณ เวลาที่เขียนบทความ resolve ไปยัง 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 ฝั่งไคลเอนต์ แต่เป็นเบาะแสในการระบุ peer tunnel plane
    • ปัจจุบันบริการพร็อกซีที่ให้ลูกค้าใช้งานทำงานบนโดเมนแบรนด์ brightdata.com ดังนั้นทราฟฟิก luminatinet.com และ brdtnet.com ในเครือข่ายจึงเป็น peer tunnel plane
    • เซิร์ฟเวอร์ระบุตัวเองว่า uWebSockets: 20
    • เอนด์พอยต์ฝั่งเพียร์ไม่ต้องการการยืนยันตัวตนสำหรับการอัปเกรด และหลังรับ WebSocket upgrade ที่มี TLS ถูกต้องแล้ว จะส่งแอปพลิเคชันเลเยอร์เฟรมที่คืนค่า public IP ของไคลเอนต์กลับมาทันที
    • ลำดับขั้นของแฮนด์เชก
      1. เซิร์ฟเวอร์ → ไคลเอนต์ tunnel_init: สร้างเซสชันและคืนค่า public IP ของไคลเอนต์
      1. เซิร์ฟเวอร์ → ไคลเอนต์ cid_set: กำหนดตัวระบุสำหรับติดตามเซสชันในรูปแบบ <IP>-<token>/ls<N>c<M>p443_<IP>_<counter> และยืนยันว่าตรงกับฟิลด์ cid ใน telemetry ของอุปกรณ์จริง
      1. เซิร์ฟเวอร์ → ไคลเอนต์ status_get: polling สถานะการว่างของอุปกรณ์, แบตเตอรี่, ประเภทเครือข่าย, แบนด์วิดท์ที่ใช้ได้ และอุปกรณ์จะตอบกลับด้วย telemetry ต่อเนื่อง เช่น 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. หลังแฮนด์เชกเสร็จ หากอุปกรณ์รายงานสถานะที่เอื้ออำนวย เลเยอร์จับคู่งานของเซิร์ฟเวอร์สามารถ push เฟรม cmd_tun มาได้ และ SDK จะนำไปใช้รันคำขอ HTTP ไปยังเว็บไซต์ของบุคคลที่สามโดยใช้งาน residential IP ของผู้ใช้เป็นต้นทาง
    • ทุกเฟรมใน WebSocket เป็น plain JSON ที่มี envelope คงที่
    • {"type": "ipc_call"|"ipc_post"|"ipc_result"|"ipc_error","cmd": <command>, "cookie": <correlation-id>,"err_code": 0, "msg": { ...payload... }}
    • คำสั่งที่ดึงออกมาจากไบนารีและยืนยันได้จากการสื่อสารจริง
    • | ทิศทาง | cmd | วัตถุประสงค์ |
    • |---|---|---|
    • | Server → Client | tunnel_init | เปิดเซสชัน, echo public IP |
    • | Server → Client | cid_set | กำหนดตัวระบุเซสชัน |
    • | Server → Client | status_get | polling สถานะ idle, แบตเตอรี่ และแบนด์วิดท์ของอุปกรณ์ |
    • | Server → Client | cmd_tun / tun | ส่งงาน scraping |
    • | Server → Client | dns | ขอให้ resolve 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 | ส่ง log สำหรับวินิจฉัยไปยังเซิร์ฟเวอร์ |
    • ไม่มี message signature, HMAC, client certificate หรือ device attestation และสิ่งที่แยกเพียร์ที่ได้รับงานจริงออกจากกันมีเพียงชั้น TLS กับตัวกรองชื่อเสียง IP ของเซิร์ฟเวอร์เท่านั้น
    • สำหรับผู้อ่านที่คุ้นเคยกับการออกแบบโปรโตคอลของมัลแวร์เชิงพาณิชย์ ระดับความปลอดภัยนี้ในทางปฏิบัติต่ำกว่า C2 ทั่วไปเสียอีก

  • เงื่อนไขที่ SDK มองว่า “idle”

    • การตั้งค่าระบุกฎสถานะของอุปกรณ์ที่สามารถรีเลย์ทราฟฟิกของผู้อื่นได้
    "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 คำว่า “idle” จึงไม่ได้หมายความว่าผู้ใช้อยู่ห่างจากอุปกรณ์ แต่หมายถึง CPU, หน่วยความจำ และแบตเตอรี่อยู่ภายใน threshold ของ SDK
    • แม้ผู้ใช้จะกำลังคุยโทรศัพท์หรือกำลังอ่านหน้าจออย่างจริงจัง ก็ยังถูกนับเป็นสถานะ idle เพื่อวัตถุประสงค์ในการรีเลย์

  • การเชื่อมตัวตนข้ามแพลตฟอร์ม

    • ภายในการตั้งค่ามี dual_pairing map ดังต่อไปนี้
    โฆษณา
    "dual_pairing": {
  "ios_com.brd.earnapp": ["win_earnapp.com", "mac_com.earnapp"]
}
    • map นี้เป็นโครงสร้างการเชื่อมโยงฝั่งเซิร์ฟเวอร์ที่ผูกการติดตั้ง iOS, Windows และ macOS ของแบรนด์เดียวกันเข้าด้วยกันเป็นเอนทิตีเดียว
    • ฟิลด์ http3_enabled: true เป็นแฟล็กสำหรับการส่งผ่านเพียร์บน QUIC และเวอร์ชันในอนาคตอาจย้าย peer tunnel จาก TCP/443 ไปเป็น UDP/443
    • ผู้ป้องกันที่ตรวจจับ WebSocket ด้วยการติดตามการเชื่อมต่อ TCP อาจพบว่าวิธีตรวจจับนี้ใช้ไม่ได้อีกเมื่อมีการย้ายไปยัง UDP/443

  • การหลบเลี่ยงการตรวจสอบ

    • แฟล็ก use_netifs: true ในการตั้งค่า SDK เป็นเงื่อนไขที่ทำให้โค้ดไบนารีของ SDK สร้าง NWConnection บนอินเทอร์เฟซบังคับเฉพาะ แทนที่จะใช้เส้นทางปริยายของระบบ
    • อินเทอร์เฟซบังคับดังกล่าวคือ en0 สำหรับ Wi‑Fi หรือ pdp_ip0 สำหรับเซลลูลาร์
    • บน iOS วิธีนี้จะ bypass อินเทอร์เฟซ tun0 ของ VPN ที่ผู้ใช้ตั้งค่าไว้โดยสมบูรณ์ และแม้ทราฟฟิก HTTPS อื่นของแอปจะผ่าน VPN แต่ peer tunnel จะไม่ผ่าน VPN ที่ผู้ใช้ตั้งค่าไว้

  • สภาพแวดล้อมการวิจัยการดักจับ TLS แบบโปร่งใสสามารถจับทุกการเรียก HTTPS ของ SDK ได้ แต่กลับไม่สามารถจับ peer tunnel ของ proxyjs.brdtnet.com:443 ได้ ทั้งที่พอร์ต 443 ถูกรีไดเร็กต์ไปยังตัวตรวจสอบอย่างชัดเจนแล้ว

    • การหลบเลี่ยงใช้ API NWParameters.requiredInterface ที่ Apple มีเอกสารอธิบายไว้
    • SDK ใช้การหลบเลี่ยงการตรวจสอบ 2 แบบที่แยกจากกัน
    • Control plane: การดึงค่าคอนฟิกและ telemetry ping ทำงานบนพื้นฐานของ primitive CFHTTPMessage ของ CFNetwork แทน URLSession·NSURLConnection ทำให้เครื่องมือความปลอดภัยของแอปมือถือที่มักใช้การทำ instrumentation ระดับ URLSession, swizzling, network extension, และ URLProtocol subclass ใช้การไม่ได้ แต่ยังคงเคารพระบบพร็อกซี จึงยังคงมีการมองเห็นสำหรับนักวิจัยการดักจับ TLS
    • Data plane: peer tunnel ทำงานบนพื้นฐาน NWConnection ที่ตั้งค่า physical interface เป็น required interface ทำให้ VPN ใช้การไม่ได้ และรับประกันว่าการสแครปจะรันจาก IP ที่อยู่อาศัย
    • สำหรับทีมความปลอดภัยที่ใช้ MDM, การตรวจสอบทราฟฟิกผ่าน VPN ขององค์กร, หรือการควบคุมโดยผู้ปกครองบนเราเตอร์ในบ้าน ช่องทางที่อ่อนไหวที่สุดถูกออกแบบมาให้ข้ามชั้นการมองเห็นโดยตรง

การแบ่งระดับตามประเทศ

  • ในการตั้งค่ามีค่าเกณฑ์แบนด์วิดท์แยกตามประเทศ
โฆษณา
ประเทศ แบตเตอรี่ขั้นต่ำสำหรับรีเลย์ ขีดจำกัดรายวัน ขีดจำกัดรายเดือน
Uzbekistan 1% 1GB 30GB
Oman 1% 1GB 30GB
Qatar 20% 40MB 250MB
UAE 20% 40MB 250MB
default, worldwide 20% 50MB 500MB
  • อุปกรณ์ใน Uzbekistan และ Oman ได้รับอนุญาตให้ทำรีเลย์ได้จนแบตเตอรี่เหลือ 1% โดยมีขีดจำกัดรายวันสูงกว่าค่าเริ่มต้น 20 เท่า และขีดจำกัดรายเดือนสูงกว่าค่าเริ่มต้น 60 เท่า
  • อุปกรณ์ใน Qatar และ UAE ถูกจำกัดด้วยเพดานที่ต่ำกว่าค่าเริ่มต้น
  • ไม่อาจยืนยันได้ว่าทำไมจึงกำหนดระดับตามประเทศเช่นนี้ และทำได้เพียงคาดเดา
  • แม้แต่ปริมาณที่อนุญาตเริ่มต้นทั่วโลกก็ยังเปิดให้ทราฟฟิกของผู้อื่นผ่านอินเทอร์เน็ตบ้านของผู้ใช้ได้เดือนละ 500MB

การตั้งค่าทดสอบและระเบียบวิธี

  • ตลอด 30 วัน ได้ทำการดักจับผ่านพร็อกซีสำหรับสกัดกั้น TLS บนอุปกรณ์ iOS ที่รันแอปพาร์ตเนอร์ซึ่งติดตั้งแบบยินยอมแล้ว โดยแอปตัวอย่างรวมถึง XYO COIN ที่ฝัง Bright SDK
  • ทำ static analysis กับ brdsdk.framework version 1.532.120 และไบนารี iOS arm64
  • โฮสต์เนมเฉพาะ, ลายนิ้วมือใบรับรอง และโครงสร้างพื้นฐาน TLS ของ Bright Data เป็นสิ่งที่ใครก็ตามที่ส่งคำขอแบบเดียวกันสามารถสังเกตเห็นได้แบบสาธารณะ
  • ในเอกสารไม่มีข้อมูลระบุตัวตนรายเซสชันของ research fleet หรือ research client

ไทม์ไลน์

  • 11 พฤษภาคม 2026 ส่งอีเมลแจ้งเตือนก่อนเผยแพร่ไปที่ privacy@brightdata.com
  • จนถึงเวลาที่เผยแพร่ ยังไม่มีการตอบกลับต่อการแจ้งเตือนดังกล่าว

แนวทางป้องกัน

  • ทราฟฟิกทิ้ง fingerprint ที่ชัดเจนไว้ที่ขอบเครือข่าย และ SDK ถูกออกแบบให้ทิ้งสัญลักษณ์ที่ระบุตัวได้ไว้ในไบนารีของแอป
  • แนวทางที่ 1 การบล็อก DNS เป็นวิธีที่ง่ายและมีประสิทธิภาพสำหรับอุปกรณ์ที่ถูก route ผ่านเครือข่าย
    • proxyjs.brdtnet.com
    • proxyjs.luminatinet.com
    • proxyjs.bright-sdk.com
    • clientsdk.bright-sdk.com
    • clientsdk.brdtnet.com
  • การบล็อก proxyjs.* จะตัด peer tunnel และไม่กระทบลูกค้าที่ใช้งานบริการพร็อกซีของ Bright Data อย่างถูกต้องตามกฎหมายสำหรับลูกค้าในโดเมนอื่น
  • แนวทางที่ 2 การกรอง TLS SNI คือการบล็อกหรือแจ้งเตือน TLS handshake ที่ server_name ตรงกับ *.brdtnet.com, *.luminatinet.com, *.luminati.io
  • การกรอง SNI ทำงานที่ขอบเครือข่ายได้โดยไม่ต้องตรวจสอบ TLS
  • แนวทางที่ 3 การตรวจจับลายนิ้วมือใบรับรอง TLS คือการบล็อกหรือแจ้งเตือนตามลายนิ้วมือต่อไปนี้
    • .brdtnet.com → SHA256 313ce4ec7d5a51e5…
    • .luminatinet.com → SHA256 5028612e625befea…
  • ลายนิ้วมือใบรับรองมีเสถียรภาพจนกว่าจะมีการเปลี่ยนใบรับรอง Sectigo โดยใบรับรองปัจจุบันมีผลใช้ได้ถึงกลางปี 2026
  • เนื่องจากข้อจำกัดที่เกี่ยวข้องกับ use_netifs ทั้งสามระดับจึงทำงานได้ก็ต่อเมื่อทราฟฟิกผ่านขอบเครือข่ายเท่านั้น
  • เมื่ออุปกรณ์ iOS ใช้เครือข่ายเซลลูลาร์ การ bind use_netifs ของ SDK ทำให้ทราฟฟิกแบบเพียร์ข้ามเครือข่าย Wi‑Fi ขององค์กรไปได้โดยสมบูรณ์
  • มาตรการควบคุมเสริมสำหรับ fleet ของอุปกรณ์ที่มีการจัดการคือการสแกนไบนารีของแอปด้วย MDM โดยค้นหา Swift symbol BrdWebSocketFacade และ BrdNetwork.DNSResolver ในแอปที่ติดตั้ง และห้ามแอปที่มีสัญลักษณ์ดังกล่าวบนอุปกรณ์ของบริษัท
  • ผู้ใช้ตามบ้านที่กังวลเกี่ยวกับสมาร์ตทีวีหรือแอปมือถือบางตัวสามารถใช้วิธีบล็อกโฮสต์เนมข้างต้นในค่า DNS ของเราเตอร์ได้
  • ตัวอย่างเครื่องมือสำหรับการบล็อกได้แก่ Pi-hole, NextDNS, Cloudflare Gateway หรือความสามารถเทียบเท่าจาก ISP

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 3 시간 전
ความเห็นจาก Lobste.rs

  • พอพูดถึงโปรโตคอลนี้แล้ว ก็อาจทำ reverse honeypot ที่คอยสมัครใจส่งข้อมูลขยะที่สุ่มสร้างขึ้นไปกับทุกคำขอ ซึ่งน่าจะเป็นโปรเจ็กต์ vibe coding สนุก ๆ สำหรับใครก็ตามที่มีโทเค็นเหลือ

    • ดูเหมือนไม่จำเป็นต้องลงมือทำโปรโตคอลนี้จริง ๆ ด้วยซ้ำ จาก log จะเห็นว่า residential proxy พวกนี้จำนวนมากปกปิดตัวเองได้ล้มเหลวอย่างสิ้นเชิง เลยสามารถปล่อยข้อมูลขยะกลับไปได้แบบง่าย ๆ
      ไม่ต้องใช้ vibe coding เลยด้วยซ้ำ และมีเครื่องมือที่ทำแบบนี้ได้อยู่แล้วเป็นสิบ ๆ ตัว หลายตัวในนั้นก็ส่งข้อมูลขยะแบบไม่รู้จบให้พร็อกซีพวกนี้มาเกิน 1 ปีแล้ว

  • ผมไม่เข้าใจเลยว่าทำไมต้องต่อ TV หรือเครื่องใช้ไฟฟ้าอื่น ๆ เข้ากับอินเทอร์เน็ต ไม่มีเหตุผลดี ๆ ที่ต้องทำแบบนั้น

    • คนดู บริการสตรีมมิง บน TV การต่อ TV เข้ากับอินเทอร์เน็ตคือวิธีที่ง่ายที่สุดในการทำแบบนั้น