Egy érdekes elemzés jelent meg az IBM X-Force Frequency X Blogján, melyben a napokban az Andorid Marketen megjelent kártevők működését elemzik. A hajtás után olvashatjátok a cikk fordítását, amely néha kissé szájbarágós ugyan, de véleményem szerint jó rálátást ad mind az androidos alkalmazások, mind pedig az ezt futtató eszközket célzó kártevők működésébe: 

Aki követte a híreket a héten, az tudja, hogy egy csomó Android alkalmazást eltávolítottak az Android Marketről, mert malware-t tartalmaztak. Több mint 50 fertőzött alkalmazásról van szó, melyek "legitim" kiadóktól származó appok másolatai voltak két root exploittal és egy rosszindulatú letöltővel kiegészítve. Nem ez az első példa az androidos malware-re, de ez az első olyan eset, ami a Google saját Android Marketét érintette - malware mintákat már korábban felfedeztek mások piacterein. Erre az új malware-re DroidDream, RootCager vagy myournet néven hivatkoznak a különböző szakértők és média források.

De hogyan is működik ez a malware? Kezdük azzal, hogy hogyan is működnek az Andorid alkalmazások. Az Android alkalmazásokat általában Javaban írják, és XML-t használnak a konfigurációjukhoz. Az Android fordítócsomag veszi a fejlesztő Java fájljait, class fájlokat gyárt belőük, melyeket aztán dex fájlkká konvertál. A dex fájlok az Android alkalmazásokat futtato Dalvik VM által feldolgozható bytekódot tartalmaznak. Az XML fájlokat egy méretre optimalizált bináris formátumra konvertálják. A dex fájlokat, a bináris XML-eket és az alkalmazás futtatásához szükséges más erőforrásokat egy APK fájlba pakolják össze. Ezeknek a fájloknak .apk a kizterjesztésük, de valójában ZIP-ekről van szó. Az APK csomag létrehozása utána fejlesző aláírja a csomagot a saját kulcsával, és feltölti az Android Marketre a Google weboldalán keresztül.

Ha a felhasználó installálni szeretne egy alkalmazást a piactérről, letölti az APK csomagot, és kitömöríti. Amikor az alkalmazás elindul, az Android eszköz lefuttat egy ún. Activity-t. Az kezdeti Activity, a program belépési pontja az AndroidManifest.xml fájlban van meghatározva.

A fertőzött csomagokban az AndroidManifest.xml-t módosították a malware készítői olyan módon, hogy először a malware induljon el az eredeti alkalmazás Activity-je helyett. A fertőzött APK létrehozásához kicsomagolták az eredeti alkalmazást, módosították a fájlokat és beszúrták a kártékony kódokat, majd újracsomagolták az egészet, és aláírták a saját kulcsukkal. Az appokat feltöltötték a piactérre, ahhonnan aztán több tízezer alkalommal le is töltötték azokat. Ez a malware által használt AndroidManifest.xml módosított része:

Ezek a beállítások azt eredményezik, hogy a com.android.root.main Activity fusson le az alkalmazás indításakor. Két háttérszolgáltatás is konfigurálásra kerül, ezek a com.android.root.Setting és com.android.root.AlarmReciever osztályokban találhatók. Az eredeti alkalmazás fő Acitivty-je egy ezektől teljesen különböző osztály.

Mit csinál ez a com.android.root.main Activity amikor fut? Több lehetőség is van ennek kiderítésére. Én most a baksmali disassemblert fogom használni a Dex bytekód visszafejtésére, ami ember által olvasható kimenetet generál a lefordított osztályokból. Néhányszor lehetséges a Dex fájlokat Javaba visszafejteni, de ilyenkor is jó látni a disassembler kimenetét. Itt látható egy részlet abból, hogy mit csinál a com.android.root.main.onCreate() metódus, mikor meghívásra kerül az Android rendszerből:

Ez a kód indítja el a com.android.root.Setting szolgáltatást. Létrhoz egy Intent objektumpéldányt, és odaadja a com.android.root.Setting osztály objektumát a konstruktornak. Aztán meghívja az Intent objektum startService() metódusát. Ez nagyjából ekvivalens a következő Android Java kóddal:

