There is bunch of Android apps pulled from the Android Market because they contained malware. There were over 50 infected applications - these apps were copies of "legitimate" apps from legitimate publishers that were modified to include two root exploits and a rogue application downloader. This isn't the first example of malware on Android, but it may be the first to affect Google's own Android Market . This new malware has been referred to as DroidDream, RootCager, and myournet by various researchers and media outlets.
So how does this malware work? First of all, we can start with the basics of how Android apps work. Android applications are mostly written in Java and use XML files for configuration. The Android compiler suite takes a developer's Java files, compiles them to class files, and then converts the class files into dex files. Dex files are bytecode for the Dalvik VM that runs Android apps. The XML files are converted to a binary format that's optimized to produce small files. The dex files, binary XML files, and other resources needed to run an application are packaged into an APK file. These files have the extension .apk, but they're just ZIP files. Once the APK package is generated, it's signed with a developer's key and uploaded to the Android Market through Google's website.
When a user wants to install an app from the market, the APK package is downloaded and extracted onto their device. When an application is started, the Android device runs what is called an Activity in the application. The initial Activity, the program's entry point, is specified in a file called AndroidManifest.xml.
The AndroidManifest.xml file in infected packages was modified by the malware author to first launch the malware itself instead of the original application's Activity. To create the infected APK packages they unpackaged the original application's APK file, modified files and inserted their malicious code, then re-packaged the app and signed it with their own key. The apps were uploaded to the market, and in some cases were downloaded tens of thousands of times. This is the modified portion of theAndroidManifest.xml file used by this malware:
These settings cause the com.android.root.main Activity to be executed when the application is launched. It also configures two background services located in the classes com.android.root.Setting and com.android.root.AlarmReceiver. In the original application, the main Activity is in a completely different class.
What does this com.android.root.main Activity do when it runs? There are a few different ways to figure this out. My current preferred method is disassembling the Dex bytecode using the baksmali disassembler which produces human-readable disassemblies of compiled classes. It's also possible to decompile Dex files into Java sometimes, but it's still good to be able to read the disassembled code. Here is a smali snippet showing what the com.android.root.main.onCreate() function does when it's executed by the Android system:
This code starts the com.android.root.Setting service. It works by creating an instance of the Intent object, passing com.android.root.Setting's class object to the constructor. Then it calls the startService() method of the Intent object. This is roughly equivalent to this Android Java code:
Intent intent = new Intent(this, com.android.root.Setting.class); startService(intent);
Next, the malware will start the original main Activity for the application:
This code locates the class for the original Activity by calling the static functionClass.forName(), passing the Activity's class name as the argument. If the class is found, a new Intent instance is created for the class and then startActivity() is called. Here's a Java representation, without the exception handling:
Class klass = Class.forName(“net.luck.star.mrtm.HomeActivity”); Intent intent = new Intent(this, klass); startActivity(intent);
After this, the com.android.root.Main Activity exits. So at this point, thecom.android.root.Setting service is running in the background and the original application starts up on the device. The unsuspecting user won't notice anything amiss.
The exploits
Now we can take a look inside of com.android.root.Setting. The onCreate()method of this class will attempt to get root access on the phone using two separate exploits - a udev exploit (CVE-2009-1185), and one based on adb resource exhaustion (the so-called rageagainstthecage exploit).
The udev exploit is executed by the com.android.root.udevRoot class. The actual exploit code is compiled C and is located in a file named exploid in the APK's assetsdirectory. This file is an ARM Linux ELF executable, a compiled version of theexploid2.c exploit which was publicly released around July of 2010. The exploit works by using hotplug to execute a shell as root. To actually cause hotplug to run,exploid will modify the state of the WiFi adapter and then return it to the original state. Other public versions of this exploit instructed the user to perform that action manually.
The installSu() method makes use of a file named profile in the APK's assets directory, which is another ARM ELF executable which just calls setguid(0),setuid(0), then execv("/system/bin/sh") - a classic root shell. This gets installed as /system/bin/profile with 04755 permissions - giving it the ability to run any command as root.
The adb exploit is a bit more complicated. It's executed by thecom.android.root.adbRoot class and the actual exploit is the compiled C in therageagainstthecage asset. This exploit is also known as CVE-2010-EASY, and uses a resource exhaustion attack against the Android debug bridge process, adb. adbinitially runs as root, but drops privileges with setuid(). However, the return value from setuid() isn't checked. Since setuid() fails when the target user is over theRLIMIT_NPROC value, adb will continue running as root if the user's process limit is maxed out. The rageagainstthecage exploit first determines the RLIMIT_NPROCvalue and then creates enough processes to reach the limit. When the limit is reached, a single process is killed and adb is restarted to take its place.
The adbRoot class makes use of thejackpal.AndroidTerm library, also packaged with the modified APK, to communicate with the rageagainstthecage exploit.
Phoning home
Before the root exploits are attempted, the malware starts a thread to make an HTTP post to a remote server. The information is formatted as XML and looks like this:
1.0 0 %s %s %s %s %s
The interesting values here are IMEI (International Mobile Equipment Identification) which identifies the physical phone handset, and IMSI (International Mobile Subscriber Identification), which identifies the SIM card in use in the phone. These values are unique identifiers for your phone and tracking them allows the malware controllers to determine exactly how many devices have been compromised.
Dropping more malware
At this point, if the malware has root access, it can do anything it wants to the phone. The last thing that the com.android.root.Settings class does before terminating is install another APK package that's included in the infected APK:
This code first checks to see if the com.android.providers.downloadsmanagerpackage is installed. If not, it copies the sqllite.db file - in the assets folder of the APK - to /system/app/DownloadProvidersManager.apk. We haven't yet fully analyzed this app yet, but it appears to have the ability to download and install other apps on an infected phone. The included AndroidManifest.xml file configures theDownloadCompleteReceiver class to run as soon as the phone boots up (using theandroid.intent.action.BOOT_COMPLETED intent) as well as when the phone state changes – for example when an incoming call is detected or a phone call is initiated (using the android.intent.action.PHONE_STATE intent).
Conclusion
According to Symantec, there were 52 total infected apps published to the Android Market: 21 by kingmall2010, 21 by myournet, and 10 by we20090202. They also claim that there were anywhere from 50,000 to 200,000 downloads of infected apps before they were pulled from the Android market. While the infected apps are now gone from the market, any infected phone is still potentially compromised.
A piece of malware with root access to a phone can read any data stored on it and transmit it anywhere. This includes contact information, documents, and even stored account passwords. With root access it's possible to install components that aren't visible from the phone's user interface and can't be easily removed. For this reason, any compromised phone should be reset to it's factory default state - in some cases this may require a trip back to the phone store.
Last year at SummerCon, Jon Oberheide demonstrated how easy it is to trick users into installing useless and fake applications that can download external malicious components. It's not necessary for apps in the market to contain malicious code embedded in them. So while this particular piece of malware was detected quite quickly, within a matter of days, it is possible for rogue apps to be stealthier.
Security conscious consumers should be wary of the apps they install on their phone and only install apps from reputable publishers though the official Android Market. Here are some things to look for to identify an app from a reputable publisher:
- The publisher has a website with contact information
- The app is from the official and original publisher (i.e., if you are installing Angry Birds, ensure it's from Rovio Mobile Ltd)
- App has a high number of downloads, ratings, and positive reviews
0 comments:
Post a Comment