Smart TV w salonie jest niemal idealnym proxy. Zawsze podłączony do prądu, zawsze na szybkim WiFi, w trybie czuwania 24/7, z praktycznie nieograniczonym pasmem, rzadko pod nadzorem, bez MDM i EDR. Badacz Buchodi we współpracy z Include Security opisał 5 czerwca, jak firma Bright Data wykorzystuje dokładnie te cechy — zamieniając miliony telewizorów Samsung, LG, Roku i urządzeń mobilnych w węzły wyjściowe komercyjnej sieci proxy, przez którą płacący klienci scrapują internet, by trenować modele AI.
To nie jest włamanie. To nie jest malware w klasycznym sensie. To jest legalny SDK, instalowany za zgodą — zgodą wyklikaną strzałkami na pilocie. A jednak, jak pokazuje analiza techniczna, protokół, którym to działa, jest mniej bezpieczny niż typowe C2 złośliwego oprogramowania. To jest ta historia.
Dlaczego to jest temat dla cyberflux
Przez ostatnie tygodnie opisywaliśmy AI z dwóch stron: jako narzędzie ataku (Mythos, Codex znajdujący HTTP/2 Bomb) i jako cel (Langflow, prompt injection w Gemini). To jest trzecia strona, której jeszcze nie dotknęliśmy: infrastruktura pozyskiwania danych dla AI jako problem bezpieczeństwa.
Modele AI potrzebują danych z sieci — do pre-treningu, do retrieval, do ugruntowania agentów, do wyszukiwania. Ale współczesnej sieci nie da się scrapować z centrum danych. Cloudflare, DataDome i HUMAN blokują żądania ze znanych adresów chmurowych. Obejściem są proxy rezydencjalne — żądanie przepuszczone przez łącze abonenta Comcast czy T-Mobile dociera do celu z adresu IP należącego do prawdziwego domowego klienta. Nie do odróżnienia od normalnego ruchu.
Większość uwagi dotąd szła na nielegalną podaż takich proxy: botnety jak Aisuru, trojanizowane aplikacje, preinfekowany sprzęt IoT. FBI wydało w tym roku formalne ostrzeżenie. To są źli aktorzy i wszyscy o nich piszą. Strona legalna — firma, która robi to samo za zgodą wyklikania — dostała znacznie mniej uwagi. A robi to na skalę, którą sama reklamuje jako największą rezydencjalną sieć proxy świata.
Jak to działa
SDK Bright Data jest jawnym, komercyjnym produktem z publiczną dokumentacją. Buchodi poddał analizie wstecznej wersję iOS (brdsdk.framework 1.532.120) i przechwycił 30 dni ruchu z urządzeń testowych z zainstalowanym za zgodą SDK partnera. Mechanizm składa się z trzech warstw.
Niezabezpieczona konfiguracja. Przy każdym uruchomieniu SDK pobiera plik konfiguracyjny z serwera Bright Data. Endpoint jest w praktyce nieuwierzytelniony — bramkuje wyłącznie na podstawie identyfikatora aplikacji (dostępnego w App Store) i wersji SDK. Podaj te dwie wartości i dowolnie wygenerowany UUID, a serwer zwróci to samo, co prawdziwemu urządzeniu: flagi funkcji, progi wykrywania bezczynności, reguły pasma per kraj — i pełny manifest partnerów. Ten manifest jest publiczny i każdy może go pobrać.
Tunel peer. Po pobraniu konfiguracji SDK otwiera trwałe połączenie WebSocket do serwera Bright Data. I tu jest pierwszy szczegół, który zatrzymuje. Cytując Buchodiego wprost: nie ma podpisywania wiadomości, nie ma HMAC, nie ma certyfikatu klienta ani atestacji urządzenia — tylko warstwa TLS i filtr reputacji IP po stronie serwera decydują, które urządzenia dostają zadania. Dla czytelników znających projektowanie protokołów komercyjnego malware: to jest istotnie mniej bezpieczne niż typowe C2.
Przez ten tunel serwer dostaje ciągły strumień stanu fizycznego urządzenia — bezczynność, typ sieci, poziom baterii, czy ekran jest włączony, czy trwa rozmowa telefoniczna, użycie CPU i pamięci — a gdy urządzenie zgłosi korzystny stan, serwer wypycha cmd_tun: konkretne instrukcje zadań scrapujących, które SDK wykonuje jako żądania HTTP wobec stron trzecich, używając rezydencjalnego IP użytkownika jako źródła.
Certyfikat, który zdradza. Tunel działa na certyfikacie TLS z nazwą CN=*.luminatinet.com — domeną Luminati Networks, czyli nazwy Bright Data sprzed 2018 roku. To jest użyteczny punkt detekcji: usługa proxy dla klientów działa na domenach brightdata.com, więc każdy ruch do luminatinet.com czy brdtnet.com w twojej sieci to konkretnie płaszczyzna tunelu peer — nie legalne użycie Bright Data przez klienta.
„Idle" nie znaczy „nieobecny"
Jest szczegół w konfiguracji, który warto nazwać, bo zgrabnie pokazuje rozjazd między tym, co użytkownik rozumie przez „zgoda na użycie bezczynnych zasobów", a tym, co SDK uznaje za bezczynność.
Reguły zawierają dwie flagi: ignore_screen_on: true i ignore_on_call: true. To znaczy, że urządzenie relayuje cudzy ruch nawet gdy ekran jest włączony i nawet gdy trwa rozmowa telefoniczna. „Bezczynny" nie oznacza, że użytkownik jest z dala od urządzenia — oznacza tylko, że CPU, pamięć i bateria mieszczą się w progach SDK. Osoba aktywnie czytająca ekran, w trakcie połączenia, jest uznawana za bezczynną do celów relayowania.
Do tego konkrety skali. Aplikacja Petflix na Roku w oknie zgody pisze, że Bright Data będzie „od czasu do czasu" używać zasobów urządzenia. Tymczasem publicznie dostępna konfiguracja SDK ustawia domyślny miesięczny budżet WiFi na 200 GB. „Od czasu do czasu" o pojemności dwustu gigabajtów miesięcznie.
Dwa bypassy inspekcji — sednem techniczne
Tu jest druga rzecz, która czyni ten SDK godnym opisania obok podatności, a nie tylko jako ciekawostkę prywatnościową. SDK używa dwóch niezależnych obejść inspekcji, po jednym na każdą płaszczyznę.
Płaszczyzna danych omija VPN. Konfiguracja zawiera flagę use_netifs: true, która każe SDK budować połączenie z konkretnym interfejsem fizycznym — WiFi (en0) albo komórkowym (pdp_ip0) — zamiast trasy domyślnej systemu. Na iOS to całkowicie omija interfejs tun0 skonfigurowanego VPN-a. Tunel peer nie przechodzi przez VPN użytkownika, nawet gdy reszta ruchu HTTPS aplikacji przez niego idzie. Buchodi potwierdził to empirycznie: jego przechwytujący setup złapał każde wywołanie HTTPS SDK — poza tunelem peer.
Płaszczyzna kontrolna omija hooki URLSession. Pobieranie konfiguracji i pingi telemetrii zbudowano na niskopoziomowych prymitywach CFNetwork zamiast URLSession — co pokonuje instrumentację na poziomie URLSession (swizzling, rozszerzenia sieciowe), powszechnie używaną w narzędziach do analizy bezpieczeństwa aplikacji mobilnych.
Obie metody to legalne API Apple. Interesująca jest kombinacja: płaszczyzna danych jest niewidoczna dla inspekcji opartej na VPN, a płaszczyzna kontrolna niewidoczna dla hooków URLSession. Badacz polegający na jednej z technik widzi tylko połowę zachowania SDK. Jak ujmuje to Include Security: dla zespołów bezpieczeństwa z MDM, inspekcją ruchu przez VPN korporacyjny czy kontrolą rodzicielską na routerze — najwrażliwszy kanał tego SDK jest zaprojektowany tak, by ominąć waszą warstwę widoczności.
To jest wzorzec, który opisywaliśmy przy Gemini i ChatGPhish: mechanizm zbudowany z legalnych klocków, którego problemem nie jest pojedynczy błąd, ale to, jak te klocki złożono. Tu legalne API Apple składają się w coś, co świadomie wymyka się każdej standardowej warstwie inspekcji.
Geografia, która każe się zastanowić
Konfiguracja zawiera progi pasma per kraj. Cztery kraje mają polityki inne niż domyślna — i sposób, w jaki je narysowano, jest sam w sobie ciekawy. Urządzenia w Uzbekistanie i Omanie mogą relayować cudzy ruch aż do 1% baterii, z dziennymi limitami 20× wyższymi i miesięcznymi 60× wyższymi niż domyślne. Katar i ZEA są dławione poniżej domyślnej. Można tylko spekulować, dlaczego tak — jedno odczytanie to celowa segmentacja rynku: luźniej tam, gdzie prąd jest stabilny, ciaśniej tam, gdzie dane mobilne są drogie. Domyślna polityka światowa i tak pozwala na 500 MB cudzego ruchu miesięcznie przez domowe łącze użytkownika.
Disclosure i co warto zauważyć
Include Security powiadomił Bright Data 11 maja 2026 mailem na adres prywatności firmy. Do momentu publikacji nie otrzymano odpowiedzi.
Warto być uczciwym co do granic tego ustalenia. Obecność partnera w konfiguracji Bright Data dowodzi, że integracja mogła kiedyś istnieć — nie dowodzi sama z siebie, że aktualnie publikowana aplikacja danego wydawcy zawiera SDK w produkcji. To wymaga weryfikacji per aplikacja. Co manifest dowodzi wprost: Bright Data udostępnia tę listę w nieuwierzytelnionym publicznym endpoincie, a co najmniej trzy podmioty skupione na CTV monetyzowały urządzenia użytkowników jako węzły wyjściowe proxy, z zasięgiem liczonym — według ich własnych materiałów — w setkach milionów gospodarstw domowych.
Bright Data w wcześniejszych wypowiedziach dla mediów utrzymywał, że udział w sieci jest „za zgodą" i że użytkownik może się wypisać w dwóch krokach. To prawda w sensie formalnym. Pytanie, które stawia ten research, brzmi: czy zgoda wyklikana strzałkami na pilocie, w oknie mówiącym „od czasu do czasu", o realnej pojemności 200 GB miesięcznie, jest zgodą poinformowaną. Polityka prywatności to zła powierzchnia kontroli dla telewizora — trudno przewijać dokument prawny strzałkami pilota.
Co zrobić
Dla użytkownika domowego: zablokuj na routerze (Pi-hole, NextDNS, Cloudflare Gateway) hostnamy tunelu peer — proxyjs.brdtnet.com, proxyjs.luminatinet.com, proxyjs.bright-sdk.com, clientsdk.bright-sdk.com, clientsdk.brdtnet.com. Zablokowanie proxyjs.* zabija tunel, nie ruszając niczego legalnego.
Dla sieci: filtruj lub alarmuj na uchwyty TLS, gdzie nazwa serwera pasuje do *.brdtnet.com, *.luminatinet.com lub *.luminati.io. Działa na granicy sieci bez inspekcji TLS.
Dla flot zarządzanych: pamiętaj o haczyku use_netifs — na iOS, gdy urządzenie jest na komórce, ruch peer omija WiFi korporacyjne całkowicie. Kontrolą uzupełniającą jest skanowanie binariów aplikacji przez MDM: szukaj symboli Swift BrdWebSocketFacade i BrdNetwork.DNSResolver i zabroń aplikacji je zawierających na urządzeniach służbowych.
I jeden szczegół na przyszłość: konfiguracja zawiera już flagę http3_enabled: true. Przyszła wersja może przenieść tunel z TCP/443 na QUIC po UDP/443 — co złamie obronę polegającą na śledzeniu połączeń TCP. Warto to mieć w głowie, projektując detekcję dziś.
Źródła
Include Security / Buchodi — pełny research techniczny z analizą protokołu, konfiguracji i metodami detekcji: https://blog.includesecurity.com/2026/06/the-smart-tv-in-your-livingroom-is-a-node-in-the-aiscraping-economy/
The Hacker News — omówienie z kontekstem rynku proxy rezydencjalnych: https://thehackernews.com/2026/06/free-apps-are-quietly-turning-smart-tvs.html
The Verge — przypadek aplikacji Petflix na Roku i analiza okna zgody: https://www.theverge.com/column/885244/smart-tv-web-crawler-ai
KrebsOnSecurity — kontekst proxy rezydencjalnych zasilających pozyskiwanie danych dla AI: https://krebsonsecurity.com/2025/10/aisuru-botnet-shifts-from-ddos-to-residential-proxies/
Nie nowy atak, tylko naprawiony błąd. Co łatka Gemini CLI mówi o tym, że tryb –yolo w potoku CI/CD to nie jest dobry pomysł