Twórca Magisk odkrył, że Google mógł zacząć sprawdzać sprzęt, aby ustalić, czy na urządzeniu został odblokowany bootloader.
Uznany programista XDA topjohnwuProjekt „Magisk” stał się w społeczności Androida synonimem „root”. Jednym z głównych powodów, dla których jest tak popularny, jest to, że może ukryć fakt, że użytkownik zmodyfikował swoje urządzenie. Jednak Google może ograniczać zdolność Magiska do ukrywania statusu odblokowania programu ładującego przed aplikacjami.
Aby zrootować telefon, zwykle musisz odblokować program ładujący, który umożliwia flashowanie zmodyfikowanych obrazów rozruchowych. Jest to potrzebne, ponieważ Magisk modyfikuje obraz rozruchowy, aby sfałszować status programu ładującego i/lub sprawdzić stan zweryfikowanego rozruchu. Interfejs API Google SafetyNet Attestation API, będący częścią Usług Google Play, służy do informowania aplikacji, czy działa ona na zmodyfikowanym urządzeniu; jeśli API SafetyNet wykryje, że bootloader został odblokowany, zwróci status błędu w celu sprawdzenia „Podstawowej integralności”. Urządzenia, które nie przejdą tej kontroli, mogą zostać zablokowane w aplikacjach korzystających z interfejsu API SafetyNet w celu określenia integralności urządzenia; takie aplikacje zazwyczaj obejmują aplikacje bankowe, aplikacje płatnicze (takie jak Google Pay) i wiele gier online (takich jak Pokémon Go). Ponieważ jednak API SafetyNet dotychczas wykorzystywało jedynie kontrolę oprogramowania w celu ustalenia, czy urządzenie nie zostało naruszone, Magisk może po prostu sfałszować bootloader i/lub status Verified Boot, ponieważ jest on zainstalowany na niższym poziomie i z wyższymi uprawnieniami niż Usługi Google Play i inna przestrzeń użytkownika Aplikacje. Jak wyjaśnia topjohnwu, MagiskHide „[tworzy] izolowane «bezpieczne środowisko» dla procesu wykrywania, które przechodzi przez interfejs API Google w celu utworzenia
Ostatnio jednak użytkownicy zauważyli, że ich urządzenia odblokowane za pomocą programu ładującego nie przechodzą podstawowej kontroli integralności SafetyNet, mimo że używali Magisk do łatania obrazu rozruchowego. Według topjohnwu dzieje się tak dlatego, że Google mógł wdrożyć poświadczenie klucza na poziomie sprzętu w celu sprawdzenia, czy obraz rozruchowy nie został naruszony. W szczególności oznacza to, że Usługi Google Play „[wysyłają] niezmodyfikowany certyfikat magazynu kluczy do serwerów SafetyNet, weryfikują jego legalność i sprawdzają dane rozszerzenia certyfikatu, aby dowiedzieć się, czy Twoje urządzenie [ma] włączoną funkcję zweryfikowanego rozruchu (status programu ładującego).” Oznacza to, że może już nie być możliwe jest ukrycie faktu, że bootloader został odblokowany, co spowoduje, że aplikacje takie jak Google Pay i Pokémon Go nie będą działać normalnie.
Jak zauważył topjohnwu, ta zmiana w sposobie, w jaki SafetyNet sprawdza stan odblokowania programu ładującego, następuje poprzez aktualizację po stronie serwera interfejsu API SafetyNet zawartego w Usługach Google Play. Jednak nie każdy użytkownik nie przechodzi zaktualizowanych testów SafetyNet, więc nowe poświadczenie klucza na poziomie sprzętu może nie być jeszcze powszechnie stosowane.
Wielokrotnie widzieliśmy, jak topjohnwu pokonuje przeszkody techniczne. Google często przeprowadza nowe kontrole w SafetyNet, które topjohnwu następnie odkrywa i omija w Magisk. Każda nowa wersja Androida wprowadza zmiany w strukturze partycji lub obrazie startowym, co wymaga od topjohnwu przestudiowania zmian, a następnie wdrożenia nowej metody łatania. Jednak tym razem nawet topjohnwu może mieć trudności ze znalezieniem obejścia.
Dzieje się tak, ponieważ tym razem obejście polegałoby na zhakowaniu oprogramowania sprzętowego Trusted Execution Environment (TEE) urządzeń w celu odzyskania klucza prywatnego. Jest to jednak niezwykle trudne, ponieważ wymaga znalezienia luki w oprogramowaniu sprzętowym, które zostało zaprojektowane tak, aby było niezwykle bezpieczne. W rzeczywistości wiele firm oferuje płatności rzędu setek tysięcy dolarów w przypadku wykrycia takiej luki. Na przykład Google płaci 250 000 dolarów za luki w zabezpieczeniach umożliwiające zdalne wykonanie kodu w zaufanym środowisku wykonawczym Pixel oraz do 1 000 000 dolarów za luki w zabezpieczeniach Tytan M chip zabezpieczający. Nawet gdyby w jakiś sposób doszło do wycieku klucza prywatnego, jest mało prawdopodobne, że od tego czasu byłby on zbyt przydatny Google może zdalnie unieważnić klucz więc nie można go użyć do sprawdzenia integralności urządzeń.
Po powszechnym egzekwowaniu zaświadczania kluczy na poziomie sprzętowym w SafetyNet większość urządzeń z odblokowanymi programami ładującymi z systemem Android 8.0 Oreo lub nowszym nie przejdzie podstawowej kontroli integralności SafetyNet. Dzieje się tak, ponieważ wszystkie urządzenia uruchomione z systemem Android 8.0 Oreo lub nowszym muszą mieć sprzętowy magazyn kluczy zaimplementowany w TEE. Niektóre urządzenia mają obecnie nawet dedykowane sprzętowe moduły bezpieczeństwa (HSM), które jeszcze bardziej utrudniają eksploatację, odsuwając TEE od głównego procesora; Titan M w Pixelu 4 i Nowy układ zabezpieczający Samsunga w Galaxy S20 są tego przykładem.
Topjohnwu również wyjaśnia że inne potencjalne obejścia są albo niemożliwe, albo bardzo trudne. Używanie Xposed Framework do modyfikowania interfejsu API SafetyNet Attestation w Usługach Google Play prawdopodobnie nie będzie działać, ponieważ „właściwe kontrole SafetyNet zweryfikują wyniki na zdalnym serwerze, a nie na [] urządzenie, którym można manipulować za pomocą platform wstrzykiwania kodu.” Co więcej, Usługi Google Play są mocno zaciemnione, co sprawia, że utworzenie takiego modułu Xposed jest na początku niezwykle trudne miejsce. Podrabianie wyniku testu SafetyNet również nie będzie możliwe, ponieważ odpowiedzi SafetyNet „pochodzą z serwerów Google i są podpisane kluczem prywatnym Google”.
Już od kilku lat Google może wzmocnić kontrole SafetyNet za pomocą sprzętowego poświadczania kluczy. Fakt, że powstrzymywali się od tego przez 3 lata, pozwolił użytkownikom cieszyć się modułami root i Magisk bez poświęcania możliwości korzystania z aplikacji bankowych. Wygląda jednak na to, że zdolność Magiska do skutecznego ukrywania statusu odblokowania bootloadera wkrótce się skończy. To zmiana, której oczekiwaliśmy od lat, ale ze smutkiem obserwujemy, że w końcu wchodzi ona w życie. Mamy nadzieję, że Google zaktualizuje interfejs API SafetyNet Attestation, aby zwracać uwagę, czy kontrola stanu odbywała się na poziomie sprzętowym zaświadczenie, ponieważ umożliwiłoby to twórcom aplikacji podjęcie decyzji, czy chcą blokować wszystkich użytkowników, którzy odblokowali aplikację program rozruchowy.
Dziękuję Danielowi Micay’owi (@DanielMicay) za jego wkład w tę sprawę!