| .. | ||
| basic-ios-testing-operations.md | ||
| burp-configuration-for-ios.md | ||
| extracting-entitlements-from-compiled-application.md | ||
| frida-configuration-in-ios.md | ||
| ios-basics.md | ||
| ios-pentesting-checklist.md | ||
| ios-testing-environment.md | ||
| README.md | ||
iOS Pentesting
iOS Basics
{% page-ref page="ios-basics.md" %}
Testing Environment
In this page you can find information about the iOS simulator, emulators and jailbreaking:
{% page-ref page="ios-testing-environment.md" %}
Initial Analysis
Basic iOS Testing Operations
During the testing several operations are going to be suggested connect to the device, read/write/upload/download files, use some tools.... Therefore, if you don't know how to perform any of these actions please, start reading the page:
{% page-ref page="basic-ios-testing-operations.md" %}
{% hint style="info" %}
For the following steps the app should be installed in the device and should have already obtained the IPA file of the application.
Read the Basic iOS Testing Operations page to learn how to do this.
{% endhint %}
Basic Static Analysis
It's recommended to use the tool MobSF to perform an automatic Static Analysis to the IPA file.
Listing Installed Apps
When targeting apps that are installed on the device, you'll first have to figure out the correct bundle identifier of the application you want to analyze. You can use frida-ps -Uai to get all apps `-a` currently installed `-i` on the connected USB device `-U`:
$ frida-ps -Uai
PID Name Identifier
---- ------------------- -----------------------------------------
6847 Calendar com.apple.mobilecal
6815 Mail com.apple.mobilemail
- App Store com.apple.AppStore
- Apple Store com.apple.store.Jolly
- Calculator com.apple.calculator
- Camera com.apple.camera
- iGoat-Swift OWASP.iGoat-Swift
Basic Enumeration of the app
For this section the tool Objection is going to be used.
Start by getting an objection's session executing something like objection -d --gadget "iGoat-Swift" explore or objection -d --gadget "OWASP.iGoat-Swift" explore
-
env: Find the paths where the application is stored inside the deviceenv Name Path ----------------- ----------------------------------------------------------------------------------------------- BundlePath /private/var/containers/Bundle/Application/179A6E8B-E7A8-476E-BBE3-B9300F546068/iGoat-Swift.app CachesDirectory /var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Library/Caches DocumentDirectory /var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Documents LibraryDirectory /var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Library -
ios bundled list_bundles: List bundles of the applicationios bundles list_bundles Executable Bundle Version Path ------------ -------------------- --------- ------------------------------------------- iGoat-Swift OWASP.iGoat-Swift 1.0 ...8-476E-BBE3-B9300F546068/iGoat-Swift.app AGXMetalA9 com.apple.AGXMetalA9 172.18.4 ...tem/Library/Extensions/AGXMetalA9.bundle -
ios bundle list_frameworks: List external frameworks used by the applicationios bundles list_frameworks Executable Bundle Version Path ------------------------------ -------------------------------------------- ---------- ------------------------------------------- ReactCommon org.cocoapods.ReactCommon 0.61.5 ...tle.app/Frameworks/ReactCommon.framework ...vateFrameworks/CoreDuetContext.framework FBReactNativeSpec org.cocoapods.FBReactNativeSpec 0.61.5 ...p/Frameworks/FBReactNativeSpec.framework ...ystem/Library/Frameworks/IOKit.framework RCTAnimation org.cocoapods.RCTAnimation 0.61.5 ...le.app/Frameworks/RCTAnimation.framework jsinspector org.cocoapods.jsinspector 0.61.5 ...tle.app/Frameworks/jsinspector.framework DoubleConversion org.cocoapods.DoubleConversion 1.1.6 ...pp/Frameworks/DoubleConversion.framework react_native_config org.cocoapods.react-native-config 0.12.0 ...Frameworks/react_native_config.framework react_native_netinfo org.cocoapods.react-native-netinfo 4.4.0 ...rameworks/react_native_netinfo.framework PureLayout org.cocoapods.PureLayout 3.1.5 ...ttle.app/Frameworks/PureLayout.framework GoogleUtilities org.cocoapods.GoogleUtilities 6.6.0 ...app/Frameworks/GoogleUtilities.framework RCTNetwork org.cocoapods.RCTNetwork 0.61.5 ...ttle.app/Frameworks/RCTNetwork.framework RCTActionSheet org.cocoapods.RCTActionSheet 0.61.5 ....app/Frameworks/RCTActionSheet.framework react_native_image_editor org.cocoapods.react-native-image-editor 2.1.0 ...orks/react_native_image_editor.framework CoreModules org.cocoapods.CoreModules 0.61.5 ...tle.app/Frameworks/CoreModules.framework RCTVibration org.cocoapods.RCTVibration 0.61.5 ...le.app/Frameworks/RCTVibration.framework RNGestureHandler org.cocoapods.RNGestureHandler 1.6.1 ...pp/Frameworks/RNGestureHandler.framework RNCClipboard org.cocoapods.RNCClipboard 1.5.1 ...le.app/Frameworks/RNCClipboard.framework react_native_image_picker org.cocoapods.react-native-image-picker 2.3.4 ...orks/react_native_image_picker.framework [..] -
memory list modules: List loaded modules in memorymemory list modules Name Base Size Path ----------------------------------- ----------- ------------------- ------------------------------------------------------------------------------ iGoat-Swift 0x104ffc000 2326528 (2.2 MiB) /private/var/containers/Bundle/Application/179A6E8B-E7A8-476E-BBE3-B9300F54... SubstrateBootstrap.dylib 0x105354000 16384 (16.0 KiB) /usr/lib/substrate/SubstrateBootstrap.dylib SystemConfiguration 0x1aa842000 495616 (484.0 KiB) /System/Library/Frameworks/SystemConfiguration.framework/SystemConfiguratio... libc++.1.dylib 0x1bdcfd000 368640 (360.0 KiB) /usr/lib/libc++.1.dylib libz.1.dylib 0x1efd3c000 73728 (72.0 KiB) /usr/lib/libz.1.dylib libsqlite3.dylib 0x1c267f000 1585152 (1.5 MiB) /usr/lib/libsqlite3.dylib Foundation 0x1ab550000 2732032 (2.6 MiB) /System/Library/Frameworks/Foundation.framework/Foundation libobjc.A.dylib 0x1bdc64000 233472 (228.0 KiB) /usr/lib/libobjc.A.dylib [...] -
memory list exports <module_name>: Exports of a loaded modulememory list exports iGoat-Swift Type Name Address -------- -------------------------------------------------------------------------------------------------------------------------------------- ----------- variable _mh_execute_header 0x104ffc000 function _mdictof 0x10516cb88 function _ZN9couchbase6differ10BaseDifferD2Ev 0x10516486c function _ZN9couchbase6differ10BaseDifferD1Ev 0x1051648f4 function _ZN9couchbase6differ10BaseDifferD0Ev 0x1051648f8 function _ZN9couchbase6differ10BaseDiffer5setupEmm 0x10516490c function _ZN9couchbase6differ10BaseDiffer11allocStripeEmm 0x105164a20 function _ZN9couchbase6differ10BaseDiffer7computeEmmj 0x105164ad8 function _ZN9couchbase6differ10BaseDiffer7changesEv 0x105164de4 function _ZN9couchbase6differ10BaseDiffer9addChangeENS0_6ChangeE 0x105164fa8 function _ZN9couchbase6differlsERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEERKNS0_6ChangeE 0x1051651d8 function _ZN9couchbase6differlsERNSt3__113basic_ostreamIcNS1_11char_traitsIcEEEERKNS1_6vectorINS0_6ChangeENS1_9allocatorIS8_EEEE 0x105165280 variable _ZTSN9couchbase6differ10BaseDifferE 0x1051d94f0 variable _ZTVN9couchbase6differ10BaseDifferE 0x10523c0a0 variable _ZTIN9couchbase6differ10BaseDifferE 0x10523c0f8 [..] -
ios hooking list classes: List classes of the appios hooking list classes AAAbsintheContext AAAbsintheSigner AAAbsintheSignerContextCache AAAcceptedTermsController AAAccount AAAccountManagementUIResponse AAAccountManager AAAddEmailUIRequest AAAppleIDSettingsRequest AAAppleTVRequest AAAttestationSigner [...] -
ios hooking list class_methods: List methods of a specific classios hooking list class_methods iGoat_Swift.RCreditInfo - cvv - setCvv: - setName: - .cxx_destruct - name - cardNumber - init - initWithValue: - setCardNumber: -
ios hooking search classes <search_term>: Search a class that contains a stringios hooking search classes iGoat iGoat_Swift.CoreDataHelper iGoat_Swift.RCreditInfo iGoat_Swift.SideContainmentSegue iGoat_Swift.CenterContainmentSegue iGoat_Swift.KeyStorageServerSideVC iGoat_Swift.HintVC iGoat_Swift.BinaryCookiesExerciseVC iGoat_Swift.ExerciseDemoVC iGoat_Swift.PlistStorageExerciseViewController iGoat_Swift.CouchBaseExerciseVC iGoat_Swift.MemoryManagementVC [...] -
ios hooking search methods <search_term>: Search a method that contains a stringios hooking search methods cvv [AMSFinanceVerifyPurchaseResponse + _dialogRequestForCVVFromPayload:verifyType:] [AMSFinanceVerifyPurchaseResponse - _handleCVVDialogResult:shouldReattempt:] [AMSFinanceVerifyPurchaseResponse - _runCVVRequestForCode:error:] [iGoat_Swift.RCreditInfo - cvv] [iGoat_Swift.RCreditInfo - setCvv:] [iGoat_Swift.RealmExerciseVC - creditCVVTextField] [iGoat_Swift.RealmExerciseVC - setCreditCVVTextField:] [iGoat_Swift.DeviceLogsExerciseVC - cvvTextField] [iGoat_Swift.DeviceLogsExerciseVC - setCvvTextField:] [iGoat_Swift.CloudMisconfigurationExerciseVC - cvvTxtField] [iGoat_Swift.CloudMisconfigurationExerciseVC - setCvvTxtField:]
Basic Hooking
Now that you have enumerated the classes and modules used by the application you may have found some interesting class and method names.
-
ios hooking watch class <class_name>: Hook all the methods of a class, dump all the initial parameters and returnsios hooking watch class iGoat_Swift.PlistStorageExerciseViewController -
ios hooking watch method "-[<class_name> <method_name>]" --dump-args --dump-return --dump-backtrace: Hook an specific method of a class dumping the parameters, backtraces and returns of the method each time it's calledios hooking watch method "-[iGoat_Swift.BinaryCookiesExerciseVC verifyItemPressed]" --dump-args --dump-backtrace --dump-return -
ios hooking set return_value "-[<class_name> <method_name>]" false: This will make the selected method return the indicated booleanios hooking set return_value "-[iGoat_Swift.BinaryCookiesExerciseVC verifyItemPressed]" false -
ios hooking generate simple <class_name>:ios hooking generate simple iGoat_Swift.RCreditInfo var target = ObjC.classes.iGoat_Swift.RCreditInfo; Interceptor.attach(target['+ sharedSchema'].implementation, { onEnter: function (args) { console.log('Entering + sharedSchema!'); }, onLeave: function (retval) { console.log('Leaving + sharedSchema'); }, }); Interceptor.attach(target['+ className'].implementation, { onEnter: function (args) { console.log('Entering + className!'); }, onLeave: function (retval) { console.log('Leaving + className'); }, }); Interceptor.attach(target['- cvv'].implementation, { onEnter: function (args) { console.log('Entering - cvv!'); }, onLeave: function (retval) { console.log('Leaving - cvv'); }, }); Interceptor.attach(target['- setCvv:'].implementation, { onEnter: function (args) { console.log('Entering - setCvv:!'); }, onLeave: function (retval) { console.log('Leaving - setCvv:'); }, });
IPA Structure
.ipa files are zipped packages, so you can change the extension to .zip and decompress them. A complete packaged app ready to be installed is commonly referred to as a Bundle.
After decompressing them you should see <NAME>.app , a zipped archive that contains the rest of the resources.
Info.plist: A file that contains some of the application specific configurations._CodeSignature/contains a plist file with a signature over all files in the bundle.Assets.car: Another zipped archive that contains assetsicons.Frameworks/contains the app native libraries as .dylib or .framework files.PlugIns/may contain app extensions as .appex filesnot present in the example.Core Data: It is used to save your application’s permanent data for offline use, to cache temporary data, and to add undo functionality to your app on a single device. To sync data across multiple devices in a single iCloud account, Core Data automatically mirrors your schema to a CloudKit container.- ****
PkgInfo: ThePkgInfofile is an alternate way to specify the type and creator codes of your application or bundle. - en.lproj, fr.proj, Base.lproj: Are the language packs that contains resources for those specific languages, and a default resource in case a language isn' t supported.
There are multiple ways to define the UI in an iOS application: storyboard, nib or xib files.
Info.plist
The information property list or Info.plist is the main source of information for an iOS app. It consists of a structured file containing key-value pairs describing essential configuration information about the app. Actually, all bundled executables app extensions, frameworks and apps are expected to have an Info.plist file. You can find all possible keys in the Apple Developer Documentation.
The file might be formatted in XML or binary (bplist). You can convert it to XML format with one simple command:
-
On macOS with
plutil, which is a tool that comes natively with macOS 10.2 and above versionsno official online documentation is currently available:$ plutil -convert xml1 Info.plist -
On Linux:
$ apt install libplist-utils $ plistutil -i Info.plist -o Info_xml.plist
Here's a non-exhaustive list of some info and the corresponding keywords that you can easily search for in the Info.plist file by just inspecting the file or by using grep -i <keyword> Info.plist:
- App permissions Purpose Strings:
UsageDescription - Custom URL schemes:
CFBundleURLTypes - Exported/imported custom document types:
UTExportedTypeDeclarations/UTImportedTypeDeclarations - App Transport Security
ATSconfiguration:NSAppTransportSecurity
Please refer to the mentioned chapters to learn more about how to test each of these points.
Data Paths
On iOS, system applications can be found in the /Applications directory while user-installed apps are available under /private/var/containers/. However, finding the right folder just by navigating the file system is not a trivial task as every app gets a random 128-bit UUID Universal Unique Identifier assigned for its directory names.
In order to easily obtain the installation directory information for user-installed apps you can use objection's command env will also show you all the directory information of the app:
OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # env
Name Path
----------------- -------------------------------------------------------------------------------------------
BundlePath /var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app
CachesDirectory /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library/Caches
DocumentDirectory /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Documents
LibraryDirectory /var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/Library
As you can see, apps have two main locations:
- The Bundle directory
`/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/`. - The Data directory
`/var/mobile/Containers/Data/Application/8C8E7EB0-BC9B-435B-8EF8-8F5560EB0693/`.
These folders contain information that must be examined closely during application security assessments for example when analyzing the stored data for sensitive data.
Bundle directory:
- AppName.app
- This is the Application Bundle as seen before in the IPA, it contains essential application data, static content as well as the application's compiled binary.
- This directory is visible to users, but users can't write to it.
- Content in this directory is not backed up.
- The contents of this folder are used to validate the code signature.
Data directory:
- Documents/
- Contains all the user-generated data. The application end user initiates the creation of this data.
- Visible to users and users can write to it.
- Content in this directory is backed up.
- The app can disable paths by setting
NSURLIsExcludedFromBackupKey.
- Library/
- Contains all files that aren't user-specific, such as caches, preferences, cookies, and property list
plistconfiguration files. - iOS apps usually use the
Application SupportandCachessubdirectories, but the app can create custom subdirectories.
- Contains all files that aren't user-specific, such as caches, preferences, cookies, and property list
- Library/Caches/
- Contains semi-persistent cached files.
- Invisible to users and users can't write to it.
- Content in this directory is not backed up.
- The OS may delete this directory's files automatically when the app is not running and storage space is running low.
- Library/Application Support/
- Contains persistent files necessary for running the app.
- Invisible to users and users can't write to it.
- Content in this directory is backed up.
- The app can disable paths by setting
NSURLIsExcludedFromBackupKey.
- Library/Preferences/
- Used for storing properties that can persist even after an application is restarted.
- Information is saved, unencrypted, inside the application sandbox in a plist file called [BUNDLE_ID].plist.
- All the key/value pairs stored using
NSUserDefaultscan be found in this file.
- tmp/
- Use this directory to write temporary files that do not need to persist between app launches.
- Contains non-persistent cached files.
- Invisible to users.
- Content in this directory is not backed up.
- The OS may delete this directory's files automatically when the app is not running and storage space is running low.
Let's take a closer look at iGoat-Swift's Application Bundle .app directory inside the Bundle directory `/var/containers/Bundle/Application/3ADAF47D-A734-49FA-B274-FBCA66589E67/iGoat-Swift.app`:
OWASP.iGoat-Swift on (iPhone: 11.1.2) [usb] # ls
NSFileType Perms NSFileProtection ... Name
------------ ------- ------------------ ... --------------------------------------
Regular 420 None ... rutger.html
Regular 420 None ... mansi.html
Regular 420 None ... splash.html
Regular 420 None ... about.html
Regular 420 None ... LICENSE.txt
Regular 420 None ... Sentinel.txt
Regular 420 None ... README.txt
Binary Reversing
Inside the <application-name>.app folder you will find a binary file called <application-name>. This is the file that will be executed. You can perform a basic inspection of the binary with the tool otool:
otool -Vh DVIA-v2 #Check some compilation attributes
magic cputype cpusubtype caps filetype ncmds sizeofcmds flags
MH_MAGIC_64 ARM64 ALL 0x00 EXECUTE 65 7112 NOUNDEFS DYLDLINK TWOLEVEL WEAK_DEFINES BINDS_TO_WEAK PIE
otool -L DVIA-v2 #Get third party libraries
DVIA-v2:
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 400.9.1)
/usr/lib/libsqlite3.dylib (compatibility version 9.0.0, current version 274.6.0)
/usr/lib/libz.1.dylib (compatibility version 1.0.0, current version 1.2.11)
@rpath/Bolts.framework/Bolts (compatibility version 1.0.0, current version 1.0.0)
[...]
Check if the app is encrypted
See if there is any output for:
otool -l <app-binary> | grep -A 4 LC_ENCRYPTION_INFO
Disassembling the binary
Disassemble the text section:
otool -tV DVIA-v2
DVIA-v2:
(__TEXT,__text) section
+[DDLog initialize]:
0000000100004ab8 sub sp, sp, #0x60
0000000100004abc stp x29, x30, [sp, #0x50] ; Latency: 6
0000000100004ac0 add x29, sp, #0x50
0000000100004ac4 sub x8, x29, #0x10
0000000100004ac8 mov x9, #0x0
0000000100004acc adrp x10, 1098 ; 0x10044e000
0000000100004ad0 add x10, x10, #0x268
To print the Objective-C segment of the sample application one can use:
otool -oV DVIA-v2
DVIA-v2:
Contents of (__DATA,__objc_classlist) section
00000001003dd5b8 0x1004423d0 _OBJC_CLASS_$_DDLog
isa 0x1004423a8 _OBJC_METACLASS_$_DDLog
superclass 0x0 _OBJC_CLASS_$_NSObject
cache 0x0 __objc_empty_cache
vtable 0x0
data 0x1003de748
flags 0x80
instanceStart 8
In order to obtain a more compact Objective-C code you can use class-dump:
class-dump some-app
//
// Generated by class-dump 3.5 (64 bit).
//
// class-dump is Copyright (C) 1997-1998, 2000-2001, 2004-2013 by Steve Nygard.
//
#pragma mark Named Structures
struct CGPoint {
double _field1;
double _field2;
};
struct CGRect {
struct CGPoint _field1;
struct CGSize _field2;
};
struct CGSize {
double _field1;
double _field2;
};
However, the best options to disassemble the binary are: Hopper and IDA.
Data Storage
To learn about how iOS stores data in the device read this page:
{% page-ref page="ios-basics.md" %}
{% hint style="warning" %}
The following places to store information should be checked right after installing the application, after checking all the functionalities of the application and even after login out from one user and login into a different one.
The goal is to find unprotected sensitive information of the application passwords, tokens, of the current user and of previously logged users.
{% endhint %}
Plist
plist files are structured XML files that contains key-value pairs. It's a way to store persistent data, so sometimes you may find sensitive information in these files. It's recommended to check these files after installing the app and after using intensively it to see if new data is written.
The most common way to persist data in plist files is through the usage of NSUserDefaults. This plist file is saved inside the app sandbox in Library/Preferences/<appBundleID>.plist
The NSUserDefaults class provides a programmatic interface for interacting with the default system. The default system allows an application to customize its behaviour according to user preferences. Data saved by NSUserDefaults can be viewed in the application bundle. This class stores data in a plist file, but it's meant to be used with small amounts of data.
This data cannot be longer accessed directly via a trusted computer, but can be accessed performing a backup.
You can dump the information saved using NSUserDefaults using objection's ios nsuserdefaults get
To find all the plist of used by the application you can access to /private/var/mobile/Containers/Data/Application/{APPID} and run:
find ./ -name "*.plist"
The file might be formatted in XML or binary (bplist). You can convert it to XML format with one simple command:
-
On macOS with
plutil, which is a tool that comes natively with macOS 10.2 and above versionsno official online documentation is currently available:$ plutil -convert xml1 Info.plist -
On Linux:
$ apt install libplist-utils $ plistutil -i Info.plist -o Info_xml.plist -
On an objection's session:
ios plist cat /private/var/mobile/Containers/Data/Application/AF1F534B-1B8F-0825-ACB21-C0301AB7E56D/Library/Preferences/com.some.package.app.plist
Core Data
Core Data is a framework for managing the model layer of objects in your application. Core Data can use SQLite as its persistent store, but the framework itself is not a database.
CoreData does not encrypt it's data by default. However, an additional encryption layer can be added to CoreData. See the GitHub Repo for more details.
You can find the SQLite Core Data information of an application in the path /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support
If you can open the SQLite and access sensitive information, then you found a miss-configuration.
{% code title="Code from iGoat" %}
-(void)storeDetails {
AppDelegate * appDelegate = (AppDelegate *)(UIApplication.sharedApplication.delegate);
NSManagedObjectContext *context =[appDelegate managedObjectContext];
User *user = [self fetchUser];
if (user) {
return;
}
user = [NSEntityDescription insertNewObjectForEntityForName:@"User"
inManagedObjectContext:context];
user.email = CoreDataEmail;
user.password = CoreDataPassword;
NSError *error;
if (![context save:&error]) {
NSLog(@"Error in saving data: %@", [error localizedDescription]);
}else{
NSLog(@"data stored in core data");
}
}
{% endcode %}
YapDatabase
YapDatabase is a key/value store built on top of SQLite.
As the Yap databases are sqlite databases you can find them using the purposed commend in the previous section.
Other SQLite Databases
It's common for applications to create their own sqlite database. They may be storing sensitive data on them and leaving it unencrypted. Therefore, it's always interesting to check every database inside the applications directory. Therefore go to the application directory where the data is saved `/private/var/mobile/Containers/Data/Application/{APPID}`
find ./ -name "*.sqlite" -or -name "*.db"
Firebase Real-Time Databases
It can be leveraged by application developers to store and sync data with a NoSQL cloud-hosted database. The data is stored as JSON and is synchronized in real-time to every connected client and also remains available even when the application goes offline.
You can find how to check for misconfigured Firebase databases here:
{% page-ref page="../pentesting/pentesting-web/buckets/firebase-database.md" %}
Realm databases
Realm Objective-C and Realm Swift aren't supplied by Apple, but they are still worth noting. They store everything unencrypted, unless the configuration has encryption enabled.
You can find this databases in /private/var/mobile/Containers/Data/Application/{APPID}
iPhone:/private/var/mobile/Containers/Data/Application/A079DF84-726C-4AEA-A194-805B97B3684A/Documents root# ls
default.realm default.realm.lock default.realm.management/ default.realm.note|
$ find ./ -name "*.realm*"
You can use the tool Realm Studio to open this database files.
The following example demonstrates how to use encryption with a Realm database:
// Open the encrypted Realm file where getKey() is a method to obtain a key from the Keychain or a server
let config = Realm.Configuration(encryptionKey: getKey())
do {
let realm = try Realm(configuration: config)
// Use the Realm as normal
} catch let error as NSError {
// If the encryption key is wrong, `error` will say that it's an invalid database
fatalError("Error opening realm: \(error)")
}
Couchbase Lite Databases
Couchbase Lite is a lightweight, embedded, document-oriented NoSQL database engine that can be synced. It compiles natively for iOS and macOS.
Check for possible couchbase databases in /private/var/mobile/Containers/Data/Application/{APPID}/Library/Application Support/
Cookies
iOS store the cookies of the apps in the Library/Cookies/cookies.binarycookies inside each apps folder. However, developers sometimes decide to save them in the keychain as the mentioned cookie file can be accessed in backups.
To inspect the cookies file you can use this python script ****or use objection's ios cookies get.
You can also use objection to convert these files to a JSON format and inspect the data.
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios cookies get --json
[
{
"domain": "highaltitudehacks.com",
"expiresDate": "2051-09-15 07:46:43 +0000",
"isHTTPOnly": "false",
"isSecure": "false",
"name": "username",
"path": "/",
"value": "admin123",
"version": "0"
}
]
Cache
By default NSURLSession stores data, such as HTTP requests and responses in the Cache.db database. This database can contain sensitive data, if tokens, usernames or any other sensitive information has been cached. To find the cached information open the data directory of the app `/var/mobile/Containers/Data/Application/<UUID>` and go to /Library/Caches/<Bundle Identifier>. The WebKit cache is also being stored in the Cache.db file. Objection can open and interact with the database with the command sqlite connect Cache.db, as it is a normal SQLite database.
It is recommended to disable Caching this data, as it may contain sensitive information in the request or response. The following list below shows different ways of achieving this:
-
It is recommended to remove Cached responses after logout. This can be done with the provided method by Apple called
removeAllCachedResponsesYou can call this method as follows:URLCache.shared.removeAllCachedResponses()This method will remove all cached requests and responses from Cache.db file.
-
If you don't need to use the advantage of cookies it would be recommended to just use the .ephemeral configuration property of URLSession, which will disable saving cookies and Caches.
An ephemeral session configuration object is similar to a default session configuration (see default), except that the corresponding session object doesn’t store caches, credential stores, or any session-related data to disk. Instead, session-related data is stored in RAM. The only time an ephemeral session writes data to disk is when you tell it to write the contents of a URL to a file. -
Cache can be also disabled by setting the Cache Policy to .notAllowed. It will disable storing Cache in any fashion, either in memory or on disk.
Snapshots
Whenever you press the home button, iOS takes a snapshot of the current screen to be able to do the transition to the application on a much smoother way. However, if sensitive data is present in the current screen, it will be saved in the image which **persists** **across** **reboots**. These are the snapshots that you can also access double tapping the home screen to switch between apps.
Unless the iPhone is jailbroken, the attacker needs to have access to the device unblocked to see these screenshots. By default the last snapshot is stored in the application's sandbox in Library/Caches/Snapshots/ or Library/SplashBoard/Snapshots folder the trusted computers can' t access the filesystem from iOX 7.0.
Once way to prevent this bad behaviour is to put a blank screen or remove the sensitive data before taking the snapshot using the ApplicationDidEnterBackground() function.
The following is a sample remediation method that will set a default screenshot.
Swift:
private var backgroundImage: UIImageView?
func applicationDidEnterBackground(_ application: UIApplication) {
let myBanner = UIImageView(image: #imageLiteral(resourceName: "overlayImage"))
myBanner.frame = UIScreen.main.bounds
backgroundImage = myBanner
window?.addSubview(myBanner)
}
func applicationWillEnterForeground(_ application: UIApplication) {
backgroundImage?.removeFromSuperview()
}
Objective-C:
@property (UIImageView *)backgroundImage;
- (void)applicationDidEnterBackground:(UIApplication *)application {
UIImageView *myBanner = [[UIImageView alloc] initWithImage:@"overlayImage.png"];
self.backgroundImage = myBanner;
self.backgroundImage.bounds = UIScreen.mainScreen.bounds;
[self.window addSubview:myBanner];
}
- (void)applicationWillEnterForeground:(UIApplication *)application {
[self.backgroundImage removeFromSuperview];
}
This sets the background image to overlayImage.png whenever the application is backgrounded. It prevents sensitive data leaks because overlayImage.png will always override the current view.
Keychain
Tools like Keychain-Dumper can be used to dump the keychain the dive must be jailbroken.
You can also use ios keychain dump from Objection.
NSURLCredential
NSURLCredential is the perfect class to store username and password in the keychain. No need to bother with NSUserDefaults nor any keychain wrapper.
****Once the user is logged in, you can store his username and password to the keychain:
NSURLCredential *credential;
credential = [NSURLCredential credentialWithUser:username password:password persistence:NSURLCredentialPersistencePermanent];
[[NSURLCredentialStorage sharedCredentialStorage] setCredential:credential forProtectionSpace:self.loginProtectionSpace];
You can use Objection's ios nsurlcredentialstorage dump to dump these secrets.
Custom Keyboards/Keyboard Cache
From iOS 8.0 Apple allows to install custom extensions for iOS like custom keyboards.
The installed keyboards can be managed via Settings > General > Keyboard > Keyboards
Custom keyboards can be used to sniff the keystrokes and send them to the attacker server. However, note that custom keyboards requiring networking connectivity will be notified to the user.
Also, the user can switch to a different more trusted keyboard for introducing the credentials.
Moreover, applications can prevent its users from using custom keyboards within the app or at least for sensitive parts of the app.
{% hint style="warning" %} It's recommended to not allow third party keyboards if you consider the users won't need them {% endhint %}
Note that because of auto-correct and auto-suggestions, the default iOS keyboard will capture and store each non-standard word word in a cache file if the attribute securetTextEntry is not set to true or if autoCorrectionType is not set to UITextAutoCorrectionTypeNo.
By default the keyboards store this cache inside the applications sandbox in Library/Keyboard/{locale}-dynamic-text.dat file or in /private/var/mobile/Library/Keyboard/dynamic-text.dat. However, it might be saving the dateaelsewhere.
It's possible to reset the cache in Settings > General > Reset > Reset Keyboard Dictionary
{% hint style="info" %}
Therefore, check always these files and search for possible sensitive information.
Intercepting the network traffic is another way to check if the custom keyboard is sending keystroked to a remote server.
{% endhint %}
The UITextInputTraits protocol is used for keyboard caching. The UITextField, UITextView, and UISearchBar classes automatically support this protocol and it offers the following properties:
var autocorrectionType: UITextAutocorrectionTypedetermines whether autocorrection is enabled during typing. When autocorrection is enabled, the text object tracks unknown words and suggests suitable replacements, replacing the typed text automatically unless the user overrides the replacement. The default value of this property isUITextAutocorrectionTypeDefault, which for most input methods enables autocorrection.var secureTextEntry: BOOLdetermines whether text copying and text caching are disabled and hides the text being entered forUITextField. The default value of this property isNO.
To identify this behaviour in the code:
- Search through the source code for similar implementations, such as
textObject.autocorrectionType = UITextAutocorrectionTypeNo;
textObject.secureTextEntry = YES;
- Open xib and storyboard files in the
Interface Builderof Xcode and verify the states ofSecure Text EntryandCorrectionin theAttributes Inspectorfor the appropriate object.
The application must prevent the caching of sensitive information entered into text fields. You can prevent caching by disabling it programmatically, using the textObject.autocorrectionType = UITextAutocorrectionTypeNo directive in the desired UITextFields, UITextViews, and UISearchBars. For data that should be masked, such as PINs and passwords, set textObject.secureTextEntry to YES.
UITextField *textField = [ [ UITextField alloc ] initWithFrame: frame ];
textField.autocorrectionType = UITextAutocorrectionTypeNo;
Logs
The most common ways to debug code is using logging, and the application may print sensitive information inside the logs.
In iOS version 6 and below, logs were world readable a malicious app could read logs from other apps and extract sensitive information from there. Nowadays, apps can only access their own logs.
However, an attacker with physical access to an unlocked device can connect it to a computer and read the logs note that the logs written to disk by an app aren't removed if the app ins uninstalled.
It's recommended to navigate through all the screens of the app and interact with every UI element and functionality of and provide input text in all text fields and review the logs looking for sensitive information exposed.
Use the following keywords to check the app's source code for predefined and custom logging statements:
- For predefined and built-in functions:
- NSLog
- NSAssert
- NSCAssert
- fprintf
- For custom functions:
- Logging
- Logfile
Monitoring System Logs
Many apps log informative and potentially sensitive messages to the console log. The log also contains crash reports and other useful information. You can collect console logs through the Xcode Devices window as follows:
- Launch Xcode.
- Connect your device to your host computer.
- Choose Window -> Devices and Simulators.
- Click on your connected iOS device in the left section of the Devices window.
- Reproduce the problem.
- Click on the Open Console button located in the upper right-hand area of the Devices window to view the console logs on a separate window.
You can also connect to the device shell as explained in Accessing the Device Shell, install socat via apt-get and run the following command:
iPhone:~ root# socat - UNIX-CONNECT:/var/run/lockdown/syslog.sock
========================
ASL is here to serve you
> watch
OK
Jun 7 13:42:14 iPhone chmod[9705] <Notice>: MS:Notice: Injecting: (null) [chmod] (1556.00)
Jun 7 13:42:14 iPhone readlink[9706] <Notice>: MS:Notice: Injecting: (null) [readlink] (1556.00)
Jun 7 13:42:14 iPhone rm[9707] <Notice>: MS:Notice: Injecting: (null) [rm] (1556.00)
Jun 7 13:42:14 iPhone touch[9708] <Notice>: MS:Notice: Injecting: (null) [touch] (1556.00)
...
Clipboard
Some applications may save sensitive information inside the clipboard, which is dangerous because then a different application may sniff the clipboard and steal the data.
Fortunately, apps signed by the same certificate can create private UIPasteboards. This way, unlike the global Pasteboard, only selected applications can share and view the content of the private pasteboard.
Then, it's important to check that sensitive information isn't being saved inside the global pasteboard.
It's also important to check that an application isn't using the global pasteboard data to perform actions, as malicious application could tamper this data.
An application can also prevent its users to copy sensitive data to the clipboard which is recommended.
You can monitor the pasteboard while you navigate through the application with objection's ios pasteboard monitor
Backups
iOS includes auto-backup features that create copies of the data stored on the device. You can make iOS backups from your host computer by using iTunes till macOS Catalina or Finder from macOS Catalina onwards, or via the iCloud backup feature. In both cases, the backup includes nearly all data stored on the iOS device except highly sensitive data such as Apple Pay information and Touch ID settings.
Since iOS backs up installed apps and their data, an obvious concern is whether sensitive user data stored by the app might unintentionally leak through the backup. Another concern, though less obvious, is whether sensitive configuration settings used to protect data or restrict app functionality could be tampered to change app behaviour after restoring a modified backup. Both concerns are valid and these vulnerabilities have proven to exist in a vast number of apps today.
A backup of a device on which a mobile application has been installed will include all subdirectories except for `Library/Caches/` and files in the app's private directory.
Therefore, avoid storing sensitive data in plaintext within any of the files or folders that are in the app's private directory or subdirectories.
Although all the files in Documents/ and Library/Application Support/ are always backed up by default, you can exclude files from the backup by calling NSURL setResourceValue:forKey:error: with the NSURLIsExcludedFromBackupKey key.
You can use the NSURLIsExcludedFromBackupKey and CFURLIsExcludedFromBackupKey file system properties to exclude files and directories from backups.
{% hint style="warning" %} Therefore when checking the backup of an application you should check if any sensitive information is accessible and if you can modify any sensitive behaviour of the application by modifying some setting of the backup and restoring the backup {% endhint %}
How to test
Start by creating a backup of the device you can do it using Finder and finding where is the backup stored. The official Apple documentation will help you to locate backups of your iPhone, iPad, and iPod touch.
Once you have found the backup of the device `/Users/carlos.martin/Library/Application Support/MobileSync/Backup/{deviceID}` you can start looking for sensitive information using grep for example, or using tools like iMazing).
To identify if a backup is encrypted, you can check the key named "IsEncrypted" from the file "Manifest.plist", located at the root of the backup directory. The following example shows a configuration indicating that the backup is encrypted:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
...
<key>Date</key>
<date>2021-03-12T17:43:33Z</date>
<key>IsEncrypted</key>
<true/>
...
</plist>
In case you need to work with an encrypted backup, there are some Python scripts in DinoSec's GitHub repo, such as backup_tool.py and backup_passwd.py, that will serve as a good starting point. However, note that they might not work with the latest iTunes/Finder versions and might need to be tweaked.
You can also use the tool iOSbackup to easily read and extract files from a password-encrypted iOS backup.
How to modify the behaviour
In the open source bitcoin wallet app, Bither, you'll see that it's possible to configure a PIN to lock the UI.
This is PIN is stored in the file net.bither.plist inside the pin_code key.
If you clear this key from that plist in the backup and restores the backup, you will be able to access the wallet.
Testing Memory for Sensitive Data
At some point sensitive information is going to be stored in memory. The objective is to make sure that this info is exposed as briefly as possible.
To investigate an application's memory, first create a memory dump. Alternatively, you can analyze the memory in real time with, for example, a debugger. Regardless of the method you use, this is a very error-prone process because dumps provide the data left by executed functions and you might miss executing critical steps. In addition, overlooking data during analysis is quite easy to do unless you know the footprint of the data you're looking for either its exact value or its format. For example, if the app encrypts according to a randomly generated symmetric key, you're very unlikely to spot the key in memory unless you find its value by other means.
Retrieving and Analyzing a Memory Dump
Wether you are using a jailbroken or a non-jailbroken device, you can dump the app's process memory with objection and Fridump.
After the memory has been dumped e.g. to a file called "memory", depending on the nature of the data you're looking for, you'll need a set of different tools to process and analyze that memory dump. For instance, if you're focusing on strings, it might be sufficient for you to execute the command strings or rabin2 -zz to extract those strings.
# using strings
$ strings memory > strings.txt
# using rabin2
$ rabin2 -ZZ memory > strings.txt
Open strings.txt in your favorite editor and dig through it to identify sensitive information.
However if you'd like to inspect other kind of data, you'd rather want to use radare2 and its search capabilities. See radare2's help on the search command `/?` for more information and a list of options. The following shows only a subset of them:
$ r2 <name_of_your_dump_file>
[0x00000000]> /?
Usage: /[!bf] [arg] Search stuff (see 'e??search' for options)
|Use io.va for searching in non virtual addressing spaces
| / foo\x00 search for string 'foo\0'
| /c[ar] search for crypto materials
| /e /E.F/i match regular expression
| /i foo search for string 'foo' ignoring case
| /m[?][ebm] magicfile search for magic, filesystems or binary headers
| /v[1248] value look for an `cfg.bigendian` 32bit value
| /w foo search for wide string 'f\0o\0o\0'
| /x ff0033 search for hex string
| /z min max search for strings of given size
...
Runtime Memory Analysis
By using r2frida you can analyze and inspect the app's memory while running and without needing to dump it. For example, you may run the previous search commands from r2frida and search the memory for a string, hexadecimal values, etc. When doing so, remember to prepend the search command and any other r2frida specific commands with a backslash \ after starting the session with r2 frida://usb//<name_of_your_app>.
Local Authentication
The tester should be aware that local authentication should always be enforced at a remote endpoint or based on a cryptographic primitive. Attackers can easily bypass local authentication if no data returns from the authentication process.
The Local Authentication framework ****provides a set of APIs for developers to extend an authentication dialog to a user. In the context of connecting to a remote service, it is possible and recommended to leverage the keychain for implementing local authentication.
The fingerprint ID sensor is operated by the SecureEnclave security coprocessor and does not expose fingerprint data to any other parts of the system. Next to Touch ID, Apple introduced Face ID: which allows authentication based on facial recognition.
Developers have two options for incorporating Touch ID/Face ID authentication:
LocalAuthentication.frameworkis a high-level API that can be used to authenticate the user via Touch ID. The app can't access any data associated with the enrolled fingerprint and is notified only whether authentication was successful.Security.frameworkis a lower level API to access keychain services. This is a secure option if your app needs to protect some secret data with biometric authentication, since the access control is managed on a system-level and can not easily be bypassed.Security.frameworkhas a C API, but there are several open source wrappers available, making access to the keychain as simple as to NSUserDefaults.
{% hint style="danger" %}
Please be aware that using either the LocalAuthentication.framework or the Security.framework, will be a control that can be bypassed by an attacker as it does only return a boolean and no data to proceed with. See Don't touch me that way, by David Lindner et al for more details.
{% endhint %}
Local Authentication Framework
Developers can display an authentication prompt by utilizing the function evaluatePolicy of the LAContext class. Two available policies define acceptable forms of authentication:
deviceOwnerAuthenticationSwiftorLAPolicyDeviceOwnerAuthenticationObjective-C: When available, the user is prompted to perform Touch ID authentication. If Touch ID is not activated, the device passcode is requested instead. If the device passcode is not enabled, policy evaluation fails.deviceOwnerAuthenticationWithBiometricsSwiftorLAPolicyDeviceOwnerAuthenticationWithBiometricsObjective-C: Authentication is restricted to biometrics where the user is prompted for Touch ID.
The evaluatePolicy function returns a boolean value indicating whether the user has authenticated successfully. Which means that it can be easily bypassed see below
Local Authentication using Keychain
The iOS keychain APIs can and should be used to implement local authentication. During this process, the app stores either a secret authentication token or another piece of secret data identifying the user in the keychain. In order to authenticate to a remote service, the user must unlock the keychain using their passphrase or fingerprint to obtain the secret data.
The keychain allows saving items with the special SecAccessControl attribute, which will allow access to the item from the keychain only after the user has passed Touch ID authentication or passcode, if such a fallback is allowed by attribute parameters.
In the following example we will save the string "test_strong_password" to the keychain. The string can be accessed only on the current device while the passcode is set `kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly` parameter and after Touch ID authentication for the currently enrolled fingers only `SecAccessControlCreateFlags.biometryCurrentSet` parameter:
{% tabs %} {% tab title="Swift" %}
// 1. create AccessControl object that will represent authentication settings
var error: Unmanaged<CFError>?
guard let accessControl = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
SecAccessControlCreateFlags.biometryCurrentSet,
&error) else {
// failed to create AccessControl object
return
}
// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute
var query: [String: Any] = [:]
query[kSecClass as String] = kSecClassGenericPassword
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecAttrAccount as String] = "OWASP Account" as CFString
query[kSecValueData as String] = "test_strong_password".data(using: .utf8)! as CFData
query[kSecAttrAccessControl as String] = accessControl
// 3. save item
let status = SecItemAdd(query as CFDictionary, nil)
if status == noErr {
// successfully saved
} else {
// error while saving
}
{% endtab %}
{% tab title="Objective-C" %}
// 1. create AccessControl object that will represent authentication settings
CFErrorRef *err = nil;
SecAccessControlRef sacRef = SecAccessControlCreateWithFlags(kCFAllocatorDefault,
kSecAttrAccessibleWhenPasscodeSetThisDeviceOnly,
kSecAccessControlUserPresence,
err);
// 2. define keychain services query. Pay attention that kSecAttrAccessControl is mutually exclusive with kSecAttrAccessible attribute
NSDictionary* query = @{
(_ _bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecAttrAccount: @"OWASP Account",
(__bridge id)kSecValueData: [@"test_strong_password" dataUsingEncoding:NSUTF8StringEncoding],
(__bridge id)kSecAttrAccessControl: (__bridge_transfer id)sacRef
};
// 3. save item
OSStatus status = SecItemAdd((__bridge CFDictionaryRef)query, nil);
if (status == noErr) {
// successfully saved
} else {
// error while saving
}
{% endtab %} {% endtabs %}
Now we can request the saved item from the keychain. Keychain services will present the authentication dialog to the user and return data or nil depending on whether a suitable fingerprint was provided or not.
{% tabs %} {% tab title="Swift" %}
// 1. define query
var query = [String: Any]()
query[kSecClass as String] = kSecClassGenericPassword
query[kSecReturnData as String] = kCFBooleanTrue
query[kSecAttrAccount as String] = "My Name" as CFString
query[kSecAttrLabel as String] = "com.me.myapp.password" as CFString
query[kSecUseOperationPrompt as String] = "Please, pass authorisation to enter this area" as CFString
// 2. get item
var queryResult: AnyObject?
let status = withUnsafeMutablePointer(to: &queryResult) {
SecItemCopyMatching(query as CFDictionary, UnsafeMutablePointer($0))
}
if status == noErr {
let password = String(data: queryResult as! Data, encoding: .utf8)!
// successfully received password
} else {
// authorization not passed
}
{% endtab %}
{% tab title="Objective-C" %}
// 1. define query
NSDictionary *query = @{(__bridge id)kSecClass: (__bridge id)kSecClassGenericPassword,
(__bridge id)kSecReturnData: @YES,
(__bridge id)kSecAttrAccount: @"My Name1",
(__bridge id)kSecAttrLabel: @"com.me.myapp.password",
(__bridge id)kSecUseOperationPrompt: @"Please, pass authorisation to enter this area" };
// 2. get item
CFTypeRef queryResult = NULL;
OSStatus status = SecItemCopyMatching((__bridge CFDictionaryRef)query, &queryResult);
if (status == noErr){
NSData* resultData = ( __bridge_transfer NSData* )queryResult;
NSString* password = [[NSString alloc] initWithData:resultData encoding:NSUTF8StringEncoding];
NSLog(@"%@", password);
} else {
NSLog(@"Something went wrong");
}
{% endtab %} {% endtabs %}
Detection
Usage of frameworks in an app can also be detected by analyzing the app binary's list of shared dynamic libraries. This can be done by using otool:
$ otool -L <AppName>.app/<AppName>
If LocalAuthentication.framework is used in an app, the output will contain both of the following lines remember that `LocalAuthentication.framework` uses `Security.framework` under the hood:
/System/Library/Frameworks/LocalAuthentication.framework/LocalAuthentication
/System/Library/Frameworks/Security.framework/Security
If Security.framework is used, only the second one will be shown.
Local Authentication Framework Bypass
Objection Biometrics Bypass can be used to bypass LocalAuthentication. Objection uses Frida to instrument the evaluatePolicy function so that it returns True even if authentication was not successfully performed. Use the ios ui biometrics_bypass command to bypass the insecure biometric authentication. Objection will register a job, which will replace the evaluatePolicy result. It will work in both, Swift and Objective-C implementations.
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # ios ui biometrics_bypass
(agent) Registering job 3mhtws9x47q. Type: ios-biometrics-disable
...itudehacks.DVIAswiftv2.develop on (iPhone: 13.2.3) [usb] # (agent) [3mhtws9x47q] Localized Reason for auth requirement: Please authenticate yourself
(agent) [3mhtws9x47q] OS authentication response: false
(agent) [3mhtws9x47q] Marking OS response as True instead
(agent) [3mhtws9x47q] Biometrics bypass hook complete
If vulnerable, the module will automatically bypass the login form.
Sensitive Functionality Exposure Through IPC
Custom URI Handlers / Deeplinks / Custom Schemes
Custom URL schemes allow apps to communicate via a custom protocol. An app must declare support for the schemes and handle incoming URLs that use those schemes.
URL schemes offer a potential attack vector into your app, so make sure to validate all URL parameters and discard any malformed URLs. In addition, limit the available actions to those that do not risk the user’s data.
For example, the URI: myapp://hostname?data=123876123 will invoke the application mydata the one that has **register** the scheme `mydata` to the action related to the hostname hostname sending the parameter data with value 123876123
One vulnerable example is the following bug in the Skype Mobile app, discovered in 2010: The Skype app registered the skype:// protocol handler, which allowed other apps to trigger calls to other Skype users and phone numbers. Unfortunately, Skype didn't ask users for permission before placing the calls, so any app could call arbitrary numbers without the user's knowledge. Attackers exploited this vulnerability by putting an invisible <iframe src="skype://xxx?call"></iframe> where `xxx` was replaced by a premium number, so any Skype user who inadvertently visited a malicious website called the premium number.
You can find the schemes registered by an application in the app's Info.plist file searching for CFBundleURLTypes example from [iGoat-Swift](https://github.com/OWASP/iGoat-Swift):
<key>CFBundleURLTypes</key>
<array>
<dict>
<key>CFBundleURLName</key>
<string>com.iGoat.myCompany</string>
<key>CFBundleURLSchemes</key>
<array>
<string>iGoat</string>
</array>
</dict>
</array>
However, note that malicious applications can re-register URIs already registered by applications. So, if you are sending sensitive information via URIs myapp://hostname?password=123456 a malicious application can intercept the URI with the sensitive information.
Also, the input of these URIs should be checked and sanitised, as it can be coming from malicious origins trying to exploit SQLInjections, XSS, CSRF, Path Traversals, or other possible vulnerabilities.
Application Query Schemes Registration
Apps can call canOpenURL: to verify that the target app is available. However, as this method was being used by malicious app as a way to enumerate installed apps, from iOS 9.0 the URL schemes passed to it must be also declared by adding the LSApplicationQueriesSchemes key to the app's Info.plist file and an array of up to 50 URL schemes.
<key>LSApplicationQueriesSchemes</key>
<array>
<string>url_scheme1</string>
<string>url_scheme2</string>
</array>
canOpenURL will always return NO for undeclared schemes, whether or not an appropriate app is installed. However, this restriction only applies to canOpenURL.
Testing URL Handling and Validation
In order to determine how a URL path is built and validated, if you have the original source code, you can search for the following methods:
application:didFinishLaunchingWithOptions:method orapplication:will-FinishLaunchingWithOptions:: verify how the decision is made and how the information about the URL is retrieved.application:openURL:options:: verify how the resource is being opened, i.e. how the data is being parsed, verify the options, especially if access by the calling app[`sourceApplication`](https://developer.apple.com/documentation/uikit/uiapplication/openurloptionskey/1623128-sourceapplication)should be allowed or denied. The app might also need user permission when using the custom URL scheme.
In Telegram you will find four different methods being used:
func application(_ application: UIApplication, open url: URL, sourceApplication: String?) -> Bool {
self.openUrl(url: url)
return true
}
func application(_ application: UIApplication, open url: URL, sourceApplication: String?,
annotation: Any) -> Bool {
self.openUrl(url: url)
return true
}
func application(_ app: UIApplication, open url: URL,
options: [UIApplicationOpenURLOptionsKey : Any] = [:]) -> Bool {
self.openUrl(url: url)
return true
}
func application(_ application: UIApplication, handleOpen url: URL) -> Bool {
self.openUrl(url: url)
return true
}
Testing URL Requests to Other Apps
The method openURL:options:completionHandler: and the deprecated openURL: method of UIApplication are responsible for opening URLs i.e. to send requests / make queries to other apps that may be local to the current app or it may be one that must be provided by a different app. If you have the original source code you can search directly for usages of those methods.
Additionally, if you are interested into knowing if the app is querying specific services or apps, and if the app is well-known, you can also search for common URL schemes online and include them in your greps (list of iOS app schemes).
egrep -nr "open.*options.*completionHandler" ./Telegram-iOS/
egrep -nr "openURL\(" ./Telegram-iOS/
egrep -nr "mt-encrypted-file://" ./Telegram-iOS/
egrep -nr "://" ./Telegram-iOS/
Testing for Deprecated Methods
Search for deprecated methods like:
For example, here we find those three:
$ rabin2 -zzq Telegram\ X.app/Telegram\ X | grep -i "openurl"
0x1000d9e90 31 30 UIApplicationOpenURLOptionsKey
0x1000dee3f 50 49 application:openURL:sourceApplication:annotation:
0x1000dee71 29 28 application:openURL:options:
0x1000dee8e 27 26 application:handleOpenURL:
0x1000df2c9 9 8 openURL:
0x1000df766 12 11 canOpenURL:
0x1000df772 35 34 openURL:options:completionHandler:
...
Calling arbitrary URLs
-
Safari: To quickly test one URL scheme you can open the URLs on Safari and observe how the app behaves. For example, if you write
tel://123456789safari will try to start calling the number. -
Notes App: Long press the links you've written in order to test custom URL schemes. Remember to exit the editing mode in order to be able to open them. Note that you can click or long press links including custom URL schemes only if the app is installed, if not they won't be highlighted as clickable links.
-
IDB:
- Start IDB, connect to your device and select the target app. You can find details in the IDB documentation.
- Go to the URL Handlers section. In URL schemes, click Refresh, and on the left you'll find a list of all custom schemes defined in the app being tested. You can load these schemes by clicking Open, on the right side. By simply opening a blank URI scheme
e.g., opening `myURLscheme://`, you can discover hidden functionalitye.g., a debug windowand bypass local authentication.
-
Frida:
If you simply want to open the URL scheme you can do it using Frida:
$ frida -U iGoat-Swift [iPhone::iGoat-Swift]-> function openURL(url) { var UIApplication = ObjC.classes.UIApplication.sharedApplication(); var toOpen = ObjC.classes.NSURL.URLWithString_(url); return UIApplication.openURL_(toOpen); } [iPhone::iGoat-Swift]-> openURL("tel://234234234") trueIn this example from Frida CodeShare the author uses the non-public API
LSApplicationWorkspace.openSensitiveURL:withOptions:to open the URLsfrom the SpringBoard app:function openURL(url) { var w = ObjC.classes.LSApplicationWorkspace.defaultWorkspace(); var toOpen = ObjC.classes.NSURL.URLWithString_(url); return w.openSensitiveURL_withOptions_(toOpen, null); }Note that the use of non-public APIs is not permitted on the App Store, that's why we don't even test these but we are allowed to use them for our dynamic analysis.
Fuzzing URL Schemes
If the app parses parts of the URL, you can also perform input fuzzing to detect memory corruption bugs.
What we have learned above can be now used to build your own fuzzer on the language of your choice, e.g. in Python and call the openURL using Frida's RPC. That fuzzer should do the following:
- Generate payloads.
- For each of them call
openURL. - Check if the app generates a crash report
`.ips`in/private/var/mobile/Library/Logs/CrashReporter.
The FuzzDB project offers fuzzing dictionaries that you can use as payloads.
Fuzzing Using Frida
Doing this with Frida is pretty easy, you can refer to this blog post to see an example that fuzzes the iGoat-Swift app working on iOS 11.1.2.
Before running the fuzzer we need the URL schemes as inputs. From the static analysis we know that the iGoat-Swift app supports the following URL scheme and parameters: iGoat://?contactNumber={0}&message={0}.
$ frida -U SpringBoard -l ios-url-scheme-fuzzing.js
[iPhone::SpringBoard]-> fuzz("iGoat", "iGoat://?contactNumber={0}&message={0}")
Watching for crashes from iGoat...
No logs were moved.
Opened URL: iGoat://?contactNumber=0&message=0
Universal Links
Universal links allows to redirect users directly to the app without passing through safari for redirection.
Universal links are unique, so they can't be claimed by other apps because they use standard HTTP(S) links to the website where the owner has uploaded a file to make sure that the website and the app are related.
As these links uses HTTP(S) schemes, when the app isn't installed, safari will open the link redirecting the users to the page. These allows apps to communicate with the app even if it isn't installed.
To create universal links it's needed to create a JSON file called apple-app-site-association with the details. Then this file needs to be hosted in the root directory of your webserver e.g. [https://google.com/apple-app-site-association](https://google.com/apple-app-site-association).
For the pentester this file is very interesting as it discloses paths. It can even be disclosing paths of releases that haven't been published yet.
Checking the Associated Domains Entitlement
n Xcode, go to the Capabilities tab and search for Associated Domains. You can also inspect the .entitlements file looking for com.apple.developer.associated-domains. Each of the domains must be prefixed with applinks:, such as applinks:www.mywebsite.com.
Here's an example from Telegram's .entitlements file:
<key>com.apple.developer.associated-domains</key>
<array>
<string>applinks:telegram.me</string>
<string>applinks:t.me</string>
</array>
More detailed information can be found in the archived Apple Developer Documentation.
If you only has the compiled application you can extract the entitlements following this guide:
{% page-ref page="extracting-entitlements-from-compiled-application.md" %}
Retrieving the Apple App Site Association File
Try to retrieve the apple-app-site-association file from the server using the associated domains you got from the previous step. This file needs to be accessible via HTTPS, without any redirects, at https://<domain>/apple-app-site-association or https://<domain>/.well-known/apple-app-site-association.
You can retrieve it yourself with your browser or use the Apple App Site Association AASA Validator.
Checking the Link Receiver Method
In order to receive links and handle them appropriately, the app delegate has to implement application:continueUserActivity:restorationHandler:. If you have the original project try searching for this method.
Please note that if the app uses openURL:options:completionHandler: to open a universal link to the app's website, the link won't open in the app. As the call originates from the app, it won't be handled as a universal link.
- The scheme of the
webpageURLmust be HTTP or HTTPSany other scheme should throw an exception. Theschemeinstance property ofURLComponents/NSURLComponentscan be used to verify this.
Checking the Data Handler Method
When iOS opens an app as the result of a universal link, the app receives an NSUserActivity object with an activityType value of NSUserActivityTypeBrowsingWeb. The activity object’s webpageURL property contains the HTTP or HTTPS URL that the user accesses. The following example in Swift verifies exactly this before opening the URL:
func application(_ application: UIApplication, continue userActivity: NSUserActivity,
restorationHandler: @escaping ([UIUserActivityRestoring]?) -> Void) -> Bool {
// ...
if userActivity.activityType == NSUserActivityTypeBrowsingWeb, let url = userActivity.webpageURL {
application.open(url, options: [:], completionHandler: nil)
}
return true
}
In addition, remember that if the URL includes parameters, they should not be trusted before being carefully sanitized and validated even when coming from trusted domain. For example, they might have been spoofed by an attacker or might include malformed data. If that is the case, the whole URL and therefore the universal link request must be discarded.
The NSURLComponents API can be used to parse and manipulate the components of the URL. This can be also part of the method application:continueUserActivity:restorationHandler: itself or might occur on a separate method being called from it. The following example demonstrates this:
func application(_ application: UIApplication,
continue userActivity: NSUserActivity,
restorationHandler: @escaping ([Any]?) -> Void) -> Bool {
guard userActivity.activityType == NSUserActivityTypeBrowsingWeb,
let incomingURL = userActivity.webpageURL,
let components = NSURLComponents(url: incomingURL, resolvingAgainstBaseURL: true),
let path = components.path,
let params = components.queryItems else {
return false
}
if let albumName = params.first(where: { $0.name == "albumname" })?.value,
let photoIndex = params.first(where: { $0.name == "index" })?.value {
// Interact with album name and photo index
return true
} else {
// Handle when album and/or album name or photo index missing
return false
}
}
Network Communication
It's important to check that no communication is occurring without encryption and also that the application is correctly validating the TLS certificate of the server.
To check these kind of issues you can use a proxy like Burp:
{% page-ref page="burp-configuration-for-ios.md" %}
Hostname check
One common issue validating the TLS certificate is to check that the certificate was signed by a trusted CA, but not check if the hostname of the certificate is the hostname being accessed.
In order to check this issue using Burp, after trusting Burp CA in the iPhone, you can create a new certificate with Burp for a different hostname and use it. If the application still works, then, something it's vulnerable.
Certificate Pinning
If an application is correctly using SSL Pinning, then the application will only works if the certificate is the once expected to be. When testing an application this might be a problem as Burp will serve it's own certificate.
In order to bypass this protection inside a jailbroken device, you can install the application SSL Kill Switch ****or install Burp Mobile Assistant****
You can also use objection's ios sslpinning disable
Misc
- In
/System/Libraryyou can find the frameworks installed in the phone used by system applications - The applications installed by the user from the App Store are located inside
/User/Applications - And the
/User/Librarycontains data saved by the user level applications - You can access
/User/Library/Notes/notes.sqliteto read the notes saved inside the application. - Inside the folder of an installed application
**`/User/Applications/<APP ID>/`**you can find some interesting files:iTunesArtwork: The icon used by the appiTunesMetadata.plist: Info of the app used in the App Store/Library/*: Contains the preferences and cache. In/Library/Cache/Snapshots/*you can find the snapshot performed to the application before sending it to the background.
Hot Patching
The developers can remotely patch all installations of their app instantly without having to resubmit the application to the App store and wait until it's approved.
For this purpose it's usually use JSPatch.
This is a dangerous mechanism that could be abused by malicious third party SDKs.
Third Parties
One problem of 3rd party SDKs is that there is no granular control over the features offered by the SDK. You could sue the SDK and have all features including diagnostic leaks and insecure HTTP connections, or not use it. Also, usually it's no possible for the applications developers to patch a vulnerability on the SDK.
Moreover some SDKs start containing malware once they are very trusted by the community.
Besides, the features these services provide can involve tracking services to monitor the user's behaviour while using the app, selling banner advertisements, or improving the user experience. The downside to third-party services is that developers don't know the details of the code executed via third-party libraries. Consequently, no more information than is necessary should be sent to a service, and no sensitive information should be disclosed.
The downside is that a developer doesn’t know in detail what code is executed via 3rd party libraries and therefore giving up visibility. Consequently it should be ensured that not more than the information needed is sent to the service and that no sensitive information is disclosed.
Most third-party services are implemented in two ways:
- with a standalone library
- with a full SDK
All data that's sent to third-party services should be anonymized to prevent exposure of PII Personal Identifiable Information that would allow the third party to identify the user account.
You can find the libraries used by an application by running otool against the app and **running** it **against** **each** shared **library** to find more shared libraries used.
Automatic Tools
****