Most dobhatom ki az iPhone-omat?!
2019. szeptember 27-én az Apple iPhone-termékcsaládjának új sérülékenységét tette közzé a Twitter és Github segítségével az axi0mX nevű felhasználó checkm8 néven. Az elnevezés a sakk-mattra utal, és a helyzet valóban komoly: a biztonsági rést kihasználva egy támadó elvileg teljes irányítást nyerhet a telefon felett.
Az érintett Apple-eszközök száma példátlanul magas: az Apple legtöbb processzora érintett az A5-től az A11 családig. Mai ismereteink szerint a hibával nem érintett az A12 és az A13 család (a megváltozott architektúra miatt), tehát az iPhone XS and XS Max, az iPhone XR, az 5. generációs iPad Mini, iPad Air (2019), és az iPhone 11 család esetében nincs veszély. A régebbi generációkban viszont az iPhone 4-től és az első iPadtől kezdve az iPhone X-ig igen.
Ilyen sok készüléket érintő, ráadásul csak tompítható, ki nem javítható hiba ritka az iparág történetében. Sok kérdést vet fel, megpróbálok néhányat megválaszolni.
Mit tehetek, ha a készülékem érintett?
Ne hagyja a telefonját őrizetlenül, csak olyan szervizbe vigye, amelyikben maradéktalanul megbízik – de oda se ezzel a hibával, mert ez javíthatatlan. A hiba kihasználásához a telefont egy különleges módba kell tenni, és USB-csatlakozáson egy számítógéphez vagy számítógépet helyettesítő eszközhöz kell kötni. Ez a telefonhoz való fizikai hozzáférés nélkül nem valósítható meg. Ha csak egyszerűen hozzácsatlakoztatom a készüléket egy számítógéphez normál állapotban, a sérülékenység nem használható ki.
Észre tudom venni, ha feltörték a telefonomat az új sérülékenységet kihasználva?
Erre a kérdésre nem könnyű válaszolni, attól függ, mekkora erőforrásokkal rendelkezik az, aki a telefont megváltoztatta. Egyelőre nem ismert olyan veszélyforrás, amely ennek a sérülékenységnek a kihasználására épül. Olyan, ami sokáig észrevétlen maradhat, kevés lesz, egy részüket pedig hamarosan fel fogják fedezni, ezekre lesz speciális védekezés is.
Lehet-e hasznos dolgokra is használni a hibát?
Igen, lehet. Lelkes amatőrök régi, de működőképes Apple-eszközökből mindenféle hasznos eszközt csinálhatnak a segítségével az Apple támogatása nélkül. Akár Androidot is kifejleszthetnek Apple-termékekre, vagy lehetővé tehető vele nem az Apple alkalmazásboltjából származó programok futtatása.
Miért nem lehet ezt a hibát az érintett készülékeken kijavítani?
A rövid válasz az, hogy egy olyan speciális elemben van a hiba, amelyet szándékosan terveznek javíthatatlanra, mert ezzel általában biztonságosabb környezethez jutunk. A hosszabb válasz kicsit bonyolultabb, de igyekszem közérthető maradni.
Manapság elég nehéz meghúzni, mi a határ a hardver és a szoftver között. Nagy egyszerűsítéssel az Apple-termékekben az alábbi 6 szoftveres réteg játszik szerepet (Az Android rétegződése is hasonló, de az egyes rétegek nevei még gyártónként is mások):
- Bootrom
- LLB
- iBoot
- SEP
- Kernel
- Alkalmazások
Amikor a telefon elindul vagy mély alvásból ébred, először a Bootromban lévő kód indul el. Ez egy csak olvasható tárolóban (ROM) kap helyet. Pont azért, mert nem lehet módosítani, egyfajta biztonságot ad, hiszen a következő réteg betöltését ő már ellenőrzi, nem indít el akármilyen kódot, képes a következő rétegen digitális aláírás-ellenőrzést végrehajtani, titkosított kódot kikódolni. A további rétegek már módosítható tárolóban vannak, és javítócsomagokkal változtathatóak, lecserélhetőek. Az egyes rétegek ellenőrzik a saját és a következő réteg indítását. Mi általában a készülék alkalmazásrétegével találkozunk.
Mi van akkor, ha ezek a programok megsérültek? Akkor a telefon nem indul el. Ha a történet itt véget érne, a hiba nem létezne, viszont nagyon sok boldogtalan telefontulajdonos volna. A Bootrom azonban képes úgynevezett DFU (Dowload Firmware Update) módra váltani. Ezt a különböző készülékeken eltérő módon lehet elérni, általában gomb(ok) hosszú nyomásával és elengedésével előre megadott ritmusban. Ekkor az USB-n keresztül beküldhetünk programokat a telefonba. Az aláírás-ellenőrzés, titkosítás és egyéb ellenőrzések viszont itt is megakadályozzák, hogy akármit beküldjünk. Ennek a folyamatnak a megvalósítását is el lehet rontani, akár szándékosan is be lehet építeni ide kiskapukat például szerviz- vagy titkosszolgálati célokra. Az Apple esetében azonban ez a réteg eddig biztonságosnak tűnt, csak nagyon régi telefonokban találtak hibát ezen a téren.
MOST SEM ITT akadtak hibára, DE MÉGIS ITT VAN A BAJ.
Ahhoz, hogy megértsük, miért, kicsit bele kell ásni magunkat az USB-kábel és -kommunikáció rejtelmeibe. Az USB (Universal Serial Bus) nagyon elterjedt eszköz készülékek összecsatolására. Egy pillanatra felejtsük el, hogy ma már létezik az USB-3.x szabvány, ahol sokkal több vezeték is van, az elvek ott is hasonlók, sőt egy új kapcsolat két összekötött készülék között ott is hasonlóan indul. A régebbi USB-kábelben négy vezeték volt: kettő az áramellátásban, kettő a kommunikációban játszik szerepet, és páronként össze vannak csavarva. A két kommunikációs (vagy jel)vezetéken egy adatfolyam megy bitenként, sorban speciálisan kódolva, ami nagy sebességű információáramlást tesz lehetővé viszonylag hosszú vezetékeken.
A kommunikáció egy adott pillanatban mindig csak egy irányban zajlik. Hogy sokféle készüléket lehessen könnyen összedugni, szabványokat dolgoztak ki (1.0, 2.0, 3.0, 3.1), amelyek igyekeztek lehetővé tenni, hogy egy új készülék egy régivel is megértse magát. Ehhez először is el kell dönteni, hogy ki a főnök a kábelen. Ezt maga a kábel kialakítása dönti el. Az újonnan felcsatlakozó eszköz (a kliens) az egyik jelvezetéket tápra húzza egy ellenállással, ezzel ad hírt magáról, és megkezdődik egy elég bonyolult kommunikáció, melynek egy része „szolgálati közlemény”. Ilyen szolgálati közlemények teszik lehetővé, hogy a sebesség felgyorsuljon a lehetséges maximumra, kezelik a hibákat és így tovább. A szolgálati közlemények is ugyanazt a csavart érpárt használják, mint az adatok, ugyanaz a hardver-szoftver páros szolgálja ki őket.
A checkm8 hiba a szolgálati közlemények feldolgozási részében van, nem a normál adatfolyamban, és még az sem olyan, hogy minden körülmények között bajt okoz, csak egy bizonyos versenyhelyzetben. Ezért maradhatott a hiba ilyen sokáig felfedezetlen.
A hiba hatására összeomlik a készülék stackje, ROP technikával a bootrom különféle kódrészleteit használva a támadó átveszi az uralmat a készülék boot folyamatán, és utána szinte bármit módosíthat. Ilyenkor még a hardver jelentős része el sem indult, sok kódon kell átrágnia magát annak, aki észrevehetetlen akar maradni, de aktív változást akar a készülékben létrehozni. Ilyen kódot egyelőre nem publikált még senki. Más eset, ha a készüléket szándékosan úgy változtatják meg, hogy tulajdonosa például az Apple App Store-ban nem található programokat futtasson valamilyen okból. Az ezt lehetővé tevő kódok tömeges megjelenése várható. A kódok közzététele mozgósíthat hasonló hibák keresésére más telefonokban, a hiba kihasználására, a készülék megjavítására, a tervezettől eltérő használatra és így tovább.
Végezetül pedig néhány szó arról, hogy ezt a hibát miért így tette közzé a felfedezője. A szokásos jóindulatú eljárás az, hogy először a gyártóval közlik a hibát, megvárják, amíg elkészül a javítás, utána jelentik be nyilvánosan. Mivel ez a hiba javíthatatlan, ennek így nem sok értelme lett volna. A nyilvános közzététel kizárja a probléma eltussolását, míg az, hogy mindenki egyszerre értesült, kizárja a részvényárak manipulálását. A tőzsde zárt, mielőtt a hír széles körben elterjedt volna, így az Apple-nek volt közel két napja, hogy kitalálja, hogy kezeli a helyzetet.
(A szerző az Atlas Soft IT-biztonságtechnikai cég vezetője.)
Rovataink a Facebookon