A Palo Alto Networks nemrég egy új iOS-es malware-ről számolt be, amely a jailbreakelt készülékeket képes megfertőzni, és részletesen elemezte annak működését. A malware egy úgynevezett C&C szerverhez (command-and-control, botnet) kapcsolódva megpróbál kártékony kódot letölteni és lefuttatni az érintett készüléken, amely kód hozzákapcsolódik a hálózatkezelő API-hoz, és így a forgalmat figyelve ellopja a felhasználó Apple ID-ját és az ahhoz tartozó jelszót. Ha ezeket megszerezte, azt feltölti a támadó szerverére, majd megpróbál az áldozat nevében alkalmazásokat letölteni az App Store-ból. Ennek a tulajdonságának köszönhetően kapta az AppBuyer nevet.
Az AppBuyer-t először 2014. május 18-án említette a WeiPhone Technical Group négy tagja. Az egészre úgy derült fény, hogy segítséget nyújtottak egy felhasználónak, aki azt tapasztalta, hogy a jailbreakelt készülékére időnként olyan alkalmazások töltődtek le, amelyeket ő maga egyébként nem vásárolt meg. Így vettek észre két, nem odaillő fájlt a készülékén, és ezeket megvizsgálva kiderült, hogy azok a felelősek mindezért. Végül megpróbálták a támadót azonosítani néhány kísérlettel, de azt nem magyarázták el, hogy a malware pontosan hogyan is működik. A malware-t irányító és kiszolgáló szerver ugyanakkor jelenleg is működik, így adott esetben ez érinthet egyeseket, ezért nézzük kissé részletesebben, miről is van szó.
Hogyan működik?
Idáig még nem derült ki, hogy hogyan települ a malware az érintett készülékekre, de ahogyan a korábban már megismert Spad.dylib/AdThief, vagy azelőtt az unflod.dylib esetén, itt is feltételezhető, hogy a warezolt tartalmaknak komoly szerepe lehet a dologban, amelyek különféle, a Cydiában alapértelmezetten nem szereplő forrásokról származhatnak. Adott esetben a nem a fejlesztők oldaláról letöltött, módosított jailbreakelő alkalmazás is szerepet játszhat, de egyelőre nem ismert a dolog forrása.
Az érintett készülékeken az alábbi két fájl megléte már egyértelműsíti a fertőzöttséget:
- /System/Library/LAunchDaemons/com.archive.plist
- /bin/updatesrv
A com.archive.plist tartalmát megnézve láthatjuk, hogy az egy launchd daemon konfigurációs fájl, ami a StartInterval alatt megadott másodpercenként lefuttatja a ProgramArguments alatt megadott elemet. Esetünkben ez 7200mp, tehát 2 óránként betölti és lefuttatja a /bin/updatesrv állományt.
A malware fő tevékenységét az alábbi ábra mutatja:
Itt a következő történik: a malware első lépésként kapcsolódik a http://www.jb-app.com/updatesrv.aspx?f=1 címre, hogy létrehozhassa a helyi UUID konfigurációját a /etc/uuid alatt. Ezt követően kiolvassa ebből a fájlból a UUID értékét, és lekéri a második URL-t, ami a http://www.jb-app.com/updatesrv.aspx?f=2&uuid=<UUID> lesz. Az updatesrv ezután megvizsgálja, hogy a szerver esetleg “IDLE” parancsot küldött-e vissza. Ha igen, akkor bezáródik és kilép. Ha viszont nem, akkor két fájlt tölt le a szerverről /tmp/u1 és /tmp/u2 néven, és lefuttatja az elsőt.
Az elemzés során az is kiderült, hogy miután az updatesrv már három alkalommal lefutott, a szerver minden esetben “IDLE”-t fog neki visszaküldeni.
Az első lefutáskor az updatesrv megvizsgálja, létezik-e a /etc/uuid. Ha nem, akkor a második URL lekérése az UUID értéke nélkül történik majd. Ezután letölti az u1 és u2 fájlokat. Az u1-ben lévő kód semmi mást nem csinál, mint generál egy egyedi UUID-t, felhasználva az aktuális időt, egy véletlen számot 0 és 9999 között, valamint az aktuális process ID-t, majd ezt írja ki a /etc/uuid fájlba. Az u2 mindössze az “1” karaktert tartalmazza, a kód futásakor nem kerül használatra.
A malware a második lefutáskor, tehát a fertőzöttség után akár 2 órával már megpróbálja ellopni a felhasználó Apple ID-ját és az ahhoz tartozó jelszót. Ekkor a korábban generált UUID-val kapcsolódik a szerverhez a http://www.jb-app.com/updatesrv.aspx?f=2&uuid=[uuid] URL-en keresztül, és két újabb fájlt tölt le a szerverről u1_80 és u2_80 néven. Az u1_80 mindössze annyit csinál, hogy az u2_80 néven letöltött fájlt bemásolja a /Library/MobileSubstrate/DynamicLibraries/ alá aid.dylib néven, ennek köszönhetően az később betöltődik a Cydia Substrate által, mivel az egy Cydia Substrate tweak. Amikor ez a tweak betöltődik, akkor az az ISURLOperation osztály connectionDidFinishLoading: metódusát felülírja, aminek eredményeképp az összes HTTP és HTTPS lekérést rögzíteni tudja, és három megadott stringet keres a lekérések body részében:
- <key>appleId</key>
- <key>guid</key>
- <key>password</key>
Minden alkalommal, amikor ilyen stringeket talál, kiolvassa az azokat követő, azokhoz kapcsolódó <string> mezők tartalmát, ezzel megszerezve az adott session esetén használt appleId, guid, password adatait. Amint ezeket megszerezte, egy újabb szerverhez kapcsolódik a 106.187.38.163 címen, és elküldi az ellopott adatokat.
A harmadik lefutáskor újabb két futtatható fájlt tölt le a szerverről u1_88 és u2_88 néven. Itt az u1_88 az u2_88 nevű fájlt átmásolja a /usr/bin mappába gzip néven. A gzip egy széleskörben használt eszköz az iOS-ben, ugyanakkor annak alapértelmezett elérési útvonala a /bin/gzip, az így átmásolt fájl pedig a /usr/bin alá kerül, tehát ez semmiképpen sem az igazi gzip.
Ezt követően ez a gzip az, ami röviden összefoglalva letöltögeti az ellopott felhasználónévvel és jelszóval az appokat a fertőzött készülékre. A letöltési kísérlet után, akár sikerült a folyamat, akár nem (mert fizetős app esetén mondjuk nem volt elég egyenleg), a folyamat kapcsolódik a 223.6.250.229-es (kínai) címre, hogy visszajelzést küldjön (jelen esetben ez az IP megegyezik a C&C szerverrel).
Akit a malware ennél részletesebb elemzése érdekel, annak az eredeti angol nyelvű cikket ajánljuk.
Hogyan lehet kivédeni?
A jailbreaket kategorikusan elutasítók természetesen ismét csípőből rávágnák kaján vigyorral az arcukon, hogy “na tessék, itt egy újabb ok, ami miatt nem érdemes jailbreakelni!”. Ezzel a kijelentéssel azonban ismét két gond is van.
Az első, hogy a jailbreak önmagában még egyáltalán nem baj – de még ha baj is, messze nem akkora, mint amekkorának ilyen esetben egyesek szeretik kikiáltani. Mivel a malware működéséhez feltétel a Cydia Substrate, így ha ez a csomag nincs fent a készülékünkön, akkor várhatóan a malware sincs. A Cydia Substrate ugyanis nem része a jailbreaknek, azt a jailbreak után, Cydiából kell feltelepíteni, vagy pedig magától települ egy olyan csomag felrakásakor, amelynek a működéséhez ez szükséges.
A másik gond, hogy hiába van fent a Cydia Substrate is a készülékünkön, ha csak megbízható forrásból származó kiegészítőket telepítünk, akkor is elég valószínűtlen, hogy ilyesmi kerülhessen a készülékünkre.
A probléma ott kezdődik, ha valaki nekiáll warezolni, mert akkor semmi sem garantálja, hogy az általa letöltött tört kiegészítővel nem kerül valami plusz “ajándék” a készülékére. A warez kapcsán ráadásul érdemes szétválasztani az App Store-os appok és a Cydiából elérhető jailbreakes kiegészítők warezolását is. Előbbinél, tehát az App Store-os appok warezolása esetén az újabb módszereknél már nem is feltétel a jailbreak, mert a feltört appot megfelelő tanúsítvánnyal aláírják, és a TestFlight működéséhez hasonlóan telepíthető lesz jailbreak és App Store nélkül. A cydiás kiegészítők warezolása ugyanakkor nyilván megkívánja a jailbreaket is, és mivel a jailbreak teljes hozzáférést ad a rendszerhez (hiszen épp ez a célja), így a felhasználó felelőssége, hogy miket telepít ezek után. Ha ezek tört kiegészítők, mindenféle megbízhatatlan forrásból, akkor nem kell csodálkozni azon, ha ezt mások kihasználják.
A gond tehát nem elsősorban a jailbreak, hiába szeretik többen is ezt állítani, hanem a warez. Ha pedig valaki eleve nem warezol, akkor hiába jailbreakelt a készüléke, gyakorlatilag csekély az esélye, hogy ilyen gondba keveredjen.
Mit tehetek?
A legegyszerűbb megoldás, ha ellenőrzöd, hogy léteznek-e a fent említett fájlok a készülékeden. Ha nincsenek ilyen fájlok, akkor nem érint téged ez a malware. Ha viszont találsz ilyen fájlokat, akkor azokat rögtön töröld le, és azonnal változtasd meg az Apple ID-d jelszavát a https://appleid.apple.com oldalon! Az alábbi fájlokat kell keresned:
- /System/Library/LaunchDaemons/com.archive.plist
- /bin/updatesrv
- /tmp/updatesrv.log
- /etc/uuid
- /Library/MobileSubstrate/DynamicLibraries/aid.dylib
- /usr/bin/gzip
Ezután még érdemes lehet bekapcsolni a kétlépcsős azonosítást is, ha az már elérhető az Apple ID-d esetén: Kétlépcsős azonosítás: magasabb biztonság az Apple ID-nkhoz
Azok számára pedig, akik nem akarnak manuálisan nyúlkálni a készülékük fájlrendszerében, készítettünk egy cydiás csomagot, ami ellenőrzi, hogy léteznek-e az említett fájlok, és eltávolítja őket, ha igen, illetve ebben az esetben szintén figyelmeztet a jelszó módosításának fontosságára. Ha ezt a megoldást választod, akkor keresd a Szifon Source-on az Aid.dylib malware fix csomagot.
A cydiás csomag csak a telepítése közben ellenőrzi és törli adott esetben a malware-t, a csomag ezután szükségtelen, így nyugodtan törölhető.
A malware kapcsán előkerült az is, hogy esetleg egy (vagy több), warezt tartalmazó cydiás source állhat az egész hátterében, így mi továbbra sem ajánljuk, hogy bárki is tört kiegészítőket telepítsen a készülékére, mert akár ilyen “mellékhatások” is elképzelhetőek.
9 Comments
Na az ilyen cikkeket szeretem olvasni 😀
Nesztek jailbreak-esek 😀
@expa: kérlek, olvasd végig a cikket, nem a jailbreak miatt van önmagában, mert a jailbreaknek sem a Cydia Substrate, sem a warezolt appok és kiegészítők, valamint az azokat tartalmazó source-ok nem része alapból! ez külön le van írva, ki van emelve a cikkben.
@expa: értelmes hozzászólás… Erre én is írhatnám, hogy nesztek Windowsosok, ugyanis kiváncsi lennék az itt irogató nagyarcu apple fanok hány százalékának van csak iphone-ja, és otthon a windowst koptatja..,
A probléma nem a JB-ben keresendő. Ha te azt hiszed hogy a sima készülék nem fertőzhető akkor bizony tévedsz…
@expa: A készüléked nem fertőzött…
Egyébként JB alatt sokkal hamarabb vannak hibajavítások (pl. ssl bug, attachment titkosítás stb) mint amit az Apple tud eszközölni, ergó még mindig jobb JBesnek lenni, mint nem 😛
Egyebkent az iOS legujabb verziojahoz mikor lesz megbizhato JB? Olvastam errol a Pangu JB-rol, de elegge fazok tole…nekem pl. az ultrasn0w nagyon bevallt anno…
@danieloravecz: az iOS legújabb verziója az iOS 8 holnaptól. hogy arra mikor lesz jailbreak, az majd kiderül. a korábbi verziókra ott a Pangu, vagy előtte az evasi0n 7, esetleg sima evasi0n vagy p0sixspwn.
az ultrasn0w az nem jailbreak, az adott baseband-verziókkal működő, szoftveres függetlenítés. esetleg a redsn0w az, amivel keverheted.
@Jadeye: bocs, redsn0w-t akartam 😀 a Pangu mennyire megbizhato?
@danieloravecz: a panguval kapcsolatos tapasztalatokat el tudod olvasni az arról szóló cikkben.