StrandHogg 2.0 to nowa, niebezpieczna luka w zabezpieczeniach Androida. Oto, jak może to wpłynąć na użytkowników i jak programiści mogą chronić przed nim swoje aplikacje.
Jest 22:00. Czy wiesz, gdzie są Twoje działania? Pojawiła się nowa luka, którą można wykorzystać na milionach urządzeń z Androidem i która jest również dość niebezpieczna. W skrócie, ta wada projektowa umożliwia atakującemu zaprezentowanie własnego działania (strony) na wierzchu innej aplikacji, co może zmylić użytkownika i zmusić go do ujawnienia swoich prywatnych danych. Luka została nazwana StrandHogg 2.0 i została niedawno ujawniona przez Promon, norweska firma ochroniarska.
Luka StrandHogg 2.0 teoretycznie dotyczy wszystkich urządzeń z Androidem w wersjach starszych niż Honeycomb (3.0) i nowszych niż Android 9 Pie (9.0). Na podstawie najnowsze statystyki dystrybucji wersji Androida, oznacza to, że około 91,8% wszystkich urządzeń z Androidem jest podatnych na StrandHogg 2.0. Luka została przypisana CVE-2020-0096 i otrzymał A
poziom ważności „krytyczny”. Nie wymaga żadnych specjalnych uprawnień do działania i może działać niemal całkowicie bez interakcji użytkownika. Wystarczy, że użytkownik otworzy aplikację zawierającą złośliwy kod, a wówczas będzie narażony na ataki.Promon był na tyle miły, że przesłał nam swoją aplikację sprawdzającą koncepcję i jej kod źródłowy, abyśmy mogli jak najlepiej wyjaśnij, jak działa exploit, dlaczego jest on ważny dla użytkowników i w jaki sposób programiści mogą chronić swoje aplikacje przeciwko temu.
Jak to działa
Załóżmy, że korzystasz z Gmaila i klikasz link internetowy. Jeśli przejdziesz do ekranu ostatnich aplikacji, możesz zauważyć, że strona internetowa znajduje się „wewnątrz” Gmaila. Podgląd pokazuje witrynę, ale ikona i nazwa aplikacji nadal pochodzą z Gmaila. Dzieje się tak, gdy aplikacja/działanie uruchamia inną aplikację/działanie w tym samym zadaniu. Teraz wyobraź sobie, że nie otworzyłeś tego linku celowo. Dla Ciebie wygląda to tak, jakby to była tylko część aplikacji Gmail. To jest zachowanie, które wykorzystuje StrandHogg 2.0.
Będziemy musieli pominąć tutaj pewne szczegóły, ale oto mniej więcej, jak działa ten exploit. W poniższym przypadku załóżmy, że osoba atakująca chce uzyskać login użytkownika do Gmaila.
- Użytkownik pobiera złośliwą aplikację (oczywiście nie wiedząc, że jest złośliwa) i otwiera ją.
- W tle aplikacja otwiera Gmaila, umieszcza na nim podobną aktywność logowania, a następnie uruchamia inną aktywność.
- Użytkownik otwiera Gmaila i widzi coś, co wygląda na ekran logowania Gmaila, ale w rzeczywistości jest to aktywność phishingowa atakującego.
Ostatnim działaniem rozpoczętym w kroku 2 może być wszystko, co pozwoli uniknąć podejrzeń. Aplikacja może sfingować awarię i wrócić do ekranu głównego lub po prostu otworzyć się do swojej głównej aktywności, jak gdyby nic się nie stało. Jedyną podejrzaną rzeczą, jaką może zobaczyć użytkownik, są animacje otwierające po uruchomieniu wszystkich działań. Najgorsza część: nawet nie będzie wyglądać, jakby Gmail był otwarty.
Oczywiście osoba atakująca może zrobić więcej niż tylko pokazać fałszywy ekran logowania. Zamiast tego złośliwa aplikacja może wyświetlić monit o przyznanie uprawnień, oszukując użytkownika do przyznania niechcianych uprawnień. Chociaż żądanie specjalnych uprawnień, takich jak Dostępność, może wzbudzić podejrzenia użytkownika, możliwe jest wyrządzenie wielu szkód za pomocą czegoś takiego jak Dostęp do pamięci masowej.
Bity techniczne
Następna sekcja to ogólny przegląd działania StrandHogg 2.0. Promon nie opublikuje pełnych szczegółów przez kilka kolejnych miesięcy, więc nie możemy zdradzić, w jaki sposób dokładnie zaimplementowano ten exploit. Jest jednak kilka szczegółów technicznych, o których możemy porozmawiać.
Krótko mówiąc, StrandHogg 2.0 przejmuje kontrolę nad Androidem Context.startActivities() Metoda API, wykorzystująca trzy intencje.
- Pierwsza Intencja to ta, która w naszym przykładzie uruchamia Gmaila. Jest oznaczony jako
Intent.FLAG_ACTIVITY_NEW_TASK. - Drugi zamiar jest złośliwy. W naszym przykładzie dotyczy to podobnego działania związanego z logowaniem. Ten zamiar nie ma żadnych flag.
- Trzecią intencją jest odwrócenie uwagi. Dzięki temu użytkownik nie jest podejrzliwy wobec Gmaila, który po prostu przypadkowo otwiera się zamiast aplikacji, którą kliknął (tj. tej, która przeprowadziła atak). Jest oznaczony jako
Intent.FLAG_ACTIVITY_NEW_TASK.
Wszystkie te intencje są następnie przekazywane w tablicy do metody startActivities() metoda.
Kluczem jest tu brak flag w drugim Intencji. W ten sposób po prostu odtworzyliśmy powyższy przykład Gmaila. Technicznie rzecz biorąc, zadanie należy do Gmaila, ale najwyższa aktywność należy do osoby atakującej. Gdy użytkownik następnie kliknie ikonę Gmaila na ekranie głównym, zamiast Gmaila wyświetli się Aktywność osoby atakującej.
Dowód koncepcji
Dzięki informacjom, które przesłał nam Promon, byliśmy w stanie odtworzyć ich dowód słuszności koncepcji. Oto nagranie ekranu z Samsunga Galaxy Note8 z systemem Android 9 Pie, pokazujące go w akcji.
Techniki i problemy łagodzenia
Teraz zwykłe replikowanie powyższego kodu w rzeczywistości nie będzie działać. Nie jest to kompletny przykład. Jest jeszcze kilka innych rzeczy, które atakujący musi zrobić, aby zadziałało, a którymi nie możemy się podzielić. Ale nie są one szczególnie trudne do odgadnięcia na własną rękę i to właśnie sprawia, że ten atak jest tak niebezpieczny. StrandHogg 2.0 to exploit stosunkowo łatwy do wdrożenia i trudny do ograniczenia.
Ograniczanie nie może polegać po prostu na umieszczeniu na czarnej liście wszystkich używanych aplikacji startActivities(), ponieważ istnieje wiele legalnych zastosowań. Bardzo trudno jest również zautomatyzować algorytm wykrywania. Złośliwi programiści mogą stosować najróżniejsze sztuczki, aby ich implementacja StrandHogg 2.0 była skutecznie niewidoczna dla usług takich jak Google Play Protect. StrandHogg 1.0 wymagał od osoby atakującej dodania atrybutu do pliku AndroidManifest.xml złośliwej aplikacji, który był stosunkowo łatwy do wykrycia. Natomiast StrandHogg 2.0 działa całkowicie w Javie/Kotlinie.
Biorąc pod uwagę zaciemnianie, odbicie, a nawet różne style kodowania, automatyczne prawidłowe wykrywanie aplikacji korzystającej z tego exploita wydaje się niepraktyczne. Co więcej, jeśli użytkownik stanie się celem ataku StrandHogg 2.0, może nawet o tym nie wiedzieć. Jeśli otworzysz Gmaila i zobaczysz jego ekran logowania, możesz po prostu pomyśleć, że Twoja sesja wygasła i bez namysłu wprowadzić dane logowania.
Kiedy skontaktowaliśmy się z Google w celu uzyskania odpowiedzi, rzecznik przedstawił następujące oświadczenie:
„Doceniamy pracę badaczy i opublikowaliśmy poprawkę zidentyfikowanego przez nich problemu. Ponadto Google Play Protect wykrywa i blokuje złośliwe aplikacje, w tym te korzystające z tej techniki.
Brzmi to dobrze i miejmy nadzieję, że będzie miało przynajmniej pewien wpływ na ataki StrandHogg 2.0. Warto jednak zauważyć, że Google Play Protect nie wykryć naszą aplikację weryfikacyjną jako złośliwą, nawet po przeprowadzeniu ręcznego skanowania.
Promon twierdzi, że „nie zaobserwowali żadnego prawdziwego złośliwego oprogramowania wykorzystującego lukę StrandHogg 2.0”, ale nie ma gwarancji, że exploit został wykryty po raz pierwszy. Z tego powodu Promon zaleca programistom kontynuowanie ochrony swoich aplikacji poprzez ustawienie aktywności programu uruchamiającego launchMode flaga do któregokolwiek singleTask Lub singleInstance. Każda z tych flag zapobiegnie wstrzykiwaniu zadań, na czym opiera się StrandHogg 2.0. Jednak użycie jednej z tych flag w działaniu może powodować problemy z przepływami niektórych aplikacji, dlatego nie zawsze jest to pożądane.
Promon promuje także własny produkt „In-App Protection by Promon SHIELD”, który brzmi jak biblioteka które twórcy aplikacji mogą wdrożyć, aby monitorować zadania w procesie aplikacji i sprawdzać, czy nie są one nieprawidłowe wstawki. Ponieważ nie ma naprawdę skutecznej strategii łagodzenia skutków dla programistów lub użytkowników, bardzo ważne jest, aby producenci jak najszybciej zaimplementowali poprawkę, która naprawi ten problem.
Na szczęście firma Promon postępowała zgodnie z wytycznymi dotyczącymi odpowiedzialnego ujawniania informacji, zanim upubliczniła ten exploit (i nie jest to jeszcze w pełni upublicznione — Promon czeka 90 dni, zanim w pełni ujawni, jak StrandHogg 2.0 Pracuje). Od tego czasu Google przeniósł poprawki dla tego exploita do systemów Android 8.0 Oreo, Android 8.1 Oreo i Android 9 Pie z Poziom poprawek zabezpieczeń Androida (SPL) z maja 2020 r.. Użytkownicy Androida 10 i nowszych nie są narażeni, chociaż nie jesteśmy do końca pewni, dlaczego tak się dzieje. Prawdopodobnie ma to coś wspólnego z nowymi ograniczeniami Androida 10 dotyczącymi uruchamiania Działań i sposobem, w jaki Google zintegrował je ze stosem zadań. Promon twierdzi, że „na Androidzie 10 atak jest całkowicie nieskuteczny, a działania są podzielone na różne zadania i na osobne stosy zadań zgodnie z adb shell dumpsys activity activities."
Jeśli producent Twojego urządzenia nadal dostarcza aktualizacje zabezpieczeń (możesz przeczytać więcej na temat jak tutaj działa proces łatania zabezpieczeń), powinieneś ich nakłonić do jak najszybszej aktualizacji. W przeciwnym razie będziesz musiał po prostu uważać na aplikacje, które pobierasz i uruchamiasz (chociaż i tak powinieneś to robić).
Aby uzyskać więcej szczegółów i przypadków użycia StrandHogg 2.0, sprawdź oficjalny komunikat na stronie Promon. Dla programistów niestandardowych ROM-ów możesz znaleźć odpowiednie zatwierdzenia AOSP, aby zapobiec atakom StrandHogg 2.0 Tutaj I Tutaj.
Harmonogram ujawnień
Oto harmonogram ujawnień udostępniony przez firmę Promon w dokumencie StandHogg 2.0:
- 4 grudnia 2019 r – Zgłoszono problem do Google
- 4 grudnia 2019 r – Udostępniono Google „złośliwą aplikację” i wideo PoC
- 4 grudnia 2019 r – Google potwierdził otrzymanie raportu
- 9 grudnia 2019 r – Google określiło wagę ustalenia jako „Krytyczną”
- 9 grudnia 2019 r – Google potwierdza, że jest w stanie odtworzyć problem
- 14 lutego 2020 r – Na początku marca informujemy Google, że zbliża się 90-dniowy okres ujawnienia informacji i pytamy o status tej sprawy
- 14 lutego 2020 r – Google odpowiada, że kwiecień to najwcześniejszy termin, w którym mogą wdrożyć poprawkę
- 14 lutego 2020 r – Informujemy Google, że pracujemy nad ograniczeniami
- 14 lutego 2020 r – odpowiada Google. Pracują nad środkami zaradczymi i pytają, czy możemy podzielić się informacjami, jakie środki łagodzące zalecamy
- 17 lutego 2020 r – Informujemy Google, że możemy wstrzymać się z ujawnieniem informacji do kwietnia. Prosimy o numer CVE
- 17 lutego 2020 r – Dzielimy się naszymi strategiami łagodzenia skutków, a także tym, jak przewidujemy łagodzenie platformy
- 23 marca 2020 r – Google odpowiada, podając identyfikator CVE (CVE-2020-0096)
- 23 marca 2020 r – Google odpowiada, że ogólna dostępność poprawki dla Androida będzie dostępna w maju
- 23 marca 2020 r – Google pyta, czy rozważymy przesunięcie ujawnienia do maja
- 27 marca 2020 r – Odpowiadamy, że ujawnienie informacji przesuniemy do maja
- 22 kwietnia 2020 r – Google informuje nas, że majowy Biuletyn Bezpieczeństwa ma zawierać łatę usuwającą lukę