Luka StrandHogg w Androidzie
#1
Cytat:Luka w Androidzie pozwala atakującym tworzyć fałszywe ekrany, które podmieniają ekran logowania aplikacji. Użytkownik jest więc przekonany, że korzysta z zaufanego programu, tymczasem wszystkie jego dane mogą zostać przechwycone.
https://www.chip.pl/2019/12/strandhogg-p...e-android/

Cytat:The vulnerability allows malicious apps to masquerade as legitimate apps that targets have already installed and come to trust, researchers from security firm Promon reported in a post. Running under the guise of trusted apps already installed, the malicious apps can then request permissions to carry out sensitive tasks, such as recording audio or video, taking photos, reading text messages or phishing login credentials. Targets who click yes to the request are then compromised.
https://arstechnica.com/information-tech...k-thieves/
Odpowiedz
#2
Z powyższego artykułu nie do końca rozumiem na czym owa "luka" miałaby polegać. Jak rozumiem klient ma aplikację bankową, instaluje np: grę ze sklepu GP, która okazuje się być trojanem. Program wykrywa, że klient ma aplikację bankową i jak rozumiem podmienia skrót z pulpitu do siebie samego, tak, że gdy klient będzie chciał odpalić apkę bankową to otworzy się trojan i wyświetli podmienioną stronę bankową, co ewentualnie pozwoli na ukradzenie danych logowania czy pieniędzy. Jeżeli to tak działa, to ciężko to nazwać luką - raczej błędem/nieporozumieniem leżącym u samych fundamentów androida jako systemu operacyjnego. Wiele aplikacji korzysta z możliwości sprawdzenia jakie klient ma zainstalowane aplikacje, często dla czysto komercyjnych - wyświetlanie spersonalizowanych reklam. A bombardowanie klienta reklamami na każdym kroku jest jednym z celów jakie obrało Google. Twórcy aplikacji dostają kompletne API do tego aby bombardować użytkowników reklamami i filmikami promocyjnymi a klientowi końcowemu udaremnia się na każdy możliwy sposób ingerencję w ten mechanizm. Zresztą cały android jest tak skonstruowany - klient ma korzystać z zasobów systemu tak jak tego chce Google i twórcy apek. A to że ktoś zmyślny zauważył w tym potencjał dla siebie? Ot, życie.
Odpowiedz
#3
W chip.pl opis jest dosyć słaby, ale to polskie forum, więc chciałem dać coś po polsku. Nie wiem czy to bardziej luka w implementacji czy zła decyzja została podjęta na poziomie architektury, ale ewidentnie jest to coś do poprawienia przez Google.

(10.12.2019, 12:38)wredniak napisał(a): Program wykrywa, że klient ma aplikację bankową i jak rozumiem podmienia skrót z pulpitu do siebie samego, tak, że gdy klient będzie chciał odpalić apkę bankową to otworzy się trojan i wyświetli podmienioną stronę bankową, co ewentualnie pozwoli na ukradzenie danych logowania czy pieniędzy.
Nie podmienia skrótu do siebie samego. W systemie jest dodawany task, który pochodzi ze złośliwej aplikacji, ale jest uruchamiany w kontekście aplikacji, w którą celowany jest atak. Możesz kliknąć w launcherze na prawdziwą, autentyczną ikonkę zaufanej aplikacji, a i tak pojawi się ekran ze złośliwej aplikacji.

Na ArsTechnica wyjaśniają to tak (link podałem już wcześniej):

Cytat:An affinity for multitasking

The vulnerability is found in a function known as TaskAffinity, a multitasking feature that allows apps to assume the identity of other apps or tasks running in the multitasking environment. Malicious apps can exploit this functionality by setting the TaskAffinity for one or more of its activities to match a package name of a trusted third-party app. By either combining the spoofed activity with an additional allowTaskReparenting activity or launching the malicious activity with an Intent.FLAG_ACTIVITY_NEW_TASK, the malicious apps will be placed inside and on top of the targeted task.

a TrendMicro tak:

Cytat:Explaining the StrandHogg exploit
StrandHogg exists in how Android devices handle multiple tasks, specifically in the feature called task reparenting. This feature has to do with how an Android device’s activity can move from the task that started it to a task that it has an affinity for. For example, task reparenting is at work when a user clicks on a link on a messenger app that opens a browser still connected to the original app that started it.
A malicious app could exploit this feature by replacing one of the target tasks an app has an affinity for with its own task. It clears out the target task and replaces it with a new task that is under the cybercriminal’s control. Thus, the hijacked task would be displayed on the screen when the user launches the affected (legitimate) app.
This hijacked task could be anything, such as tasks that ask users for various permissions (eg. access to photos and files, contact list, etc.) that a user could unknowingly grant for the malicious app. Using this vulnerability, a cybercriminal could also lace a phishing scheme deep into the natural flow of a legitimate app.
https://www.trendmicro.com/vinfo/hk-en/s...imate-apps

Teraz znalazłem taki temat na Twitterze:
https://twitter.com/fs0c131y/status/1201761350231482368
https://threadreaderapp.com/thread/12017...82368.html

Ale jeszcze nie przeczytałem artykułu z konferencji.
Odpowiedz
#4
(10.12.2019, 13:37)bluszcz napisał(a): W chip.pl opis jest dosyć słaby, ale to polskie forum, więc chciałem dać coś po polsku. Nie wiem czy to bardziej luka w implementacji czy zła decyzja została podjęta na poziomie architektury, ale ewidentnie jest to coś do poprawienia przez Google.
Dzięki, teraz zrozumiałem. Podejrzewam jednak, że ta funkcjonalność była przemyślana pod kątem innych zastosowań. Niestety licho nie śpi i wcześniej czy później takie rewelacje wychodzą na światło dzienne. Generalnie jako klient urządzenia z androidem czuję się tak jakbym wypożyczał to urządzenie, a nie był jego właścicielem.
Myślę, że łatka na opisywany problem może uderzyć rykoszetem w istniejące już rozwiązania, o których szary użytkownik nawet nie zdaje sobie sprawy.
Odpowiedz




Użytkownicy przeglądający ten wątek: 1 gości