This guide should serve as an introduction for those wishing to get into iOS application security testing. It demonstrates grabbing low hanging fruit. This guide will not cover all aspects of iOS application security and therefore should not be used as a fully fledged methodology. The line between web application assessments and mobile assessments is blurred as both consist of client/server models and most apps (if not all) speak HTTP (and hopefully some HTTPS). Many of the vulnerabilities you find will therefore require an intelligent web application security specialist's brain behind that Burp proxy. Incidentally, we have tons of them here at SpiderLabs! :)
Alas, let's get on with the show.
Ingredients
1x Jailbroken iPhone/iPad (Cydia)
1x Macbook Pro (to create a wireless network) OR a wirelessnetwork
1x Burp Proxy (or similar)
1x Self-signed Certificate (to MiTM HTTPS traffic)
Prepare iPhone/iPad
Cydia should already be installed if the device is jailbroken. OpenCydia, select Sources and add a new source; "http://cydia.hackulo.us".
Install OpenSSH, Installous 4 and Clutch.
Installing the app
If the app is on iTunes then this is easy - find it on the AppStore, download, sync device. If the app isn't on iTunes then the likelihood is that your client will send you a .IPA file. You can double click this file and it will load in iTunes - sync device as before.
WARNING: iTunes may force you to wipe the device if it is synced with another computer. If so, there is a way around this that doesn't involve syncing. Don't click on the .IPA and don't open iTunes. Instead, scp the .IPA file over to /User/Documents/Installous/Downloads/ on the device and install that way using Installous.
If your client sends you a .XCArchive package, don't worry, not all is lost. Assuming you're on OS X, sort out your X code path else you'll get this error.
Error: No developer directory foundat /Developer. Run /usr/bin/xcode-select to update the developer directorypath.
To fix, do the following:
sudo xcode-select -switch/Applications/Xcode.app/Contents/Developer
Now go to your .XCArchive file, right click and "Show Package Contents" and navigate to where the iOS .app file is - jot this down, you'll need it for the next bit.
Now armed with the .app file location you can bust out xcrun (our magic wand in this case) and create the .IPA file/package.Replace the path to your .app (what you jotted down before) in the command below. Note to specify "-sdk iphoneos" even if it is for the iPad.
/usr/bin/xcrun -sdk iphoneos PackageApplication"/absolute/path/to/MyApp.xcarchive/Products/Applications/MyApp.app"-o "/absolute/path/to/MyApp.ipa"
You can now scp the .IPA to your iPad and use Installous (within Cydia) to install as usual.
Finding the app
SSH to the device, the app will be installed in /var/mobile/Applications/<ID>/.
HINT: Look for the date when trying to locate the app, or justdo a find.
Connect to the wireless network
Connect the device to the wireless network - be it the Macbook Pro's "Internet Sharing" wireless network or an actual wireless network. Ensure that the Macbook Pro which will intercept requests/responses(via Burp) is on the same network.
Install the self-signed certificate
On the intercepting Macbook Pro we will export Burp's certificate via Firefox. Set Burp up as a proxy on TCP port 8080 (listening on ALL interfaces). Open Firefox, visit any HTTPS site, view the exception message, view certificate, highlight "PortSwigger CA" in the certificate hierarchy and not the site. Export as .CER. Mail it to yourself, open the e-mail on the device, click on the attachment and install it.
Important: Make sure you export the "PortSwigger CA" line item and not the random website below (twitter.com in this case).
Setting up the proxy
Ensure that Burp is listening on ALL interfaces, or at least one that the device could see over the network. On the device, go to Network, Wi-Fi, click on the blue arrow to the right of the connected wireless network, scroll down to "HTTP Proxy" and select Manual. Insert the details of the Macbook Pro with Burp running, IP and TCP port 8080.
Testing the proxy works
Open Safari on the device and test that Burp captures the HTTP traffic correctly. If it works then load up the iOS application and you will be able to see traffic.
Decrypting apps from iTunes
If you downloaded your client's app from iTunes then you will need to remove the encryption before you analyse it with strings, etc. Tore move iTunes encryption you can use gdb, or you can use an app called Clutch(which you installed earlier in Cydia). Clutch puts cracked apps in /var/root/Documents/Cracked/.Scp the .IPA file off the device to the Macbook Pro to analyse.
Looking for strings in the binary
Unzip the .IPA file (it's a package really) that you received from the previous step. Go to the extracted folder, e.g./BAH.app/<BAH> and use "strings" on the binary: stringsBAH > stringsdump.txt. Review stringsdump.txt for any useful stuff.HINT: grep "password", "secret", "http://","encrypt", etc, etc.
Looking at classes, objects, libraries
Use class-dump against the binary and discover information: ./class-dumpbinary or otool: ./otool -ov binary. Things here will become useful during runtime manipulation - variables, view classes, etc.
App files
Apps are installed in /var/mobile/Applications/<ID>/.Inside <APP>.app are application resource files including the binary. Have a look for cached data, databases, etc. A typical app file structure looks like:
/var/mobile/Applications/<ID>/App.app/
/var/mobile/Applications/<ID>/Library/Caches/
/var/mobile/Applications/<ID>/Library/Cookies/
/var/mobile/Applications/<ID>/Library/Preferences/
/var/mobile/Applications/<ID>/tmp/
/var/mobile/Applications/<ID>/Documents/
various .plist files
various .sqlite files
Keychain
Apple's Keychain also worth a look for sensitive data relating to the app: /var/Keychains/keychain-2.db. Use the KeychainDumper tool at https://github.com/ptoomey3/Keychain-Dumper/blob/master/keychain_dumper to dump allKeychain items (using a wildcard entitlements.xml). If you don't trust the binary you can also download the source and build it yourself.
Finito.
What I covered is finding low hanging fruit. Testing past this point will depend on what the app does, its complexity, etc. A lot of testing can be done via Burp as it will interface with web services in many cases, speak HTTP(S) (JSON goodness) and the OWASP Top 10 will apply. Other things to look for; how the app is sent to the background (snapshots), file protection, how it uses the pasteboard, how input/output is handled (UI Web View), etc. There is also a whole world related to runtime manipulation... another blog post!