A neves jailbreakfejlesztő és biztonsági szakértő, Cyril Cattiaux, közismert nicknevén @Pod2G, közzétett egy cikket, amiben elmondja, hogy az iMessage protokoll nem is annyira biztonságos, ahogyan azt az Apple állítja. Nevezetesen mind az Apple, mind egy, a készülékünkhöz fizikailag hozzáférő támadó olvasni és módosítani tudja az üzeneteinket.

A Hack In The Box elnevezésű IT-biztonságtechnikai konferencián tartott előadás anyagában Pod2G elmondja: ő és csapata nem állítják, hogy az Apple elolvassa az iMessage-einket, csupán azt, hogy erre neki (és másoknak) lehetősége van. Szerintük a legvalószínűbb, hogy erre csak akkor kerülne sor, ha az Apple-t erre utasítanák (például az amerikai kormány vagy egyéb jogi szervezetek – az NSA-botrány óta mindenki erre gondol elsősorban).

Mit csinálsz, Apple? Avagy egy biztonsági intézkedés hiánya

Készült egy videó is, amiben a hackerek bemutatják, hogy nemcsak az Apple, de elvileg bárki, aki egyszer hozzáfért a készülékünkhöz, elolvashatja és megváltoztathatja az iMessage-ek tartalmát. A támadás – nagyon leegyszerűsítve – annyiból áll, hogy magukat az Apple szervereinek kiadó, „hamis” kulcsokat és aláírásokat telepítenek az iPhone-ra vagy iPadre. A sebezhetőség lényege, mondják a szakértők, az úgynevezett „certificate pinning” technológia hiánya. Ez azt jelenti, hogy a protokoll bármilyen olyan SSL-tanúsítványt érvényesnek fogad el, amit egy ismert (ebben az esetben hamisított és a készülék Keychain-jéhez adott) tanúsítványkiállító (Certificate Authority, CA) adott ki (és azokat a tanúsítványokat is érvényesnek tekinti, amelyeket ezzel a hitelesnek vélt tanúsítvánnyal írtak alá). A certificate pinning technika alkalmazása esetén csak konkrét tanúsítványokat fogad el a rendszer, tehát nem az aláíró személye és identitása számít, hanem csak az, hogy egy bizonyos tanúsítványról már eldöntöttük-e egyszer, hogy érvényes.

A hamisítást egyébként az Apple által kiadott iPhone Configuration Utility nevű alkalmazással végezték. Ennek a programnak a használatakor amikor egy készüléket első alkalommal csatlakoztatnak a számítógéphez, akkor az automatikusan rátölt egy új CA-t. Ennek az a további, „érdekes” következménye, hogy egy olyan cégnél, ahol külön IT-csoport felügyeli az iOS-készülékeket, az első használat előtt be tudnak állítani egy proxy-t, és ezzel le tudják hallgatni a készülék teljes internetes forgalmazását…

Az iMessage lehallgatása

Az Apple azt állítja, hogy az iMessage egy, az elejétől a végéig titkosított („end-to-end” titkosítással rendelkező) csatorna, ezért az üzeneteinket sem az Apple, sem egy jogosulatlan kívüálló nem tudja olvasni. Ez azonban nem igaz: a teljes titkosítás ellenére is lehetséges a fent leírt támadás.

Amikor a biztonsági szakértők kicsit mélyebbre ásták magukat a protokollba, néhány kellemetlen meglepetés érte őket. Az SSL-en keresztülmenő adatok tartalmazzák a küldő fél Apple ID-ját és a hozzá tartozó jelszót. Igaz, hogy az SSL protokoll ugye titkosítva van, de azon belül miért kell vajon plaintextben küldeni a jelszót? Az azonosításhoz elég lenne egy hash is. Íme, egy ehhez hasonló property list fájlt küld a Messages alkalmazás az Apple-nek (nyilván az adatok itt a példában nem valódiak):

<?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>password</key>
    <string>Icandoaproperkeynote</string>
    <key>username</key>
    <string>tim_c@icloud.com</string>
