Turn Android Emulator into a Pwnage Weapon

Turn Android Emulator into a Pwnage Weapon

Today, we’re going to look at a scenario where the Android Emulator can be re-purposed as an exploitation tool. Specifically, we will look at attacks that involve cloning an application and user data from a stolen Android phone onto a computer running the Android emulator. An attacker that does this will be able to use the application as if they were the user. They would also be able to return the phone to the user before the target becomes aware of the compromise.
A natural defense to this sort of attack would be to have the application verify what device is running it before giving the user access. The application would only be allowed to run on a device registered with the user’s account. A natural defense against this kind of attack would be to have the application verify the device and to run only on a device registered with the user’s account.
We will demonstrate a new tool that repurposes the Android emulator to give false device information in order to subvert such a defense mechanism. We will demonstrate a new tool that subverts this defense by repurposing the Android emulator in order to provide false device information.
A natural defense against this kind of attack would be to have the application verify the device and to run only on a device registered with the user’s account. We will demonstrate a new tool that subverts this defense by repurposing the Android emulator in order to provide false device information.
The Scenario
Let’s consider a sensitive Android application that gives the user access to a secure asset. Think corporate VPN access, email, or a social networking client. An attacker wants to gain access to this sensitive application, preferably without alerting the user that they have been compromised. If an attacker can gain physical access to the phone, they can then do the following:

• Steals a legitimate user’s phone
• Temporarily root it to gain access to the file system
• Copy the target application’s data off
• Return the phone to the previous unrooted state (if it was unrooted)\
• Return the phone to the owner, leaving them oblivious to the fact that their phone was stolen and tampered with
• Copy the application to a device owned by the attacker and launch the application from there

The attacker can then use the copied application to access the same sensitive assets the user while leaving the user oblivious to the compromise. Had the attacker kept the phone, the user would become aware of their missing property, and would take action to cancel their accounts. We obviously want to prevent this. One method would be to impede an attacker’s ability to operate the application on a device that isn’t the user’s.
How would our developer enforce this requirement? A natural choice is to use a piece of data unique to every phone to create a one-to-one relationship between this data and every account. A phone number is a clear starting point. Another option is the IMEI or IMSI, which are stored in the SIM card and are unique hardware and network identifiers, respectively. The application will record the phone number, IMEI, and IMSI of the device it’s installed on, and function only if all of these match the information on the account.
The Tool
One of the benefits to security researchers from Android’s rich SDK is the Android emulator. You can run arbitrary Android apps on the emulator; all you need is the APK distributable. The emulator is a first-class android device, and should behave exactly as a phone would.
When performing mobile application assessments, we often use an emulator as the testing platform. It allows us to control the environment in ways that would be much harder with a physical device. For instance, the “-tcpdump” argument gives us a pcap file of the emulator’s network traffic; there is no need to set up a wifi access point on our machine and use iptables to hook up wireshark to a phone.
There are lots of other ways in which the emulator makes your life easier as a pentester, but today let’s talk about an actual attack that utilizes it.
In the above scenario, instead of copying the application to another device, the attacker can copy it to an emulator. Normally, emulators have their own fixed phone number, IMEI, and IMSI, but the Android SDK is open source and therefore modifiable.
We have released a fork of the Android emulator that allows you to spoof the phone number, IMEI, and IMSI at launch. For instance, below is a screenshot of an emulator that thinks it has the same phone number as Pizza Pizza:

Weaponizing the Android Emulator

The application only allows phones with the correct phone number, IMEI, and IMSI to access it, but we can simply copy it to an emulator with those identifiers spoofed. We can thus thwart the defense mechanism that tries to prevent our application from running on devices without a given identifier.
The Attack
Here are step-by-step instructions for a successful attack:
Copying from the phone
Assume that: you have access to the target phone, it has USB debugging enabled, and you have a copy of the Android SDK installed (http://developer.android.com/sdk/index.html).

1. Obtain the target phone’s IMEI, IMSI, and phone number. The IMEI and phone number can be found by navigating to the Settings -> About Phone -> Status screen on the phone.The IMSI will sometimes appear on the screen as well, but not always. If it does not, you can write a small Android app that will display the IMSI using the API call for this. More details here: http://stackoverflow.com/questions/2372757/acces-the-sim-card-with-an-android-application.
2. Copy all of the application data and the APK to your computer: 

adb pull /data/data/application_name
adb pull /data/app/application_name.ap

Cloning on to an emulator

1. Get the code for our fork of the Android Emulator: https://github.com/SecurityCompass/android_emulator_spoofing 
   

   git clone git://github.com/SecurityCompass/android_emulator_spoofing.git

2.  In the directory this pulled to, build with:

   sh android-configure.sh

   make 

3. Create a new AVD to emulate the same version of Android as the target phone. The easiest way to do this is to use the AVD manager that came with the Android SDK. Let’s say you named it “spoofavd.”
4. Launch the spoofing emulator:
   

   export ANDROID_SDK_ROOT=/path/to/android_sdk/

   ./objs/emulator @spoofavd -imei target_imei -imsi target_imsi -phone-number target_phone_number 

    
5. Install the application and clone its state from the target:

   adb install application_name.apk

   adb remount

   adb push application_name /data/data/ 

The emulator will now be running a clone of the application from the target’s device, and any authentication based on IMSI, IMEI, or the phone number will be subverted!
Defending against this attack
How can developers ensure that activated applications aren’t cloned? As we have shown, “unique” hardware identifiers can be spoofed, and so cannot be relied upon to guarantee an account is associated with only one phone.
If this were a web application, we would recommend a solution using the correlation of user sessions with IP addresses. A user accessing the site from a previously unseen IP would be asked a security question and the answer would be verified on the server.
Unfortunately, mobile internet doesn’t really provide devices with static IP addresses. What is more, IP addresses can change on a minute-by-minute basis. Therefore, a network-based solution to the problem outlined wouldn’t work in the mobile space.
We have to protect against cloned application with strong local controls. Full disk encryption of mobile phones would go a long way to solve this problem, but unfortunately this isn’t a reality for stock Android phones right now, but is available on some tablets. Whisper Systems is working on making that a reality.
All of the data stored by our sensitive application should be stored encrypted on the phone. We still run into the problem of key management; if the key is stored along with the data, encryption isn’t really going to stop an attacker from finding the key. A common solution is to use password-based encryption, for instance PBKDF2. If our application has a local password and encrypts all stored data with a key derived from that password, the attacker would only be able to use the cloned application if they knew the password (or the key directly). This would still leave our application susceptible to a brute-force attack, but would mitigate other risks associated with applications being compromised locally.
Source:SCLabs

NOTE: Only for educational Purpose. We will not be responsible for any mischief done by you.

Regards,
Hardeep Singh (cyb3r.gladiat0r)