Decrypting iOS Applications (Automatically)

My previous post was about how to decrypt the iOS application manually. It is good to know how does it work but it can be tiring if you want to decrypt many applications. All the mentioned steps are gathered together in one tool - Clutch by KJCracks.

Clutch

The application and source code are available on the github https://github.com/KJCracks/Clutch/releases. Clutch automatically decrypts the application and creates the .ipa files.

Using the Clutch

You need only to download the application from the github (the compiled version is available). Running Clutch without parameters shows all available applications that can be decrypted. Running Clutch with the name from the list decrypt the application, running with "-a" decrypts all listed application.

After the application is decrypted it can be installed as the ipa package and analyze.

Hack in the Box Amsterdam 2014

We are very pleased to announce that our presentation "Exploring and Exploiting iOS Web Browsers" has been accepted for the Hack in the Box Security Conference 2014 Amsterdam.

In the presentation, we will discuss how iOS third-party web browsers are built. We will go through the main properties and limitations of UIWebView, common features added by browser developers, and common design or programming flaws that result in security vulnerabilities. While security of the underlying WebKit engine is exposed to continuous research, and the imperfections of mobile browser UI are widely known, the publicly available resources dedicated to secure implementation of web views in iOS applications do not cover the challenges which a browser developer faces. We would like to fill this gap in at least a small part.
Apart from the theory and development advice, our talk will also be an opportunity to disclose a dozen of the most interesting examples of security vulnerabilities and weaknesses which we identified in the most popular iOS third-party web browsers, and in Safari/UIWebView itself. We will explain how did they arise, demonstrate their exploitation, show examples of vulnerable code (Objective C and JavaScript) and – where possible – patches that were issued to address these vulnerabilities. Finally, we will demonstrate a sample test suite which can be used to assess basic security properties of UIWebView implementations in iOS web browsers.
More details can be found here: http://haxpo.nl/hitb2014ams-pilorz-zmyslowski/

See you there :)

Decrypting iOS Applications (Manual)

Reversing the iOS application can be interesting and profitable. This short article presents how to decrypt an iOS application for reverse engineering. The example application is Puffin browser.

Pre-requirement

Before the application can be decrypted, some packages need to be installed.

• gdb - the GDB available from the Cydia repository is not working properly. The correct version can be downloaded from the Radere repository. One needs to add http://cydia.radare.org to the repository (the source setting need to be set to Developer)
  
• iOS Toolchain
• file
• adv-cmds
• gawk

All these packages need to be installed with required dependencies.

Finding the code

First thing what we need to check if the code is really encrypted. We can do this using the otool tool and looking for the  LC_ENCRYPTION_INFO section.

otool -arch all -Vl <app name> | grep -A4 LC_ENCRYPTION_INFO

Above command reveals two important information: the begining of the code (cryptoff) and the size of the code (cryptsize). It will be need during the dump of the code

Dumping memory

Because the iOS 7 is using ASLR the decrypted code will be located in different memory address ranges. We need to load it, run and stop after the decryption routine is finished (on the original application entry point). To do this we need to load the application in gdb and set break point on the begining of the application - UIApplicationMain.

When the gdb stops on the break point we can find the appropriate region. Using the info sharedlibrary command we can display all loaded libraries with their base addresses.

The Puffin application (position number 2) has the base address 0x9000. Now we can dump the code. To do this we will need two addresses - begin and end. They are calculated in follows:

Begin address = base address + cryptoff 
                                   0x9000 + 16384    = 0xD000

End address = base address + cryptoff + cryptsize 
                                0x9000 + 16384    + 511808    = 0x4ED000

The dump is made by the following command:

dump binary memory <dump name> <begin address> <end address>

Creating binary

 Now we need to copy the dumped code into the thin version of our application.

dd bs=1 seek=<cryptoff> conv=notrunc if=<dump name> of=<application>

Now the dump is completed and the application can ba analyzed using the IDA Pro or the Hopper Disassembler.

JavaScript Off for iOS

While testing UIWebView on iOS I found out there is no option to turn off JavaScript for web content. Initially I tried to use HTML5 "sandbox" attribute do achieve this, but in practice Content Security Policy is a much more flexible solution. Injecting CSP headers into NSHTTPURLResponse seems to work even for file: and data: URL schemes.

A sample application testing above solution is available on GitHub, and a similar solution has recently made its way into Onion Browser as an experimental feature. I am looking forward to see how it's going to work in practice.

On a side note, Quick Look is another solution if you need to load a single HTML document with JavaScript turned off.

iOS UIWebView baseURL

UIWebView is one of the most popular components in Cocoa Touch library. It can be used to easily embed web content into iOS applications and - of course - to equally easily introduce Cross-Site Scripting vulnerabilities.

When loading content into webView on iOS, a programmer can choose one of three methods:

• – loadData:MIMEType:textEncodingName:baseURL:
• – loadHTMLString:baseURL:
• – loadRequest:

Did you notice baseURL in the first two? This inconspicuous parameter is quite important when dealing with XSS.

Same Origin Policy works a bit different in iOS than we're used to in desktop browsers, namely file: and applewebdata: URLs have complete cross-origin access to any web resources, in addition to local file access. This means if you save untrusted HTML document locally and then call loadRequest method to load it from its file:/// path into UIWebView, you're simply creating a universal Cross-Site Scripting vulnerability. This document can now read all cookies stored by the application, call JavaScript across domains (including your corporate intranet), and do all that stuff Same Origin Policy usually prevents.

Alternatively to loading untrusted local file with loadRequest, you may first read its content and then use one of the two remaining methods: loadData or loadHTMLString. Unfortunately, by default UIWebView content is loaded with file/applewebdata privileges. This is where the baseURL comes in handy. Simply set the baseURL to "about:blank" URL and Same Origin Policy will prevent cross-origin access (as it probably should do by default, Apple?).

Of course this won't be enough if a webView contains sensitive data and untrusted content at the same time, or if you bridge JavaScript with Objective-C through special URLs catched in webView:shouldStartLoadWithRequest:request. In such cases you should remove all XSS vulnerabilities from your application, one by one.

WebView security in iOS - presentation from OWASP Poland meeting

English translation: http://www.slideshare.net/lpilorz/webview-security-on-ios-en
Original (Polish) version: http://www.slideshare.net/lpilorz/webview-security-on-ios-pl