fbpx Skip to content

Mivel az iOS-t futtató eszközökre jóformán alig van bármi kártevő, így amennyiben valami mégis felbukkan, azt azonnal felkapja a média. November 7-én írtunk a WireLurker névre keresztelt trójairól, ami kifejezetten a Mac-es alkalmazások (elsősorban kínai) warezolóit célozta meg. Most egy újabb lehetséges veszélyforrás került elő, aminek a FireEye mobil biztonsági szakértői a Masque Attack nevet adták.

adat_biztonsag

A kutatók már 2014 júliusában felfedezték, hogy ha egy alkalmazás enterprise vagy ad-hoc provisioning segítségével kerül telepítésre a készülékre (tehát nem az App Store-ból, hanem belső intranetről például, vagy mondjuk a TestFlight segítségével), akkor az képes felülírni a készüléken egy, az App Store-ból származó, eredeti verziót is, amennyiben mindkét app esetén ugyanaz a bundle azonosító. Ennek következtében ha egy csalogató szövegű app megvezeti a felhasználót, és az illető annak telepítését jóváhagyja, az gyakorlatilag bármely, az App Store-ból letöltött appot képes felülírni. Ennek az az oka, hogy az iOS nem követeli meg, hogy az azonos bundle azonosítóval rendelkező appok esetén a tanúsítványuk is egyezzen. A kutatók ennek a hibának a meglétét egészen a 7.1.1-ig visszamenően igazolni tudták, és ez még megvan a 8.1.1 beta 1 esetén is, függetlenül attól, hogy a készülékek jailbreakelve vannak-e vagy sem, és a hiba kihasználható nem csak USB-n, de akár az interneten keresztül is.

A kutatók már július 26-án értesítették felfedezésükről az Apple-t. Amikor megvizsgálták a napokban felkapott, de már szintén korábban felfedezett WireLurker működését, azt találták, hogy a WireLurker gyakorlatilag egy korlátozott formája a Masque Attacknak, ami USB-n keresztül támadja meg a készülékeket egy fertőzött számítógépről. Ezzel szemben viszont a Masque Attack képes akár az interneten keresztül is kifejteni “jótékony hatását”, már feltéve, hogy a felhasználó nem elég elővigyázatos. Előfordulhat például, hogy egy banki appot másolnak le, megtartva annak funkcióit és kinézetét – mindössze beépítve azt a pluszt, amivel ellophatják a banki adatait. Mivel a két app bundle azonosítója megegyezik, az iOS azt gondolja, hogy ez az adott app új verziója, és így az alkalmazás helyi adatait sem törli, hiszen egy-egy app frissítésekor is megmaradnak annak adatai. Ezek az adatok viszont szinte bármit tartalmazhatnak, kezdve a gyorsítótárba letöltött emailektől egészen akár a login tokenekig, így a malware már be is tud lépni az adott fiókba a felhasználó adataival.

A kutatók ráadásul már arra is találtak bizonyítékot, hogy az ilyen típusú támadások elkezdtek terjedni, így fontosnak tartották tájékoztatni a közvéleményt.

Biztonsági problémák

