StrandHogg 2.0 este o nouă vulnerabilitate periculoasă pentru Android. Iată cum poate afecta utilizatorii și cum dezvoltatorii își pot proteja aplicațiile împotriva acesteia.
Este ora 22:00. Știi unde sunt activitățile tale? Există o nouă vulnerabilitate care poate fi exploatată pe milioane de dispozitive Android și este, de asemenea, una destul de urâtă. Pe scurt, acest defect de design îi permite unui atacator să-și prezinte propria activitate (pagină) peste cea a altei aplicații, potențial derutând utilizatorul să-și dea datele private. Vulnerabilitatea a fost numită StrandHogg 2.0 și a fost dezvăluită recent de Promon, o firmă de securitate norvegiană.
Vulnerabilitatea StrandHogg 2.0 afectează teoretic toate dispozitivele Android care rulează versiuni Android la fel de vechi ca Honeycomb (3.0) și până la Android 9 Pie (9.0). Bazat pe statistici de distribuție a ultimei versiuni Android, asta inseamna ca aproximativ 91,8% din toate dispozitivele Android sunt vulnerabile la StrandHogg 2.0
. Vulnerabilitatea a fost atribuită CVE-2020-0096 și i s-a dat a nivelul de severitate al „critic”. Nu necesită permisiuni speciale pentru a funcționa și poate funcționa aproape în întregime fără interacțiunea utilizatorului. Tot ce trebuie să facă un utilizator este să deschidă o aplicație cu cod rău intenționat ascuns în ea și apoi este vulnerabil la exploatare.Promon a fost destul de amabil să ne trimită aplicația lor de dovadă a conceptului și codul sursă, astfel încât să putem cel mai bine explicați cum funcționează exploit-ul, de ce este important pentru utilizatori și cum își pot proteja aplicațiile dezvoltatorii impotriva.
Cum functioneaza
Să presupunem că utilizați Gmail și că faceți clic pe un link web. Dacă accesați ecranul de aplicații recente, este posibil să observați că pagina web pare să fie „în interiorul” Gmail. Previzualizarea arată site-ul web, dar pictograma aplicației și numele sunt încă din Gmail. Acesta este ceva care se întâmplă atunci când o aplicație/Activitate lansează o altă aplicație/Activitate în aceeași sarcină. Acum imaginați-vă că nu ați deschis intenționat acel link. Pentru tine, se pare că face parte doar din aplicația Gmail. Acesta este comportamentul pe care StrandHogg 2.0 îl exploatează.
Va trebui să omitem câteva detalii aici, dar iată cum funcționează acest exploit. Pentru următoarele, să presupunem că atacatorul dorește să obțină datele de conectare Gmail ale utilizatorului.
- Utilizatorul descarcă o aplicație rău intenționată (desigur, fără să știe că este rău intenționată) și o deschide.
- În fundal, aplicația deschide Gmail, pune deasupra acesteia o activitate de conectare asemănătoare și apoi lansează o altă activitate.
- Utilizatorul deschide Gmail și vede ceea ce arată ca ecranul de conectare al Gmail, dar este de fapt activitatea de phishing a atacatorului.
Activitatea finală lansată în pasul 2 poate fi orice care evită suspiciunea. Aplicația ar putea simula un accident și poate reveni la ecranul de pornire sau s-ar putea deschide doar la Activitatea sa principală ca și cum nimic nu s-ar întâmpla. Singurul lucru suspect pe care îl poate vedea utilizatorul este o grămadă de animații de deschidere pe măsură ce se lansează toate activitățile. Partea cea mai rea: nici măcar nu va părea că Gmail a fost deschis.
Desigur, un atacator poate face mai mult decât să arate un ecran de conectare fals. O aplicație rău intenționată ar putea prezenta o solicitare de permisiuni, înșelând utilizatorul să acorde permisiuni nedorite. Deși solicitarea oricăror permisiuni speciale, cum ar fi Accesibilitatea, ar putea face utilizatorul să fie suspicios, este posibil să faci multe daune cu ceva precum Accesul la stocare.
Bitele tehnice
Această secțiune următoare este o prezentare generală la nivel înalt a modului în care funcționează StrandHogg 2.0. Promon nu va lansa detaliile complete timp de câteva luni, așa că nu putem spune exact cum este implementat acest exploit. Există totuși câteva detalii tehnice despre care putem vorbi.
Pe scurt, StrandHogg 2.0 deturnează Android-urile Context.startActivities() Metoda API, folosind trei intentii.
- Prima Intenție este cea care lansează, în cazul exemplului nostru, Gmail. Este marcat cu
Intent.FLAG_ACTIVITY_NEW_TASK. - A doua Intenție este cea rău intenționată. În exemplul nostru, este pentru activitatea de conectare asemănătoare. Această intenție nu are steaguri.
- A treia intenție este distragerea atenției. Se asigură că utilizatorul nu este suspicios că Gmail se deschide aleatoriu în loc de aplicația pe care a accesat-o (adică cea care lansează atacul). Este marcat cu
Intent.FLAG_ACTIVITY_NEW_TASK.
Toate aceste intenții sunt apoi transmise într-o matrice către startActivities() metodă.
Lipsa steagurilor a doua Intent este cheia aici. Făcând acest lucru, practic tocmai am replicat exemplul Gmail de mai sus. Sarcina este din punct de vedere tehnic a Gmail, dar cea mai mare activitate este a atacatorului. Atunci când utilizatorul face clic pe pictograma de pe ecranul de pornire al Gmail, se afișează Activitatea atacatorului în loc de cea a lui Gmail.
Dovada de concept
Cu informațiile pe care ni le-a trimis Promon, am putut să le reproducem dovada conceptului. Iată o înregistrare a ecranului de la un Samsung Galaxy Note8 care rulează Android 9 Pie care îl arată în acțiune.
Tehnici și probleme de atenuare
Acum, simpla replicare a celor de mai sus în cod nu va funcționa de fapt. Nu este un exemplu complet și există alte câteva lucruri pe care un atacator trebuie să le facă pentru ca acesta să funcționeze, pe care nu le putem împărtăși. Dar nu sunt deosebit de greu de ghicit pe cont propriu și asta face parte din ceea ce face acest atac atât de periculos. StrandHogg 2.0 este o exploatare relativ ușor de implementat și greu de atenuat.
Atenuarea nu poate implica doar introducerea pe lista neagră a tuturor aplicațiilor care folosesc startActivities(), deoarece există o mulțime de utilizări legitime pentru acesta. De asemenea, este foarte dificil să automatizezi un algoritm de detectare pentru acesta. Dezvoltatorii rău intenționați pot folosi tot felul de trucuri pentru a face implementarea StrandHogg 2.0 efectiv invizibilă pentru servicii precum Google Play Protect. StrandHogg 1.0 a cerut atacatorului să adauge un atribut în AndroidManifest.xml al aplicației rău intenționate, care a fost relativ ușor de detectat. StrandHogg 2.0, pe de altă parte, funcționează în întregime în Java/Kotlin.
Ținând cont de ofuscarea, reflectarea și chiar și doar diferitele stiluri de codare, pare imposibil să detectăm automat în mod corespunzător o aplicație care folosește acest exploit. Mai mult, dacă un utilizator este subiectul unui atac StrandHogg 2.0, s-ar putea să nu știe. Dacă deschideți Gmail și vedeți ecranul său de conectare, s-ar putea să credeți că sesiunea dvs. a expirat și să introduceți detaliile de conectare fără să vă gândiți.
Când am contactat Google pentru un răspuns, un purtător de cuvânt a oferit următoarea declarație:
„Apreciem munca cercetătorilor și am lansat o remediere a problemei identificate de ei. În plus, Google Play Protect detectează și blochează aplicațiile rău intenționate, inclusiv pe cele care folosesc această tehnică.”
Acest lucru sună bine și sperăm că are cel puțin un efect împotriva atacurilor StrandHogg 2.0. Totuși, merită remarcat faptul că Google Play Protect nu a detectați aplicația noastră de dovadă a conceptului ca fiind rău intenționată, chiar și după efectuarea unei scanări manuale.
Promon spune că ei "nu am observat niciun program malware din viața reală care să utilizeze vulnerabilitatea StrandHogg 2.0," dar nu există nicio garanție că aceasta este prima dată când exploit-ul este descoperit. Din acest motiv, Promon recomandă dezvoltatorilor să continue și să-și protejeze aplicațiile prin setarea activității lansatorului. launchMode pavilion la oricare singleTask sau singleInstance. Oricare dintre aceste steaguri va preveni injectarea sarcinilor, pe care se bazează StrandHogg 2.0. Cu toate acestea, faptul că Activitatea dvs. utilizează unul dintre aceste semnalizatoare poate cauza probleme cu anumite fluxuri de aplicații, deci nu este întotdeauna de dorit.
Promon își promovează, de asemenea, propriul produs „Protecție în aplicație de către Promon SHIELD”, care sună ca o bibliotecă pe care dezvoltatorii de aplicații le pot implementa pentru a monitoriza sarcinile din procesul aplicației dvs. pentru a verifica dacă există neregularități inserții. Deoarece nu există o strategie cu adevărat eficientă pentru dezvoltatori sau utilizatori, este destul de important ca producătorii să implementeze patch-ul pentru a remedia acest lucru cât mai curând posibil.
Din fericire, Promon a urmat regulile de dezvăluire responsabilă înainte de a face public această exploatare (și încă nu este pe deplin public—Promon așteaptă 90 de zile înainte de a dezvălui pe deplin modul în care StrandHogg 2.0 lucrări). De atunci, Google a retroportat corecții pentru acest exploit pe Android 8.0 Oreo, Android 8.1 Oreo și Android 9 Pie cu Mai 2020 Nivelul corecției de securitate Android (SPL). Utilizatorii de pe Android 10 și versiuni ulterioare nu sunt vulnerabili, deși nu suntem în întregime siguri de ce este cazul. Probabil că are ceva de-a face cu noile restricții ale Android 10 privind lansarea activităților și modul în care Google a integrat asta în stiva de sarcini. Promon spune că „pe Android 10 atacul este complet ineficient, iar activitățile sunt împărțite în sarcini diferite și în stive de sarcini separate, conform adb shell dumpsys activity activities."
Dacă producătorul dispozitivului dvs. încă oferă actualizări de securitate (puteți citi mai multe despre cum funcționează aici procesul de corecție de securitate), ar trebui să-i deranjați pentru o actualizare cât mai curând posibil. În caz contrar, va trebui doar să fiți atenți la ce aplicații descărcați și rulați (deși ar trebui să faceți asta oricum).
Pentru mai multe detalii și cazuri de utilizare ale StrandHogg 2.0, consultați anunț oficial pe site-ul Promon. Pentru dezvoltatorii de ROM personalizate, puteți găsi comiterile AOSP relevante pentru prevenirea atacurilor StrandHogg 2.0 Aici și Aici.
Cronologia dezvăluirii
Iată cronologia dezvăluirii pe care Promon a împărtășit-o în documentul său StandHogg 2.0:
- 4 decembrie 2019 – Problemă raportată la Google
- 4 decembrie 2019 – A partajat o „aplicație rău intenționată” PoC și un videoclip cu Google
- 4 decembrie 2019 – Google a confirmat primirea raportului
- 9 decembrie 2019 – Google a stabilit severitatea constatării ca „Critic”
- 9 decembrie 2019 – Google confirmă că poate reproduce problema
- 14 februarie 2020 – informăm Google că dezvăluirea de 90 de zile se apropie la începutul lunii martie și solicităm statutul din partea lor
- 14 februarie 2020 – Google răspunde că aprilie este cel mai curând în care pot lansa o remediere
- 14 februarie 2020 – informăm Google că lucrăm la atenuări
- 14 februarie 2020 – Google răspunde. Ei lucrează la remedieri și ne întreabă dacă putem spune ce măsuri de atenuare recomandăm
- 17 februarie 2020 – informăm Google că putem reține dezvăluirea până în aprilie. Solicităm numărul CVE
- 17 februarie 2020 – Împărtășim strategiile noastre de atenuare, precum și modul în care avem în vedere o atenuare a platformei
- 23 martie 2020 – Google răspunde cu ID-ul CVE (CVE-2020-0096)
- 23 martie 2020 – Google răspunde că disponibilitatea generală a remedierii pentru Android va fi disponibilă în mai
- 23 martie 2020 – Google întreabă dacă vom lua în considerare amânarea dezvăluirii până în mai
- 27 martie 2020 – Răspundem că vom amâna dezvăluirea până în mai
- 22 aprilie 2020 – Google ne informează că Buletinul de securitate din mai este programat să conțină un patch pentru vulnerabilitate