Google poinformowało o rozbiciu botnetu x.cpe, który działał na ponad 1,3 mln certyfikowanych urządzeń Android TV. Za operacją stał nie zewnętrzny cyberprzestępca, lecz jeden z partnerów produkcyjnych Google — szczecińska… a właściwie chińska Videostrong Technology z Shenzhen, producent OEM/ODM sprzętu sprzedawanego głównie pod marką MECOOL. Firma celowo instalowała backdoor w urządzeniach, które przeszły testy certyfikacyjne Google, a następnie sprzedawała dostęp do zainfekowanych maszyn partnerom zajmującym się ad fraudem, proxy residential i dystrybucją kolejnego złośliwego oprogramowania.

Sprawa dotyczy każdego, kto kupił tani box Android TV niewiadomego pochodzenia lub wdrożył takie urządzenia w firmie — w digital signage, kioskach, systemach telemedycznych czy instalacjach karaoke. Google zapowiada zmianę procesu certyfikacji, zerwało współpracę z Videostrong i pozbawiło firmę prawa do używania aplikacji i usług Google, ale samo urządzenie nie wraca do stanu fabrycznego: Play Protect pozostaje wyłączony, a moduły złośliwego oprogramowania są zainstalowane jako aplikacje systemowe. Dla polskich firm oznacza to konkretny problem w łańcuchu dostaw sprzętu IoT, którego nie da się rozwiązać samym komunikatem producenta.

Co dokładnie się wydarzyło

Google Threat Intelligence Group opisało operację, w której złośliwe oprogramowanie było wbudowane bezpośrednio w wiele modeli urządzeń i wiele marek przez kilka lat. Według Google botnet nie powstał przypadkiem ani w wyniku błędu deweloperskiego — był świadomie zaprojektowany, wdrożony i obsługiwany w celu osiągnięcia korzyści finansowych. Firma z Shenzhen sprzedawała partnerom dostęp do backdoora i ładowała na zainfekowane urządzenia ich moduły: skrypty ad fraud, oprogramowanie wciągające urządzenia do sieci proxy residential oraz kolejne złośliwe pakiety.

Google podjęło działania prawne wobec domen i serwerów wykorzystywanych przez Videostrong do obsługi botnetu oraz wobec domen command-and-control (C2) stojących za modułami partnerskimi. Według szacunków Google odcięcie dostępu do tych serwerów C2 mogło odciąć co najmniej 10 mln innych zainfekowanych urządzeń, bo partnerzy dystrybuowali swoje moduły także poza samym x.cpe. To liczba szacunkowa, nie potwierdzona niezależnym audytem.

W akcji uczestniczyły japońska National Police Agency, Lumen, Human Security, Plume, Synthient oraz Trend Micro (TrendAI). Synthient opublikował listę 182 nazw modeli urządzeń objętych botnetem. Trend Micro naliczył łącznie 1 472 554 zainfekowane urządzenia — nieco więcej niż szacunek Google. Google zakończyło relację z Videostrong i zakazało firmie oraz podmiotom zależnym używania aplikacji i usług Google.

Tło techniczne prostym językiem

Android TV to system oparty na Androidzie, ale żeby producent mógł legalnie instalować aplikacje Google (Sklep Play, YouTube, usługi Google Play) i używać znaku Android TV, musi przejść certyfikację. Proces obejmuje testy zgodności i bezpieczeństwa — ma wychwycić między innymi złośliwy kod. Videostrong przeszedł ten proces, a mimo to zainstalował backdoor.

Mechanizm był dwuetapowy. W fabrycznie nowym urządzeniu znajdował się niewielki pakiet — stub o nazwie x.cpe lub com.oemservice. Sam w sobie nie robił nic złego, więc testy certyfikacyjne mogły go przepuścić. Miał jednak uprawnienia systemowe, które pozwalały mu na instalowanie modułów po poleceniu z zewnątrz. Po pierwszym uruchomieniu i podłączeniu urządzenia do internetu stub łączył się z serwerem operatora, pobierał właściwe złośliwe moduły i instalował je po cichu. Jednocześnie wyłączał Play Protect — mechanizm Androida, który normalnie ostrzegłby użytkownika przed zainstalowaniem szkodliwego pakietu.

