StrandHogg 2.0 Utnyttelse forklart

StrandHogg 2.0 er en farlig ny Android-sårbarhet. Her er hvordan det kan påvirke brukere og hvordan utviklere kan beskytte appene sine mot det.

Klokken er 22:00. Vet du hvor aktivitetene dine er? Det er en ny sårbarhet som kan utnyttes på millioner av Android-enheter, og den er også ganske ekkel. I et nøtteskall lar denne designfeilen en angriper presentere sin egen aktivitet (side) på toppen av en annen app, og potensielt forvirre brukeren til å gi bort sine private data. Sårbarheten har blitt kalt StrandHogg 2.0 og ble nylig avslørt av Promon, et norsk sikkerhetsfirma.

StrandHogg 2.0-sårbarheten påvirker teoretisk alle Android-enheter som kjører Android-versjoner så gamle som Honeycomb (3.0) og opp til Android 9 Pie (9.0). Basert på siste distribusjonsstatistikk for Android-versjonen, det betyr det omtrent 91,8 % av alle Android-enheter er sårbare for StrandHogg 2.0. Sårbarheten ble tildelt CVE-2020-0096 og fikk en alvorlighetsgrad av "kritisk". Det krever ingen spesielle tillatelser for å fungere og kan fungere nesten helt uten brukerinteraksjon. Alt en bruker trenger å gjøre er å åpne en app med ondsinnet kode gjemt i den, og da er de sårbare for utnyttelse.

Promon var så snill å sende oss deres proof of concept-app og dens kildekode slik at vi kunne best mulig forklare hvordan utnyttelsen fungerer, hvorfor den er viktig for brukerne, og hvordan utviklere kan beskytte appene sine imot det.

Hvordan det fungerer

La oss si at du bruker Gmail og klikker på en nettkobling. Hvis du går til skjermbildet for nylige apper, kan du legge merke til at nettsiden ser ut til å være "inne" i Gmail. Forhåndsvisningen viser nettstedet, men appikonet og navnet er fortsatt fra Gmail. Dette er noe som skjer når en app/aktivitet starter en annen app/aktivitet i samme oppgave. Tenk deg nå at du ikke med vilje åpnet den lenken. For deg ser det ut som om det bare er en del av Gmail-appen. Dette er oppførselen StrandHogg 2.0 utnytter.

Vi må utelate noen detaljer her, men her er omtrent hvordan denne utnyttelsen fungerer. For det følgende, la oss anta at angriperen ønsker å få brukerens Gmail-pålogging.

Brukeren laster ned en ondsinnet app (selvfølgelig uten å vite at den er ondsinnet) og åpner den.
I bakgrunnen åpner appen Gmail, legger en påloggingsaktivitet på toppen av den, og starter deretter en annen aktivitet.
Brukeren åpner Gmail og ser det som ser ut som Gmails påloggingsskjerm, men som faktisk er angriperens phishing-aktivitet.

Den endelige aktiviteten som ble lansert i trinn 2 kan være alt som unngår mistanke. Appen kan forfalske et krasj og gå tilbake til startskjermen, eller den kan bare åpne til hovedaktiviteten som om ingenting har skjedd. Det eneste mistenkelige brukeren kan se er en haug med åpningsanimasjoner når alle aktivitetene starter. Det verste: Det vil ikke engang se ut som Gmail ble åpnet.

Kilde: Promon

Selvfølgelig kan en angriper gjøre mer enn bare å vise en falsk påloggingsskjerm. En ondsinnet app kan presentere en tillatelsesforespørsel i stedet, og lure brukeren til å gi uønskede tillatelser. Selv om det å be om spesielle tillatelser som tilgjengelighet kan gjøre brukeren mistenksom, er det mulig å gjøre mye skade med noe som Storage Access.

De tekniske bitene

Denne neste delen er en oversikt på høyt nivå over hvordan StrandHogg 2.0 fungerer. Promon vil ikke gi ut alle detaljer før om noen måneder, så vi kan ikke dele nøyaktig hvordan denne utnyttelsen implementeres. Det er imidlertid noen tekniske detaljer vi kan snakke om.

