Az alábbi cikket Ys. írta a 0x90 blogon, és mivel a cikksorozata kapcsolódik az iPhone-hoz, mi érdekesnek gondoljuk a számotokra is, így ezeket engedelmével egymás után át is emelnénk ide, a Szifonra.
***
A mai rész megint kicsit mesélős lesz, és nem is szorosan véve az alkalmazások biztonságával fogunk foglalkozni, hanem kicsit belenézünk abba, hogy az iOS-ben hol is használnak digitális aláírásokat biztonsági kontrollokként.
Mint sok minden az iOS viszonylatában, ez a témakör is organikus fejlődés eredményeként tart ott, ahol: amikor az Apple 2008-ban kihozta az iOS 2.0-ás verzióját, meghirdetett egy programot, amit Mandatory Code Signingnak kereszteltek el és azóta is központi részét képezi az iOS biztonsági kontrolljainak. Arról van szó, hogy egy alkalmazás telepítéséhez és futtatásához szükséges egy megbízható fél, magyarul trusted party digitális aláírása. Ez a védelem több szinten is megjelenik.
1. Telepítési csomag szintjén.
Amikor az iTunes-ban vagy az iPhone Configuration Utility-ben telepíteni szeretnénk egy alkalmazást, akkor a vonatkozó fájlok felmásolása után az iOS ellenőrzi a telepítő érvényességét. A telepítési csomagban van pár kritikus fontosságú dolog, ezek a következők:
embedded.mobileprovision. A Provisioning Profile leírása egy plist fájlban. Itt találhatóak meg az alkalmazás metaadatai – aláírási szempontból a legfontosabb az, hogy szerepel itt egy lista azokról az eszközökről, amikre fel lehet telepíteni az adott alkalmazást. Amennyiben az eszközünk nincs rajta a listán, nem fogjuk tudni telepíteni.
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN”
“http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>ApplicationIdentifierPrefix</key>
<array>
<string>MCXZR3VWZ</string>
</array>
<key>CreationDate</key>
<date>2011-02-12T22:49:00Z</date>
<key>DeveloperCertificates</key>
<array>
<data>
MIIFbTCCBFWgAwIBAgIITvjgD9Z1rCQwDQYJKoZIhvcNAQEFBQAwgZYxCzAJ…
</data>
</array>
<key>Entitlements</key>
<dict>
<key>application-identifier</key>
<string>MCXZR3VWZ.*</string>
<key>com.apple.developer.ubiquity-container-
identifiers</key>
<array>
<string>MCXZR3VWZ.*</string>
</array>
<key>com.apple.developer.ubiquity-kvstore-
identifier</key>
<string>MCXZR3VWZ.*</string>
<key>get-task-allow</key>
<true/>
<key>keychain-access-groups</key>
<array>
<string>MCXZR3VWZ.*</string>
</array>
</dict>
<key>ExpirationDate</key>
<date>2011-03-12T22:49:00Z</date>
<key>Name</key>
<string>Blah Company Profile</string>
<key>ProvisionedDevices</key>
<array>
<string>227FA72-AA3………..6AAF</string>
</array>
<key>TeamIdentifier</key>
<array>
<string>MCXZR3VWZ</string>
</array>
<key>TimeToLive</key>
<integer>90</integer>
<key>UUID</key>
<string>87C4CE1E-D87B-4037-95D2-8…9246</string>
<key>Version</key>
<integer>1</integer>
</dict>
</plist>
A világ összes UDID-ját nem kell természetesen beütni, ha tetszőleges divájszra szeretnénk feltenni az appunkat – ilyen esetekben az aláírásban ez szerepel:
<key>ProvisionsAllDevices</key>
<true/>
Ilyen aláírást azonban fejlesztő nem tud kiadni – kétféleképpen lehet hozzájutni tetszőleges eszközös provisioning profilhoz: az Apple átnézi és kirakja az AppStore-ba, vagy ha elég nagy cég vagyunk és csatlakoztunk az Enterprise Programhoz – ebben az esetben nem megy ki AppStore-ba az alkalmazás.
_CodeSignature/CodeSignature. Ez pontosan az, amire gondolsz – minden egyes fájlt aláírunk a telepítési csomagban, ezek összegyűjtve benne vannak ebben a plist fájlban.
2. Binárisok szintjén. Binárisokhoz hozzá is lehet fűzni az aláírt entitlementet, ebben az esetben önleíró lesz a móka. Ha nincs ilyen aláírás (vagy nem megfelelő), akkor a kernel egész egyszerűen nem fogja betölteni a binárist és visszautasítja a futtatást. Ha jailbreakelt eszközünk van, az ldid utility segítségével egyszerűen meg lehet nézni a csatolt provisioning profilt:
black-ipad:/var/mobile/Applications/6C1A9DFC-3363-4CB1-A0C5-A5E712E94B28/Blah.app root# ldid -e BlahApp
<?xml version=”1.0″ encoding=”UTF-8″?>
<!DOCTYPE plist PUBLIC “-//Apple//DTD PLIST 1.0//EN” “http://www.apple.com/DTDs/PropertyList-1.0.dtd”>
<plist version=”1.0″>
<dict>
<key>application-identifier</key>
<string>XYZ.Blah</string>
<key>get-task-allow</key>
<false/>
<key>keychain-access-groups</key>
<array>
<string>XYZ.Blah</string>
</array>
</dict>
</plist>
Szemfüles olvasóink most valszeg ráncolják a homlokukat: mi az, hogy a csatolt aláírásban van megadva, hogy mely keychain bejegyzésekhez férhet hozzá a binárisunk? Miért nem tudnánk olyat csinálni, hogy ide beütünk egy *-ot és a binárisunk annyit csinál, hogy szépen kidumpolja a keychaint? Hmmmm… a keychainDumper (azaz kulcskarikadömper) pontosan így működik.
3. Memória szintjén. A digitális aláírás harmadik szintje a memóriába töltött binárisok memóriaterületének aláírását jelenti. A célja annyi, hogy egy hibásan megírt alkalmazás exploitálásával ne tudjon a támadó shellkódot injektálni a memóriába, majd lefuttatni. Hasonló célok ihlették a MCS-t is, mint a DEP-et, viszont a DEP-nél ez a mechanizmus jóval erősebb. A sikeres exploitáláshoz ROP-chaineket kell összelegózni legitim memóriaterületekből – sőt, iOS alatt a egész shellkódot ROP-chainekből kell összerakni, ami nem könnyű általános esetben (understatement warning!). Erről a részről többet nem is mondanék, aki érdeklődik a dolog iránt mélyebben, annak ajánlom Charlie “pwn2own” Miller könyvét.
10 Comments
Nem lenne egyszerubb csak a linket kinthagyni a 0x90-rol? 1-2 elvetemult emberen kivul mast ugysem erdekel, azok meg ugyis olvassak eredetiben odaat…
@dnp:
+1
@dnp: Engem érdekel az iOS App Security sorozat és nem olvasom azt az oldalt ahol eredetileg megjelennek ezek a cikkek.
@hSn0wQ:
Sajnálhatod… Pedig piszok érdekes oldal.
@taky1974: Engem egy kicsit részletesebben érdekel az iOS rendszer.Ennyi.Ne értsd félre én se vagyok annyira kocka,hogy órákig böngésszem ezeket a cikkeket,de azért azt elmondhatom,hogy vannak hasznos részek ezekben a cikkekben.Azért mert téged nem érdekel mert számodra unalmas azért még mást érdekelhet.
@HSn0wQ: +1.
@hSn0wQ:
Értem én az okfejtésed. De szerintem többen olvasnának pl. teljes navi összehasonlító tesztet vagy fotó app összehasonlító tesztet, vagy új iPhone kiegészítőkről írásokat stb…
Egy ilyen cikk kb. tényleg 5 embert érdekel itt. És ez azért van, mert ide felhasználók járnak és nem fejlesztők. Érdemes megnézni az ilyen cikkekhez és egy populárisabb cikkhez a hozzászólásokat. Azt is tudom hogy most uborkaszezon van, de akkor lehetne írni arról hogy kiadták a ML GM verziót vagy más mac-es témát. Na mindegy is, nem én vagyok a fontos.
Tehát nem az írást (ezeket az írásokat) fikázom, mert biztosan nagyon jók. Csak erre az oldalra való átemelését nem értem én sem.
Béke
Felreertesek elkerulese vegett engem is erdekel a tema, meg ha nulla vagyok is objectC-hez. Az eredeti oldalon szoktam olvasgatni a postokat, de szerintem nem idevaloak.Viszont irhtanatok pl C64 assemblyrol 🙂 Most annak kezdtem neki, egesz jo kis efekteket osszehoztam benne a heten. Vegulis van C64 emu iOS ala, szal kb annyira idevag mint az aktualis cikk 🙂
@dnp: Hát azért azt vitatnám,hogy nem kapcsolódik a cikk az iPhone-okhoz.Én örülök,hogy itt is megjelennek ezek a cikkek.Ez a “C64 assemblyrol” nem tudom micsoda.Lehet,hogy én szívesebben olvasom ezt. 😉 De vesszünk már össze azon,hogy kinek mi az iPhone-os téma.
@taky1974: Én sem vagyok fejlesztő.(Illetve szeretnék csak hát egyáltalán nem egyszerü a történet…) Szóval én is szimpla paraszti júzerként mondom a magamét.A Mountain Lion GM-ről írt már a szifon.Számomra érdekesebb témák azok amiket az iOS App Security sorozatban írnak mint a navi meg a többi,de ezen nincs értelme összeveszni.
“Béke” -nem tudtam,hogy haragban vagyunk. 😀
@taky1974: @dnp: Egyébként vendég bloggerként nektek is lehetőségetek van arról írni ami szerintetek klappol.
@taky1974: Mountain Lion és más Mac-es dolgok: azokra meg a PC-s kollégák nyávognak, hogy minek, hiszen nekik nem fut a gépükön, sem az iPhone-jukon. de egyébként ez egy iPhone-os blog, így a Mac-es hírekből maximum az az érdekes, ami az iOS-hez is kapcsolódik. a fontosabb dolgokat azért eddig is megírtuk szerintem.