Architektura była trzystopniowa: backdoor osadzony w partycji /oem/ (trwały, przeżywa aktualizacje systemu), loader i silnik wykonawczy oraz moduły monetyzacyjne, które mogły uruchamiać kolejne backdoory i dociągać następne moduły. Google opisuje to jako platformę modularną, którą Videostrong rozwijał z prostego droppera w rozbudowany system sprzedaży dostępu stronom trzecim.

Operatorzy mieli pełny dostęp do urządzeń: mogli uruchamiać komendy terminala, przechwytywać obraz z ekranu i skanować sieć lokalną w poszukiwaniu innych urządzeń. Google twierdzi, że obserwowało Videostrong podczas takich działań w czasie rzeczywistym.

Dlaczego certyfikacja tego nie wychwyciła

Według Google Videostrong użył technik obfuskacji, żeby wykorzystać lukę w testach i załadować złośliwy kod dopiero po pierwszym uruchomieniu urządzenia. To kluczowy punkt: testy certyfikacyjne sprawdzają zwykle obraz systemu w stanie fabrycznym. Jeśli szkodliwy kod jest pobierany z sieci po pierwszym boocie, w momencie testu go tam nie ma. Sam stub bez funkcji ofensywnych wygląda niewinnie.

Google przyznaje, że jego proces przeglądu nie wychwycił tego mechanizmu, i zapowiada aktualizację procesu certyfikacji. Nie podało publicznie szczegółów nowych wymagań ani terminu ich wdrożenia. To deklaracja producenta, nie niezależnie zweryfikowany fakt.

Google wymaga od producentów OEM przejścia kompleksowego zestawu testów zgodności i bezpieczeństwa. Videostrong wykorzystał techniki obfuskacji, żeby wykorzystać lukę w naszych testach i załadować złośliwy kod po pierwszym uruchomieniu urządzenia — brzmi stanowisko Google przytaczane przez SecurityWeek.

Warto odróżnić dwie rzeczy. Po pierwsze: certyfikacja nie jest gwarancją bezpieczeństwa, jest gwarancją zgodności i dostępu do ekosystemu Google. Po drugie: Android jest otwartoźródłowy, więc niecertyfikowane boxy mogą zawierać złośliwe oprogramowanie bez żadnego procesu, który by to wychwycił. Paradoksalnie certyfikowane urządzenia Videostrong były „bezpieczniejsze” tylko na papierze.

Realne konsekwencje dla użytkowników i firm

Google twierdzi, że po akcji urządzenia powinny być bezpieczne w użyciu, ale prawdopodobnie nie tak bezpieczne, jak powinny. Play Protect pozostaje wyłączony, a nieaktywne moduły złośliwego oprogramowania nadal są zainstalowane. Ponieważ są ładowane jako aplikacje systemowe, użytkownik nie może ich łatwo usunąć. To oznacza, że urządzenie po rozbiciu botnetu nie jest czyste — jest odcięte od operatora, ale wciąż nosi ślady infekcji.

Dla firmy wdrażającej takie urządzenia konsekwencje układają się w kilka warstw:

Bezpieczeństwo sieci. Urządzenie z backdoorem mogło skanować sieć lokalną i służyć jako punkt wejścia do dalszych działań. Nawet po odcięciu C2 nie wiadomo, jakie dane zostały przechwycone wcześniej.
Poufność. Możliwość przechwytywania ekranu oznacza ryzyko wycieku danych wyświetlanych na signage, kioskach czy terminalach telemedycznych.
Reputacja i zgodność. Jeśli zainfekowane urządzenie brało udział w ad fraudzie lub ruchu proxy, firma mogła nieświadomie uczestniczyć w nielegalnym ruchu sieciowym. To problem w kontekście RODO i umów z klientami.
Trwałość problemu. Moduły systemowe trudno usunąć, a Play Protect jest wyłączony. Przywrócenie urządzenia do stanu fabrycznego może nie wystarczyć, jeśli backdoor siedzi w partycji /oem/ i wraca po resecie.

Scenariusze ryzyka

