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.