A StrandHogg 2.0 egy veszélyes új Android sebezhetőség. Íme, hogyan érintheti a felhasználókat, és hogyan védhetik meg a fejlesztők alkalmazásaikat ellene.
22:00 van. Tudod, hol vannak a tevékenységeid? Van egy új sebezhetőség, amelyet több millió Android-eszközön lehet kihasználni, és ez is egy elég csúnya. Dióhéjban ez a tervezési hiba lehetővé teszi a támadó számára, hogy saját tevékenységét (oldalát) mutassa be egy másik alkalmazás tetején, ami megzavarhatja a felhasználót abban, hogy kiadja személyes adatait. A sebezhetőséget StrandHogg 2.0-nak nevezték el, és nemrégiben hozta nyilvánosságra Prom, egy norvég biztonsági cég.
A StrandHogg 2.0 sebezhetősége elméletileg minden olyan Android-eszközt érint, amelyen a Honeycomb (3.0) és legfeljebb Android 9 Pie (9.0) Android-verziók futnak. Alapján legújabb Android-verzió terjesztési statisztikái, ez azt jelenti az összes Android-eszköz körülbelül 91,8%-a sebezhető a StrandHogg 2.0-val szemben. A sérülékenység hozzá lett rendelve CVE-2020-0096
és kapott a a "kritikus" súlyossági szintje. Nem igényel különleges engedélyeket a működéséhez, és szinte teljesen felhasználói beavatkozás nélkül is működhet. A felhasználónak mindössze annyit kell tennie, hogy megnyit egy alkalmazást, amelyben rosszindulatú kód van elrejtve, és akkor ki van téve a kihasználásnak.A Promon volt olyan kedves, hogy elküldte nekünk a proof of concept alkalmazását és annak forráskódját, hogy a legjobban tudjunk működni elmagyarázza, hogyan működik a kihasználás, miért fontos a felhasználók számára, és hogyan védhetik meg a fejlesztők alkalmazásaikat ellene.
Hogyan működik
Tegyük fel, hogy Gmailt használ, és rákattint egy internetes hivatkozásra. Ha a legutóbbi alkalmazások képernyőjére lép, észreveheti, hogy a weboldal úgy tűnik, hogy a Gmail „bent van”. Az előnézet a webhelyet mutatja, de az alkalmazás ikonja és neve továbbra is a Gmailből származik. Ez akkor történik, amikor egy alkalmazás/tevékenység elindít egy másik alkalmazást/tevékenységet ugyanabban a feladatban. Most képzelje el, hogy nem szándékosan nyitotta meg a linket. Az Ön számára úgy tűnik, hogy ez csak a Gmail alkalmazás része. Ezt a viselkedést használja ki a StrandHogg 2.0.
Néhány részletet ki kell hagynunk itt, de nagyjából így működik ez a kizsákmányolás. A következőkhöz tegyük fel, hogy a támadó meg akarja szerezni a felhasználó Gmail bejelentkezési adatait.
- A felhasználó letölt egy rosszindulatú alkalmazást (természetesen anélkül, hogy tudná, hogy rosszindulatú), és megnyitja azt.
- A háttérben az alkalmazás megnyitja a Gmailt, ráhelyez egy hasonló bejelentkezési tevékenységet, majd elindít egy másik tevékenységet.
- A felhasználó megnyitja a Gmailt, és azt látja, ami a Gmail bejelentkezési képernyőjének tűnik, de valójában a támadó adathalász tevékenysége.
A 2. lépésben elindított utolsó tevékenység bármi lehet, ami elkerüli a gyanút. Az alkalmazás összeomlást színlelhet, és visszatérhet a kezdőképernyőre, vagy egyszerűen megnyílik a fő tevékenységre, mintha mi sem történt volna. Az egyetlen gyanús dolog, amit a felhasználó láthat, az egy csomó nyitóanimáció, amikor az összes tevékenység elindul. A legrosszabb rész: Még csak nem is úgy tűnik, mintha a Gmailt megnyitották volna.
Természetesen egy támadó többet tehet, mint egy hamis bejelentkezési képernyőt. Ehelyett egy rosszindulatú alkalmazás engedélykérést jeleníthet meg, amely ráveszi a felhasználót, hogy nem kívánt engedélyeket adjon. Bár a különleges engedélyek kérése, például az akadálymentesítés, gyanússá teheti a felhasználót, sok kárt okozhat például a Storage Access használatával.
A technikai bitek
Ez a következő rész egy magas szintű áttekintést nyújt a StrandHogg 2.0 működéséről. A Promon még néhány hónapig nem hozza nyilvánosságra a részleteket, így nem tudjuk megosztani pontosan, hogyan valósítják meg ezt a kizsákmányolást. Vannak azonban technikai részletek, amelyekről beszélhetünk.
Dióhéjban a StrandHogg 2.0 eltérítette az Androidot Context.startActivities() API-módszer, három intent használatával.
- Az első Intent az, amely elindítja a példánkban a Gmailt. Ez meg van jelölve
Intent.FLAG_ACTIVITY_NEW_TASK. - A második szándék a rosszindulatú. Példánkban ez a hasonmás bejelentkezési tevékenységre vonatkozik. Ennek a szándéknak nincsenek zászlói.
- A harmadik szándék a figyelemelterelés. Gondoskodik arról, hogy a felhasználó ne gyanakodjon arra, hogy a Gmail véletlenszerűen megnyílik az általa megérintett (azaz a támadást indító) alkalmazás helyett. Ez meg van jelölve
Intent.FLAG_ACTIVITY_NEW_TASK.
Mindezek a szándékok ezután egy tömbben átadásra kerülnek a startActivities() módszer.
A második Intent zászlóinak hiánya a kulcs itt. Ezzel lényegében a fenti Gmail példát reprodukáltuk. A feladat technikailag a Gmailé, de a legfelső tevékenység a támadóé. Amikor a felhasználó rákattint a Gmail kezdőképernyőjének ikonjára, a támadó tevékenysége jelenik meg a Gmail helyett.
Proof of Concept
A Promon által küldött információkkal sikerült megismételnünk a koncepciójukat. Íme egy képernyőfelvétel az Android 9 Pie rendszert futtató Samsung Galaxy Note8 készülékről, amely működés közben mutatja be.
Mérséklési technikák és problémák
A fentiek egyszerű replikálása kódban nem fog működni. Ez nem egy teljes példa, és van még néhány dolog, amit a támadónak meg kell tennie, hogy működjön, amit nem tudunk megosztani. De nem különösebben nehéz kitalálni őket egyedül, és ez az oka annak, hogy ez a támadás olyan veszélyes. A StrandHogg 2.0 viszonylag könnyen megvalósítható, és nehezen mérsékelhető.
A mérséklés nem csak azt jelenti, hogy az összes használó alkalmazást feketelistára helyezik startActivities(), hiszen rengeteg jogos felhasználása létezik. Nagyon nehéz automatizálni egy észlelési algoritmust is. A rosszindulatú fejlesztők mindenféle trükköt bevethetnek, hogy a StrandHogg 2.0 implementációját gyakorlatilag láthatatlanná tegyék az olyan szolgáltatások számára, mint a Google Play Protect. A StrandHogg 1.0 megkövetelte a támadótól, hogy adjon hozzá egy attribútumot a rosszindulatú alkalmazás AndroidManifest.xml fájljához, ami viszonylag könnyen észlelhető volt. A StrandHogg 2.0 viszont teljes egészében Java/Kotlin nyelven működik.
Figyelembe véve az elhomályosodást, a tükröződést és még csak a különböző kódolási stílusokat is, nem tűnik praktikusnak az ezt a kihasználást használó alkalmazás automatikus megfelelő észlelése. Sőt, ha egy felhasználót StrandHogg 2.0-s támadás ér, akkor lehet, hogy nem is tudja. Ha megnyitja a Gmailt, és megjelenik a bejelentkezési képernyő, akkor azt gondolhatja, hogy a munkamenet lejárt, és gondolkodás nélkül adja meg bejelentkezési adatait.
Amikor megkerestük a Google-t válaszért, egy szóvivő a következő nyilatkozatot tette:
"Nagyra értékeljük a kutatók munkáját, és kiadtunk egy javítást az általuk azonosított problémára. Ezenkívül a Google Play Protect észleli és blokkolja a rosszindulatú alkalmazásokat, beleértve azokat is, amelyek ezt a technikát használják."
Ez jól hangzik, és remélhetőleg lesz legalább némi hatása a StrandHogg 2.0 támadásokkal szemben. Érdemes azonban megjegyezni, hogy a Google Play Protect nem észleli, hogy a proof of concept alkalmazásunk rosszindulatú, még kézi vizsgálat után is.
Promon azt mondja, hogy "nem észleltek olyan valós kártevőket, amelyek a StrandHogg 2.0 sebezhetőségét használták volna", de nincs garancia arra, hogy ez az első alkalom, hogy felfedezték a zsákmányt. Emiatt a Promon azt javasolja a fejlesztőknek, hogy védjék alkalmazásaikat az indítótevékenység beállításával. launchMode zászlót bármelyikre singleTask vagy singleInstance. Ezen jelzők bármelyike megakadályozza a feladat-injektálást, amelyre a StrandHogg 2.0 támaszkodik. Ha azonban a tevékenységek valamelyikét használja, az problémákat okozhat bizonyos alkalmazásfolyamatoknál, ezért ez nem mindig kívánatos.
A Promon saját "In-App Protection by Promon SHIELD" termékét is népszerűsíti, amely úgy hangzik, mint egy könyvtár amelyet az alkalmazásfejlesztők bevezethetnek az alkalmazás folyamatában lévő feladatok figyelésére, hogy ellenőrizzék a szabálytalanságokat beszúrások. Mivel nincs igazán hatékony fejlesztői vagy felhasználómérséklő stratégia, nagyon fontos, hogy a gyártók alkalmazzák a javítást, hogy ezt mielőbb megjavítsák.
Szerencsére a Promon betartotta a felelősségteljes nyilvánosságra hozatali irányelveket, mielőtt nyilvánosságra hozta volna ezt a kihasználást (és még mindig nem teljesen nyilvános – a Promon 90 napot vár, mielőtt teljes mértékben nyilvánosságra hozza, hogyan működik a StrandHogg 2.0 művek). A Google azóta visszaportálta a javításokat ehhez a kizsákmányoláshoz az Android 8.0 Oreo, Android 8.1 Oreo és Android 9 Pie rendszerekhez. 2020. május Android biztonsági javítási szint (SPL). Az Android 10 és újabb rendszert használó felhasználók nincsenek sebezhetőek, bár nem vagyunk teljesen biztosak abban, hogy ez miért van így. Valószínűleg valami köze van az Android 10 új korlátozásaihoz, amelyek a tevékenységek elindítására vonatkoznak, és hogy a Google hogyan integrálta ezt a feladatcsomagba. Promon azt mondja, hogy "az Android 10 rendszeren a támadás teljesen hatástalan, és a tevékenységek különböző feladatokra és külön feladatcsomagokra vannak felosztva adb shell dumpsys activity activities."
Ha az eszköz gyártója továbbra is biztosít biztonsági frissítéseket (további információ: hogyan működik itt a biztonsági javítási folyamat), kérje meg őket a lehető leghamarabbi frissítésért. Ellenkező esetben csak óvatosnak kell lennie azzal kapcsolatban, hogy mely alkalmazásokat tölti le és futtatja (bár ezt mindenképpen meg kell tennie).
A StrandHogg 2.0 további részleteiért és használati eseteiért tekintse meg a hivatalos bejelentés a Promon honlapján. Egyedi ROM fejlesztők számára megtalálhatja a megfelelő AOSP commitokat a StrandHogg 2.0 támadások megelőzésére itt és itt.
Közzétételi idővonal
Íme a Promon a StandHogg 2.0 dokumentumában megosztott közzétételi idővonal:
- 2019. december 4 – A problémát jelentették a Google-nak
- 2019. december 4 – Megosztott egy PoC „rosszindulatú alkalmazást” és videót a Google-lal
- 2019. december 4 – A Google megerősítette a jelentés kézhezvételét
- 2019. december 9 – A Google a lelet súlyosságát „kritikus”-ra állította
- 2019. december 9 – A Google megerősíti, hogy képesek reprodukálni a problémát
- 2020. február 14 – Tájékoztatjuk a Google-t, hogy március elején közeleg a 90 napos nyilvánosságra hozatal, és státuszukat kérjük az oldalukon
- 2020. február 14 – A Google azt válaszolja, hogy április a leghamarabb, amikor ki lehet javítani
- 2020. február 14 – Tájékoztatjuk a Google-t, hogy dolgozunk az enyhítéseken
- 2020. február 14 – válaszol a Google. Dolgoznak a kárelhárításon, és megkérdezik, megoszthatjuk-e, milyen enyhítéseket javasolunk
- 2020. február 17 – Tájékoztatjuk a Google-t, hogy áprilisig visszatarthatjuk a nyilvánosságra hozatalt. CVE számot kérünk
- 2020. február 17 – Megosztjuk a mérséklési stratégiáinkat, valamint azt, hogy miként képzeljük el a platform mérséklését
- 2020. március 23 – A Google a CVE azonosítóval válaszol (CVE-2020-0096)
- 2020. március 23 – A Google azt válaszolja, hogy a javítás általánosan elérhető Androidra májusban lesz elérhető
- 2020. március 23 – A Google megkérdezi, megfontoljuk-e a közzététel májusra halasztását
- 2020. március 27 – Azt válaszoljuk, hogy májusra halasztjuk a közzétételt
- 2020. április 22 – A Google arról tájékoztat bennünket, hogy a májusi Biztonsági közlemény a tervek szerint tartalmazni fogja a biztonsági rés javítását