Intent intent = new Intent(this, com.android.root.Setting.class);
 startService(intent);

Ez után  a malware elindítja az alkalmazás eredeti Activity-jét:

Ez a kódrészlet megkeresi az eredeti Activity-t a statikus Class.forName() függvény meghívásával, az osztály nevét átadva paraméterként. Ha megkerült az osztály, egy új új Intent példány keletkezik számára, és meghívásra kerül a startActivtiy(). Íme a Java reprezentáció, kivételkezelés nélkül:  

  Class klass = Class.forName(“net.luck.star.mrtm.HomeActivity”);
  Intent intent = new Intent(this, klass);
  startActivity(intent);

Ezutána com.android.root.Main Activity már létezik. A com.android.root.Setting szolgáltatás a háttérben fut, és az eredeti alkalmazás elindul az eszközön. A gyanútlan felhasználó nem vesz észre semmi különöset.

Az exploitok

Vegyük szemügyre a com.android.root.Setting osztály belsejét! Az osztály onCreate() metódusa root hozzáférést probál szerezni két különböző exploit - az udev (CVE-2009-1185) és egy másik, adb erőforrás kimerítésen alapuló (rageagainstthecage néven is ismert) - segítségével.

Az udev exploitot a com.android.root.udevRoot osztály futtatja. A tényleges exploit kód az exploid nevű, C-ből fordított fájlban található az APS assets könyvtárában. Ez a fájl egy ARM Linux ELF futtatható állomány, a 2010. júliusa környékén nyilvánosságra került exploid2.c lefordított változata. Az exploit a hotplugot használja egy shell rootként történő megnyitására. Hogy a hotplug lefusson, az exploid megváltoztatja a WiFi adapter állapotát, majd visszaállítja azt az eredeti helyzetbe. Az exploit más publikus változatainál ezt a felhasználónak manuálisan kell megtennie. 

Az installSu() metódus egy profile nevű fájlt használ az APK assets könyvtárából, ami szintént egy ARM elf állomány, ami csak egy setguid(0), setuid(0) végül egy execv("/system/bin/sh") parancsot ad ki - klasszikus root shell. Ez a fájl a /system/bin/profile útvonalra települ 04755 jogokkal - lehetővé téve tetszőleges parancs rootként történő lefuttatását. 

Az adb exploit egy kicsit bonyolultabb. Ezt a com.android.root.adbRoot osztály futtatja, és tényleges exploit egy C-ből fordított állomány a rageagainstthecage assetben. Ez az exploit CVE-2010-EASY néven is ismert és egy erőforrás-kimerítő támadást intéz az Android debug bridge folyamatához, az adb-hez. Az adb kezdetben rootként fut, de eldobja a jogosultsgágati a setuid() segítségével, a setuid() visszatérési értéke azonban nem kerül ellenőrzésre. Mivel a setuid() nem végzi el a dolgát, ha cél felhasználó RLIMIT_NPROC érték fölött van, az adb tovább fut rootként, ha a felhasználó elérte a folyamatkorlátját. A rageagainstthecage exploit először meghatározza az RLIMIT_NPROC értékét, majd elég folyamatot generál ennek eléréséhez. Amikor eléri a limitet, megöli az egyik folyamatot, majd újraindítja az adb-t, hogy átvegye annak helyét. 

Az adbRoot osztály a rageagainstthecage-el történő kommunikációhoz a thejackpal.AndroidTerm könyvtárat használja, amit szintént tartalmaz a módosított APK.

Hazatelefonálás

Mielőtt hibakihazsnálással próbálkozna, a malware egy szálat indít, amely egy HTTP POST-ot küld egy távoli kiszolgáló felé. Az üzenet XML formátumú, és így néz ki:

  <?xml version="1.0" encoding="UTF-8"?>
  <Request>
    <Protocol>1.0</Protocol>
    <Command>0</Command>
    <ClientInfo>
      <Partner>%s</Partner>
      <ProductId>%s</ProductId>
      <IMEI>%s</IMEI>
      <IMSI>%s</IMSI>
      <Modle>%s</Modle>
    </ClientInfo>
  </Request>