Scenariusz	Prawdopodobieństwo	Skutek
Firma ma wdrożone boxy MECOOL lub białe etykiety z listy 182 modeli	Zależy od listy zakupowej — wymaga weryfikacji	Wysokie: urządzenia mogły być częścią botnetu
Urządzenia pracują w sieci firmowej bez segmentacji	Wysokie w typowych wdrożeniach signage	Wysokie: możliwość skanowania i ruchu bocznego
Firma kupiła sprzęt od pośrednika bez dokumentacji certyfikacji	Wysokie przy zakupach „białych etykiet”	Średnie: brak możliwości weryfikacji pochodzenia
Dostawca nadal sprzedaje urządzenia pod inną marką	Możliwe — Android jest open source	Wysokie: nowe infekcje bez aplikacji Google
Moduły systemowe pozostają po akcji Google	Potwierdzone przez Google	Średnie: urządzenie nie jest w pełni czyste

Trzeba wyraźnie zaznaczyć: powyższa tabela to interpretacja ryzyka, nie zestaw potwierdzonych incydentów w polskich firmach. Materiał dowodowy nie zawiera danych o polskich wdrożeniach ani o dostępności konkretnych modeli z listy 182 w polskiej dystrybucji. To wymaga sprawdzenia po stronie czytelnika.

Jak sprawdzić, czy problem dotyczy twojej firmy

Zbierz listę modeli. Spisz wszystkie urządzenia Android TV, boxy set-top, signage i kioski w firmie — marka, model, numer seryjny, dostawca, data zakupu.
Porównaj z listą Synthient. Synthient opublikował listę 182 nazw modeli objętych botnetem. Sprawdź, czy któryś z twoich modeli tam jest. Lista obejmuje MECOOL i urządzenia białych etykiet — zwróć uwagę na nazwy handlowe, nie tylko na producenta.
Sprawdź markę i pochodzenie. Jeśli urządzenie jest sprzedawane pod marką MECOOL lub jako „biała etykieta” niewiadomego pochodzenia, traktuj je jako podejrzane do czasu potwierdzenia.
Sprawdź stan Play Protect. W ustawieniach Google Play sprawdź, czy ochrona jest włączona. Wyłączony Play Protect na urządzeniu, które nigdy nie było świadomie modyfikowane, to sygnał ostrzegawczy.
Sprawdź pakiety systemowe. Obecność pakietu com.oemservice lub x.cpe wśród aplikacji systemowych to bezpośredni wskaźnik. Nie próbuj usuwać go ręcznie — to może wymagać interwencji dostawcy lub wymiany urządzenia.
Przejrzyj ruch sieciowy. Przeanalizuj logi firewall i DNS pod kątem nietypowych połączeń wychodzących z segmentu, w którym pracują urządzenia.
Zapytaj dostawcę. Zażądaj pisemnego potwierdzenia pochodzenia urządzeń, certyfikacji Google i informacji, czy dostawca miał kontakt z Videostrong lub podmiotami zależnymi.

Plan reakcji krok po kroku

Krok 1: Izolacja

Urządzenia podejrzane lub znajdujące się na liście 182 odłącz od sieci firmowej lub przenieś do wydzielonego VLAN-u bez dostępu do zasobów wewnętrznych. Nie wyłączaj ich pochopnie, jeśli służą do krytycznych funkcji — najpierw zabezpiecz segmentację.

Krok 2: Inwentaryzacja i weryfikacja

Ustal, które urządzenia są objęte problemem, jakie dane były na nich wyświetlane i jakie miały uprawnienia sieciowe. Sprawdź, czy urządzenia miały dostęp do wewnętrznych systemów, baz danych lub sieci OT.

Krok 3: Decyzja o dalszym użytkowaniu

Dla urządzeń potwierdzonych jako zainfekowane realna opcja to wymiana sprzętu. Przywrócenie do ustawień fabrycznych może nie usunąć backdoora z partycji /oem/ i nie przywróci Play Protect. Google nie potwierdziło publicznie, czy istnieje skuteczna procedura czyszczenia tych urządzeń.

Krok 4: Komunikacja i zgodność

