StrandHogg 2.0 je nova nevarna ranljivost Androida. Evo, kako lahko vpliva na uporabnike in kako lahko razvijalci pred tem zaščitijo svoje aplikacije.
Ura je 22:00. Ali veste, kje so vaše dejavnosti? Obstaja nova ranljivost, ki jo je mogoče izkoristiti na milijonih naprav Android, poleg tega pa je precej neprijetna. Na kratko, ta načrtna napaka omogoča napadalcu, da predstavi svojo lastno dejavnost (stran) na vrhu druge aplikacije, kar lahko uporabnika zmede, da izda svoje zasebne podatke. Ranljivost je bila poimenovana StrandHogg 2.0 in jo je nedavno razkril Promon, norveško varnostno podjetje.
Ranljivost StrandHogg 2.0 teoretično vpliva na vse naprave Android, ki uporabljajo različice Androida, stare od Honeycomb (3.0) do Android 9 Pie (9.0). Temelji na statistika distribucije najnovejše različice Androida, to pomeni, da približno 91,8 % vseh naprav Android je ranljivih za StrandHogg 2.0. Ranljivost je bila dodeljena CVE-2020-0096 in dobil je a stopnja resnosti "kritična". Za delo ne potrebuje nobenih posebnih dovoljenj in lahko skoraj v celoti deluje brez interakcije uporabnika. Vse, kar mora uporabnik storiti, je, da odpre aplikacijo, v kateri je skrita zlonamerna koda, in potem je ranljiv za izkoriščanje.
Promon je bil tako prijazen, da nam je poslal svojo aplikacijo za dokaz koncepta in njeno izvorno kodo, da smo lahko najbolje pojasnite, kako izkoriščanje deluje, zakaj je pomembno za uporabnike in kako lahko razvijalci zaščitijo svoje aplikacije proti temu.
Kako deluje
Recimo, da uporabljate Gmail in kliknete spletno povezavo. Če odprete zaslon nedavnih aplikacij, boste morda opazili, da je spletna stran »znotraj« Gmaila. Predogled prikazuje spletno mesto, vendar sta ikona in ime aplikacije še vedno iz Gmaila. To se zgodi, ko aplikacija/dejavnost zažene drugo aplikacijo/dejavnost v isti nalogi. Zdaj pa si predstavljajte, da te povezave niste namenoma odprli. Za vas se zdi, da je le del aplikacije Gmail. To je vedenje, ki ga izkorišča StrandHogg 2.0.
Tukaj bomo morali izpustiti nekaj podrobnosti, toda tukaj je približno, kako to izkoriščanje deluje. Za naslednje predpostavimo, da želi napadalec pridobiti uporabniško prijavo v Gmail.
- Uporabnik naloži zlonamerno aplikacijo (seveda ne da bi vedel, da je zlonamerna) in jo odpre.
- V ozadju aplikacija odpre Gmail, na vrh postavi podobno prijavno dejavnost in nato zažene drugo dejavnost.
- Uporabnik odpre Gmail in vidi nekaj, kar je videti kot Gmailov prijavni zaslon, vendar je v resnici napadalčeva dejavnost lažnega predstavljanja.
Končna aktivnost, zagnana v 2. koraku, je lahko karkoli, kar se izogne sumu. Aplikacija bi lahko ponaredila zrušitev in se vrnila na začetni zaslon ali pa bi se preprosto odprla v svojo glavno dejavnost, kot da se ni nič zgodilo. Edina sumljiva stvar, ki jo lahko uporabnik vidi, je kup začetnih animacij, ko se zaženejo vse dejavnosti. Najslabši del: sploh ne bo videti, kot da je bil Gmail odprt.
Seveda lahko napadalec stori več kot le prikaže lažni prijavni zaslon. Zlonamerna aplikacija bi lahko namesto tega prikazala poziv za dovoljenja in uporabnika zavedla, da bi podelil neželena dovoljenja. Medtem ko lahko zaradi zahtev po kakršnih koli posebnih dovoljenjih, kot je Dostopnost, uporabnik postane sumljiv, je mogoče narediti veliko škode z nečim, kot je dostop do shrambe.
Tehnični delci
Ta naslednji razdelek je pregled na visoki ravni delovanja StrandHogg 2.0. Promon ne bo izdal vseh podrobnosti še nekaj mesecev, zato ne moremo natančno deliti, kako je ta izkoriščanje implementirano. Obstaja nekaj tehničnih podrobnosti, o katerih se lahko pogovarjamo.
Na kratko, StrandHogg 2.0 ugrabi Android Context.startActivities() Metoda API z uporabo treh namenov.
- Prvi namen je tisti, ki zažene, v našem primeru, Gmail. Označeno je z
Intent.FLAG_ACTIVITY_NEW_TASK. - Drugi namen je zlonamerni. V našem primeru je to za prijavo podoben dejavnosti. Ta namen nima zastavic.
- Tretji namen je odvračanje pozornosti. Zagotavlja, da uporabnik ni sumljiv glede Gmaila, ki se samo naključno odpre namesto aplikacije, ki se je dotakne (tj. tiste, ki je sprožila napad). Označeno je z
Intent.FLAG_ACTIVITY_NEW_TASK.
Vsi ti nameni so nato v matriki posredovani v startActivities() metoda.
Tu je ključno pomanjkanje zastavic druge namere. S tem smo v bistvu pravkar ponovili primer Gmaila od zgoraj. Naloga je tehnično Gmailova, vendar je najvišja dejavnost napadalčeva. Ko uporabnik nato klikne ikono začetnega zaslona Gmaila, se namesto Gmailove dejavnosti prikaže napadalčeva dejavnost.
Dokaz koncepta
Z informacijami, ki nam jih je poslal Promon, smo lahko ponovili njihov dokaz koncepta. Tukaj je posnetek zaslona Samsung Galaxy Note8 z operacijskim sistemom Android 9 Pie, ki ga prikazuje v akciji.
Tehnike in težave za ublažitev
Enostavno kopiranje zgornjega v kodo dejansko ne bo delovalo. To ni popoln primer in obstaja še nekaj drugih stvari, ki jih mora storiti napadalec, da deluje, česar pa ne moremo deliti. Vendar jih ni posebej težko uganiti sam, in to je del tega, zaradi česar je ta napad tako nevaren. StrandHogg 2.0 je razmeroma enostaven izkoriščanje za implementacijo in težko ublažiti.
Ublažitev ne more vključevati samo črne liste vseh aplikacij, ki uporabljajo startActivities(), saj obstaja veliko zakonitih uporab zanj. Prav tako je zelo težko avtomatizirati algoritem zaznavanja zanj. Zlonamerni razvijalci lahko uporabijo najrazličnejše trike, da naredijo svojo implementacijo StrandHogg 2.0 učinkovito nevidno za storitve, kot je Google Play Protect. StrandHogg 1.0 je od napadalca zahteval, da doda atribut v AndroidManifest.xml zlonamerne aplikacije, kar je bilo razmeroma enostavno odkriti. StrandHogg 2.0 po drugi strani v celoti deluje v Javi/Kotlin.
Ob upoštevanju zakrivanja, refleksije in celo samo različnih stilov kodiranja se zdi nepraktično samodejno pravilno zaznati aplikacijo, ki uporablja to izkoriščanje. Še več, če je uporabnik predmet napada StrandHogg 2.0, morda sploh ne ve. Če odprete Gmail in vidite njegov prijavni zaslon, boste morda samo pomislili, da je vaša seja potekla, in brez premisleka vnesite podatke za prijavo.
Ko smo kontaktirali Google za odgovor, je tiskovni predstavnik ponudil to izjavo:
»Cenimo delo raziskovalcev in izdali smo popravek za težavo, ki so jo odkrili. Poleg tega Google Play Protect zazna in blokira zlonamerne aplikacije, vključno s tistimi, ki uporabljajo to tehniko."
To se sliši dobro in upajmo, da ima vsaj nekaj učinka proti napadom StrandHogg 2.0. Vendar je vredno omeniti, da Google Play Protect ni zazna našo aplikacijo za dokaz koncepta kot zlonamerno, tudi po izvedbi ročnega pregleda.
Promon pravi, da so "niso opazili nobene resnične zlonamerne programske opreme, ki bi uporabljala ranljivost StrandHogg 2.0," vendar ni nobenega zagotovila, da je bilo tokrat prvič odkrito izkoriščanje. Iz tega razloga Promon priporoča, da razvijalci nadaljujejo in zaščitijo svoje aplikacije tako, da nastavijo dejavnost zaganjalnika launchMode zastavo bodisi singleTask oz singleInstance. Katera koli od teh zastav bo preprečila vstavljanje opravila, na kar se zanaša StrandHogg 2.0. Če pa vaša dejavnost uporablja eno od teh zastavic, lahko povzroči težave z določenimi tokovi aplikacij, zato ni vedno zaželeno.
Promon prav tako promovira svoj izdelek "In-App Protection by Promon SHIELD", ki zveni kot knjižnica ki jih razvijalci aplikacij lahko implementirajo za spremljanje opravil v procesu vaše aplikacije, da preverijo nepravilnosti vstavitve. Ker ni resnično učinkovite strategije za ublažitev za razvijalce ali uporabnike, je zelo pomembno, da proizvajalci implementirajo popravek za čimprejšnjo odpravo te težave.
K sreči je Promon upošteval smernice odgovornega razkritja, preden je to izkoriščanje objavil (in še vedno ni v celoti javno – Promon čaka 90 dni, preden v celoti razkrije, kako StrandHogg 2.0 dela). Google je od takrat prenesel popravke za to izkoriščanje v Android 8.0 Oreo, Android 8.1 Oreo in Android 9 Pie z Maj 2020 Raven varnostnega popravka za Android (SPL). Uporabniki v sistemu Android 10 in novejšem niso ranljivi, čeprav nismo povsem prepričani, zakaj je tako. Verjetno ima nekaj opraviti z novimi omejitvami Androida 10 glede zagona dejavnosti in kako je Google to integriral v sklad opravil. Promon pravi, da je "v sistemu Android 10 napad popolnoma neučinkovit, dejavnosti pa so razdeljene na različne naloge in v ločene nize nalog glede na adb shell dumpsys activity activities."
Če proizvajalec vaše naprave še vedno zagotavlja varnostne posodobitve (lahko preberete več o kako tukaj deluje postopek varnostnega popravka), čimprej jih prosite za posodobitev. V nasprotnem primeru boste morali le paziti, katere aplikacije prenašate in izvajate (čeprav bi to vseeno morali početi).
Za več podrobnosti in primere uporabe StrandHogg 2.0 si oglejte uradna objava na Promonovi spletni strani. Za razvijalce ROM-a po meri lahko najdete ustrezne zaveze AOSP za preprečevanje napadov StrandHogg 2.0 tukaj in tukaj.
Časovnica razkritja
Tukaj je časovnica razkritja, ki jo je Promon delil v svojem dokumentu StandHogg 2.0:
- 4. december 2019 – Težavo smo prijavili Googlu
- 4. december 2019 – Z Googlom je delil »zlonamerno aplikacijo« in video PoC
- 4. december 2019 – Google je potrdil prejem poročila
- 9. december 2019 – Google je nastavil resnost ugotovitve kot »Kritično«
- 9. december 2019 – Google potrjuje, da je sposoben reproducirati težavo
- 14. februar 2020 – Google obveščamo, da se v začetku marca bliža 90-dnevno razkritje, in prosimo za status na njihovi strani
- 14. februar 2020 – Google odgovarja, da je april najhitreje, ko lahko uvedejo popravek
- 14. februar 2020 – Google obveščamo, da delamo na ublažitvah
- 14. februar 2020 – odgovarja Google. Delajo na sanacijah in prosijo, ali lahko delimo, katere ublažitve priporočamo
- 17. februar 2020 – Google obveščamo, da lahko razkritje zadržimo do aprila. Zahtevamo številko CVE
- 17. februar 2020 – Delimo svoje strategije za ublažitev, pa tudi, kako si predstavljamo ublažitev platforme
- 23. marec 2020 – Google odgovori z ID-jem CVE (CVE-2020-0096)
- 23. marec 2020 – Google odgovarja, da bo splošna razpoložljivost popravka za Android na voljo maja
- 23. marec 2020 – Google sprašuje, ali bomo razmislili o odložitvi razkritja na May
- 27. marec 2020 – Odgovarjamo, da bomo razkritje odložili do maja
- 22. april 2020 – Google nas obvešča, da naj bi majski varnostni bilten vseboval popravek za ranljivost