Kolejna luka w narzędziach do rootowania Androida potwierdza uniwersalny problem

Rootowanie Androida przeszło długą drogę od czasów, gdy wymagało głębokiej znajomości ADB i ryzykownych operacji na bootloaderze. Dzisiaj narzędzia takie jak KernelSU, APatch czy SKRoot obiecują łatwiejszy dostęp do uprawnień administratora, ale jak pokazuje najnowsze odkrycie zespołu Zimperium zLabs, nadal niosą ze sobą poważne zagrożenia bezpieczeństwa.

TLDR:

• Luka w KernelSU 0.5.7 pozwalała złośliwym aplikacjom podszywać się pod oficjalny menedżer poprzez manipulację kolejności plików APK w systemowej tabeli deskryptorów, co umożliwiało uzyskanie pełnego dostępu root bez wiedzy użytkownika
• Badacze Zimperium przypominają, że niemal każdy framework (KernelSU, Magisk, APatch) miał w swojej historii krytyczne luki bezpieczeństwa, a używanie zrootowanych urządzeń wiąże się z poważnym ryzykiem.

Badacze z Zimperium odkryli krytyczną lukę w KernelSU w wersji 0.5.7, która pozwalała atakującym podszywać się pod aplikację menedżera i uzyskiwać dostęp root do urządzenia. Co szczególnie niepokojące, luka została pierwotnie zidentyfikowana już w połowie 2023 roku, ale dopiero teraz została publicznie ujawniona. Pokazuje to, jak długo potencjalnie niebezpieczne oprogramowanie może funkcjonować w ekosystemie, zanim jego wady zostaną naprawione.

Współczesne frameworki rootujące (w tym właśnie KernelSU), opierają się na jednej strategii: patchowaniu jądra Androida. Podejście to polega na hookowaniu (przechwytywaniu) kluczowych funkcji kernela poprzez hot-patching prekompilowanego jądra lub bezpośrednią modyfikację kodu źródłowego. Pozwala to narzędziom na przechwytywanie wykonania i uruchamianie arbitralnego kodu w przestrzeni jądra. Aby zbudować mostek między przestrzenią kernela a użytkownika, zazwyczaj hookują specyficzne wywołania systemowe, tworząc ukryte kanały komunikacji z aplikacją menedżera KernelSU, działającą z normalnymi uprawnieniami użytkownika.