I et nøtteskall, StrandHogg 2.0 kaprer Android Context.startActivities() API-metode, med tre intensjoner.

Den første intensjonen er den som lanserer, i vårt eksempel, Gmail. Det er flagget med Intent.FLAG_ACTIVITY_NEW_TASK.
Den andre hensikten er den ondsinnede. I vårt eksempel er det for påloggingsaktiviteten som ligner på hverandre. Denne hensikten har ingen flagg.
Den tredje hensikten er distraksjonen. Den sørger for at brukeren ikke er mistenksom på at Gmail bare åpner tilfeldig i stedet for appen de trykker på (dvs. den som startet angrepet). Det er flagget med Intent.FLAG_ACTIVITY_NEW_TASK.

Alle disse hensiktene sendes deretter i en rekke til startActivities() metode.

Den andre Intents mangel på flagg er nøkkelen her. Ved å gjøre det har vi i utgangspunktet bare replikert Gmail-eksemplet ovenfra. Oppgaven er teknisk sett Gmails, men den øverste aktiviteten er angriperens. Når brukeren deretter klikker på Gmails startskjermikon, vises angriperens aktivitet i stedet for Gmails.

Proof of Concept

Med informasjonen som Promon sendte oss, var vi i stand til å gjenskape deres proof of concept. Her er et skjermopptak fra en Samsung Galaxy Note8 som kjører Android 9 Pie som viser den i aksjon.

Avbøtende teknikker og problemer

Nå vil det faktisk ikke fungere å replikere det ovennevnte i koden. Det er ikke et komplett eksempel, og det er et par andre ting som en angriper må gjøre for å få det til å fungere, som vi ikke kan dele. Men de er ikke spesielt vanskelige å gjette på egenhånd, og det er noe av det som gjør dette angrepet så farlig. StrandHogg 2.0 er en relativt enkel utnyttelse å implementere, og vanskelig å redusere.

Redusering kan ikke bare innebære å svarteliste alle apper som bruker startActivities(), siden det er mange legitime bruksområder for det. Det er også veldig vanskelig å automatisere en deteksjonsalgoritme for det. Ondsinnede utviklere kan bruke alle slags triks for å gjøre implementeringen av StrandHogg 2.0 effektivt usynlig for tjenester som Google Play Protect. StrandHogg 1.0 krevde at angriperen la til et attributt i den ondsinnede appens AndroidManifest.xml, som var relativt lett å oppdage. StrandHogg 2.0, derimot, fungerer utelukkende i Java/Kotlin.

Tatt i betraktning tilsløring, refleksjon og til og med bare forskjellige kodestiler, virker det upraktisk å automatisk oppdage en app som bruker denne utnyttelsen. Dessuten er det at hvis en bruker er gjenstand for et StrandHogg 2.0-angrep, vet de kanskje ikke engang. Hvis du åpner Gmail og du ser påloggingsskjermen, tror du kanskje at økten er utløpt og skriver inn påloggingsdetaljene uten å tenke på det.

Da vi kontaktet Google for å få svar, kom en talsperson med følgende uttalelse:

"Vi setter pris på arbeidet til forskerne, og har gitt ut en løsning for problemet de identifiserte. I tillegg oppdager og blokkerer Google Play Protect skadelige apper, inkludert de som bruker denne teknikken."

Dette høres bra ut, og forhåpentligvis har det i det minste en viss effekt mot StrandHogg 2.0-angrep. Det er imidlertid verdt å merke seg at Google Play Protect gjorde ikke oppdage proof of concept-appen vår som skadelig, selv etter å ha utført en manuell skanning.

