Zdalne wykonanie kodu na telefonach Samsunga – Galaxy S6/S5/Note4 – przez…klawiaturę

za swiftkey.com

Wczoraj został opublikowany dość elektryzujący post pokazujący dokładną ścieżkę exploitacji telefonów Samsunga (Galaxy S6, Galaxy S5 oraz Note 4). Całość odbywa się poprzez wykorzystanie błędu w klawiaturze Swift, którą Samsung instaluje domyślnie w wybranych modelach swoich telefonów (różne doniesienia mówią o potencjalnie nawet 600 milionach podatnych telefonów!).

Problem umożliwia wykonanie z wysokimi uprawnieniami dowolnego kodu na atakowanym telefonie. Co więcej, nawet używanie innej domyślnie klawiatury nie zabezpiecza nas przed atakiem, a domyślnie dołączanej do telefonów Samsunga klawiatury Swift nie da się w sposób normalny (tj. bez np. rootowania telefonu) usunąć.

Oryginalnie, autorzy znaleziska podsumowują całość tak:

A remote attacker capable of controlling a user’s network traffic can manipulate the keyboard update mechanism on Samsung phones and execute code as a privileged (system) user on the target’s phone.

W wolnym tłumaczeniu: zdalny atakujący który ma możliwość kontrolowania ruchu z urządzenia (w zasadzie dowolny atak MiTM) – może wpłynąć na mechanizm aktualizacji telefonów i wykonać dowolny kod z uprawnieniami system na atakowanym telefonie.

 

Cała publikacja pokazuje bardzo dużo szczegółów: od opisu podatnych urządzeń przez możliwy wpływ na system (atakujący ma wysokie uprawnienia w systemie operacyjnym, więc może choćby instalować własne złośliwe aplikacje / podsłuchiwać rozmowy / SMSy – w skrócie wpływać na wszystko co potrafi telefon ofiary) a skończywszy na odpowiednim Proof of Concept pokazującym problem. Całość została również zaprezentowana 16 czerwca 2015 roku na konferencji BlackHat w Londynie.

Szczegóły techniczne

Klawiatura Swift co jakiś czas próbuje pobrać z sieci przez http (!) plik zip z aktualizacjami paczek językowych, które następnie rozpakowuje w folderze /data/data/com.sec.android.inputmethod/app_SwiftKey/<język>.

Mając możliwość podglądu i modyfikacji ruchu w sieci ofiary, np. przy pomocy proxy, wystarczy podmienić zipa z aktualizacją i podrzucić w nim własne pliki. Aplikacja weryfikowała integralność pliku, ale robiła to tylko… przez sumę SHA1 odbieraną we wcześniejszym zapytaniu do serwera (też przez http).

Zatem atakujący poza podmianą samego zipa, musiał jeszcze pamiętać o ustawieniu poprawnej sumy SHA1.  Co więcej, dzięki zastosowaniu prostej sztuczki z nadaniem plikowi w zipie nazwy np. ../../../../../../../../../../../../data/payload, możliwe było wyjście poza katalog SwitfKey i zapisanie pliku w dowolnej lokalizacji na telefonie.

Kolejnym krokiem było wymyślenie sposobu, jak wykorzystać ten problem do wykonania dowolnego kodu. W tym celu znalazca błędu zajrzał do katalogu /data/dalvik-cache, gdzie przechowywane są wstępnie przekompilowane klasy używane przez aplikacje na Androidzie, aby znaleźć tam pakiety uruchamiane z uprawnieniami użytkownika systemowego. Po wybraniu jednego z takich plików (konkretnie: /data/dalvik-cache/system@priv-app@DeviceTest.apk@classes.dex), wystarczyło już tylko przygotować kod w Javie z exploitem, przekompilować go do pliku dex i wrzucić w zipa. Po zmuszeniu Swifta do aktualizacji i restarcie telefonu, badacz mógł już podłączyć się netcatem do urządzenia:

nc 192.168.181.96 8889
       id
       uid=1000(system) gid=1000(system) groups=1000(system),1001(radio),1007(log),1010(wifi),1015(sdcard_rw),1021(gps),1023(media_rw),1024(mtp),1028(sdcard_r),2001(cache),3001(net_bt_admin),3002(net_bt),3003(inet),3004(net_raw),3005(net_admin),3009(qcom_diag),41000(u0_a31000) context=u:r:system_app:s0

PoC można też zobaczyć na filmie:

Jak się zabezpieczyć?

Autorzy znaleziska piszą tak:

Unfortunately, the flawed keyboard app can’t be uninstalled or disabled. Also, it isn’t easy for the Samsung mobile device user to tell if the carrier has patched the problem with a software update. To reduce your risk, avoid insecure Wi-Fi networks, use a different mobile device and contact your carrier for patch information and timing.

Czyli w zasadzie sami nie możemy zrobić update nowej klawiatury (choć przynajmniej najnowsze wersje Switfkey dostępne w GooglePlay nie są podatne). Trzeba zatem czekać na oficjalnego patcha lub ew. patcha od operatora GSM. Warto na pewno unikać potencjalnie niebezpiecznych miejsc gdzie często sniffowany jest ruch (jak np. publiczne / otwarte sieci WiFi).

–ms & mb