Jeśli urządzenia przetwarzały dane osobowe lub były częścią infrastruktury klienta, oceń obowiązki informacyjne wynikające z RODO i umów. Ustal, czy doszło do naruszenia ochrony danych — to wymaga analizy prawnej, nie tylko technicznej.

Krok 5: Działania naprawcze w sieci

Sprawdź logi pod kątem nietypowej aktywności z segmentu urządzeń. Zrotuj poświadczenia, które mogły być dostępne z tych urządzeń. Zwiększ monitoring ruchu wychodzącego.

Typowe błędy

Traktowanie certyfikatu Google jako gwarancji bezpieczeństwa. Certyfikacja potwierdza zgodność i dostęp do ekosystemu, nie odporność na celowy backdoor producenta.
Poleganie wyłącznie na komunikacie producenta. Videostrong nie jest już partnerem Google, ale jego urządzenia nadal mogą być w obrocie pod innymi markami.
Przywracanie do ustawień fabrycznych bez weryfikacji. Backdoor w partycji /oem/ i wyłączony Play Protect to problemy, których reset może nie rozwiązać.
Brak segmentacji sieci IoT. Urządzenia signage i kioski często trafiają do tej samej sieci co systemy wewnętrzne — to zwiększa skutki każdej infekcji.
Zakupy bez dokumentacji łańcucha dostaw. Brak informacji o producencie OEM/ODM uniemożliwia weryfikację pochodzenia sprzętu.
Ignorowanie listy modeli. Lista 182 nazw to konkretne narzędzie weryfikacji — bez niej inwentaryzacja jest niepełna.

Działania krótkoterminowe

Zinwentaryzuj urządzenia i porównaj z listą Synthient.
Odizoluj podejrzane urządzenia w sieci.
Sprawdź stan Play Protect i obecność pakietów com.oemservice / x.cpe.
Przeanalizuj logi sieciowe z ostatnich tygodni.
Zabezpiecz dane wyświetlane na urządzeniach — oceń, czy mogły wyciec.
Skontaktuj się z dostawcą i zażądaj pisemnych wyjaśnień.

Działania długoterminowe

Wprowadź wymóg dokumentowania łańcucha dostaw sprzętu IoT w procedurach zakupowych.
Ustal politykę segmentacji sieci dla urządzeń signage, kiosków i telemedycyny.
Wpisz w umowy z dostawcami klauzule o odpowiedzialności za złośliwe oprogramowanie w firmware i obowiązek informowania o incydentach.
Zaplanuj cykliczny przegląd urządzeń IoT pod kątem certyfikacji i aktualizacji bezpieczeństwa.
Rozważ wymianę sprzętu na urządzenia od dostawców z udokumentowanym procesem bezpieczeństwa firmware.
Monitoruj komunikaty Google i innych dostawców o zmianach w procesie certyfikacji.

Checklista praktyczna

Pytanie kontrolne	Tak / Nie	Działanie przy „Tak”
Czy w firmie są urządzenia MECOOL lub białe etykiety Android TV?		Sprawdź listę 182 modeli
Czy urządzenia mają dostęp do sieci wewnętrznej?		Wprowadź segmentację
Czy Play Protect jest wyłączony na którymś urządzeniu?		Traktuj jako podejrzane
Czy w aplikacjach systemowych jest com.oemservice lub x.cpe?		Odizoluj i zgłoś dostawcy
Czy dostawca potwierdził pochodzenie i certyfikację sprzętu?		Brak potwierdzenia = ryzyko
Czy urządzenia wyświetlały dane osobowe lub poufne?		Oceń ryzyko wycieku i obowiązki RODO
Czy logi sieciowe pokazują nietypowe połączenia wychodzące?		Zgłoś do zespołu bezpieczeństwa

Co powinien zrobić właściciel firmy / administrator

Właściciel firmy: potraktuj sprawę jako problem łańcucha dostaw, nie jako ciekawostkę technologiczną. Zlec inwentaryzację urządzeń IoT i sprawdzenie, czy firma kupowała sprzęt od pośredników bez dokumentacji. Ustal, kto odpowiada za bezpieczeństwo tych urządzeń, i wpisz wymagania bezpieczeństwa do umów z dostawcami. Jeśli urządzenia przetwarzały dane klientów, skonsultuj się z prawnikiem w sprawie obowiązków informacyjnych.

