StrandHogg 2.0 Udnyttelse forklaret

StrandHogg 2.0 er en farlig ny Android-sårbarhed. Her er, hvordan det kan påvirke brugerne, og hvordan udviklere kan beskytte deres apps mod det.

Klokken er 22:00. Ved du, hvor dine aktiviteter er? Der er en ny sårbarhed, der kan udnyttes på millioner af Android-enheder, og det er også en ret ubehagelig en. I en nøddeskal giver denne designfejl en angriber mulighed for at præsentere deres egen aktivitet (side) oven på en anden apps, hvilket potentielt forvirrer brugeren til at give deres private data væk. Sårbarheden er blevet døbt StrandHogg 2.0 og blev for nylig afsløret af Promon, et norsk sikkerhedsfirma.

StrandHogg 2.0-sårbarheden påvirker teoretisk alle Android-enheder, der kører Android-versioner så gamle som Honeycomb (3.0) og op til Android 9 Pie (9.0). Baseret på seneste distributionsstatistikker for Android-versioner, det betyder det cirka 91,8 % af alle Android-enheder er sårbare over for StrandHogg 2.0. Sårbarheden blev tildelt CVE-2020-0096 og fik en sværhedsgrad af "kritisk".

Det kræver ingen særlige tilladelser for at fungere og kan fungere næsten helt uden brugerinteraktion. Alt hvad en bruger skal gøre er at åbne en app med ondsindet kode gemt væk i den, og så er de sårbare over for udnyttelse.

Promon var så venlig at sende os deres proof of concept-app og dens kildekode, så vi bedst kunne forklare, hvordan udnyttelsen fungerer, hvorfor den betyder noget for brugerne, og hvordan udviklere kan beskytte deres apps imod det.


Hvordan det virker

Lad os sige, at du bruger Gmail, og du klikker på et weblink. Hvis du går til din seneste apps-skærm, bemærker du muligvis, at websiden ser ud til at være "inde i" Gmail. Forhåndsvisningen viser webstedet, men appikonet og navnet er stadig fra Gmail. Dette er noget, der sker, når en app/aktivitet starter en anden app/aktivitet i samme opgave. Forestil dig nu, at du ikke med vilje åbnede det link. For dig ser det ud til, at det bare er en del af Gmail-appen. Dette er den adfærd, StrandHogg 2.0 udnytter.

Vi bliver nødt til at udelade nogle detaljer her, men her er nogenlunde, hvordan denne udnyttelse fungerer. For det følgende, lad os antage, at angriberen ønsker at få brugerens Gmail-login.

  1. Brugeren downloader en ondsindet app (selvfølgelig uden at vide, at den er ondsindet) og åbner den.
  2. I baggrunden åbner appen Gmail, lægger en loginaktivitet, der ligner hinanden, oven på den og starter derefter en anden aktivitet.
  3. Brugeren åbner Gmail og ser, hvad der ligner Gmails login-skærm, men som faktisk er angriberens phishing-aktivitet.

Den sidste aktivitet, der blev lanceret i trin 2, kan være alt, der undgår mistanke. Appen kunne forfalske et nedbrud og gå tilbage til startskærmen, eller den kunne bare åbne til sin hovedaktivitet, som om intet var hændt. Det eneste mistænkelige, som brugeren kan se, er en masse åbningsanimationer, når alle aktiviteterne starter. Det værste: Det vil ikke engang se ud til, at Gmail blev åbnet.

Kilde: Promon

Selvfølgelig kan en angriber mere end blot at vise en falsk login-skærm. En ondsindet app kunne præsentere en tilladelsesprompt i stedet for at narre brugeren til at give uønskede tilladelser. Selvom det kan gøre brugeren mistænksom at anmode om særlige tilladelser, såsom tilgængelighed, er det muligt at gøre meget skade med noget som Storage Access.


De tekniske bits

Dette næste afsnit er en oversigt på højt niveau over, hvordan StrandHogg 2.0 fungerer. Promon vil ikke frigive de fulde detaljer før om et par måneder, så vi kan ikke fortælle præcis, hvordan denne udnyttelse implementeres. Der er dog nogle tekniske detaljer, som vi kan tale om.

