w marcu kilku użytkowników z zainstalowanym Magiskiem zauważyło, że ich urządzenia nie działają. Ta wiadomość była niepokojąca dla społeczności w XDA, ponieważ oznacza to, że wiele kluczowych aplikacji bankowych/finansowych i popularnych gier, takich jak Pokémon Go I Fate / Grand Order, odmawiało uruchomienia na zakorzenionych urządzeniach. Przez pewien czas wydawało się, że zaostrzone ograniczenia w SafetyNet zostały wycofane, tylko po to, aby ponownie wprowadzić je dla garstki użytkowników w ciągu ostatnich kilku tygodni. Jednak na początku maja Google po cichu potwierdziło, że testuje sprzętową atestację odpowiedzi SafetyNet, co sprawiło, że Magisk nie był w stanie ukryć statusu odblokowania bootloadera w marcu. Jeśli ta zmiana zostanie szeroko wprowadzona, oznacza to, że użytkownicy będą musieli wybierać między dostępem do root / custom ROM/kernels / etc. lub ich preferowane aplikacje i gry bankowe. Jeden z największych apeli 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. SafetyNet Attestation API jest jednym z tych interfejsów API i może być wywoływany przez aplikacje innych firm w celu sprawdzenia, czy środowisko programowe urządzenia zostało w jakikolwiek sposób naruszone. API sprawdza różne rzeczy, takie jak oznaki binariów superużytkownika, status odblokowania bootloadera i inne. Kiedy wykorzenić urządzenie z Magisk, to „izolowane’ bezpieczne środowisko 'dla procesu wykrywania, i przechodzi przez API Google, aby utworzyć legit SafetyNet wynik, który nie odzwierciedla rzeczywistego stanu urządzenia,” na XDA starszy uznany deweloper topjohnwu. Pozwala to użytkownikowi rootować swój telefon, zapewniając jednocześnie, że API zawsze zwraca „false” dla wszelkich czeków odblokowujących bootloader. Ta metoda omijania wykrywania odblokowywania bootloadera SafetyNet działa dla Magisk przez ostatnie kilka lat, ale to tylko dlatego, że Google wstrzymało się z weryfikacją integralności obrazu rozruchowego za pomocą atestacji sprzętu. W marcu wydawało się, że Google w końcu zaczyna stosować atest sprzętowy w SafetyNet, aby zweryfikować obraz rozruchowy, ale nigdy nie otrzymaliśmy oficjalnego oświadczenia od Google Potwierdzającego zmianę i tylko kilku użytkowników zostało dotkniętych. Jak zauważył Starszy członek XDA Displax, Google potwierdził 5 maja 2020 r., że odpowiedzi API SafetyNet Attestation z niektórych urządzeń zawierają teraz kontrole sprzętowe.
w grupie Google dla klientów API SafetyNet Google wyszczególnił nową funkcję interfejsu API atestacji: evaluationType. Odpowiedź JSON Web Signature (JWS) z niektórych urządzeń będzie miała pole o nazwie „evaluationType”, które „zapewni programistom wgląd w typy sygnałów/pomiarów, które przyczyniły się do każdej indywidualnej odpowiedzi API atestacji SafetyNet.”Jednym z obsługiwanych tokenów w tym polu jest „HARDWARE_BACKED”, co wskazuje, że API ” dostępne zabezpieczenia sprzętowe urządzenia zdalnego (np. sprzętowe poświadczenie klucza) w celu wpływania na ocenę.”Google twierdzi, że” obecnie ocenia i dostosowuje kryteria kwalifikowalności dla urządzeń, w których będziemy polegać na funkcjach zabezpieczeń opartych na sprzęcie.”Oznacza to, że na niektórych urządzeniach usługi Google Play wykorzystują teraz atest sprzętowy, aby wykryć, że oprogramowanie urządzenia nie zostało naruszone. Google oficjalnie nie udokumentowało tej zmiany poza ogłoszeniem w grupie Google, więc niektórzy programiści, którzy używają SafetyNet, mogą nie być świadomi tej zmiany (a zatem nie sprawdzają jeszcze pola „HARDWARE_BACKED” w odpowiedziach ŚJ.) Jednak w przypadku tych aplikacji, które sprawdzają to pole, nie ma teraz możliwości ukrycia przed nimi dostępu do roota, pod warunkiem, że urządzenie jest częścią testu, który działa Google.
według topjohnwu, certyfikacja sprzętowa oznacza, że usługi Google Play są teraz” niezmodyfikowanym certyfikatem keystore dla serwerów SafetyNet, jego legalnością i danymi rozszerzenia certyfikatu, aby wiedzieć, czy Twoje urządzenie zweryfikowało rozruch (status bootloadera).”Ponieważ klucze prywatne, z których pochodzą certyfikaty keystore, są wspierane przez izolowane bezpieczne środowisko telefonu, ich odzyskanie wiązałoby się z pokonaniem bezpieczeństwa zaufanego środowiska wykonawczego telefonu (TEE) lub dedykowanego modułu zabezpieczeń sprzętowych (hsm). Gdyby ktoś był w stanie w jakiś sposób ujawnić klucz prywatny, klucze szybko zostałyby wycofane, gdy google się dowie. Google oferuje setki tysięcy dolarów w nagrodach za wszelkie krytyczne luki w zabezpieczeniach wpływające na TEE w telefonach Pixel, co pokazuje, że jest bardzo mało prawdopodobne,aby to było potencjalną drogą do obejścia wykrywania odblokowywania bootloadera.
innym potencjalnym sposobem, w jaki Magisk może nadal fałszować status odblokowania bootloadera, jest zmodyfikowanie kodu po stronie klienta SafetyNet, aby zawsze używał podstawowej oceny. Jak zauważa topjohnwu, choć, wymagałoby to wstrzykiwania niestandardowego kodu do usług Google Play za pomocą zaczepiania framework jak Xposed Framework. Jest to nie tylko trudne do zrobienia, ponieważ usługi Google Play są bardzo zaciemnione, ale także niemożliwe do ukrycia, ponieważ ” niektóre analizy przestrzeni pamięci bardzo łatwo ujawnią manipulację kodem.”Co więcej, działałoby to tylko wtedy, gdy serwery Google nadal akceptują podstawowe oceny i jeśli oceny HARDWARE_BACKED nie są egzekwowane na urządzeniach, które je obsługują. (Odpowiedzi SafetyNet „z serwerów Google i są podpisane kluczem prywatnym Google”, według topjohnwu, więc rzeczywiste odpowiedzi nie mogą być sfałszowane.)
od Androida 7 Nougat, Google wymaga, aby wszystkie urządzenia miały odizolowane bezpieczne środowisko, co oznacza, że zmiana sposobu, w jaki SafetyNet weryfikuje odblokowanie bootloadera, wpłynie na większość urządzeń, które są tam. Ponieważ starsze urządzenia bez izolowanego bezpiecznego środowiska oczywiście nie mogą wykonywać atestacji sprzętowej, Magisk nadal będzie mógł ukryć dostęp roota na tych urządzeniach. Ale jeśli ta zmiana zostanie szeroko wprowadzona, wszyscy inni będą musieli dokonać trudnego wyboru między dostępem roota a aplikacjami bankowymi.
niestety, prawdopodobnie istnieje wiele aplikacji, które używają kontroli SafetyNet, gdy w rzeczywistości nie muszą. Jednym z przykładów przytoczonych przez topjohnwu jest oficjalna aplikacja McDonald ’ s, która pozornie odmawia uruchomienia na odblokowanym urządzeniu bootloadera. Na Twitterze topjohnwu wywołuje aplikacje, które nadużywają API, tworząc wrogie środowisko dla zaawansowanych użytkowników. Uznany przez XDA deweloper Quinny899 dołącza do anegdoty o tym, jak jego zespół rozważał użycie 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. SafetyNet, jak twierdzi, nie powinien być stosowany zamiast odpowiednich praktyk bezpieczeństwa i obsługi danych, zwłaszcza gdy rozważa się możliwość exploitów superużytkownika.
zalecam @AndroidDev, aby ograniczyć testowanie SafetyNet ze sprzętem do „prawdziwych” aplikacji wrażliwych na bezpieczeństwo. Programiści powinni przejść proces aplikacji, aby zakwalifikować ten poziom dostępu do API. To śmieszne, że McDonalds odmawia uruchomienia na odblokowanym urządzeniu bootloadera.
— John Wu (@topjohnwu) czerwiec 29, 2020
aby uzyskać więcej informacji o tym, jak nowa zmiana SafetyNet wpływa na Magisk, sprawdź doskonałe FAQ topjohnwu na Twitterze. Jeśli chcesz tylko sprawdzić, czy Twoje urządzenie jest częścią nowego testu Google SafetyNet, możesz postępować zgodnie z tym przewodnikiem autorstwa starszego członka XDA Displax lub pobrać najnowsze wydanie Magisk Manager.
zaktualizowany Menedżer Magisk, aby odzwierciedlić pole evaluationType w kontrolach SafetyNet, aby ludzie mogli zacząć liczyć ostatnie dni chwały
pic.twitter.com/x61tGjM7IK
— John Wu (@topjohnwu) czerwiec 30, 2020
ten artykuł został zaktualizowany o 10:46 AM EST W June 30, 2020, aby poprawić, że Google wypłaca tylko nagrody za luki w zabezpieczeniach tee Znalezione w telefonach Pixel. Ponadto dodano szczegóły dotyczące najnowszego wydania Magisk Manager, które teraz pokazuje pole evaluationType we wbudowanym kontrolerze SafetyNet.
- o autorze
- Czytaj dalej
- Google forms Android Ready se Alliance to drive adoption of digital car keys and driver ’ s licences
- Fairphone 2 od 2015 teraz otrzymuje oficjalną aktualizację do Androida 9 Pie
- Motorola Moto G50 sport budżet 5G chip i niska cena
- ASUS wydaje nowe aktualizacje dla ROG Phone 5, ROG Phone 3 i ROG Phone II z łatkami bezpieczeństwa i poprawkami błędów
o autorze
Mishaal Rahman
Jestem redaktorem naczelnym XDA. Oprócz najświeższych wiadomości na temat systemu operacyjnego Android i urządzeń mobilnych, zarządzam wszystkimi treściami redakcyjnymi i recenzjami na portalu. Porady / Pytania dla mediów: [email protected].
Czytaj dalej
-
Google forms Android Ready se Alliance to drive adoption of digital car keys and driver ’ s licences
-
Fairphone 2 od 2015 teraz otrzymuje oficjalną aktualizację do Androida 9 Pie
-
Motorola Moto G50 sport budżet 5G chip i niska cena
-
ASUS wydaje nowe aktualizacje dla ROG Phone 5, ROG Phone 3 i ROG Phone II z łatkami bezpieczeństwa i poprawkami błędów