A Masque Attack segítségével a támadó egy csalogató névvel (például “New Flappy Bird”) ráveheti az áldozatot arra, hogy feltelepítse a támadó által elkészített appot, és az iOS felül fogja írni azt, az App Store-ból letöltött appot, ami a támadó alkalmazásával azonos bundle azonosítóval rendelkezik. A Masque Attack nem képes felülírni a gyári appokat, de az App Store-ból származóak közül viszont bármelyiket. Ennek az alábbi következményei vannak:

  1. A támadó lemásolhatja az eredeti app bejelentkezési felületét, ezzel el tudja lopni a felhasználó bejelentkezési adatait. A kutatók már több email vagy banki app esetén találtak erre példát, amikor a malware ugyanazt a felhasználói felületet használja, amit az eredeti, így verve át a felhasználót, hogy megadja a valós bejelentkezési adatait, majd ezeket fel tudja tölteni egy távoli szerverre.
  2. Szintén problémás, hogy az eredeti app adatai megmaradtak. Ennek a fentebb már említett oka, hogy az iOS az adott app frissítésének tekintheti az így települő verziót, és ugye frissítéskor nem fogja törölni az adatokat. Így egy adott alkalmazás a készülékre letöltött emaileket is képes feltöltei egy távoli szerverre.
  3. Az MDM (Mobile Device Management) interfész nem képes megkülönböztetni a malware-t az eredeti apptól, hiszen azoknak egyezik a bundle azonosítója. Jelenleg nincs olyan MDM API, ami lekérdezhetné és visszaellenőrizhetné egy-egy app tanúsítványát, így meglehetősen nehéz az MDM számára az ilyen támadások felismerése.
  4. Mivel az enterprise provisioning segítségével terjesztett appokat az Apple nem ellenőrzi, így a támadó olyan privát API-kat is használhat, amikre az App Store jóváhagyási folyamata miatt nem lenne lehetősége. Ilyen lehet a háttérben való figyelés (background monitoring, CVE-2014-1276), vagy mondjuk az iCloud felületének imitálása, hogy ellopja a felhasználó Apple ID-ját és jelszavát.
  5. A támadó egyúttal kikerülheti az iOS beépített sandboxingját, és root jogot szerezhet, amennyiben ismert sebezhetőségeket is kihasznál, mint például azt, amit a Pangu fejlesztői is felhasználtak a jailbreakhez.

Példa

A kutatók az egyik kísérletben egy belső alkalmazást használtak, aminek a bundle azonosítójának a com.google.Gmail-t adták meg, de csalogatónak a “New Flappy Bird” volt a beugratós üzenetben. Ezt az appot egy enterprise tanúsítvánnyal írták alá, és amikor a teszt készülékre az feltelepült, felülírta az App Store-ból származó, eredeti Gmail appot.

Masque_Attack

A fenti ábrán látható az egész folyamata. Az (a) és (b) képen látható, hogy az eredeti Gmail app telepítve van a készülékre, és 22 olvasatlan üzenet van. A (c) azt mutatja, hogy az áldozat beugrott a csalinak, és telepíti a kutatók által elkészített “New Flappy Bird” nevű alkalmazást a weboldalról. Itt érdemes megjegyezni, hogy a “New Flappy Bird” név egy olyan változó, amit a támadó maga adhat meg, amikor előkészíti az appot. Ugyanakkor ez az app a com.google.Gmail bundle azonosítóval rendelkezik.

Amint az áldozat rányom a Telepítés (Install) opcióra, a (d) képen látható, hogy az előkészített app felülírja a készüléken lévő Gmail appot a telepítés során. Ennek végeztével az “új” Gmail appot megnyitva az áldozat bejelentkezik, és egy, a Gmail appal megegyező felület fogadja, itt most a próba kedvéért azonban még ott szerepel, hogy “yes, you are pwned”, vagyis hogy “igen, fel vagy törve”. A támadók azonban nem lesznek ilyen jó fejek, nem fogják elárulni magukat. Eközben pedig az új app hozzáfér a Gmail app által létrehozott fájlokhoz, így az abban letöltődött emailjeink sqlite3 adatbázis-fájljához, amit fel is tud tölteni egy távoli szerverre, és amit utána egy sqlite böngészővel már meg is lehet nézni közelebbről:

Masque_Attack_sqlite

Elsőként lássuk egy videóban is ennek a működését, aztán pedig nézzük meg azt, hogy hogyan lehet védekezni ellene.

Hogyan lehet védekezni?

A felhasználók viszonylag egyszerűen kivédhetik az ilyesmit, ha az alábbi három dolgot betartják:

  1. Ne telepítsünk alkalmazásokat az App Store-on, vagy mondjuk a TestFlighton (vagy más, megbízható helyen) kívülről;
  2. Ne nyomjunk rá ismeretlen weboldalakon előugró, telepítést felajánló üzenetekre – lásd a fenti ábrán a (c) képet, függetlenül attól, mit állít az az adott appról. A támadók nyilván olyan neveket fognak itt használni, ami vonzó lehet. Ne ugorjunk be ezeknek.
  3. Ha egy alkalmazás megnyitásakor az iOS feldob egy figyelmeztetést (lásd alább), hogy az adott alkalmazás egy nem megbízható fejlesztőtől származik, akkor azt ne fogadjuk el, hanem kattintsunk a Nem Megbízható (Don’t Trust) opcióra, és azonnal töröljük le az adott appot.

