ios application penetration testing for beginners

PRATEEK GIANCHANDANI

1

iOS Application Pen-testing for beginners

Twitter:@prateekg147

Email:prateek.searchingeye@gmail.com

ABOUT ME

• Security Researcher (5 years)

• iOS Developer (3 years) - 5 apps on the app store

• Author of Damn Vulnerable iOS Application

• Blogger (http://highaltitudehacks.com)

• Freelance penetration tester

AGENDA

• Setting up an iOS pen-testing environment• Understanding the iOS filesystem• Understanding the Objective-C runtime• Runtime analysis and manipulation• Insecure Data storage• Side channel data leakage• URL schemes• Analyzing network traffic over HTTP/HTTPs• Jailbreak detection• Broken cryptography• Secure coding guidelines• Patching iOS applications• Automated testing

Setting up an iOS pen testing environment

WHAT YOU NEED ?

• A jailbroken iOS device

• Xcode installed

• Some tools that need to be installed on your jailbroken device

• Jailbreak your device by downloading the evasi0n software from evasi0n.com

• Click on jailbreak and follow the process to jailbreak your device

• Big boss recommended tools from cydia

• Open SSH

• class-dump or class-dump-z (https://code.google.com/p/networkpx/wiki/class_dump_z)

• cycript (http://www.cycript.org/)

• clutch (https://dl.dropboxusercontent.com/u/34557464/clutch)

• gdb (https://dl.dropboxusercontent.com/u/34557464/gdb)

Also install the following on your device

• Download a good file explorer utility, for e.g iExplorer.

Understanding the iOS filesystem

• All the applications installed by Apple by default go inside the /Applications directory and run with the user root.

• All the applications downloaded from the app store go inside /var/mobile/applications and run with the user mobile.

• Every application runs in its own environment known as the application sandbox, thereby preventing it to access resources from other applications. This is done to enforce additional security.

Here is how a typical application directory looks likeThe APP_NAME.app folder contains the application binary.

Xcode

IDE for developing native iOS applicationshttps://developer.apple.com/xcode/

Understanding the Objective-C runtime

• All native iOS applications are written in Objective-C, which is a runtime oriented language.

• Objective-C defers decisions from compile time and link time to the time when the code in the application is actually being executed.

• Gives rise to a category of attacks knows as runtime manipulation.

• Variables and properties can be analyzed and modified at runtime.

• Messages aren’t bound to method implementations until runtime, thereby allowing us to modify the method implementations.

• The functions are implemented in the shared library found at /usr/lib/libobjc.A.dylib.

Usage: otool -l [binaryName]

• Objective-C is based on the messaging framework.

• Whenever a message is being sent, the objc_msgSend() method gets called.

• Setting a breakpoint for the objc_msgSend call can help us analyze the flow of the application.

• r0 register points to the class on which the method is being called.

• r1 is a string that denotes the method signature.

Runtime Analysis with GDB

Runtime Analysis with GDB

• Set a breakpoint for objc_msgSend.

• Use commands to execute a command when the breakpoint is being hit.

• Print out the values of r0 and r1

Runtime Analysis with GDB

• Command line utility. Extremely helpful tool in iOS pentesting.

• Extracts class information from unencrypted Mach-O binaries.

• Helps in finding out the method names, properties, protocols being used in any class.

• Tells a lot about the design of the application.

• Information is presented in a readable format.

class-dump-z

Usage: class-dump-z [binaryName]

• Application that are installed by default on iOS device won’t be encrypted, and hence class information can be dumped without any issues.

• For applications downloaded from the App store, you must decrypt the application first using clutch.

class-dump-z

Usage: clutch [App Name]

• Just using the clutch command will display a list of applications that can be decrypted.

• Use “clutch [App Name]” to decrypt the application. The decrypted ipa file will be stored in the location as shown below.

• Unzip the ipa file to a new folder.

• Dump the class information from the binary inside this folder.

• According to cycript.org - Cycript allows developers to explore and modify running applications on either iOS or Mac OS X using a hybrid of Objective-C++ and JavaScript syntax through an interactive console that features syntax highlighting and tab completion.

• Allows the user to hook into a running process during runtime and modify the values of instance variables, global variables, swizzle method implementations, call a particular method etc.

• Complete documentation can be found at http://www.cycript.org/

Cycript

Setting up Cycript

Runtime analysis using Cycript

• You can hook into the runtime of an application by using the command “cycript -p [PID]”

• Some cool things that you can do with Cycript can be found here http://iphonedevwiki.net/index.php/Cycript_Tricks

• For the case below, you can define a method named printMethods that takes input as a class and prints out all its methods.

• This method has been taken from http://iphonedevwiki.net/index.php/Cycript_Tricks

• For e.g, you can define your own methods.

• You can also use the messages property of a class to print out all its messages, for e.g “AppDelegate.messages”. This will only print out the instance methods.

• If you want to print out the class methods as well, use the isa pointer and print out its messages. The isa pointer for any object is a pointer to its class structure. For e.g “AppDelegate->isa.messages”

• This will print out the class methods.

• Similarly, you can also print out the instance methods of any view controller, class etc. In the example below, i am printing out the instance methods for the class RuntimeManipulationVC.

Runtime manipulation using Cycript

• With cycript, you can manipulate the values of instance variables, global variables for a particular class.

• You can also modify method implementations.

Runtime manipulation demo

• In this case, we are manipulating the instance variable “urlToLoad” in the view controller RuntimeManipulationDetailsVC for DamnVulnerableiOSApp (http://damnvulnerableiosapp.com)

• The first step is to get a reference to the view controller.

• Once you get the reference, you can modify any of it’s variables.

• For e.g UIApp.keyWindow.rootViewController.topViewController.topViewController.urlToLoad = [NSString stringWithFormat:@"http://google.com"];

• We can also swizzle method implementations and replace the method implementation with our own.

• Let’s assume you find a method with the name isLoginValidated in a particular view controller that returns a YES or NO depending on whether the login information is correct or not.

• To try this demo, download Damn Vulnerable iOS app from http://damnvulnerableiosapp.com

Runtime manipulation demo (Method Swizzling)

• We can modify this method’s implementation to always return TRUE.

• As you can see, the code on the R.H.S is actually Javascript, this is the beauty about Cycript, it can contain both Objective-C and javascript syntax.

Runtime manipulation demo (Method Swizzling)

• RuntimeManipulationDetailsVC.messages['isLoginValidated'] = function() {return TRUE;}

• Plist

• NSUserDefaults

• CoreData (Sqlite)

• Keychain

Insecure Local Data Storage

There are many ways of storing data locally on an iOS device.Some of these techniques are …

• Data stored in plist files is stored unencrypted in the application sandbox.

• An attacker doesn’t even need to have a jailbroken device to access the contents of the plist file. It can be accessed using simple file explorer utilities like iExplorer.

• Most often, developers make the mistake of storing confidential data in Plist files.

Plist

Plist

• Sample code for storing data in plist files.

Plist

• These files can be easily found using any simple file explorer utility like iExplorer in the application folder.

Plist

• On inspecting these files, you can find the information being saved in the plist file.

Plist

• Do not use plist files to store confidential information like username/passwords.

• Do not store session ID’s , important properties etc in a plist file.

• Plist files should only be used to store information that is not important, for e.g, a list of image names, the last launch date of the application etc.

NSUserDefaults

• Used for storing properties, objects that can persist even after an application restart.

• Information is saved unencrypted inside the application sandbox in a plist file with the name [BUNDLE_ID].plist inside the folder Library -> preferences .

• Developers make a common mistake of storing critical data using NSUserDefaults.

NSUserDefaults

• All the information stored using NSUserDefaults can be found inside the file [BUNDLE_ID].plist inside the folder Library -> Preferences.

NSUserDefaults

• All the key/value pairs stored using NSUserDefaults can be found in this file.

Core Data

• Core Data framework is used to store persistent data, manage relationships between objects etc.

• Information is again saved unencrypted on the device in .db or .sqlite files.

• An attacker can gather information about Core data objects by using a sqlite client.

• Navigate to your application directory and look for files with the extension .db or .sqlite.

• Use an sqlite client to access these files.

Core Data

• You can dump information from the tables in the database using the commands as shown in the image below.

Core Data

Core Data

• Core data framework should not be used to store confidential information as the information is stored unencrypted on the device.

• If you want to save some confidential informaiton, encrypt it before saving locally or use some wrappers over core data that store encrypted information on the device.

Keychain

• It is the most secure way of storing information locally on the device.

• Used by most of the popular application like Gmail, Facebook to store confidential information like passwords, authentication tokens etc.

• Currently, information stored in the keychain can only be dumped from a jailbroken device using a tool named Keychain Dumper.

• https://github.com/ptoomey3/Keychain-Dumper

Keychain dumper demo

Keychain dumper demo

• Keychain information dumped for the application Damn Vulnerable iOS app can be clearly found in the image below.

• Even though keychain is one of the most secure places to store information, consider adding an extra layer of encryption before saving data using keychain to make the job even more difficult for the attacker.

Side Channel Data leakage

• There are many different ways in which data can be leaked from the application without the awareness of the developer.

• Device Logs

• Application snapshots

• Pasteboard

• Keystroke logging

Device Logs

• Some developer use logs while debugging their applications but forget to remove them while releasing the application.

• To see the device logs while you are running an application, make sure that the device is connected to your computer.

• In Xcode, go to Window -> Organizer -> Device -> Your Device -> Console.

Device Logs

• Device logs should only be enabled for DEBUG mode in the application, this will ensure that the logs are disabled when the application is downloaded from the App store and run on a user’s device.

Application Snapshots

• iOS by default takes a screenshot of your application when you take the application to background by pressing the home button.

• This screenshot is shown to the user when he opens the app again while the app is loaded in the background.

• This is done to provide a seamless experience.

• The problem is that the screenshot is stored without any protection in the application folder.

• Sometimes, these screenshots can contain confidential information that might be leaked to an attacker.

Application Snapshots

• The following image shows the application snapshot stored in the application folder.

Pasteboard

• Data copied using the cut/copy features in iOS goes inside a buffer known as a pasteboard item.

• It is possible for other applications to access the content of this pasteboard.

• If the pasteboard item contains some confidential information, it might lead to information leakage.

Pasteboard

• Data can be copied using the Copy feature in iOS.

• Once it is copied, it remains in the buffer.

Pasteboard

• Using the following command in Cycript or any other app can dump out the contents of the pasteboard.

[UIPasteboard generalPasteboard].items[0]55544555555

[UIPasteboard generalPasteboard].items[0]

Pasteboard

• For text fields that might contain secure information, make sure the Secure property is set.

• Clear pasteboard contents when the application enters background.

[UIPasteboard generalPasteboard].items[0]55544555555

• Use pasteboard with specific identifiers, this makes it difficult for other applications to fetch data from this pasteboard item.

Keystroke logging

• iOS by default logs every input that you enter in any text field unless the secure flag is not set.

• This helps in autocorrecting the user later.

• All the keystroke logs can be easily fetched out from a device.

• These logs might contain information that is important.

• Logs remain stored on the device for a long time hence making it even more insecure.

• Logs are stored in a file with the extension .dat in the location “/var/mobile/Library/Keyboard/“

[UIPasteboard generalPasteboard].items[0]55544555555

Keystroke logging

• The prefix of the file denotes the language in which the keystroke logs are stored.

• Here is how a part of the logs file look like.

[UIPasteboard generalPasteboard].items[0]55544555555

URL Schemes

• Used for IPC between applications.

• Every application can register for a particular URL scheme.

• Any url starting with that particular URL scheme invokes the application that is registered to handle that url.

• For e.g, the facebook iOS application registers for the URL scheme “fb”

• Url’s starting with fb:// will invoke the facebook iOS application.

• The Facebook iOS application will decide what to do with that particular url depending on its parameters.

• For e.g fb://chat_text?name=Prateek&message=Hello

[UIPasteboard generalPasteboard].items[0]55544555555

URL Schemes

• Any application can call a url starting with a particular url scheme and invoke the registered application.

• Attacker can also embed the url inside an iframe in a malicious page, and hence when the user visits the page, the url will execute and the registered application will be called.

• These URL schemes can be used to execute important operations, for e.g FaceTime iOS app allowed other apps to call users via URL schemes.

• The problem happens when the operation is executed without any validation from the user.

[UIPasteboard generalPasteboard].items[0]55544555555

• A simple solution for this is to validate the action before performing it.

• For critical apps, you can also set a list of whitelisted applications and only allow them to invoke an action. This can be checked by the sourceApplication property in the calling method.

• Skype URL scheme vulnerability http://software-security.sans.org/blog/2010/11/08/insecure-handling-url-schemes-apples-ios/

URL Schemes

• How to find out the URL scheme used by a particular application ?

• This info can be found from the Info.plist file.

URL Schemes

• Look for the property CFBundleURLSchemes inside CFBundleURLTypes -> Item 0

• As we can see, the Facebook iOS app registers for quite a lot of URL schemes.

URL Schemes

• Another important thing could be to find out the URL structure an application is expecting in order to perform a certain action.

• This can be found by reverse engineering the application using tools like Hopper (hopperapp.com) and looking for strings that start with that particular URL scheme or looking at the disassembly of this method in the AppDelegate class.

• Related article: http://highaltitudehacks.com/2014/03/07/ios-application-security-part-30-attacking-url-schemes

URL Schemes

• It is important to analyze the network traffic that flows between the client/server in an application.

• Look for credentials, authentication tokens, API keys being transmitted over unsecured http channel.

• Check for the entropy in Session ID’s.

• Traffic can be analyzed using a simple proxy tool like Burp proxy.

• Try to manipulate the request/response using Burp and see how the client side application responds to it.

Analyzing network traffic over HTTP/HTTPs

Analyzing traffic over HTTP

• Configure Burp Proxy to start listening for traffic. Make sure it is listening on all interfaces.

Analyzing traffic over HTTP

• Configure your iOS device to use your computer as a proxy.

Analyzing traffic over HTTP

• You can now intercept the traffic as it goes to the server.

Analyzing traffic over HTTPs

• This will require you to install Burp’s CA certificate as a trusted root on your device.

• Configure your browser to relay traffic over Burp proxy.

Analyzing traffic over HTTPs

• You will get a warning, click on Add Exception.

Analyzing traffic over HTTPs

• Click on View.

Analyzing traffic over HTTPs

• Go to Details, select the topmost certificate, click on Export and save the file with extension as .crt

Analyzing traffic over HTTPs

• Send this file to your device via email, click on it and Install it. Accept all the instructions and click on Done.

Analyzing traffic over HTTPs

• Quit and restart the application you want to sniff traffic for. You will now be able to see the traffic even if it is over HTTPs

• For critical applications like banking applications etc, it is important that you ensure that the application doesn’t work on a jailbroken device.

• With a copy of your app’s binary and tools like Cycript at his disposal, an attacker is in complete control on a jailbroken device.

• It is therefore important to check for a jailbroken device and disable certain features of the application or quit the application in order to protect it from executing certain operations.

• Application can be quit by using by a single line of code, for e.g exit(-1).

Jailbreak Detection

• There are many ways to check for a jailbroken device.

• Checking for specific files that exist on a jailbroken device is one of the most common techniques being used.

• Another way is to check if the application is able to modify a file outside it’s own sandbox.

• Most than 80% of the jailbroken devices have Cydia installed, so check if you can open a url that starts with Cydia’s URL scheme, i.e cydia://

• It is important to note that no that there is no foolproof technique to detect a jailbroken device, however a combination of checks can make the job difficult for even a skilled hacker.

Jailbreak Detection

+(BOOL)isJailbroken{ #if !(TARGET_IPHONE_SIMULATOR) if ([[NSFileManager defaultManager] fileExistsAtPath:@"/Applications/Cydia.app"]){ return YES; }else if([[NSFileManager defaultManager] fileExistsAtPath:@"/Library/MobileSubstrate/MobileSubstrate.dylib"]){ return YES; }else if([[NSFileManager defaultManager] fileExistsAtPath:@"/bin/bash"]){ return YES; }else if([[NSFileManager defaultManager] fileExistsAtPath:@"/usr/sbin/sshd"]){ return YES; }else if([[NSFileManager defaultManager] fileExistsAtPath:@"/etc/apt"]){ return YES; } NSError *error; NSString *stringToBeWritten = @"This is a test."; [stringToBeWritten writeToFile:@"/private/jailbreak.txt" atomically:YES encoding:NSUTF8StringEncoding error:&error]; if(error==nil){ //Device is jailbroken return YES; } else { [[NSFileManager defaultManager] removeItemAtPath:@"/private/jailbreak.txt" error:nil]; } if([[UIApplication sharedApplication] canOpenURL:[NSURL URLWithString:@"cydia://package/com.example.package"]]){ //Device is jailbroken return YES; } #endif //All checks have failed. Most probably, the device is not jailbroken return NO; }

Jailbreak Detection

• Combining all the usual techniques, we get this method.

Jailbreak Detection

• The problem is that the signature of this method gives everything away.

• Attacker can use Cycript to bypass the check for jailbreak detection.

Jailbreak Detection

• It is better to rename the method to something that doesn’t look important.

• Something like +(BOOL)isDefaultColour.

• Yeah i know, we do ignore the iOS coding guidelines, but in this case, the guidelines are something that gives everything away.

• After analyzing the class-dump output of the application, the hacker is most likely to ignore this method.

• He can always reverse engineer this method to see what’s going on inside, so this method is also not foolproof.

Broken Cryptography

• Occurs when data stored on the device is not encrypted properly.

• One of the most common vulnerabilities found in iOS applications.

• Can also occur by use of deprecated or weak algorithms.

• Sometimes the key used in encryption is hardcoded in the app thereby making it much easier for the attacker to break into the application.

• Related article: http://www.andreas-kurtz.de/2013/07/how-to-easily-spot-broken-cryptography.html

Secure coding guidelines

• Do not store confidential data using NSUserDefaults, plist files or Core Data framework. Use keychain to store data like passwords, authentication tokens, API-keys etc.

• Use proper encryption while storing data locally in any insecure place. Do not use hardcoded keys etc.

• Validate incoming URLs using URL schemes and properly authorize the user before taking any action.

• Add checks to detect jailbroken device for critical applications like banking applications etc.

• Text fields that might contain important information should be marked Secure. This will prevent leaking of data via pasteboard, application snapshots etc.

• Clear pasteboard data when the application enters into background.

• Add checks to prevent debuggers from hooking into your application. Add the highlighted lines of code in your application.

Secure coding guidelines

Patching iOS applications

• Patching an application changes its logic permanently.

• This is better that making a change in cycript where you have to repeat the same process over and over again after an application restart.

• Often used to disable checks like Jailbreak detection, piracy check etc.

• Tools used for patching iOS application: IDA Pro, Hexfiend and Hopper.

• Once an application has been patched, it needs to be resigned using ldid before it can be deployed on the device.

Patching iOS applications

• Hopper is one of the best tools available for patching iOS applications.

• Not free, but the value for money is very good.

• Patching iOS applications with Hopper: http://highaltitudehacks.com/2014/01/17/ios-application-security-part-28-patching-ios-application-with-hopper/

• Patching iOS applications with IDA Pro and Hex fiend:http://highaltitudehacks.com/2013/12/17/ios-application-security-part-26-patching-ios-applications-using-ida-pro-and-hex-fiend

Patching iOS applications

• To modify any instruction in Hopper, click on Modify -> Assemble Instruction.

Patching iOS applications

• Make the change and click on Assemble and Go Next

Patching iOS applications

• Once the change has been made, click on File -> Produce new executable and overwrite the existing one.

Patching iOS applications

• To deploy the application back to your device, resign the application binary first using ldid as shown in the image below.

Then copy the .app file to the /Applications directory on the device using Scp. You can also use sftp or the utility iExplorer to upload this application.

Patching iOS applications

Now login as the mobile user, use the command su to get root privileges and give the binary executable permissions. Then use the exit command to go back as the mobile user, and use the command uicache to install the application. If this doesn’t work, you can reboot the device or try this method again.

You will see that the application has been successfully installed on your device.

Automated testing

• Automating tests while doing an iOS penetration test can help you save a lot of time.

• Though not all tests can be automated, there are some tools that do a very good job at this.

• Snoop-it - https://code.google.com/p/snoop-it/

• iNalyzer - https://appsec-labs.com/iNalyzer

• iRET - https://blog.veracode.com/2014/03/introducing-the-ios-reverse-engineering-toolkit/

Snoop-it

• Source: https://code.google.com/p/snoop-it/

• For iOS 7, it currently supports only 32 bit devices.

• Related article: http://highaltitudehacks.com/2013/08/20/ios-application-security-part-9-analyzing-security-of-ios-applications-using-snoop-it/

Snoop-it

• Here is how the interface looks like.

iNalyzer

• Related article: http://highaltitudehacks.com/2013/09/17/ios-application-security-part-15-static-analysis-of-ios-applications-using-inalyzer/

iRET

Source: https://blog.veracode.com/2014/03/introducing-the-ios-reverse-engineering-toolkit/

• Related article: http://highaltitudehacks.com/2014/03/25/ios-application-security-part-32-automating-tasks-with-ios-reverse-engineering-toolkit-iret

Challenges

Make sure to download the lab exercises for this course.

1) Local data storage demo - Run the app localDataStorageDemo and try to find the place where the data is saved using NSUserDefaults, Keychain and plist.

2) Broken Cryptography- Run the app InsecureCryptographyDemo and set a password in the app. Using a weakness in the encryption technique, try to find out the password back from the application.

3) Runtime Analysis- Run the app GDB-demo and use runtime analysis techniques to bypass the login form in this app.

Further practice

Try out all the challenges in Damn Vulnerable iOS App (http://damnvulnerableiosapp.com)

THANK-YOU

Questions ?Get in touch !

prateek.searchingeye@gmail.com