Administrator: zacznij od inwentaryzacji i porównania z listą Synthient. Odizoluj podejrzane urządzenia w sieci, sprawdź Play Protect i pakiety systemowe, przejrzyj logi. Nie zakładaj, że reset do ustawień fabrycznych rozwiąże problem — potwierdź to z dostawcą lub wymień sprzęt. Udokumentuj działania, żeby mieć podstawę do roszczeń wobec dostawcy i do ewentualnych zgłoszeń regulacyjnych.

Co pozostaje niejasne

Materiał dowodowy nie odpowiada na kilka pytań istotnych dla polskich firm. Po pierwsze, nie wiadomo, które z 182 modeli z listy Synthient były sprzedawane w Polsce i przez jakich dystrybutorów. Po drugie, Google nie podało szczegółów nowego procesu certyfikacji ani terminu jego wdrożenia. Po trzecie, nie ma potwierdzenia, czy istnieje skuteczna procedura usunięcia backdoora z partycji /oem/ bez wymiany urządzenia. Po czwarte, skala 10 mln dodatkowych urządzeń to szacunek Google, nie wynik niezależnego audytu.

Te luki nie unmiejszają problemu — wręcz przeciwnie, pokazują, że firmy muszą działać na podstawie własnej weryfikacji, a nie wyłącznie komunikatów producenta. Najważniejszy wniosek jest prosty: certyfikat nie zastępuje due diligence w łańcuchu dostaw, a tanie urządzenia IoT w firmowej sieci wymagają takiego samego nadzoru jak komputery i serwery.

Weryfikacja praktyczna: jak potwierdzić lub wykluczyć infekcję bez zgadywania

Weryfikacja nie polega na jednym sprawdzeniu — wymaga zestawienia kilku niezależnych sygnałów. Poniżej praktyczna kolejność działań, którą można wykonać na urządzeniu bez ingerencji w firmware.

Krok A: Identyfikacja urządzenia na poziomie modelu i pochodzenia

Zapisz dokładną nazwę modelu z obudowy i z ustawień systemowych — nazwy handlowe mogą się różnić od nazwy modelu w systemie.
Ustal, czy urządzenie jest sprzedawane pod marką MECOOL lub jako biała etykieta niewiadomego pochodzenia — w takim przypadku traktuj je jako podejrzane do czasu potwierdzenia.
Porównaj model z listą 182 nazw modeli opublikowaną przez Synthient. Lista obejmuje zarówno MECOOL, jak i urządzenia białych etykiet.
Zanotuj dostawcę i datę zakupu — bez tego nie da się później dochodzić roszczeń ani ustalić, czy sprzęt pochodzi z partii objętej problemem.

Krok B: Kontrola stanu ochrony i pakietów systemowych

W ustawieniach Google Play sprawdź, czy Play Protect jest włączony. Wyłączona ochrona na urządzeniu, którego nikt świadomie nie modyfikował, to sygnał ostrzegawczy — botnet wyłączał Play Protect, aby niezauważenie instalować pakiety.
Przejrzyj listę aplikacji systemowych pod kątem pakietu com.oemservice lub x.cpe. Ten pakiet nie ma sam z siebie złośliwych funkcji, ale ma uprawnienia systemowe do instalowania modułów malware.
Nie usuwaj tych pakietów ręcznie. Są ładowane jako aplikacje systemowe, więc zwykłe odinstalowanie może być niemożliwe lub niepełne — to wymaga interwencji dostawcy albo wymiany urządzenia.

Krok C: Analiza ruchu i zachowania urządzenia

Przejrzyj logi firewall i DNS dla segmentu, w którym pracują urządzenia. Szukaj nietypowych połączeń wychodzących — botnet wykorzystywał urządzenia m.in. jako residential proxy do routowania dużego wolumenu ruchu.
Sprawdź, czy urządzenia komunikują się z zewnętrznymi zasobami, których nie powinny odwiedzać (ad fraud, dodatkowe moduły malware).
Zestaw wyniki z listą modeli i stanem Play Protect — dopiero kilka sygnałów razem daje podstawę do decyzji o izolacji.

