Introduction to iOS App Pentesting - Setting up the environment / Things to look out for

In my previous blog, I went on about setting up the basic environment with regards to Android app pentesting. Its even easier with iOS application testing, keeping in mind that you will be using a Mac and Xcode.

My setup is as follows:

• Mac OS X 10.8.4
• Xcode 4.6.2 
• The Xcode Project of the Application I am assessing

Since the latest iOS/Xcode versions I have not seen an iPad or iPhone simulator for other operating systems, so I get the full Xcode project from the developers, compile and run the application via the iPhone/iPad Simulator inside of Xcode.

So I have my iOS application running in the Xcode iPhone Simulator, the below is one of many different kinds of password managers and already I have some data in it:

The simulator and running application are all placed under a specific folder on your Mac, the default location can be found here:

/Users/<username>/Library/Application Support/iPhone Simulator/*.*

As my password manager application is running on iOS 6.1 it will be placed under the 6.1 folder:
 
/Users/<username>/Library/Application Support/iPhone Simulator/6.1/<hash value>

Using a terminal one can access the directories and start looking at the application file and folder permissions. iOS apps store tons of data in sqlite and Cache files, as with this application I found that the stored username and passwords are stored in the clear.

Under the applications installed folder on the simulator, I simply run a grep for my details:

I open the file pmdb, with a SQLITE viewer and find all my details stored in the clear on the device:

Now if my device were stolen and the perp rooted the phone he could essentially gain access to all my stored credentials for anything I saved within the application.  

Once again when it comes to mobile application security its mostly about Data Protection, financial apps should be protecting user data and keeping very little sensitive data on the device, if at all!

Some tips when looking at iOS apps:

Keyboard Cache
 
Keystrokes entered on iOS devices could potentially get cached in the 

~/Library/Keyboard/dynamic-text.dat

file stored in the device operating system for auto-correction dictionaries. This functionality is similar to the AUTOCOMPLETE for web browsers. If AUTOCOMPLETE is not set to off for the UITextField then text in these fields could be cached.

Snapshots
 
Every time a user tabs the Home button from within a iOS application, the window of the application shrinks and disappears. In order to create the shrinking effect, the device takes an automatic screenshot. These snapshots are stored in the snapshots directory of the application.

For example:

~/Library/Caches/Snapshots/<app being assessed>/* 

UIPasteBoard

If iOS applications use the UIPasteBoard for copying and pasting objects, this information could be obtained by other applications from the clipboard. In addition to this if the persistent pasteboard property is used by the developer, the copied information will be stored unencrypted on the devices file system and can be found at:
 
~/Library/Caches/com.apple.UIKit.pboard/pasteboardDB

If the application contains sensitive information, it is therefore critical for them to use private pasteboards for copy and paste operations. Also the persistent property should be used at a minimal.

SQLite Database

iOS applications store client side data in SQLite databases on the device under various locations under the applications install folder. Information in these databases is often not encrypted and can therefore contain sensitive data such as passwords, usernames, keys etc. It may even contain application state information, which could be altered to bypass the application logic.

Property List (.plist files)

Property list files are not a good place to store sensitive information. Instead applications should store sensitive data in the keychain. Apple uses sandboxing functionalities to limit access from one application to another application’s data. However, despite sandboxing of applications numerous application property files are readable by other applications. This is because of the loose sandbox rules.

Introduction to Android App Pentesting - Setting up the environment

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:

http://developer.android.com/sdk/index.html

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:

http://labs.mwrinfosecurity.com/assets/380/sieve.apk

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:

https://viaforensics.com/resources/reports/best-practices-ios-android-secure-mobile-development/

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.

http://labs.mwrinfosecurity.com/tools/2012/03/16/mercury/

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!