Luki w ADB odnalezione i wyeliminowane dzięki pracy społeczności Androida

Android Debug Bridge, znany bardziej jako ADB, jest popularnym narzędziem deweloperskim dla Androida, stworzonym i upublicznionym przez Google. Pozyskać go można pobierając SDK Androida, lub różne toolkity z forów internetowych. Za pomocą kabla USB (lub Wi-Fi) i zestawu poleceń z łatwością wyślemy do urządzenia plik, zainstalujemy aplikację lub uzyskamy log systemowy, który może zostać wykorzystany do poznania przyczyny błędu w systemie. Dlatego jest on powszechnie używane zarówno przez programistów, jak i zwykłych użytkowników, którzy starają się pomóc twórcom tzw. custom ROM-ów w procesie eliminacji błędów. Z dużą dawką prawdopodobieństwa można stwierdzić, że ADB jest najbardziej złożonym narzędziem do komunikacji na linii komputer – Android.

Jak się jednak okazuje. ADB może także zostać użyte do ataku na Androida, o czym poinformował portal droidsec.org zajmujący się tematyką bezpieczeństwa mobilnego systemu Google'a.

Aby zrozumieć działanie ADB i genezę zagrożenia, musimy poznać trzy podstawowe elementy składowe, którymi są:

Demon ADB, uruchamiany na urządzeniu z Androidem. Jest on kontrolowany przez „Debugowanie USB” dostępne w opcjach programistycznych urządzenia. Demon ten aktywuje komunikację między komputerem a smartfonem zazwyczaj przez kabel USB, ale możliwa jest także komunikacja przez port TCP.

Serwer ADB, uruchamiany na maszynie deweloperskiej (najczęściej komputerze osobistym). Zyskuje się do niego dostęp poprzez zainstalowanie tzw. platform-tools z Android SDK. Element ten jest niewidoczny dla użytkowników i aktywuje się po wpisaniu komendy „adb” lub poprzez użycie komend „start-server” i „kill-server”. Głównym zadaniem narzędzia jest obsługa przekierowania portów i nawiązanie solidnego połączenie z urządzeniami podłączonymi do komputera.

Klient ADB uruchamiany na komputerze. Jest nią komenda „adb” używana przez programistów (lub inne narzędzia) celem uzyskania dostępu do urządzenia z Androidem przez wspomniany kabel USB lub Wi-Fi. Używając różnych poleceń (np. adb push) użytkownik nawiązuje komunikację między serwerem a demonem. Niektóre polecenia jak „adb devices” działają wyłącznie po stronie komputera, bez angażowania demona ADB na urządzeniu.

Od premiery Androida w wersji 4.2.2 Jellybean, wymagane jest dodatkowe uwierzytelnienie serwerem ADB i demonem. Najczęściej przedstawiane jest ono jako monit na ekranie urządzenia, proszący o sparowanie urządzeń. Owo uwierzytelnienie nie jest natomiast wymagane między klientem a serwerem. Z racji tego, że serwer nasłuchuje port TPC, inni użytkownicy korzystający z systemów obsługujących kilku użytkowników (multi-user) mogą używać serwera do komunikacji z połączonymi urządzeniami. Zwyczajem niektórych deweloperów i użytkowników jest uruchamianie serwera ADB z dostępem roota, gdy klient ADB uruchomiony jest w trybie normalnym. Nie jest to rozwiązanie idealne, które w przypadku używania multi-usera może przysporzyć wielu kłopotów.

Programiści przeprowadzający audyt kodu Androida odnaleźli dwie luki, które mogą umożliwić hakerowi przejęcie kontroli nad urządzeniem za pomocą protokołu ADB. Pierwsza z nich polega na przepełnieniu stosu klienta ADB i ma bezpośredni związek z błędnie napisanym plikiem system/core/adb/adb_client.c, będącym częścią składową ADB po stronie klienta. W przypadku błędnego połączenia klienta z serwerem nawiązywane jest nowe połączenie. W niesprzyjających okolicznościach może nastąpić przepełnienie stosu klienta ADB, które może zostać wykorzystane przez napastnika do przejęcia kontroli nad urządzeniem. Drugi błąd leży po stronie serwera i polega na braku dwóch zabezpieczeń, które powinny zostać wprowadzone do pliku binarnego ADB przez Google. Niezbędne zmiany nie zostały jednak wprowadzone.

Na systemach obsługujących wielu użytkowników, napastnik może więc rozpocząć atak na serwer ADB i czekać na to, aby kolejny użytkownik wpisał komendę „adb”. W przypadku, gdy uruchomiony serwer nasłuchuje bez błędu, atakujący nie będzie w stanie kontynuować ataku. Gdy nastąpi jednak przepełnienie stosu, atakujący ma możliwość skutecznego przejęcia kontroli. Drobnym pocieszeniem jest fakt, że atak możliwy jest tylko w bardzo wczesnym stadium negocjacji serwera z klientem.

Systemem podatnym na ataki jest Linux w wersji x86_64. Co ciekawe, wydanie 32-bitowe nie jest wrażliwe na atak. W przypadku ataku system wyświetla błąd, blokując przy tym dostęp do danych. Osoby weryfikujące kod przeprowadzały test tylko na systemie Linux. Zachowanie Windows i OS-a X w tym scenariuszu ataku nie jest znane.

Dla obu luk zostały już przygotowane łatki. Wprowadzono je jednak na tyle późno, że zmiany nie zostały włączone do głównej gałęzi Androida przed premierą KitKata. Jedyną na razie skuteczną metodą ochrony jest zbudowanie systemu samemu z uwzględnieniem wprowadzonych zmian. Dużą rolę w rozwiązaniu problemu mieli użytkownicy, którzy mogą przeprowadzać audyt kodu i wprowadzać własne poprawki. Podobne rozwiązania nie są powszechne wśród innych systemów mobilnych.