Krok D: Potwierdzenie u dostawcy

Zażądaj pisemnego potwierdzenia pochodzenia urządzeń, certyfikacji Google i informacji, czy dostawca miał kontakt z Videostrong lub podmiotami zależnymi.
Zapytaj wprost, czy dostawca wie o pakiecie com.oemservice / x.cpe w firmware dostarczanych urządzeń.
Uzyskaj na piśmie informację, czy istnieje procedura czyszczenia urządzenia z backdoora w partycji /oem/ — Google nie potwierdziło publicznie skutecznej metody usunięcia bez wymiany sprzętu.

Monitoring po wdrożeniu: co obserwować i jak długo

Po izolacji, wymianie lub potwierdzeniu czystości urządzeń monitoring nie kończy się — botnet działał modułowo, a operatorzy po disruptions szybko przechodzą na nowe loadery lub konkurencyjne SDK monetyzacyjne. Poniżej zakres obserwacji.

Co monitorować w sieci

Ruch wychodzący z segmentu urządzeń IoT/signage — szczególnie połączenia do nieznanych domen i nietypowe wolumeny, charakterystyczne dla residential proxy.
Zapytania DNS do domen powiązanych z infrastrukturą botnetu — Google podjęło działania prawne wobec domen i serwerów Videostrong oraz domen C&C modułów dodatkowych, ale lista nie jest publicznie wyczerpująca.
Nowe urządzenia pojawiające się w sieci bez udokumentowanego procesu zakupu — to może być sprzęt z niezweryfikowanego łańcucha dostaw.
Zachowania typowe dla ad fraud — nietypowa aktywność sieciowa urządzeń, które powinny jedynie wyświetlać treści (signage, kioski).

Co monitorować na urządzeniach

Stan Play Protect — jego ponowne wyłączenie na urządzeniu, które wcześniej miało włączoną ochronę, to sygnał alarmowy.
Pojawianie się nowych pakietów systemowych lub modułów instalowanych bez wiedzy administratora.
Możliwość wykonywania poleceń terminalowych, przechwytywania ekranu i sondowania innych urządzeń w sieci lokalnej — Videostrong miał pełny dostęp do urządzeń i Google obserwowało te działania w czasie rzeczywistym.

Jak długo i jak dokumentować

Ustal okres obserwacji dłuższy niż standardowy cykl przeglądu — materiał nie podaje daty wdrożenia nowego procesu certyfikacji Google, więc nie ma podstawy do skrócenia monitoringu.
Prowadź rejestr: data sprawdzenia, model, numer seryjny, stan Play Protect, obecność pakietów, wynik analizy logów, decyzja. Dokumentacja jest podstawą do roszczeń wobec dostawcy i do ewentualnych zgłoszeń regulacyjnych.
Zapisuj, które urządzenia zostały wymienione, a które wyczyszczone — bez tego nie da się wykazać, że problem został zamknięty.

Checklista wdrożeniowa po decyzji o działaniu

Poniższa lista porządkuje czynności wykonawcze — uzupełnia wcześniejszą checklistę kontrolną o elementy typowe dla wdrożenia i utrzymania.