</dict>
</plist>

A protokollok: a kliens, a Push és az ESS-szerverek

Az iMessage-üzenetek a Push protokollon keresztül jutnak el a feladótól a címzetthez. A protokoll TLS-alapú (tehát titkosított), az 5223-as porton át folyik, és az adatokat a [0…255]-courier.push.apple.com szerverek valamelyike továbbítja. A hitelesítéshez egy úgynevezett klienstanúsítványt („client certificate”-et) használnak. Ez a tanúsítvány nagyon érzékeny, mert minden Push-kommunikációt ezzel írnak alá. A klienstanúsítványt az Apple (az albert.apple.com című szerveren lévő „Apple iPhone Device CA” nevű certificate authority) állítja ki akkor, amikor a készüléket aktiválják.

A rendszer szerveroldali működését csak az Apple ismeri, viszont a kliensoldalon is sokmident figyelhetünk meg. Üzenetküldéskor a Messages alkalmazás az Apple ESS szerveréről kér le néhány adatot: egy úgynevezett „Push-Token”-t és két titkosítási kulcsot.

A Push-Token egy készülékpárhoz (feladó és címzett) tartozó egyedi azonosító, ami autentikációs és útválasztási (routing) információt is tartalmaz. Generálási algoritmusát ismét csak az Apple tudja, mint ahogyan a pontos felhasználás módját is. Egy érdekesség mindenesetre a kliensoldalról is látszik: a Push-Token egyetlen készülékpárhoz tartozik. Ha tehát a címzettnek több iMessage-képes készüléke van ugyanahhoz az Apple ID-hoz rendelve, akkor mindegyikre külön-külön elmegy az üzenet, így – gyakorlatilag – egy gombnyomással több üzenetet is küldünk. Az üzenetek a fent már ismertetett módon az Apple Push Notification Service (APNS) nevű szolgáltatáson keresztül mennek el. Íme az OS X-en futó iMessage alkalmazás hálózati forgalmazása:

root@joker:~>> ps aux |grep apsd
root 90 0.0 0.1 2467868 8052 ?? Ss Thu09AM 0:06.06 /System/Library/PrivateFrameworks/ApplePushService.framework/apsd
root 20295 0.0 0.0 2432768 588 s003 S+ 3:08PM 0:00.00 grep apsd

root@joker:~>> lsof -p 90 |grep TCP
apsd 90 root 9u IPv4 0x667b30bc14a94f93 0t0 TCP joker.lan:65158->17.172.232.179:5223 (ESTABLISHED)

root@joker:~>> whois 17.172.232.179
NetRange:       17.0.0.0 - 17.255.255.255
CIDR:           17.0.0.0/8
OriginAS:
NetName:        APPLE-WWNET
NetHandle:      NET-17-0-0-0-1
Parent:
NetType:        Direct Assignment
RegDate:        1990-04-16
Updated:        2012-04-02
Ref:            http://whois.arin.net/rest/net/NET-17-0-0-0-1
OrgName:        Apple Inc.
OrgId:          APPLEC-1-Z
Address:        20400 Stevens Creek Blvd., City Center Bldg 3
City:           Cupertino
StateProv:      CA
PostalCode:     95014
Country:        US
RegDate:        2009-12-14
Updated:        2011-03-08
Ref:            http://whois.arin.net/rest/org/APPLEC-1-Z
...

(Az első sorban látható apsd program a készüéken vagy a számítógépen futó Push daemon.)

Habár a Push hivatalos dokumentációjából nem derül ki, kicsit a sorok között olvasva arra a következtetésre juthatunk, hogy a készülékek folyamatos kapcsolatban vannak az APNS-szerverrel, ezért lehetséges egy-egy Push-Token segítségével eldönteni, hogy mely eszközökre kell elküldeni az üzeneteket.

Man in the middle

