A short while back I had to figure out
how to setup and pentest an Android and iOS financial app. Not having done either before
and not really finding too much information on the interwebs I took bits and
pieces of what I did find and put it into the basic setup I am going to
demonstrate in this short write up.
This is not an all-in-one from setup to haxor, just a guideline to the basic setup.
As mentioned above this is just an introduction
to
setting up my environment for an Android app pentest and some of the
basic things to look for, there are some great sources of information on the different
kinds of flaws and issues but to really understand the information, you need to setup your
environment and start playing around.
Depending on the app your
assessing you will be looking at different things, for instance; a banking
application may store credentials in various databases or even keep a full
history of the HTTP session in some cache files that could contain some
sensitive information. Other apps may open up various holes on devices that
allow another process to query sensitive data from the app your assessing via content-providers.
Anyways back to setting up
the environment, I use a Mac but this can easily be tweaked to run on Windows
or Linux.
Setup the Android Virtual Device (AVD)
You will firstly need to download and install the
Android SDK (ADT Bundle), which can be found at the below link:
There are versions for
Linux, Windows and OSX. The ADT Bundle contains everything you will need
including Eclipse, ADT plugins and Android platform tools.
Extract the SDK to a folder
then run the Eclipse application.
Once the Eclipse interface
is up and running you can then create and setup a new Android Virtual Device
(AVD). This will be the emulated device which you will use to install, run and test the Android app your going to assess. On
the Eclipse interface find the Android Virtual Device Manager as seen in the
below screen:
There are various options
for creating a new device, I usually setup a tablet device but certain apps are built for phone or tablet specific displays.
Once created we can then use
the SDK emulator tools (using a terminal or command prompt) under the following
locations:
/adt-bundle/sdk/platform-tools/*
/adt-bundle/sdk/tools/*
Now we can run the newly created AVD image, in the terminal we execute the following command:
./emulator –avd {AVD Name}
At this point the test
device will boot up in a new window on your base machine.
Setting up a Proxy
If your app makes use of a
browser/web service you can also boot the device up and set a default proxy, so
that if your app is talking to a web service etc. you can use a great tool like
Burpsuite to proxy all communications through for your tinkering.
./emulator –avd {AVD Name} –http-proxy
http://127.0.0.1:8080
This can also be set inside
the already booted up device:
Home > Settings > Wireless
& Networks > Mobile Networks > Access Point Names
There are a few other ways to set proxies these are just the two I use
The default device is very clean with very limited apps installed.You can find various sources to install extra Google apps and such, but for now I will show you how to install the Android app you are going to pentest.
Installing Android Apk
To install .apk files to the
virtual device we use a tool under the SDK tools folder (platform-tools, but this can change on different releases) called adb.
./adb install {path to .apk}
The app should now
be available on the device, either on the home page or under the applications
page. You can run it inside the device, perhaps first run it and let it do its thing before you start poking around at files, folders etc, get some real data in there.
Accessing the device - shell
You will now want to have
shell access on the device. A shell on the device is a good starting point when
playing with the app and seeing what the app installs, directories created, file
permissions and data stored.
To get a shell simply use
the adb tool:
./adb shell
By default Android apps are installed
under the /data/data/ directory:
Inside the apps main directory there
are some interesting folders and databases.
Android apps make use of
sqlite databases for storage of all kinds of data which could include usernames,
passwords etc. You will need to get familiar with sqlite3 commands to easily
query the databases on the device.
There are a few commands to
learn, but here are the basics:
.table – will list all the tables in the database
.schema {table name} – will list the table structure
.quit – will exit
Here’s an interesting find,
inside the database is a table called password and httpauth. You can then query
these with select * from password
That’s pretty much the basic
environment setup.
Sieve - An App to Test
MWR have released an Android test app appropriately named Sieve. The app has all kinds of holes and flaws to find. You can download a copy from here:
Conclusion
I think when it comes to Android or iOS apps, data protection is about the most important category on the list, as these devices are more susceptible to loss and theft than regular computers. In addition to this, cached data may get copied to various machines that are used for syncing and data could be stolen from there.
It has been found that mobile operating systems can cache sensitive information such as keystrokes and create snapshots (screenshots of running applications) for extended periods of time. Applications on Android devices may store sensitive information in the form of temporary files, .localstore files, or in client side SQLite databases, .db.
For more details on Android and iOS secure development,
which you can use to develop your own security tests from look at:
MWR Information Security, has
also development an amazing tool called Mercury. Mercury is a framework for
exploring the Android platform; to find vulnerabilities and share
proof-of-concept exploits.
In fact MWR have a few
papers on Android security and even won some own2pwn at CanSecWest, so look them up for more info, great bunch of guys!