KernelSU w podatnej wersji używał trójstopniowej weryfikacji podczas procesu CMD_BECOME_MANAGER: sprawdzał ścieżkę aplikacji na podstawie jej UID, własność folderu oraz podpis cyfrowy pakietu APK. Luka tkwiła w ostatnim kroku – system skanował tabelę deskryptorów plików w poszukiwaniu pierwszego pliku /data/app/*/base.apk pasującego do wzorca, aby zweryfikować podpis.

Atakujący mogli wykorzystać lukę poprzez manipulację kolejności deskryptorów plików, zapewniając, że oficjalny base.apk KernelSU pojawia się wcześniej w tabeli fd (file descriptor – liście wszystkich otwartych plików danego procesu) niż APK atakującego. W praktyce oznaczało to dołączenie oficjalnego pliku APK managera KSU do własnej aplikacji – na przykład w katalogu lib – i odpowiednie zarządzanie deskryptorami plików. Taka manipulacja pozwalała kernelowi na odczytanie prawidłowego podpisu zamiast podpisu złośliwej aplikacji.

Przebieg ataku wygląda więc następująco: 

1. Napastnik zdołał umieścić swoją własną złośliwą aplikację z uprawnienieniem RECEIVE_BOOT_COMPLETED w manifeście aplikacji na zrootowanym urządzeniu z KernelSU v0.5.7. Nie ma jeszcze uprawnień roota.
2. Na urządzeniu jest zainstalowany też oficjalny menedżer KernelSU.
3. Teraz napastnik dołącza oficjalny APK KernelSU do swojej aplikacji (np. w katalogu /lib).
4. Manipulujle deskryptorami plików, aby zidentyfikować fd swojego pakietu APK, zamknąć stdin (fd 0), otworzyć oficjalny KernelSU APK na niższym numerze fd.
5. Wywołuje CMD_BECOME_MANAGER z odpowiednią ścieżką – system znajdzie najpierw oficjalny APK (z prawidłowym podpisem) zamiast złośliwej aplikacji.
6. Teraz czas na klasyczny timing attack, złośliwa aplikacja musi uruchomić się przed menedżerem, najlepiej po restarcie. 
7. W efekcie napastnik dostaje pełne uprawnienia roota (euid=0)
8. I może wykonywać polecenia CMD_GRANT_ROOT i CMS_SET_SEPOLICY, przejmując kontrolę nad urządzeniem

Nic więc dziwnego, że badacze Zimperium stwierdzają: „W naszym doświadczeniu, niemal każdy framework rootujący zawiera przynajmniej jedną krytyczną lukę w pewnym momencie swojego cyklu życia”. Problem nie ogranicza się zresztą tylko do KernelSU. Magisk niedawno zmagał się z luką CVE-2024-48336, która pozwalała lokalnym aplikacjom podszywać się pod Google Mobile Services i cicho uzyskiwać uprawnienia roota bez interakcji z użytkownikiem. APatch w starszych wersjach miał słabszy mechanizm uwierzytelniania hasłem, który mógł być wykorzystany do uruchamiania uprzywilejowanych operacji.

Dla potencjalnych napastników kluczową zaletą tego typu luk jest to, że mogą być wykorzystane bez jakiejkolwiek interakcji ze strony użytkownika. Atak jest skuteczny, gdy złośliwa aplikacja zostanie uruchomiona przed prawdziwym menedżerem KernelSU. W praktyce może to być całkiem realne — wystarczy, że aplikacja atakującego zadeklaruje uprawnienie RECEIVE_BOOT_COMPLETED w manifeście, aby automatycznie uruchamiać się po restarcie urządzenia. Ponieważ Android nie gwarantuje deterministycznej kolejności startowania aplikacji (zależna jest ona od priorytetów procesów i dostępności zasobów), złośliwa aplikacja może wyprzedzić oficjalny menedżer i przeprowadzić atak, zanim użytkownik zdąży cokolwiek zauważyć.

Szerszy problem tkwi w samym charakterze tych narzędzi. Frameworki rootujące są często rozwijane przez niezależnych programistów bez formalnego nadzoru bezpieczeństwa, co wprowadza nieprzewidywalne ryzyka. Problemy te wynikają z pośpiesznego rozwoju, braku formalnych przeglądów bezpieczeństwa i inherentnej złożoności modyfikowania uprzywilejowanego zachowania kernela z przestrzeni użytkownika.

Dla użytkowników oznacza to konieczność stałego balansowania między korzyściami płynącymi z pełnej kontroli nad urządzeniem a potencjalnymi zagrożeniami bezpieczeństwa. Każda luka w narzędziach rootujących, które w pewnym sensie można przecież uznać za malware, może potencjalnie prowadzić do instalacji malware cyberprzestępców, kradzieży wrażliwych danych czy nawet całkowitego przejęcia kontroli nad urządzeniem. W środowiskach korporacyjnych problem jest jeszcze poważniejszy: zrootowane urządzenia mogą ominąć kontrole bezpieczeństwa aplikacji i stanowić wektor ataku na infrastrukturę firmową.

Nam pozostaje się zastanawiać, czy użytkownicy rootujący swoje urządzenia nie wpadają w pułapkę własnych potrzeb. Po narzędzia takie jak KernelSU czy APatch sięga się głównie w celu usunięcia bloatware w rodzaju preinstalowanych aplikacji Netfliksa czy Facebooka, zablokowania reklam na poziomie systemowym czy uzyskania pełnej kontroli nad personalizacją, co jest całkowicie zrozumiałe. Jednak w pogoni za tymi udogodnieniami, entuzjaści z XDA Developers i temu podobnych społeczności, przerzucający się między kolejnymi narzędziami do „uwalniania” swoich telefonów, mogą nieświadomie narażać się na exploity. Paradoksalnie, próbując uwolnić się od ograniczeń narzuconych przez producentów, skazują się na potencjalnie poważniejsze zagrożenia niż te, od których próbowali się uwolnić.

Mam roota, co robić?

Przede wszystkim należy sprawdzić wersję używanego frameworka. Luka dotyczyła konkretnie KernelSU w wersji 0.5.7, a deweloperzy naprawili ją już w 2023 roku, przy okazji wydania wersji 0.6.9.  Wprowadzili wtedy też usprawienia mechanizmu bezpieczeństwa, przechodząc z weryfikacji nazwy pakietu APK na weryfikację podpisu aplikacji menedżera, gdyż jak wyjaśniają twórcy: „(…) podpisów nie można podrobić tak jak nazw pakietów”. Dodatkowo wprowadzili zarządzanie autoryzacją, które pozwala kontrolować, które aplikacje mogą używać uprawnień root, oraz funkcje App Profiles do ograniczania tych uprawnień.

Użytkownicy starszych wersji (a jest ich niemało, często narzędzia pozostają niezaktualizowane od czasu uzyskania roota) powinni niezwłocznie zaktualizować je do najnowszego wydania. 

Ogólnie rzecz biorąc, warto ograniczyć liczbę zainstalowanych aplikacji z nieznanych źródeł, regularnie monitorować aplikacje z uprawnieniami root oraz unikać eksperymentowania ze zbyt świeżymi wersjami narzędzi rootujących na głównych urządzeniach. Dla osób, które nie potrzebują funkcji roota, rozsądnym rozwiązaniem może być powrót do stock ROM-u – współczesne systemy androidowe oferują już wiele z funkcji, dla których użytkownicy wcześniej rootowali urządzenia, takich jak zaawansowane zarządzanie uprawnieniami czy personalizacja interfejsu. Tym, którzy zdecydują się pozostać przy zrootowanych urządzeniach, zaleca się śledzenie newsów o mobilnym bezpieczeństwie i szybkie reagowanie na informacje o nowych lukach.

źródło: zimperium.com/blog

~Adam Golański