Kort sagt, StrandHogg 2.0 kaprer Androids Context.startActivities() API-metode, der bruger tre hensigter.

  • Den første hensigt er den, der i vores eksempel lancerer Gmail. Det er markeret med Intent.FLAG_ACTIVITY_NEW_TASK.
  • Den anden hensigt er den ondsindede. I vores eksempel er det til login-aktiviteten, der ligner hinanden. Denne hensigt har ingen flag.
  • Den tredje hensigt er distraktionen. Det sikrer, at brugeren ikke er mistænksom over for Gmail, der bare åbner tilfældigt i stedet for den app, de trykkede på (dvs. den, der lancerede angrebet). Det er markeret med Intent.FLAG_ACTIVITY_NEW_TASK.

Alle disse hensigter sendes derefter i et array til startActivities() metode.

Den anden Intents mangel på flag er nøglen her. Ved at gøre det har vi stort set blot replikeret Gmail-eksemplet fra oven. Opgaven er teknisk set Gmails, men den øverste aktivitet er angriberens. Når brugeren derefter klikker på Gmails startskærmsikon, vises angriberens aktivitet i stedet for Gmails.


Proof of Concept

Med de oplysninger, som Promon sendte os, var vi i stand til at gentage deres proof of concept. Her er en skærmoptagelse fra en Samsung Galaxy Note8, der kører Android 9 Pie, der viser den i aktion.


Afhjælpningsteknikker og problemer

Nu vil det faktisk ikke fungere at replikere ovenstående i kode. Det er ikke et komplet eksempel, og der er et par andre ting, som en angriber skal gøre for at få det til at fungere, som vi ikke kan dele. Men de er ikke særlig svære at gætte på egen hånd, og det er en del af det, der gør dette angreb så farligt. StrandHogg 2.0 er en relativt nem udnyttelse at implementere og svær at afbøde.

Afhjælpning kan ikke kun involvere blacklisting af alle apps, der bruger startActivities(), da der er masser af legitime anvendelser for det. Det er også virkelig svært at automatisere en detektionsalgoritme til det. Ondsindede udviklere kan anvende alle mulige tricks for at gøre deres implementering af StrandHogg 2.0 effektivt usynlig for tjenester som Google Play Protect. StrandHogg 1.0 krævede, at angriberen tilføjede en attribut i den ondsindede apps AndroidManifest.xml, som var relativt let at opdage. StrandHogg 2.0 fungerer på den anden side udelukkende i Java/Kotlin.

Under hensyntagen til sløring, refleksion og endda bare forskellige kodningsstile, virker det upraktisk automatisk korrekt at registrere en app, der gør brug af denne udnyttelse. Hvad mere er, er, at hvis en bruger er genstand for et StrandHogg 2.0-angreb, ved de det måske ikke engang. Hvis du åbner Gmail, og du ser dens login-skærm, tror du måske bare, at din session er udløbet og indtaster dine loginoplysninger uden en ekstra tanke.

Da vi kontaktede Google for at få et svar, tilbød en talsmand følgende udtalelse:

"Vi sætter pris på forskernes arbejde og har frigivet en løsning på det problem, de har identificeret. Derudover registrerer og blokerer Google Play Protect ondsindede apps, inklusive dem, der bruger denne teknik."

Dette lyder godt, og forhåbentlig har det i det mindste en vis effekt mod StrandHogg 2.0-angreb. Det er dog værd at bemærke, at Google Play Protect gjorde ikke opdage vores proof of concept-app som ondsindet, selv efter at have udført en manuel scanning.

Promon siger, at de "har ikke observeret nogen virkelig malware, der bruger StrandHogg 2.0-sårbarheden," men der er ingen garanti for, at det er første gang, udnyttelsen er blevet opdaget. Af den grund anbefaler Promon, at udviklere går videre og beskytter deres apps ved at indstille deres launcher Activity's launchMode flag til enten singleTask eller singleInstance. Begge disse flag vil forhindre opgaveinjektion, hvilket er hvad StrandHogg 2.0 er afhængig af. Men hvis din aktivitet bruger et af disse flag, kan det forårsage problemer med visse app-flows, så det er ikke altid ønskeligt.

