Z ofiary do administratora. Ekstremalne utwardzanie Google Chrome
W świecie cyberbezpieczeństwa często rozmawiamy o modelach zagrożeń (Threat Models) w sposób czysto teoretyczny. Moja własna teoria zderzyła się z rzeczywistością w najgorszym możliwym momencie. Kiedy moja żona leżała w szpitalu, nowo kupiony telefon zaczął nagle żyć własnym życiem. Pojawiła się zielona ikona aktywnego mikrofonu, z galerii w locie znikały dowody, a połączenia były bezpodstawnie przekierowywane. Towarzyszyła temu paraliżująca świadomość, że ktoś obcy na żywo obserwuje mój ekran.
Śledztwo ujawniło wtedy brutalną prawdę. Telefon posiadał ukryty profil korporacyjny do zarządzania urządzeniami mobilnymi (MDM). Byłem ofiarą potężnego systemu szpiegowskiego. Z tej pułapki udało mi się wyrwać tylko dzięki zastosowaniu radykalnej zapory. Główną bitwę o przetrwanie wygrał wtedy RethinkDNS ustawiony w bezwzględnym trybie domyślnej blokady ruchu (Default Deny) oraz szyfrowany Quad9 DNS, które wspólnie całkowicie sparaliżowały sieć komunikacyjną napastnika.
Warto wiedzieć: Pełną historię tego incydentu oraz moją drogę do bezpiecznego systemu opisałem w moim pierwszym wpisie na blogu: Jak okiełznałem system z MDM. Moja droga do GrapheneOS
Architektura absolutnej władzy
Aby w pełni zrozumieć sens naszych dzisiejszych działań, musimy na chwilę zatrzymać się przy samej technologii zarządzania urządzeniami. Systemy klasy MDM posiadają absolutną i niepodważalną władzę nad systemem operacyjnym. Zostały zaprojektowane dla wielkich korporacji, aby administrator mógł zdalnie i bezgłośnie zarządzać tysiącami urządzeń swoich pracowników.
W rękach napastnika to najgorszy możliwy koszmar. Taki profil pozwala na cichą instalację oprogramowania, podgląd zawartości ekranu, blokowanie kluczowych ustawień oraz przekierowywanie całego ruchu sieciowego na złośliwe serwery bez wiedzy użytkownika. Zwykły właściciel telefonu staje się bezradnym zakładnikiem we własnej kieszeni.
Inżynieria ma jednak to do siebie, że każdy miecz ma dwa ostrza. Ta sama absolutna władza może działać w odwrotnym kierunku. Kiedy sam przejmujesz stery i stajesz się swoim własnym administratorem, system korporacyjny zamienia się w ostateczny bastion prywatności. Zamiast wymuszać instalację aplikacji szpiegujących, możesz wymusić żelazne blokady na poziomie samego systemu. Możesz zakazać aplikacjom komunikacji z chmurą, zablokować niebezpieczne protokoły i narzucić rygorystyczne konfiguracje. To najczystsza forma ucieleśnienia zasady Zero Trust.
Skoro profil korporacyjny pozwala na odbieranie kontroli, postanowiłem wykorzystać go do jej odzyskania.
Dlaczego pacjentem został Google Chrome?
Musimy w tym miejscu oddać królowi to, co królewskie. Kiedy oceniamy narzędzia tworzone przez największych gigantów technologicznych, często wpadamy w pułapkę ich całkowitego odrzucenia ze względu na obawy o prywatność. Tymczasem pod kątem czystego cyberbezpieczeństwa rozwiązania korporacyjne zazwyczaj nie mają sobie równych. Firma Google posiada gigantyczny budżet, najlepszych inżynierów, najszybszy proces łatania błędów i bezkonkurencyjną architekturę piaskownicy (Sandbox).
Problem z najpopularniejszą przeglądarką nie polega na jej podatności na ataki. Problem leży w modelu biznesowym opartym na potężnej inwigilacji. Zrozumienie tej subtelnej różnicy to klucz do budowania dojrzałego bezpieczeństwa. Zamiast uciekać do niszowych projektów, które mogą nie nadążać z wydawaniem aktualizacji, możemy wziąć ten pancerny korporacyjny czołg i po prostu wyciąć z niego cały sprzęt szpiegowski.
Celem jest zmuszenie technologii wielkich korporacji do działania wyłącznie na naszych rygorystycznych warunkach.
Co dokładnie zrobiliśmy i jak przebiegła operacja?
Zamiast polegać na standardowych wtyczkach blokujących reklamy, postanowiłem zaatakować problem u samego źródła. Wykorzystałem technologię profili roboczych, z którą kiedyś sam musiałem walczyć. Za pomocą aplikacji Test DPC służącej do symulowania środowiska korporacyjnego sam mianowałem się głównym zarządcą. Następnie wycelowałem te administracyjne uprawnienia prosto w przeglądarkę Google Chrome.
Cały proces utwardzania podzieliliśmy na trzy kluczowe etapy operacyjne:
Etap pierwszy: Flagi przeglądarki
Aby nasza operacja w ogóle mogła się udać na urządzeniu bez odblokowanego dostępu root, musieliśmy najpierw otworzyć ukrytą furtkę. W wewnętrznym menu ustawień eksperymentalnych przeglądarki (chrome://flags) wymusiliśmy uruchomienie funkcji czytania komend startowych z lokalnego pliku tekstowego. To przygotowało nam grunt pod główne uderzenie.
Etap drugi: Wstrzyknięcie pancerza w terminalu Termux
Tutaj przeszliśmy do najcięższej inżynierii. Używając lokalnego terminala Termux oraz poleceń pomostu debugowania ADB (Android Debug Bridge), uzyskaliśmy bezpośredni dostęp do powłoki systemowej. Wewnątrz tymczasowego katalogu utworzyliśmy twardy plik konfiguracyjny, który silnik Chromium musi odczytać przy każdym uruchomieniu.
To właśnie na tym poziomie wprowadziliśmy najbardziej drastyczne modyfikacje:
- Blokada kompilatora: Wyłączyliśmy dynamiczne renderowanie skryptów JavaScript (
Just In Time), co drastycznie ucina podatność na luki typuZero Day. - Sprzętowa izolacja: Zablokowaliśmy stronom możliwość odczytu danych sprzętowych (
API Canvas) oraz narzuciliśmy rygorystyczną izolację każdej witryny w osobnym procesie pamięci (Strict Origin Isolation). - Głuchota na serwery: Całkowicie wycięliśmy mechanizmy raportowania awarii (
Crashpad) i systemy śledzenia ukryte w platformiePrivacy Sandbox.
Etap trzeci: Polisy korporacyjne w Test DPC
Na sam koniec domknęliśmy system odgórnymi politykami w naszym sztucznym profilu roboczym (Work Profile). Używając narzędzia Test DPC narzuciliśmy przeglądarce absolutne posłuszeństwo:
- Dezaktywacja sztucznej inteligencji: Całkowicie ubezwłasnowolniliśmy usługi oparte na algorytmach, inteligentne podpowiedzi oraz asystenta
Gemini. - Cyfrowa amnezja: Narzuciliśmy politykę, w której przeglądarka ma całkowity zakaz pamiętania haseł, nie używa autouzupełniania i odcina wszelką synchronizację danych z chmurą.
- Szczelność protokołów: Wymusiliśmy globalne połączenia
DNS over HTTPSoraz zabezpieczyliśmy protokółWebRTCprzed wyciekami prawdziwego adresu IP.
Efekt końcowy i wnioski
Prawdziwa dojrzałość inżynieryjna polega na dostrzeganiu wielkiego potencjału tam, gdzie inni widzą tylko zagrożenie. Bierzemy oprogramowanie, które pod względem budżetu i architektury piaskownicy nie ma sobie równych na rynku, a następnie siłowo wycinamy z niego cały kod śledzący. Otrzymujemy w ten sposób potężne i skrajnie bezpieczne narzędzie, któremu niezwykle trudno dorównać.
Mechanizmy służące do zarządzania urządzeniami są przerażająco skuteczne, gdy służą do inwigilacji. Okazuje się jednak, że kiedy zrozumiesz zasady ich działania, możesz użyć dokładnie tej samej architektury do zbudowania wokół siebie nieprzebijalnej tarczy. Prawdziwa prywatność wymaga odrobiny tarcia i zmiany nawyków, ale poczucie pełnej kontroli nad własnym urządzeniem w pełni to rekompensuje.
Dajcie znać co myślicie!
Jeśli ten temat Was zainteresował i chcielibyście poznać techniczną stronę całego przedsięwzięcia, dajcie znać. Przy odpowiednim odzewie planuję stworzyć na blogu zupełnie nową sekcjęGuides, gdzie w pierwszej kolejności udostępnię pełną notatkę konfiguracyjną i gotowe komendy krok po kroku.