Ukrywanie dostępu do roota w Magisk stanie się o wiele trudniejsze dzięki niedawnej zmianie w SafetyNet, która wprowadza atestację sprzętu.
W marcu kilku użytkowników zainstalowało Magisk zauważony że ich urządzenia nie przeszły atestu SafetyNet. Ta wiadomość była niepokojąca dla społeczności XDA, ponieważ oznacza, że wiele kluczowych aplikacji bankowych/finansowych i popularnych gier, takich jak Pokémon Go i Fate/Grand Order, odmawiało działania na urządzeniach zrootowanych. Przez pewien czas wydawało się, że zaostrzone ograniczenia w SafetyNet zostaną wycofane, by w ciągu ostatnich kilku tygodni ponownie zostać wprowadzone dla garstki użytkowników. Jednak na początku maja Google po cichu potwierdził, że testuje atesty oparte na sprzęcie Odpowiedzi SafetyNet, co sprawiło, że Magisk nie był w stanie ponownie ukryć statusu odblokowania bootloadera Marsz. Jeśli ta zmiana zostanie szeroko wdrożona, będzie to oznaczać, że użytkownicy będą musieli wybierać pomiędzy dostępem do roota/niestandardowych ROMów/jądra/itp. lub preferowane aplikacje i gry bankowe. Jedna z największych zalet Androida dla zaawansowanych użytkowników może wkrótce zniknąć.
Aby podsumować tę serię wydarzeń, powinniśmy najpierw porozmawiać o samym SafetyNet. SafetyNet to zestaw interfejsów API w Usługach Google Play. Jednym z takich interfejsów jest interfejs SafetyNet Attestation API, który może zostać wywołany przez aplikacje innych firm w celu sprawdzenia, czy środowisko oprogramowania urządzenia nie zostało w jakikolwiek sposób naruszone. Interfejs API sprawdza różne rzeczy, takie jak oznaki plików binarnych superużytkownika, stan odblokowania programu ładującego i inne. Kiedy zrootujesz urządzenie za pomocą Magisk, „[tworzy] izolowane„ bezpieczne środowisko ”dla procesu wykrywania [SafetyNet] i przechodzi przez interfejs API Google, aby utworzyć legalny Wynik SafetyNet, który nie odzwierciedla rzeczywistego stanu urządzenia” – twierdzi starszy uznany programista XDA topjohnwu. Dzięki temu użytkownik może zrootować swój telefon, zapewniając jednocześnie, że API zawsze zwróci wartość „false” w przypadku kontroli odblokowania bootloadera. Ta metoda ominięcia wykrywania odblokowania bootloadera przez SafetyNet sprawdza się w przypadku Magisk od kilku ostatnich lat lat, ale dzieje się tak tylko dlatego, że Google wstrzymywał się ze sprawdzaniem integralności obrazu rozruchowego przy użyciu sprzętu zaświadczenie. W marcu wydawało się, że Google w końcu zaczął wykorzystywać atestację sprzętu w SafetyNet do weryfikacji obraz rozruchowy, ale nigdy nie otrzymaliśmy oficjalnego oświadczenia od Google potwierdzającego tę zmianę i tylko kilku użytkowników tak zrobiło dotknięty. Jak zauważył starszy członek XDA DisplaxJednak 5 maja 2020 r. firma Google potwierdziła, że odpowiedzi interfejsu API SafetyNet Attestation z niektórych urządzeń obejmują teraz kontrole sprzętowe.
W grupie dyskusyjnej Google dla „Klientów interfejsu API SafetyNet” firma Google szczegółowo opisała nową funkcję interfejsu API zaświadczania: typ oceny. Odpowiedź JSON Web Signature (JWS) z niektórych urządzeń będzie zawierać pole o nazwie „evaluationType”, które „zapewni programistom wgląd na typy sygnałów/pomiarów, które przyczyniły się do każdej indywidualnej odpowiedzi API SafetyNet Attestation.” Jeden z obsługiwanych tokenów w tym polu znajduje się wartość „HARDWARE_BACKED”, co oznacza, że interfejs API „[używał] dostępnych funkcji zabezpieczeń sprzętowych urządzenia zdalnego (np. poświadczenie klucza sprzętowego), aby wpłynąć na [jego] ocenę.” Google twierdzi, że „obecnie ocenia i dostosowuje kryteria kwalifikacyjne dla urządzeń, w przypadku których będziemy polegać na urządzeniach wspieranych sprzętowo funkcje zabezpieczeń.” Oznacza to, że na niektórych urządzeniach Usługi Google Play korzystają teraz z zaświadczania opartego na sprzęcie, aby wykryć, czy oprogramowanie urządzenia nie zostało naruszone. Firma Google nie udokumentowała oficjalnie tej zmiany poza ogłoszeniem w Grupie dyskusyjnej Google, więc niektórzy programiści korzystający z SafetyNet mogą to zrobić nie jestem świadomy tej zmiany (i dlatego nie sprawdzam jeszcze pola „HARDWARE_BACKED” w odpowiedziach JWS). Jednak w przypadku tych aplikacji, które sprawdzasz to pole, nie można teraz ukryć przed nimi dostępu do konta root, pod warunkiem, że Twoje urządzenie bierze udział w teście, w którym uczestniczy Google działanie.
Według topjohnwu poświadczenie oparte na sprzęcie oznacza, że Usługi Google Play teraz „[wysyłają] niezmodyfikowany certyfikat magazynu kluczy do serwerów SafetyNet, [weryfikują] jego legalność i [sprawdza] dane rozszerzenia certyfikatu, aby dowiedzieć się, czy Twoje urządzenie [ma] włączoną opcję zweryfikowanego rozruchu (status programu ładującego).” Ponieważ klucze prywatne, z których pochodzą certyfikaty magazynu kluczy są wspierane przez izolowane, bezpieczne środowisko telefonu, odzyskanie ich wiązałoby się z pokonaniem zabezpieczeń Trusted Execution Environment (TEE) telefonu lub dedykowanych zabezpieczeń sprzętowych moduł (HSM). Jeśli udałoby się w jakiś sposób ujawnić klucz prywatny, plik klucze zostałyby szybko unieważnione gdy Google się o tym dowiedziało. Google oferuje setki tysięcy dolarów nagród za każdą krytyczną lukę w zabezpieczeniach wpływającą na TEE w telefonach Pixel, co pokazuje, że jest niezwykle mało prawdopodobne, aby był to potencjalny sposób na ominięcie wykrywania odblokowania programu ładującego w każdym razie.
Innym potencjalnym sposobem, w jaki Magisk może w dalszym ciągu fałszować status odblokowania bootloadera, jest modyfikacja kodu po stronie klienta SafetyNet, aby zawsze korzystał z oceny BASIC. Jak notatki topjohnwuwymagałoby to jednak wstrzyknięcia niestandardowego kodu do Usług Google Play za pośrednictwem platformy przechwytującej, takiej jak Xposed Framework. Jest to nie tylko trudne, ponieważ Usługi Google Play są mocno zaciemnione, ale także niemożliwe do ukrycia, ponieważ „niektóre analizy przestrzeni pamięci bardzo ujawnią manipulację kodem co więcej, działałoby to również tylko wtedy, gdy serwery Google nadal akceptują oceny w języku BASIC i jeśli oceny HARDWARE_BACKED nie są wymuszane na urządzeniach obsługujących ich. (Jak twierdzi topjohnwu, odpowiedzi SafetyNet „[pochodzą] z serwerów Google i są podpisane kluczem prywatnym Google”, więc nie można sfałszować rzeczywistych odpowiedzi).
Od wersji Androida 7 Nougat Google wymaga, aby wszystkie urządzenia miały izolowane, bezpieczne środowisko, co oznacza, że ta zmiana w sposobie, w jaki SafetyNet sprawdza odblokowanie programu ładującego, będzie miała wpływ na większość niedostępnych urządzeń Tam. Ponieważ starsze urządzenia bez izolowanego bezpiecznego środowiska oczywiście nie mogą przeprowadzać atestów wspieranych sprzętowo, Magisk nadal będzie mógł ukryć dostęp roota na tych urządzeniach. Jeśli jednak ta zmiana zostanie szeroko wdrożona, wszyscy inni będą musieli dokonać trudnego wyboru między dostępem do konta root a aplikacjami bankowymi.
Niestety, prawdopodobnie istnieje wiele aplikacji, które korzystają z kontroli SafetyNet, gdy tak naprawdę nie muszą. Jednym z przykładów cytowanych przez topjohnwu jest oficjalna aplikacja McDonald's, która najwyraźniej nie chce działać na urządzeniu z odblokowanym bootloaderem. Na Twitterze topjohnwu określa aplikacje nadużywające interfejsu API jako tworzące wrogie środowisko dla zaawansowanych użytkowników. Uznany programista XDA Quinny899 dołącza się anegdota o tym, jak jego zespół rozważał wykorzystanie SafetyNet do sprawdzenia stanu bezpieczeństwa urządzenia. Ostatecznie postanowili tego nie robić, ponieważ aplikacja jego zespołu szyfruje wszystkie wrażliwe dane, z którymi współpracuje. Jego zdaniem nie należy stosować SafetyNet zamiast odpowiednich praktyk w zakresie bezpieczeństwa i przetwarzania danych, zwłaszcza biorąc pod uwagę: możliwość exploitów superużytkownika.
Aby uzyskać więcej informacji na temat wpływu nowej zmiany SafetyNet na Magisk, sprawdź topjohnwu doskonałe FAQ na Twitterze. Jeśli chcesz tylko sprawdzić, czy Twoje urządzenie bierze udział w nowym teście Google SafetyNet, możesz to zrobić ten przewodnik przez XDA Senior Member Displax lub pobierz najnowszą wersję Magisk Manager.
Ten artykuł zaktualizowano 30 czerwca 2020 r. o godz. 10:46 czasu wschodniego, aby skorygować fakt, że Google wypłaca nagrody wyłącznie za luki w zabezpieczeniach TEE wykryte w telefonach Pixel. Ponadto dodano szczegóły dotyczące najnowszej wersji Magisk Managera, która teraz pokazuje pole oceny Typ we wbudowanym module sprawdzającym SafetyNet.