Promon promoverer også sit eget "In-App Protection by Promon SHIELD"-produkt, der lyder som et bibliotek som app-udviklere kan implementere for at overvåge opgaverne i din apps proces for at tjekke for uregelmæssigheder indsættelser. Fordi der ikke er nogen virkelig effektiv udvikler- eller brugerreduktionsstrategi, er det ret vigtigt, at producenter implementerer patchen for at rette dette ASAP.

Heldigvis fulgte Promon retningslinjerne for ansvarlig offentliggørelse, før han offentliggjorde denne udnyttelse (og det er stadig ikke helt offentligt - Promon venter 90 dage, før han fuldt ud afslører, hvordan StrandHogg 2.0 arbejder). Google har siden tilbageporteret patches til denne udnyttelse til Android 8.0 Oreo, Android 8.1 Oreo og Android 9 Pie med Maj 2020 Android Security Patch Level (SPL). Brugere på Android 10 og nyere er ikke sårbare, selvom vi ikke er helt sikre på, hvorfor det er tilfældet. Det har sandsynligvis noget at gøre med Android 10's nye begrænsninger vedrørende lancering af aktiviteter, og hvordan Google integrerede det i opgavestakken. Promon siger, at "på Android 10 er angrebet fuldstændig ineffektivt, og aktiviteterne er opdelt i forskellige opgaver og i separate opgavestakke iflg. adb shell dumpsys activity activities."

Hvis din enhedsproducent stadig leverer sikkerhedsopdateringer (du kan læse mere om hvordan sikkerhedsrettelsesprocessen fungerer her), bør du plage dem for en opdatering så hurtigt som muligt. Ellers skal du bare være forsigtig med, hvilke apps du downloader og kører (selvom du burde gøre det alligevel).

For flere detaljer og anvendelsesmuligheder for StrandHogg 2.0, tjek officiel meddelelse på Promons hjemmeside. For brugerdefinerede ROM-udviklere kan du finde de relevante AOSP-commits til at forhindre StrandHogg 2.0-angreb her og her.


Tidslinje for offentliggørelse

Her er den afsløringstidslinje, som Promon delte i sit StandHogg 2.0-dokument:

  • 4. december 2019 – Rapporterede problem til Google
  • 4. december 2019 – Delte en PoC «ondsindet app» og video med Google
  • 4. december 2019 – Google bekræftede modtagelsen af ​​rapporten
  • 9. december 2019 – Google satte sværhedsgraden af ​​​​fundet som "Kritisk"
  • 9. december 2019 – Google bekræfter, at de er i stand til at genskabe problemet
  • 14. februar 2020 – Vi informerer Google om, at 90-dages offentliggørelse nærmer sig i begyndelsen af ​​marts, og beder om status på deres side
  • 14. februar 2020 – Google svarer, at april er den hurtigste, de kan udrulle en rettelse
  • 14. februar 2020 – Vi informerer Google om, at vi arbejder på afhjælpning
  • 14. februar 2020 – Google svarer. De arbejder på udbedring og spørger, om vi kan dele, hvilke afhjælpninger vi anbefaler
  • 17. februar 2020 – Vi informerer Google om, at vi kan udsætte offentliggørelsen til april. Vi anmoder om CVE-nummeret
  • 17. februar 2020 – Vi deler vores afbødningsstrategier, samt hvordan vi forestiller os en platformsreduktion
  • 23. marts 2020 – Google svarer med CVE-id'et (CVE-2020-0096)
  • 23. marts 2020 – Google svarer, at den generelle tilgængelighed af rettelsen til Android vil være tilgængelig i maj
  • 23. marts 2020 – Google spørger, om vi vil overveje at udsætte offentliggørelsen til maj
  • 27. marts 2020 - Vi svarer, at vi vil udsætte offentliggørelsen til maj
  • 22. april 2020 – Google informerer os om, at May Security Bulletin er planlagt til at indeholde en patch til sårbarheden