Masque_Attack_trust

Annak ellenőrzéséhez, hogy esetleg vannak-e már ilyen alkalmazások a készülékünkön, menjünk a Beállítások (Settings) appban az Általános (General) menüpont alján a Profilok opcióhoz. Ha nincs ilyen opció, akkor nincsenek telepített profilok sem. Amennyiben itt olyan profilt találunk, amit semmihez sem tudunk kötni, azt érdemes törölni.

Itt elsősorban ismét a tört appokat telepítők találkozhatnak különböző profilokkal, és nekik már saját felelősségük eldönteni, mit akarnak kezdeni ezzel a helyzettel, de ahogyan fent is látható, még akár az általuk megbízhatónak gondolt appokat is lecserélhetik a támadók valami egészen másra.

Olvasd el a hozzászólásokat is

7 Comments

  1. Ezért ne telepítsünk az App Storon kívül sehonnét

  2. Ismét egy olyan veszély, ahol maga a felhasználó a veszély. Majd ha olyan jön, amihez nem kellek, elkezdek aggódni.

  3. Itt ragadnám nem a lehetőséget, hogy felfedjem a Hammer Attack nevű veszélyt is. Itt, a figyelmetlen és a szövegeknek bedőlő felhasználóval azt hitetik el, hogy a honlapot két percig a képernyőn hagyva, az iPhone-t törhetetlenné teszi. A hiszékeny felhasználó ilyen esetekben -a leírás ellenére- betöri a telefonja képernyőjét az “5. lépés: tegyünk próbát egy vasúti kalapáccsal” utasítást követve.
    Természetesen itt is kell a felhasználói közreműködés, de jól rávilágít, hogy milyen sérülékeny a készülékünk, amennyiben nem figyelünk oda használat közben.
    A dolog ellen úgy védekezhetünk, hogy az 5. lépést nem olvassuk el.

  4. De akkor ezzel azt is meg lehet csinálni, hogy egy nem jb-s eszközre letöltök egy gagyi ingyen letölthető appot, majd az azonosítóját kihasználva feltelepíttetek vele egy x eurós tört appot az ingyenes helyére, hiszen felülirja a fájlokat. Hoppá 😀 . Tudom, sajnos nem erre fogják használni 🙁 .

  5. @dundiego: ezt csak akkor tudnád megtenni, ha az adott appot aláírnád egy enterprise tanúsítvánnyal, vagy mondjuk a készülék UDID-jét ismerve célzottan csak ahhoz, egy egyszerű fejlesztői tanúsítvánnyal. aláírás nélkül a jailbreak nélküli eszközre nem fog települni. (amikor valaki jailbreak nélkül warezol, voltaképpen épp ezt teszi, egy enterprise tanúsítvánnyal aláírt appot telepít fel, de ugye fennáll annak az esélye, hogy az adott app nem pont az, aminek látszik.)

  6. Köszi. Tehát akkor csak az apple által engedélyezett enterprise hálózatok álltal kínált appok a potenciális veszélyforrások? Gondolok én: mail kliensek, ent. applikációk (például nálam m*bile@w*rks -mobileiron-on belül telepíthető appok), naptár, dokumentum kezelő alkalmazások. Játékok nem, hiszen melyik cég vesz ent. licenszt játékokhoz az alkalmazottaknak. És gondolom az a legnagyobb gond itt az, nem úgy mint anno a BB esetén, itt nincs olyan, hogy be-/ vagy kikapcsolt vállalati aktiválás.

  7. Sziasztok!A HaoXuan profile az nem tudjátok mi?Nem találom a neten…..


Add a Comment