Zinwentaryzuj wszystkie urządzenia Android TV, boxy set-top, signage i kioski: marka, model, numer seryjny, dostawca, data zakupu.
Porównaj modele z listą 182 nazw Synthient, uwzględniając marki MECOOL i białe etykiety.
Sprawdź stan Play Protect i obecność pakietów com.oemservice / x.cpe na każdym urządzeniu.
Odizoluj podejrzane urządzenia w wydzielonym VLAN bez dostępu do zasobów wewnętrznych — nie wyłączaj ich pochopnie, jeśli pełnią krytyczne funkcje.
Przeanalizuj logi firewall i DNS z ostatnich tygodni dla segmentu urządzeń.
Oceń, jakie dane były wyświetlane lub przetwarzane na urządzeniach i czy mogły wyciec.
Zrotuj poświadczenia, które mogły być dostępne z poziomu tych urządzeń.
Zażądaj od dostawcy pisemnego potwierdzenia pochodzenia, certyfikacji i braku kontaktów z Videostrong.
Dla urządzeń potwierdzonych jako zainfekowane zaplanuj wymianę sprzętu — reset do ustawień fabrycznych może nie usunąć backdoora z partycji /oem/ i nie przywróci Play Protect.
Udokumentuj decyzje i działania; jeśli urządzenia przetwarzały dane osobowe, przekaż sprawę do oceny prawnej pod kątem RODO i umów.
Wpisz do procedur zakupowych wymóg dokumentowania łańcucha dostaw sprzętu IoT.
Ustal politykę segmentacji sieci dla signage, kiosków i urządzeń telemedycznych.
Dodaj do umów z dostawcami klauzule o odpowiedzialności za złośliwe oprogramowanie w firmware i obowiązek informowania o incydentach.
Zaplanuj cykliczny przegląd urządzeń IoT pod kątem certyfikacji i aktualizacji bezpieczeństwa.
Monitoruj komunikaty Google o zmianach w procesie certyfikacji — Google zapowiedziało aktualizację procesu, ale nie podało szczegółów ani terminu.

Weryfikacja dostawcy i łańcucha dostaw: pytania, które trzeba zadać

Skala problemu — 1,3 mln urządzeń według Google, 1 472 554 według Trend Micro — pokazuje, że infekcja nie była pojedynczym błędem, lecz wieloletnią operacją obejmującą wiele modeli i marek. Dlatego weryfikacja dostawcy musi być konkretna.

Czy dostawca jest producentem OEM/ODM, czy pośrednikiem? Videostrong to chiński OEM/ODM z Shenzhen, który sam operował botnetem — brak wiedzy o producencie uniemożliwia weryfikację.
Czy urządzenia przeszły certyfikację Google i czy dostawca potrafi to udokumentować? Certyfikacja nie gwarantuje braku backdoora, ale jej brak to dodatkowy sygnał ryzyka.
Czy dostawca miał kontakt z Videostrong lub podmiotami zależnymi? Google zakończyło współpracę z Videostrong i zakazało firmie oraz podmiotom zależnym korzystania z aplikacji i usług Google.
Czy dostawca potwierdza, że urządzenia nie zawierają pakietu com.oemservice / x.cpe i że Play Protect jest włączony fabrycznie?
Czy dostawca zobowiązuje się do informowania o incydentach bezpieczeństwa firmware i do wymiany sprzętu w razie potwierdzonej infekcji?

Odpowiedzi na te pytania należy uzyskać na piśmie — komunikat ustny nie stanowi podstawy do roszczeń ani do wykazania należytej staranności.

Ograniczenia materiału dowodowego a decyzje operacyjne

Materiał nie odpowiada na kilka pytań, które bezpośrednio wpływają na decyzje w firmie. Po pierwsze, nie wiadomo, które z 182 modeli były sprzedawane w Polsce i przez jakich dystrybutorów. Po drugie, Google nie podało szczegółów nowego procesu certyfikacji ani terminu jego wdrożenia. Po trzecie, brak potwierdzenia, czy istnieje skuteczna procedura usunięcia backdoora z partycji /oem/ bez wymiany urządzenia. Po czwarte, skala 10 mln dodatkowych urządzeń to szacunek Google, nie wynik niezależnego audytu.

W praktyce oznacza to, że decyzje trzeba opierać na własnej weryfikacji, a nie wyłącznie na komunikatach producenta. Najbezpieczniejsze założenie operacyjne: urządzenie z listy 182 modeli lub z wyłączonym Play Protect traktuj jako zainfekowane do czasu udokumentowania czystości przez dostawcę lub wymiany sprzętu.

Źródła i materiały do dalszej weryfikacji

Artykuł jest autorskim opracowaniem przygotowanym na podstawie poniższych materiałów. Linki prowadzą do publikacji źródłowych.

Google dismantles botnet secretly running on 1.3 million Android TV boxes (arstechnica.com)
Google Dismantles XCPE Botnet of 1.3 Million Android Devices (www.securityweek.com)
One of Google’s Android partners turned 1.3 million set-top boxes into a botnet (www.theverge.com)

Zdjęcie wyróżniające: Alessandro Oliverio / Pexels.