Promon sier at de "har ikke observert noen virkelig skadelig programvare som bruker StrandHogg 2.0-sårbarheten," men det er ingen garanti for at dette er første gang utnyttelsen er oppdaget. Av den grunn anbefaler Promon at utviklere går videre og beskytter appene sine ved å angi startaktivitetens launchMode flagg til enten singleTask eller singleInstance. Begge disse flaggene vil forhindre oppgaveinjeksjon, noe StrandHogg 2.0 er avhengig av. Men å ha aktiviteten din til å bruke et av disse flaggene kan forårsake problemer med visse appflyter, så det er ikke alltid ønskelig.

Promon promoterer også sitt eget "In-App Protection by Promon SHIELD"-produkt som høres ut som et bibliotek som apputviklere kan implementere for å overvåke oppgavene i appens prosess for å se etter uregelmessigheter innsettinger. Fordi det ikke finnes noen virkelig effektiv utvikler- eller brukerreduksjonsstrategi, er det ganske viktig at produsenter implementerer oppdateringen for å fikse dette ASAP.

Heldigvis fulgte Promon retningslinjer for ansvarlig avsløring før han offentliggjorde denne utnyttelsen (og det er fortsatt ikke helt offentlig – Promon venter 90 dager før han avslører hvordan StrandHogg 2.0 virker). Google har siden tilbakeportert oppdateringer for denne utnyttelsen til Android 8.0 Oreo, Android 8.1 Oreo og Android 9 Pie med Mai 2020 Android Security Patch Level (SPL). Brukere på Android 10 og nyere er ikke sårbare, selv om vi ikke er helt sikre på hvorfor det er tilfelle. Det har sannsynligvis noe å gjøre med Android 10s nye restriksjoner angående lansering av aktiviteter og hvordan Google integrerte det i oppgavestakken. Promon sier at «på Android 10 er angrepet helt ineffektivt, og aktivitetene er delt opp i forskjellige oppgaver og i separate oppgavestabler iht. adb shell dumpsys activity activities."

Hvis enhetsprodusenten fortsatt leverer sikkerhetsoppdateringer (kan du lese mer om hvordan sikkerhetsoppdateringsprosessen fungerer her), bør du plage dem for en oppdatering så snart som mulig. Ellers må du bare være forsiktig med hvilke apper du laster ned og kjører (selv om du bør gjøre det uansett).

For flere detaljer og bruksområder for StrandHogg 2.0, sjekk ut offisiell kunngjøring på Promons nettside. For tilpassede ROM-utviklere kan du finne de relevante AOSP-commits for å forhindre StrandHogg 2.0-angrep her og her.

Tidslinje for avsløring

Her er tidslinjen for avsløring som Promon delte i sitt StandHogg 2.0-dokument:

4. desember 2019 – Rapportert problem til Google
4. desember 2019 – Delte en PoC «ondsinnet app» og video med Google
4. desember 2019 – Google bekreftet å ha mottatt rapporten
9. desember 2019 – Google satte alvorlighetsgraden av funnet som «kritisk»
9. desember 2019 – Google bekrefter at de er i stand til å gjenskape problemet
14. februar 2020 – Vi informerer Google om at 90-dagers avsløring nærmer seg i begynnelsen av mars, og ber om status på deres side
14. februar 2020 – Google svarer at april er den raskeste de kan lansere en løsning
14. februar 2020 – Vi informerer Google om at vi jobber med avbøtende tiltak
14. februar 2020 – Google svarer. De jobber med utbedring, og spør om vi kan dele hvilke avbøtende tiltak vi anbefaler
17. februar 2020 – Vi informerer Google om at vi kan holde tilbake avsløringen til april. Vi ber om CVE-nummeret
17. februar 2020 – Vi deler våre reduksjonsstrategier, samt hvordan vi ser for oss en plattformreduksjon
23. mars 2020 – Google svarer med CVE-ID (CVE-2020-0096)
23. mars 2020 – Google svarer at generell tilgjengelighet av løsningen for Android vil være tilgjengelig i mai
23. mars 2020 – Google spør om vi vil vurdere å utsette avsløringen til mai
27. mars 2020 – Vi svarer at vi vil utsette avsløringen til mai
22. april 2020 – Google informerer oss om at May Security Bulletin er planlagt å inneholde en oppdatering for sårbarheten