2. • Intro to iOS applications
• 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/Cert pinning
• Jailbreak detection
• Broken cryptography
• Secure coding guidelines
• Patching iOS applications
• Automated testing
AGENDA
3. Intro to iOS applications
WHAT DO iOS apps look like ?
• Developed using Apple’s SDK Xcode.
• Distributed as .ipa files through the App store.
• Compiled for ARM architecture.
• Requires a provisioing profile to sign the application.
• Encrypted with FairPlay DRM and signed with Apple’s signature.
4. Intro to iOS applications
Types of iOS applications
• Native applications – Developed in Objective-C. Deliver much better
performance than web applications.
• Web applications – Developed in Html, CSS and javascript. Run using
Webkit.
• Hybrid applications – Combination of a web and native application.
6. Intro to iOS applications
What is Objective-C ?
Objective-C is a general-purpose, object-oriented programming
language that adds Smalltalk-style messaging to the C
programming language. It is the main programming language
used by Apple for the OS X and iOS operating systems, and their
respective application programming interfaces (APIs), Cocoa
and Cocoa Touch.
Source: Wikipedia
8. Intro to iOS applications
Header files have the extension .h while implementation files have the extension .m
A sample implementation file
Objective-C continued
10. • Swift is a brand new native programming language for iOS,
introduced at WWDC’14 for the first time.
• Even when written without a single line of Objective-C code, every
Swift app executes inside the Objective-C runtime.
• This may not always be the case – with the release of Swift-only
system frameworks a full Swift runtime may appear.
Introduction to Swift
11. • The important thing is that instead of objc_msgSend() method call,
Swift classes operate with vtable (which contains the table of
available methods).
• vtables are created at compile time (when objc dispatch tables are
generated dynamically).
• This table contains functions pointers accessed by index, so it
doesn’t need to bind selector to implementation.
Introduction to Swift
12. • Another interesting Swift feature is Name Mangling. Prepare to see
something like
__TFCCC4test1a1b1c1dfS2_FTS0_1xS1_1vFT1xSi_Si_OVS_1e1f when
analysing Swift apps.
• This string holds not only the exact function name, but also
information about it’s type, parameters, nested classes etc. This is
made for holding all the necessary method information in one
string in the vtable.
• The same thing goes for Class names.
• You can use the function _stdlib_demangleName() for demangling.
Introduction to Swift
13. Setting up an iOS pen testing environment
WHAT YOU NEED ?
• A jailbroken iOS device (up to iOS 8.2)
• Xcode installed on your system
• Some tools that need to be installed on your jailbroken device
14. • Jailbreak your device by downloading the pangu software from
pangu.io
• Click on “Start Jailbreak”and follow the process to jailbreak your
device
15. • For iOS 8.2 and iOS 8.3 you can make “Semi Jailbreak” using
Safari – just visit the page http://pangu8.com/82.html
• You’ll have to visit this page each time after rebooting your device
16. • 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)
• For iOS 8, make sure you tap on Refresh the first time you
open up Cydia.
Also install the following on your device
18. • Download a good file explorer utility like iExplorer or iFunbox
Understanding the iOS filesystem
19. • Download a good file explorer utility like iExplorer.
Understanding the iOS filesystem
20. • 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 (iOS
7)
• 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.
• For iOS 8, the applications downloaded from App store reside
in /var/mobile/Containers/Bundle/Application
21. • Downloaded applications bundles reside in
/var/mobile/Containers/Bundle/Application/<ID>/. Here you can
find the *.app file with all the resources included.
• Their /Documents and /Library data reside in
/var/mobile/Containers/Data/Application/<ID>/. Here you can
found writable application data, such as *.sqlite dbs or plist
files.
• Starting from iOS 8.0 many applications have different
extensions (widgets). Their shared data can be found in
/var/mobile/Containers/Shared/AppGroup/<ID>.
22. Here is how a typical application directory looks like
The *.app folder contains the application binary.
23. Here is how a typical shared application directory looks
like
25. Understanding the Objective-C runtime
• All native iOS applications are 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.
27. • 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
29. • 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
30. 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.
32. • Unzip the ipa file to a new folder.
• Dump the class information from the binary inside this
folder.
33. • 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
35. 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
36. • 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.
37. • 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.
38. • 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 as well.
39. • 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.
40. 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.
41. 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.topViewCont
roller.urlToLoad = [NSString stringWithFormat:@"http://google.com"];
42. • 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)
43. • 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 related both Objective-C and javascript
syntax.
Runtime manipulation demo (Method Swizzling)
• RuntimeManipulationDetailsVC.messages['isLoginValidated'] =
function() {return TRUE;}
44. • 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 …
45. • 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
47. Plist
• These files can be easily found using any simple file explorer
utility like iExplorer in the application folder.
48. Plist
• On inspecting these files, you can find the information being
saved in the plist file.
49. 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.
50. 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.
51. NSUserDefaults
• All the information stored using NSUserDefaults can be found
inside the file [BUNDLE_ID].plist inside the folder Library ->
Preferences.
53. 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.
54. • 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
55. • Navigate to your application directory and look for files with the
extension .db or .sqlite.
• Use an sqlite client to access these files.
• You can dump information from the tables in the database using
the commands as shown in the image below.
Core Data
57. 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 use some confidential informaiton, encrypt it
before saving locally or use some wrappers over core data that
store encrypted information on the device.
58. 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.
• Common database for all apps. Data is stored outside of the
application sandbox.
• 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
59. Keychain
• One line implementation.
• Access group allows applications to share keychain data.
KeychainItemWrapper *wrapper = [[KeychainItemWrapper alloc]
initWithIdentifier:@“Identifier” accessGroup:nil];
The same access group has to be given from both the apps and both
the app ID’s have to be mentioned in the plist file for both the
applications.
60. Storing Data in Keychain
• Using Keychain is quite simple (especially with third-party
wrappers). One of them is SSKeychain
(https://github.com/soffes/sskeychain):
• [SSKeychain setPassword:@”secretkey” forService:@”DVIA”
account:@”Admin”];
• NSString *pass = [SSKeychain passwordForService:@”DVIA”
account:@”Admin”];
62. 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 in the application to make the job for the attacker
more difficult.
63. Realm
• Realm is a popular third-party cross-platform built on a custom
C++ core.
• Just like in all other cases information is stored unencrypted in the
/Documents folder, in the *.realm files.
• An attacker can gather information using the default Realm
Browser: https://github.com/realm/realm-
cocoa/tree/master/tools/RealmBrowser
65. Apple Watch
• Apple Watch is the new wearable device from Apple.
• All the Apple Watch apps are simply extensions of native iOS
applications.
66. Apple Watch
• The running app extension and containing app have no direct
access to each other’s containers, so they use a shared data
directory for data syncing.
• Their shared data can be found in
/var/mobile/Containers/Shared/AppGroup/<ID>.
• So, all the Insecure Data Storage vulnerabilities can be applied to
Apple Watch extensions.
67. 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
• Cookies
68. 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
69. 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.
70. 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.
• Provides 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.
72. Pasteboard
• Data copied using the cut/copy features in iOS goes inside a
buffer known inside 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.
73. Pasteboard
• Data can be copied using the Copy feature in iOS.
• Once it is copied, it remains in the buffer.
74. Pasteboard
• Using the following command in Cycript or any other app can
dump out the contents of the pasteboard.
[UIPasteboard generalPasteboard].items[0]
75. 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.
76. 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/“
77. 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.
78. Cookies
• Some applications create persistance cookies and store them in
cookies.binarycookies file in application’s home directory.
• The sample code for storing cookies:
• [[NSHTTPCookieStorage sharedHTTPCookieStorage]
setCookie:cookie];
• The path to cookies is: /Library/Cookies/Cookies.binarycookies
[UIPasteboard generalPasteboard].items[0]
55544555555
79. Cookies
• Revealing cookies is quite easy:
• Download the python script BinaryCookieReader.py from
http://securitylearn.net/wp-
content/uploads/tools/iOS/BinaryCookieReader.py
• Download the Cookies.binarycookies file from your device.
• Run binarycookiereader.py /file-path-to-cookies
81. 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
82. 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, 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 allows other apps to call user via URL
scheme.
• The problem happens when the operation is executed without
any validation from the user.
83. • 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
84. • How to find out the URL scheme used by a particular
application ?
• This info can be found from the Info.plist file.
URL
Schemes
85. • 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
86. • 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
87. • 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
88. Analyzing traffic over HTTP
• Configure Burp Proxy to start listening for traffic. Make sure
it is listening on all interfaces.
89. Analyzing traffic over HTTP
• Configure your iOS device to use your computer as a proxy.
90. Analyzing traffic over HTTP
• You can now intercept the traffic as it goes to the server.
91. 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.
94. Analyzing traffic over HTTPs
• Go to Details, select the topmost certificate, click on Export
and save the file with extension as .crt
95. 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.
96. 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
97. Certificate pinning
• The server’s certificate is hardcoded in the application bundle
and checked while exchanging data with the server.
• Provides protection against MITM attacks.
• Used by applications like Twitter, Square etc.
98. Certificate pinning
• The server’s certificate is hardcoded in the application
bundle and checked while exchanging data with the
server.
• Provides protection against MITM attacks.
• Used by applications like Twitter, Square etc.
99. Certificate pinning bypass
• Certificate pinning can be bypassed by hooking into some
low level methods during runtime.
• iOS SSL kill switch was released in Blackhat to
demonstrate this.
• https://github.com/iSECPartners/ios-ssl-kill-switch
100. Certificate pinning bypass
• Once it is enabled, user can see the traffic through
applications like Twitter as well.
101. • Most of modern applications use some third-party services
for analytics, data storage, push-notifications, crash-
reporting, social-auth and so on.
• Besides different vulnerabilities in SDKs, this opens a couple
of new attack vectors for penetration tester:
• The unsecure storage of API keys,
• The lack of security on the server-side.
Attacking Third-Party Services
102. • Parse.com is a MBaaS which helps with setting up backend
infrastructure for mobile applications. Some of its
capabilities:
• Cloud data storage
• Push notifications
• Cloud code hosting
• Gathering usage statistics
Attacking Parse.com
103. • All the data in Cloud Core is stored in Parse Classes
(ordinary database tables).
Attacking Parse.com
104. • There are different levels of
access-permissions: class
level and object level.
We’re going to investigate
CLA.
• All of Class Level Access
permissions are set to
Public by default.
Attacking Parse.com
105. • Using Hopper we can extract the API keys and Parse Classes
names from target application:
Attacking Parse.com
106. • Now you can query the Parse API using these keys:
• [Parse setApplicationId:<APP_ID> clientKey:<CLIENT_KEY>]
• PFQuery *query = [PFQuery queryWithClassName:@”Target”];
• NSArray *data = [query findObjects];
• You can perform all the CRUD operations on class with Public
access permissions.
Attacking Parse.com
107. • To simplify these tasks, you can use the Parse Revealer utility:
https://github.com/igrekde/ParseRevealer
• It automates the analysis of access permissions and structure of
provided classes.
Attacking Parse.com
108. • Flurry.com is the most popular mobile analytics service.
• It uses the single API key to identify the application. This key
can be retrieved using Hopper app.
• With this key an attacker can build his own application,
generating a large number of random events and pollute the
target app’s statistics monitoring. It can lead to impossibility of
statistics analysis, which is very crucial for popular
applications.
Attacking Flurry.com
110. • 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.
• 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.
Jailbreak Detection
111. • 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
112. • 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
113. +(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 these techniques, we get this method.
114. Jailbreak Detection
• The problem is that the signature of this method gives
everything away.
• Attacker can use Cycript to use bypass the check for
jailbreak detection.
115. 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 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.
116. Broken Cryptography
• Occurs when data stored on the device is not encrypted
properly.
• One of the most common vulnerabilities found in iOS
applications.
• Can occur by use of deprecated or weak algorithms.
• Sometimes the key while encryption is hardcoded in the app
thereby making it much easier for the attacker to break the
application.
• Related article: http://www.andreas-kurtz.de/2013/07/how-
to-easily-spot-broken-cryptography.html
117. 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.
• Use libraries like SQLCipher to encrypt sqlite databases.
118. • 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
119. Patching iOS applications
• Patching an application changes its login permanently.
• This is better that making a change in cycript where you have to repeat
the same process over and over again.
• 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.
120. 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
121. Patching iOS applications
• To modify any instruction in Hopper, click on it and click on Modify ->
Assemble Instruction.
123. Patching iOS applications
• Once the change has been made, click on File -> Produce new executable
and overwrite the existing one.
124. 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.
125. 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.
126. Extracting Device Backups
• It’s possible to extract the data from iOS device for further
researches.
• The first way is using libimobiledevice – a library to communicate
with different services of iOS devices using native protocols.
• You can download it from GitHub:
https://github.com/libimobiledevice/libimobiledevice
127. Extracting Device Backups
• Run idevice_id –l for the list of connected devices
• Run idevicebackup2 backup --full --source <UDID>~/Documents to
make the full backup of the specified device.
128. Extracting Device Backups
• Download iBackupBot: http://www.icopybot.com/itunes-backup-
manager.htm
• Drag the backup folder to iBackupBot and enjoy browsing.
129. Extracting Device Backups
• The developer can mark files and directories to exclude them from
backups.
• The backup can be protected by the passcode.
130. Extracting iCloud Device Backups
• The other way of extracting backups is from iCloud.
• You need to know the AppleID and password, linked with the
target device.
• Use iLoot: https://github.com/hackappcom/iloot
• > python iloot.py email@icloud.com password
131. 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/
• idb - http://www.idbtool.com/
• iSpy - https://github.com/BishopFox/iSpy
132. 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/