Így működik a kiskapu az alkalmazáson belüli vásárlásoknál
Így működik a kiskapu az alkalmazáson belüli vásárlásoknál (c) IDG/Apple
Egy orosz hacker néhány hete talált egy lyukat az App Store-ban, és fizetős alkalmazáson belüli funkciókat ingyen letölthettek.
Az orosz hacker Alekszej Borodin saját szerverét online tette egy alkalmazáson belüli vásárlási szolgáltatással. A felhasználóknak csak le kellett tölteniük a mellékelt tanúsítványokat, és telepíteniük őket az iPhone-ra, és az ingyenes üzlet felé nyitva állt az út. Az Apple meglepően gyorsan reagált a sebezhetőségre, és néhány nap múlva kiadott egy eszközt a fejlesztőknek és egy frissítést az iOS 6-hoz. Az iPhone gyártója azt állítja, hogy a hiányt véglegesen lezárják az iOS 6-tól.
A hacker néhány nappal ezelőtt újra megszólalt, és lépésről lépésre közzétette a hackelésre vonatkozó utasításokat, beleértve a szerver kódját is. Az információ immár ártalmatlan, mivel a hackelés már nem működik, de érdekes betekintést nyújt az Apple szerverek, a fejlesztők szerverei és az iPhone közötti kommunikációba.
Alkalmazáson belüli vásárlás esetén az iPhone többször kommunikál az Apple szervereivel. Az iTunes külön szerverének (buy.itunes.apple.com) kérésével az iPhone információkat továbbít az alkalmazásból, például az alkalmazás azonosítóját, verziószámát, gyártóját és az iPhone GUID/UUID azonosítóját (globálisan egyedi azonosító vagy egyetemesen egyedi azonosító). . A válasz a jól ismert vásárlási visszaigazolás „Szeretne Y euróért vásárolni az X alkalmazást?” Úgy néz ki, hogy az iPhone képernyőn két gombbal rendelkező kérdés lényegesen több paramétert tartalmaz bontott formában. Például az egyedi iTunes Adam ID - nyolc- vagy kilencjegyű azonosító szám az iTunes összes alkalmazásához -, valamint az ár, a verziószám, a gyártó és hasonlók. Borodin arról számolt be, hogy tesztjein a legtöbb alkalmazás képes volt figyelmen kívül hagyni az iTunes azonosítót. Más szavakkal, az iTunes vásárlási visszaigazolási kérelme szinte ugyanazokat az információkat tartalmazza, amelyeket az iPhone már elküldött a szervernek. Az új információkat, például az Adam ID-t egyszerűen figyelmen kívül hagyják.
A vásárlási folyamat következő lépése: a felhasználó a "Vásárlás" gombra kattintva elküldi az igazolást az iTunes-nak. Az App Store minden egyes alkalmazás letöltésekor engedélyt kér. A felhatalmazás során Borodin szerint bizalmas adatokat, például Apple ID-t és jelszót küldtek az iPhone-tól egy titkosítatlan plist fájlban. Elméletileg itt egy újabb biztonsági rés nyílik meg: Mivel az iPhone és az App Store közötti adatátvitel többnyire vezeték nélkül működik, a bűnözők számára meglehetősen könnyű bármikor megszerezni az érzékeny hozzáférési adatokat.
Számlainformáció
appleId apleid
fiók gyermek 0
cím
keresztnév Keresztnév
vezetéknév Vezetéknév
passwordToken Jelszó token (15 percig érvényes)
clearToken token (15 percig érvényes
dsPersonId Az Ön személyi igazolványa
creditDisplay
creditBalance 1311811 (iTunes-jóváírás)
freeSongBalance 1311811 (valószínűleg az iTunes Match számainak száma)
A biztonsági rés érvényesítési tanúsítványa
A következő néhány lépésben az App Store ellenőrzi a vásárlást és azt, hogy az alkalmazás megérkezett-e az iPhone készülékre. Ehhez digitális vásárlási visszaigazolást küld, amely általános információkat tartalmaz az alkalmazásról, valamint további információkat a vásárlás dátumáról, a tranzakció számáról és a vásárlás érvényesítési tanúsítványáról. Az érvényesítési tanúsítványban Borodin megtalálta a kulcsfontosságú sebezhetőséget, amelyet a hackeléshez használt. A korábbi verzióban az App Store a teljes fájlcsomagot, vagyis a tanúsítványt a kulccsal együtt szállította. A tanúsítvány elrendezése a következőképpen néz ki:
VÉTEL VÁLTOZATA ALÁÍRÁS | TANÚSÍTVÁNY MÉRETE BIZONYÍTVÁNY
1 bájt 128 4 bájt ...
A szokásos titkosítási módszerekkel, például e-mailekkel a feladó az elektronikus leveleket a kiadott tanúsítványukkal együtt küldi el. A címzettnek van egy titkos kulcsa a visszafejtéshez. Ha a tanúsítvány és a kulcs egyezik, a címzett olvasható formában kapja meg az adatokat. A bűnözőknek alig van lehetőségük az adatok dekódolására az érvényes kulcs nélkül, még akkor is, ha sikerült elérniük a nyers adatokat.
Borodin kihasználta ezt a logikai hibát az Apple részéről: Az iPhone által elérhetővé tett DNS-beállításokat nem az App Store-ba, hanem egy másik szerverre irányították át. A proxy szerver hamisított tanúsítványokat adott ki az App Store számára ugyanazzal a felépítéssel, mint az eredeti tanúsítvány. Mivel az iPhone kulcsai szintén a hackertől származnak, a tanúsítvány és a kulcs természetesen megegyeztek, és az App Store a vásárlást érvényesnek tekintette.
A hacker ajánlásokat is ad arra vonatkozóan, hogy az alkalmazásfejlesztők hogyan kerülhetik el az ilyen behatolásokat a jövőben. Egyrészt az Apple szállítja az úgynevezett ellenőrzési vezérlőt - egy további sort a vásárlás visszaigazoló kódjában. Ezenkívül Borodin azt javasolja, hogy ellenőrizze a vásárlás visszaigazolásában szereplő összes információt, beleértve az iTunes azonosítót is. Azokat az alkalmazásokat, amelyek megvásárlását a külső fejlesztői szerveren is megvizsgálták saját tanúsítványaikkal és kulcsaikkal, nem érintette a feltörés. Ez is hatékony védelem az ilyen betörések ellen.