A Man-in-the-middle típusú támadás végrehajtásához először is – a már említett módon – hozzá kell adnunk a készüléken lévő Keychainhez egy Certificate Authority-t, hogy egy proxy-szerverre irányíthassunk át minden, a hálózaton átmenő adatot. Továbbá, mivel a hitelesítés kétoldli (tehát nemcsak az Apple szerverei ellenőrzik a készülék identitását, hanem fordítva is), ezért a Push-szerverekkel is el kell hitetnünk, hogy a „proxy valójában a készülék”. Ezt úgy oldjuk meg, hogy kibontjuk a készülék által küldött adatokból a Push-tanúsítvány privát részét, és azt telepítjük a proxy-ra is.

Így már nem nehéz lehallgatni a kommunikációt. Amit találtunk:

0a                    >> Message Type
XX XX XX XX           >> Next Length
04 00 04 XX XX XX XX  >> Identifier (4 bytes)
01 00 14 XX .. .. XX  >> Topic Hash (20 bytes)
02 00 20 XX .. .. XX  >> Push-Token (32 bytes)
03 XX XX ...          >> iMessage payload

(az XX-szel jelölt bájtok változnak, mert az üzenet hosszától és tartalmától függenek.)

Mivel a kommunikáció az elejétől a végéig titkosított, a titkosítási kulcsokat a felek vagy közvetlenül eljuttatják egymáshoz, vagy létezik egy úgynevezett „kulcskönyvtár” (key directory), ahol ezeket biztonságosan tárolják, és hitelesítés ellenében kiadják. Valóban, az Apple-nek léteznek úgynevezett ESS-szerverei (maguk a hackerek sem tudják, mit jelenthet ez a rövidítés), amik kulcskönyvtárként működnek. Üzenetküldéskor tehát a Messages app először ide küld egy lekérést, a következő formátumban:

GET /WebObjects/QueryService.woa/wa/query?uri=tel:+33123456789
'Host': service1.ess.apple.com
'Content-Type': application/x-apple-plist
'x-id-cert': [Provision Certificate]
'x-id-nonce': [Random Nonce with Timestamp]
'x-id-sig': [Query Signed with Provision Cert.]

Láthatjuk, hogy itt a +33123456789 URI-hez (ez egy Apple ID-hoz kötött (készülék)azonosító, ami lehet telefonszám vagy e-mail cím is) kéri a kulcsokat. Ez a lekérés szintén titkosított, és egy Provision nevű certificate-tel van aláírva. A Provision tanúsítványt pedig egy Apple IDS Realm CA nevű tanúsítványhatóság írja alá. Ez egy hónapig érvényes.

A szerver válasza egy XML property list, amit a könnyebb olvashatóság kedvéért JSON-ra konvertáltunk nektek:

{
  'push-token': [PushToken]
  'client-data':
  {
    'show-peer-errors': True,
    'public-message-identity-version': 1.0,
    'public-message-identity-key': [Public Keys Buffer]
  }
}

Minden egyes Push tokenhez tartozik egy ugyanilyen válasz. A két, már fentebb említett nyilvános kulcs egyike az ECDSA, egy 256-bites kulcs, ami a címzett válaszát hivatott ellenőrizni. A másik egy 1280-bites kulcs, ami a kimenő üzenetet kódolja.

A ténylegesen elküldött adat ismét egy property list, ezúttal bináris formában. A következő kulcs-érték-párokat tartalmazza:

D:   True
E:   'pair'
P:   <variable length binary data> (iMessage payload, deflate compressed)
U:   <128bit binary data> (iMessage UID)
c:   100
i:   <32bit integer> (messageId, same as in PUSH header)
sP:  mailto:tim_c@icloud.com  (sender URI)
t:   <256bit binary data> (sender Push-Token)
tP:  mailto:mark_z@facebook.com (receiver URI)
ua:  [Mac OS X,10.8.5,12F37,MacBookPro10,2] (sender OS and hardware version)
v:   1

A „P” mező a tényleges iMessage payload. Ez titkosított és tömörített (igen, először titkosított, és csak azután tömörített…). A következő információ található benne:

