StrandHogg 2.0 on vaarallinen uusi Android-haavoittuvuus. Näin se voi vaikuttaa käyttäjiin ja kuinka kehittäjät voivat suojata sovelluksiaan siltä.
Kello on 22.00. Tiedätkö, missä toimintasi ovat? Siellä on uusi haavoittuvuus, jota voidaan hyödyntää miljoonissa Android-laitteissa, ja se on myös melko ilkeä. Lyhyesti sanottuna tämän suunnitteluvirheen ansiosta hyökkääjä voi esittää oman toimintansa (sivunsa) toisen sovelluksen päällä, mikä saattaa hämmentää käyttäjää luovuttamaan yksityisiä tietojaan. Haavoittuvuus on nimetty StrandHogg 2.0:ksi, ja se paljasti äskettäin Promon, norjalainen turvallisuusyritys.
StrandHogg 2.0 -haavoittuvuus vaikuttaa teoriassa kaikkiin Android-laitteisiin, joissa on Honeycomb (3.0) ja jopa Android 9 Pie (9.0) versiot. Perustuu uusimman Android-version jakelutilastot, se tarkoittaa sitä noin 91,8 % kaikista Android-laitteista on alttiita StrandHogg 2.0:lle. Haavoittuvuus määritettiin CVE-2020-0096 ja hänelle annettiin a vakavuusaste "kriittinen". Se ei vaadi erityisiä käyttöoikeuksia toimiakseen ja voi toimia lähes kokonaan ilman käyttäjän vuorovaikutusta. Käyttäjän tarvitsee vain avata sovellus, jossa on haitallista koodia piilossa, ja sitten hän on alttiina hyväksikäytölle.
Promon oli ystävällisesti lähettänyt meille proof of concept -sovelluksensa ja sen lähdekoodin, jotta voimme parhaiten selittää, miten hyväksikäyttö toimii, miksi sillä on merkitystä käyttäjille ja kuinka kehittäjät voivat suojata sovelluksiaan sitä vastaan.
Kuinka se toimii
Oletetaan, että käytät Gmailia ja napsautat verkkolinkkiä. Jos siirryt viimeaikaisten sovellusten näyttöön, saatat huomata, että verkkosivu näyttää olevan Gmailin "sisällä". Esikatselu näyttää verkkosivuston, mutta sovelluksen kuvake ja nimi ovat edelleen Gmailista. Tämä tapahtuu, kun sovellus/toiminto käynnistää toisen sovelluksen/toiminnon samassa tehtävässä. Kuvittele nyt, että et tarkoituksella avannut tuota linkkiä. Sinusta näyttää siltä, että se on vain osa Gmail-sovellusta. StrandHogg 2.0 hyödyntää tätä toimintaa.
Meidän on jätettävä joitakin yksityiskohtia pois tästä, mutta tässä on suunnilleen kuinka tämä hyväksikäyttö toimii. Oletetaan seuraavassa, että hyökkääjä haluaa saada käyttäjän Gmail-kirjautumistunnuksen.
- Käyttäjä lataa haitallisen sovelluksen (tietysti tietämättä sen olevan haitallinen) ja avaa sen.
- Taustalla sovellus avaa Gmailin, lisää sen päälle samankaltaisen kirjautumistoiminnon ja käynnistää sitten toisen toiminnon.
- Käyttäjä avaa Gmailin ja näkee sen, mikä näyttää Gmailin kirjautumisnäytöltä, mutta on itse asiassa hyökkääjän tietojenkalastelutoiminto.
Vaiheessa 2 käynnistetty viimeinen toiminto voi olla mikä tahansa, mikä välttää epäilykset. Sovellus voi teeskennellä kaatumisen ja palata aloitusnäyttöön, tai se voi vain avata päätoimintoonsa ikään kuin mitään ei tapahtuisi. Ainoa epäilyttävä asia, jonka käyttäjä saattaa nähdä, on joukko avausanimaatioita, kun kaikki toiminnot käynnistyvät. Pahin osa: Se ei edes näytä siltä, että Gmail avattiin.
Hyökkääjä voi tietysti tehdä muutakin kuin vain näyttää väärennetyn kirjautumisnäytön. Haitallinen sovellus voi sen sijaan näyttää lupakehotteen, joka huijaa käyttäjän myöntämään ei-toivottuja käyttöoikeuksia. Vaikka erityisten käyttöoikeuksien, kuten saavutettavuuden, pyytäminen saattaa tehdä käyttäjästä epäluuloisen, on mahdollista tehdä paljon vahinkoa esimerkiksi Storage Accessilla.
Tekniset osat
Tämä seuraava osa on korkeatasoinen yleiskatsaus StrandHogg 2.0:n toiminnasta. Promon ei julkaise kaikkia yksityiskohtia muutamaan kuukauteen, joten emme voi kertoa tarkasti, kuinka tämä hyväksikäyttö on toteutettu. On kuitenkin joitain teknisiä yksityiskohtia, joista voimme puhua.
Lyhyesti sanottuna StrandHogg 2.0 kaappaa Androidin Context.startActivities() API-menetelmä, jossa käytetään kolmea tarkoitusta.
- Ensimmäinen Intent on se, joka käynnistää, esimerkkimme tapauksessa, Gmailin. Se on merkitty
Intent.FLAG_ACTIVITY_NEW_TASK. - Toinen tarkoitus on haitallinen. Esimerkissämme se on samankaltaista kirjautumistoimintoa varten. Tällä Intentillä ei ole lippuja.
- Kolmas tarkoitus on häiriötekijä. Se varmistaa, että käyttäjä ei epäile Gmailia, joka vain avautuu satunnaisesti napautetun sovelluksen (eli hyökkäyksen käynnistäneen) sijaan. Se on merkitty
Intent.FLAG_ACTIVITY_NEW_TASK.
Kaikki nämä intentit välitetään sitten taulukossa startActivities() menetelmä.
Toisen Intentin lippujen puute on avain tässä. Näin toimimalla olemme periaatteessa vain toistaneet Gmail-esimerkin ylhäältä. Tehtävä on teknisesti Gmailin, mutta ylin toiminto on hyökkääjän. Kun käyttäjä napsauttaa sitten Gmailin aloitusnäytön kuvaketta, Gmailin sijaan näytetään hyökkääjän toiminta.
Käsitteen todiste
Promonin meille lähettämien tietojen avulla pystyimme toistamaan heidän konseptinsa todisteen. Tässä on Android 9 Pie -käyttöjärjestelmää käyttävän Samsung Galaxy Note8:n näyttötallenne, joka näyttää sen toiminnassa.
Lieventämistekniikat ja -ongelmat
Nyt pelkkä yllä olevan kopioiminen koodissa ei todellakaan toimi. Se ei ole täydellinen esimerkki, ja hyökkääjän on tehtävä muutamia muita asioita, jotta se toimisi, mutta joita emme voi jakaa. Mutta niitä ei ole erityisen vaikea arvata itse, ja se on osa sitä, mikä tekee tästä hyökkäyksestä niin vaarallisen. StrandHogg 2.0 on suhteellisen helppo hyödyntää, ja sitä on vaikea lieventää.
Lieventäminen ei voi tarkoittaa vain kaikkien sitä käyttävien sovellusten lisäämistä mustalle listalle startActivities(), koska sille on monia laillisia käyttötarkoituksia. Sen tunnistusalgoritmin automatisointi on myös todella vaikeaa. Haitalliset kehittäjät voivat käyttää kaikenlaisia temppuja tehdäkseen StrandHogg 2.0:n toteutuksensa näkymättömäksi palveluille, kuten Google Play Protect. StrandHogg 1.0 vaati hyökkääjää lisäämään haitallisen sovelluksen AndroidManifest.xml-tiedostoon attribuutin, joka oli suhteellisen helppo havaita. StrandHogg 2.0 puolestaan toimii kokonaan Java/Kotlinissa.
Kun otetaan huomioon hämärtyminen, heijastus ja jopa vain erilaiset koodaustyylit, näyttää epäkäytännölliseltä tunnistaa automaattisesti oikein tätä hyväksikäyttöä käyttävä sovellus. Lisäksi jos käyttäjä joutuu StrandHogg 2.0 -hyökkäyksen kohteeksi, hän ei välttämättä edes tiedä. Jos avaat Gmailin ja näet sen kirjautumisnäytön, saatat ajatella, että istuntosi on vanhentunut ja annat kirjautumistietosi ajattelematta.
Kun otimme yhteyttä Googleen saadaksemme vastausta, tiedottaja tarjosi seuraavan lausunnon:
"Arvostamme tutkijoiden työtä ja olemme julkaisseet korjauksen heidän havaitsemaansa ongelmaan. Lisäksi Google Play Protect havaitsee ja estää haitalliset sovellukset, mukaan lukien tätä tekniikkaa käyttävät."
Tämä kuulostaa hyvältä, ja toivottavasti sillä on ainakin jonkinlainen vaikutus StrandHogg 2.0 -hyökkäyksiä vastaan. On kuitenkin syytä huomata, että Google Play Protect ei tehnyt havaita proof of concept -sovelluksemme haitalliseksi, jopa manuaalisen tarkistuksen jälkeen.
Promon sanoo, että he "eivät ole havainneet todellisia haittaohjelmia, jotka käyttävät StrandHogg 2.0 -haavoittuvuutta", mutta ei ole takeita siitä, että tämä on ensimmäinen kerta, kun hyväksikäyttö löydetään. Tästä syystä Promon suosittelee, että kehittäjät jatkavat ja suojaavat sovelluksiaan asettamalla käynnistystoimintonsa launchMode lippu kummallekaan singleTask tai singleInstance. Kumpikin näistä lipuista estää tehtävien lisäämisen, johon StrandHogg 2.0 luottaa. Kuitenkin, jos toimintosi käyttää jotakin näistä lipuista, se voi aiheuttaa ongelmia tietyissä sovelluskuluissa, joten se ei ole aina toivottavaa.
Promon mainostaa myös omaa "In-App Protection by Promon SHIELD" -tuotetta, joka kuulostaa kirjastolta jonka sovelluskehittäjät voivat ottaa käyttöön valvoakseen sovelluksesi prosessissa olevia tehtäviä ja tarkistaakseen, onko niissä epäsäännöllisiä lisäykset. Koska ei ole olemassa todella tehokasta kehittäjien tai käyttäjien lieventämisstrategiaa, on melko tärkeää, että valmistajat ottavat korjaustiedoston korjatakseen tämän mahdollisimman pian.
Onneksi Promon noudatti vastuullisia paljastamisohjeita ennen kuin julkisti tämän hyväksikäytön (ja se ei ole vieläkään täysin julkinen – Promon odottaa 90 päivää ennen kuin paljastaa täysin, miten StrandHogg 2.0 toimii). Google on sittemmin siirtänyt korjaustiedostoja tälle hyödylle Android 8.0 Oreolle, Android 8.1 Oreolle ja Android 9 Pie Toukokuu 2020 Android Security Patch Level (SPL). Android 10:n ja sitä uudempien käyttöjärjestelmien käyttäjät eivät ole haavoittuvia, vaikka emme ole täysin varmoja, miksi näin on. Sillä on todennäköisesti jotain tekemistä Android 10:n uusien rajoitusten kanssa, jotka koskevat toimintojen käynnistämistä ja kuinka Google integroi sen tehtäväpinoon. Promon sanoo, että "Android 10:ssä hyökkäys on täysin tehoton ja toiminnot on jaettu eri tehtäviin ja erillisiin tehtäväpinoihin adb shell dumpsys activity activities."
Jos laitteesi valmistaja tarjoaa edelleen tietoturvapäivityksiä (voit lukea lisää kuinka suojauskorjausprosessi toimii täällä), sinun tulee pyytää niitä päivittämään mahdollisimman pian. Muussa tapauksessa sinun on vain oltava varovainen lataamiesi ja suorittamiesi sovellusten suhteen (vaikka sinun pitäisi tehdä se joka tapauksessa).
Lisätietoja ja StrandHogg 2.0:n käyttötapauksia on osoitteessa virallinen ilmoitus Promonin verkkosivuilla. Räätälöityjen ROM-kehittäjien osalta voit löytää asianmukaiset AOSP-sitoumukset StrandHogg 2.0 -hyökkäysten estämiseksi tässä ja tässä.
Ilmoituksen aikajana
Tässä on ilmoitusaikajana, jonka Promon jakoi StandHogg 2.0 -asiakirjassaan:
- 4. joulukuuta 2019 – Ilmoitettu ongelmasta Googlelle
- 4. joulukuuta 2019 – Jakoi PoC-haitallisen sovelluksen ja videon Googlen kanssa
- 4. joulukuuta 2019 – Google vahvisti saaneensa raportin
- 9. joulukuuta 2019 – Google asetti löydön vakavuuden "kriittiseksi"
- 9. joulukuuta 2019 – Google vahvistaa, että he pystyvät toistamaan ongelman
- 14. helmikuuta 2020 – Ilmoitamme Googlelle, että 90 päivän julkistaminen lähestyy maaliskuun alussa ja pyydämme heidän puolellaan statusta
- 14. helmikuuta 2020 – Google vastaa, että huhtikuu on nopein korjaus
- 14. helmikuuta 2020 – Ilmoitamme Googlelle, että pyrimme lieventämiseen
- 14. helmikuuta 2020 – Google vastaa. He työskentelevät korjausten parissa ja kysyvät, voimmeko kertoa, mitä lievennyksiä suosittelemme
- 17. helmikuuta 2020 – Ilmoitamme Googlelle, että voimme viivyttää julkistamista huhtikuuhun asti. Pyydämme CVE-numeroa
- 17. helmikuuta 2020 – Jaamme lieventämisstrategiamme sekä näkemyksemme alustan lieventämisestä
- 23. maaliskuuta 2020 – Google vastaa CVE-tunnuksella (CVE-2020-0096)
- 23. maaliskuuta 2020 – Google vastaa, että korjauksen yleinen saatavuus Androidille on saatavilla toukokuussa
- 23. maaliskuuta 2020 – Google kysyy, harkitsemmeko julkistamisen lykkäämistä toukokuuhun
- 27. maaliskuuta 2020 – Vastaamme, että siirrämme julkistamisen toukokuulle
- 22. huhtikuuta 2020 – Google ilmoittaa, että toukokuun tietoturvatiedotteessa on määrä sisältää korjaustiedoston haavoittuvuutta varten