Még 2014 novemberében bukkant fel a Masque Attack névre keresztelt sebezhetőség: egy megfelelően előkészített app letöltés közben felülírhatott a készüléken egy másik appot. A letöltésre való csábítás pedig érkezhetett üzenetben, emailben, vagy akár egyszerűen csak webböngészés közben.

Akkor a sebezhetőség felfedezői, a FireEye szakértői tájékoztatták a részletekről az Apple-t, összesen öt biztonsági problémát jelentve feléjük, melyekkel négy különböző típusú támadás volt végrehajtható. Az időközben megjelent iOS 8.1.3 már javította ezek egy részét, de nem maradéktalanul – így a szakértők most az iOS URL-sémák kezelési hibájára mutatnak rá, amely jelenleg is megvan.

Az iOS esetén az URL-sémák lehetővé teszik, hogy az egyes appok másik appokkal tudjanak komunikálni: a legegyszerűbb példa erre, hogy mondjuk a Facebook Messenger esetén ha valaki profiljára nyomunk rá, akkor az átugrik a Facebook appba, és ott nyitja meg az illető profilját – vagy ugyanígy az üzenetekre nyomva átdob minket a Messengerbe.

A sebezhetőséget itt az jelenti, ha szándékosan olyan URL-sémát ad meg a támadó az általa előkészített appban, amelyet más app már használ, mert így a támadó app képes ellopni az eredeti apptól a kommunikációt, és ezzel megszerezheti például a felhasználóneveket és jelszavak. Ami ráadásul még problémásabb, hogy az első Masque Attack-kal szemben a Masque Attack II már az App Store-ba beküldött appon keresztül is végrehajtható lehet.

A megbízhatósági jóváhagyás kikerülése

Amikor a felhasználó első alkalommal nyom rá egy enterprise tanúsítvánnyal aláírt appra, az iOS rákérdez, hogy a felhasználó megbízhatónak tartja-e az adott aláírót, és az app addig nem indul el, amíg a felhasználó azt megbízhatónak nem jelöli:

Az Apple erre természetesen azt javasolta védekezésként, hogy ilyenkor a felhasználó nyomjon a “Don’t Trust” (Nem Megbízható) opcióra. Csakhogy kiderült, hogy ez sajnos nem elegendő.

Az iOS ugyanis akkor nem kér ilyen jóváhagyást, ha az enterprise tanúsítvánnyal aláírt appot egy URL-séma segítségével hívjuk meg. Sőt: az sem számít, ha korábban a felhasználó elutasította az app indítását a Nem Megbízható (Don’t Trust) opcióra nyomva, az iOS az URL-séma használatával ekkor is elindítja az adott appot, jóváhagyás nélkül is. Más szóval ez azt jelenti, hogy ha a felhasználó rányom egy linkre, amit mondjuk üzenetben, az iOS Mail appjában, vagy a Gmail appban kapott, az iOS elindítja a kívánt appot anélkül, hogy a felhasználó jóváhagyását kérné, és egyben a korábbi elutasítást is teljességgel figyelmen kívül hagyja, amivel így olyan app is elindítható lehet, ami tartalmazza a Masque Attack támadást.

A támadó tehát összeállíthat és közzétehet egy olyan, enterprise tanúsítvánnyal aláírt appot, amely más, népszerű appok URL-sémáját regisztrálva a rendszerben, képessé válik azok kommunikációját ellopni, és azok felületét utánozva adathalász módon begyűjtheti a felhasználó bejelentkezési azonosítóit, stb. Az iOS nem védi meg tehát ettől a támadástól a felhasználót, hiszen az URL-sémák használatával olyan app is lefut, ami esetén a felhasználó előzetes hozzájárulása lenne egyébként szükséges, a rendszer azonban ezt mégsem kéri.

A FireEye-os kollégák persze egyéb módszereket is találtak arra, hogy kikerülhető legyen a jóváhagyás, amiket jelentettek is az Apple-nek, és a 8.1.3-ban azokat javította is a cég, ugyanakkor az App Store statisztikái alapján az összes eszköz 28%-án még iOS 7 vagy korábbi rendszer fut, amelyek viszont továbbra is érintettek, azokról nem is beszélve, akik még nem frissítettek a 8.1.3-ra bármely egyéb okból.

Az alábbi videóban a szakértők ezt a problémát mutatják be konkrét példákkal:

URL-séma hijacking

Az iOS Developer Library szerint: “If more than one third-party app registers to handle the same URL scheme, there is currently no process for determining which app will be given that scheme”, vagyis ha a külső fejlesztők appjai közül egyszerre több is ugyanazt az URL-sémát regisztrálja, akkor jelenleg nincs lehetőség kideríteni, hogy melyik app kapta meg az adott URL-sémát. Ugyanakkor ha két app ugyanazt az URL-sémát regisztrálja, az iOS mindig ugyanazzal az appal szolgálja ki az adott sémát, függetlenül az iOS-verziótól és készüléktípustól. Ezen túl egy app így képes blokkolni egy másikat egy adott URL-séma kiszolgálásában, ha a fejlesztő megfelelő bundle id-t használ.

Például a BASCOM Anywhere Filter Browser és a Chrome – web browser by Google is ugyanazokat az URL-sémákat (googlechrome:// és googlechromes://) regisztrálják. Ha mindkét app telepítve van a készüléken, akkor ha Safariban a felhasználó ilyen URL-sémával ellátott linkre kattint, az iOS 8.1.3-at futtató eszköz a Chrome helyett a BASCOM appot indítja el.

A támadónak két lehetősége van: vagy közzétesz egy olyan appot az App Store-ban, ami így “ellopja” egy másik app URL-sémáját, vagy ugyanezt teszi, de az appot egy enterprise tanúsítvánnyal írja alá, és az App Store-on kívül terjeszti (ahogyan azt több tört app esetén is csinálják).

A második videó ezt mutatja be:

Hogyan lehet védekezni?

Ismét viszonylag egyszerűen kivédhetjük az ilyesmit, ha az alábbi három dolgot betartjuk:

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, 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, 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.

Amennyiben nem töröljük le az ilyen appot, úgy a fentiekben leírtak alapján az még akkor is elindulhat, ha nem hagytuk jóvá a tanúsítványát és a futtatását.