Az érdekes mezők az IMEI (International Mobile Equipment Identification), ami a telefonkészüléket, és az IMSI (International Mobile Subscribe Identification), ami a használt SIM kártyát azonosítja. Ezek telefononként egyedi azonosítók, és a követésük lehetővé teszi a malware irányítóinak, hogy meghatározzák a komprommitált készülékek pontos számát.

Még több malware begyűjtése

Ennél a pontnál a malware root hozzáféréssel rendelkezik, bármit megtehet a telefonnal, amit akar. Az utolsó dolog, amit a com.android.root.Settings osztály tesz terminálás előtt az, hogy egy másik APK-t telepít, amelyet szintén a fertőzött APK csomag tartalmaz:

Ez a kód először ellenőrzi, hogy a cim.android.providers.downloasmanager csomag telepítve van-e már. Ha nem, átmásolja az APK assets könyvtárában található sqllite.db fájlt a /system/app/DownloadProvidersManager.apk alá. Ezt az alkalmazást még nem analizáltuk teljeskörűen, de úgy tűnik, hogy képes más appokat a fertőzött telefonra telepíteni. A tartalmazott AndroidManifest.xml fájl úgy konfigurálja a DownloadCompleteReciever osztályt, hogy induljon el, amint a telefon felbootolt (erre az android.intent.action.BOOT_COMPLETED intetet használja), vagy amikor a telefon állapota megváltozik - például amikor bejövő hívást detektál, vagy híváskezdeményezés történik (erre az android.intent.action.PHONE_STATE intentet használja)

Konklúzió

A Symantec szerint összesen 52 fertőzött alkalmazást publikáltak az Android Marketen: 21-et kingmall2010, 21-et myournet és 10-es a we20090202 nevű felhasználó. Állításuk szerint 50.000 és 80.000 közé volt tehető a fertőzött appok letöltéseinek száma, mielőtt eltávolították őket az Android Marketről. Bár az alkalmazásoka  piactéren már nem elérhetőek, a fertőzött készülékek még potenciálisan komprommitáltak lehetnek.

Egy root hozzáféréssel rendelkező malware bármilyen telefonon tárolt adathoz hozzáférhet, és kiküldheti azt akárhová. Ide tartoznak a kapcsolat információk, dokumentumok és még a tárolt jelszavak is. Root hozzáférés birtokában lehetséges a felhasználói felületen láthatatlan komponenseket telepíteni, melyeket aztán csak nehezen lehet eltávolítani. Emiatt minden komprommitált telefont vissza kell állítani a gyári állapotba - ehhez néhány esetben vissza kell vinni a telefont az üzletbe, ahol vásárolták.

A tavalyi SummerCon-on Jon Oberheide megmutatta, hogy mennyire könnyű rávenni a felhasználókat, hogy haszontalan, vagy hamisított alkalmazásokat telepítsenek, melyek további rosszindulatú komponenseket töltenek le. Nem is szükséges, hogy a piactéren található appok rosszindulatú kódot tartalmazzanak. Így bár ezt a konkrét malware-t sikerült gyorsan, napokon belül detektálni, lehet hogy a rosszándékú alkalmazások később jobban elrejtőznek.

A biztonságtudatos fogyasztók meg kell hogy válogassák az alkalmazásokat, amiket telepítenek, és csak a hivatalos Android Marketről származó, jóhírű kiadótól származó appokat szabad installálniuk. íme néhány szempont, melyek alapján eldönthető, hogy a kiadó megbízható-e:

• A kiadó kapcsolat információkat közzétevő weboldallal rendelkezik
• Az alkalmazás a hivatalos és eredeti kiadótól származik (pl. ha az Angry Birds-t installálod, győződj meg róla, hogy a kiadó a Rovio Mobile Ltd)
• Az alkalmazás nagyszámú letöltéssel, osztályzattal és kritikával rendelkezik

Bár sok teljesen biztonságos és legitim app nem teljesíti ezeket a feltételeket, az IBM X-Force-nál úgy érezzük, hogy jobb félni, mint megijedni.

Frissítés (ez már saját):

A google a távoli alkalmazás-eltávolítás funkción keresztül leszedi a rosszindulatú alkalmazásokat a fertőzött készülékekről, valamint biztonsági frissítéseket tesz közzé a kihasznált hibák javítására.