(byte)     0x02          version?
(short)    ciphertext    length
(data)     ciphertext    RSA / AES-CTR data : ciphered with the RSA public key of the recipient
(byte)     signature     length
(data)     signature     ECDSA signature of <ciphertext> : computed with the ECDSA private key of the emitter

A titkosítást feloldva újabb property list fájlt kapunk:

p: array of URIs in the discussion group
t: iMessage text (for iOS)
v: version (1)
x: iMessage html (attachments, and style - for OS X)

A tényleges támadás

A man-in-the-middle támadás esetén a „középen” lévő ember háromféleképpen helyezkedhet el: vagy a küldő és a Push-szerver között, vagy a Push-szerver és a címzett között, vagy mindkét helyen egyszerre.

Álljon még itt egy pár kép arról, hogy mit is lehet elérni az egyes támadástípusok esetén:

Itt a támadó a feladó és az Apple szervere között helyezedik el, így az elküldött üzeneteket valamint a feladónak érkező válaszokat tudja olvasni és módosítani. (Nyilván ugyanez igaz a feladóoldali elrendezésre is, a kommunikáció szimmetrikus.)

Még ennél is nagyobb hatalmat kap a támadó, ha mindkét oldalon be tud avatkozni az üzenetváltásba:

Ekkor mindkét fél üzeneteit tudja olvasni és módosítani. De mi a helyzet akkor, ha mégegy lépéssel tovább megyünk? Ha egészen egyszerűen lemásoljuk az Apple kulcsait, és teljesen megkerüljük a Push-szervereket? Ekkor egy klasszikus, egyszerű MITM-támadássá avanzsál a módszer:

Ez egyben azt is bizonyítja, hogy a támadó helyére betehetjük magát az Apple-t is. Mivel a szerverek rendelkeznek minden szükséges kulccsal, az end-to-end titkosítás ellenére tudják olvasni és manipulálni az üzeneteket. (Ehhez az eljáráshoz szükséges mindkét fél titkos és nyilvános kulcsa, hiszen a titkosított üzenetet ki kell bontatni az olvasáshoz a címzett titkos kulcsával, és módosítás után visszakódolni a nyilvános kulccsal. A másik irányban a feladó kulcsaira igaz ugyanez.)

Demonstráció

A hackerek egy videót is készítettek, amiben konkrétan megvalósítanak egy ilyen támadást. Láthatjuk, amint a „megpatkolt” készüléken küldött és fogadott üzenetek „maguktól” l33tsp34k-ké alakulnak:

Mit tehetünk ez ellen?

Két dolgot. Az egyik dolgot csak az Apple valósíthatja meg: egy átláthatóbb, megbízhatóbb protokollt és titkosítási infrastruktúrát kellene kiépítenie. A másik, amit megpróbálhatunk, az az, hogy egy, az Apple-től független titkosítási réteget használunk, tehát nem sima szövegben (plaintext) küldjük el iMessage-einket, hanem egy olyan kulccsal kódoljuk, amit sem az Apple, sem más potenciális hallgatózó, támadó nem ismer, csak a küldő és fogadó fél.

Ezen felül Pod2G csapata írt egy iMITMProtect nevű alkalmazást, ami megpróbálja a cikk elején leírt certificate pinning hiányát orvosolni oly módon, hogy az első alkalommal, amikor a Push-Tokent és a kriptográfiai kulcsokat megkapja egy készülék, akkor azokat egy helyi adatbázisban tárolják. Ha ezek bármikor megváltoznak, akkor gyanakodni lehet, hogy valaki hallgatózik, tehát az alkalmazás figyelmeztet minket erre. Az app egyelőre csak OS X-re érhető el, de a fejlesztők azt ígérik: amint megjelenik a jailbreak, készítenek belőle cydiás változatot is, iOS-készülékekre.

Nektek mi a véleményetek erről a biztonsági hibáról? Valós problémának tartjátok?