coelner/hacktricks
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

GitBook: [master] 4 pages modified

Browse Source
This commit is contained in:
CPol 2021-05-17 19:08:47 +00:00 committed by gitbook-bot
parent 17cd871714
commit 3926f377c2
No known key found for this signature in database
GPG Key ID: 07D2180C7B12D0FF
4 changed files with 402 additions and 33 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1
SUMMARY.md
View File

@ -507,6 +507,7 @@
* [Online Platforms with API](online-platforms-with-api.md)
* [Stealing Sensitive Information Disclosure from a Web](stealing-sensitive-information-disclosure-from-a-web.md)
* [iOS Pentesting](ios-pentesting/README.md)
* [Extracting Entitlements From Compiled Application](ios-pentesting/extracting-entitlements-from-compiled-application.md)
* [iOS Basics](ios-pentesting/ios-basics.md)
* [Frida Configuration in iOS](ios-pentesting/frida-configuration-in-ios.md)
* [iOS Testing Environment](ios-pentesting/ios-testing-environment.md)

313
ios-pentesting/README.md
View File

@ -578,24 +578,6 @@ It's also important to check that an **application isn't using the global pasteb
An **application can also prevent its users to copy sensitive data to the clipboard** \(which is recommended\).
## 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 t**racking 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\).
## 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.
@ -830,17 +812,182 @@ If `Security.framework` is used, only the second one will be shown.
If vulnerable, the module will automatically bypass the login form.
## Sensitive Functionality Exposure Through IPC
### Custom URI Handlers / Deeplinks / Custom Schemes
A custom URI handler is used to invoke an application from an URI.
Custom URL schemes [allow apps to communicate via a custom protocol](https://developer.apple.com/library/content/documentation/iPhone/Conceptual/iPhoneOSProgrammingGuide/Inter-AppCommunication/Inter-AppCommunication.html#//apple_ref/doc/uid/TP40007072-CH6-SW1). 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 d**o 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`
You can find the **schemes registered by an application** in the app's **`Info.plist`** file searching for **`CFBundleURLTypes`**.
One vulnerable example is the following [bug in the Skype Mobile app](http://www.dhanjani.com/blog/2010/11/insecure-handling-of-url-schemes-in-apples-ios.html), 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)\):
```markup
<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:`](https://developer.apple.com/documentation/uikit/uiapplication/1622952-canopenurl?language=objc) 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](https://developer.apple.com/documentation/uikit/uiapplication/1622952-canopenurl?language=objc#discussion) by adding the `LSApplicationQueriesSchemes` key to the app's `Info.plist` file and an array of **up to 50 URL schemes**.
```markup
<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 or `application:will-FinishLaunchingWithOptions:`: verify how the decision is made and how the information about the URL is retrieved.
* [`application:openURL:options:`](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623112-application?language=objc): verify how the resource is being opened, i.e. how the data is being parsed, verify the [options](https://developer.apple.com/documentation/uikit/uiapplication/openurloptionskey), 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](https://github.com/peter-iakovlev/Telegram-iOS/blob/87e0a33ac438c1d702f2a0b75bf21f26866e346f/Telegram-iOS/AppDelegate.swift#L1250):
```swift
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:`](https://developer.apple.com/documentation/uikit/uiapplication/1648685-openurl?language=objc) and the [deprecated `openURL:` method of `UIApplication`](https://developer.apple.com/documentation/uikit/uiapplication/1622961-openurl?language=objc) 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 \(l**[**ist of iOS app schemes**](https://ios.gadgethacks.com/how-to/always-updated-list-ios-app-url-scheme-names-paths-for-shortcuts-0184033/)**\)**.
```bash
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:
* [`application:handleOpenURL:`](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1622964-application?language=objc)
* [`openURL:`](https://developer.apple.com/documentation/uikit/uiapplication/1622961-openurl?language=objc)
* [`application:openURL:sourceApplication:annotation:`](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623073-application)
For example, here we find those three:
```bash
$ 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://123456789` safari 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**](https://github.com/facebook/idb):
* Start IDB, connect to your device and select the target app. You can find details in the [IDB documentation](https://www.idbtool.com/documentation/setup.html).
* 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 functionality \(e.g., a debug window\) and bypass local authentication.
* **Frida**:
If you simply want to open the URL scheme you can do it using Frida:
```javascript
$ 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")
true
```
In this example from [Frida CodeShare](https://codeshare.frida.re/@dki/ios-url-scheme-fuzzing/) the author uses the non-public API `LSApplicationWorkspace.openSensitiveURL:withOptions:` to open the URLs \(from the SpringBoard app\):
```javascript
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](https://www.frida.re/docs/javascript-api/#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](https://github.com/fuzzdb-project/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](https://grepharder.github.io/blog/0x03_learning_about_universal_links_and_fuzzing_url_schemes_on_ios_with_frida.html) 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}`.
```bash
$ 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.
@ -850,22 +997,85 @@ As these links uses HTTP\(S\) schemes, when the **app isn't installed, safari wi
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.
### Hot Patching
​**Checking the Associated Domains Entitlement**
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**](https://github.com/bang590/JSPatch)**.
This is a dangerous mechanism that could be abused by malicious third party SDKs.**
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`.
### Misc
Here's an example from Telegram's `.entitlements` file:
* In **`/System/Library`** you 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/Library`** contains data saved by the user level applications
* You can access **`/User/Library/Notes/notes.sqlite`** to 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 app
* **`iTunesMetadata.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.
```markup
<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](https://developer.apple.com/library/archive/documentation/General/Conceptual/AppSearch/UniversalLinks.html#//apple_ref/doc/uid/TP40016308-CH12-SW2).
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](https://branch.io/resources/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:`](https://developer.apple.com/documentation/uikit/uiapplicationdelegate/1623072-application). If you have the original project try searching for this method.
Please note that if the app uses [`openURL:options:completionHandler:`](https://developer.apple.com/documentation/uikit/uiapplication/1648685-openurl?language=objc) 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 `webpageURL` must be HTTP or HTTPS \(any other scheme should throw an exception\). The [`scheme` instance property](https://developer.apple.com/documentation/foundation/urlcomponents/1779624-scheme) of `URLComponents` / `NSURLComponents` can 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:
```swift
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](https://developer.apple.com/documentation/uikit/core_app/allowing_apps_and_websites_to_link_to_your_content/handling_universal_links#3001935) demonstrates this:
```swift
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
}
}
```
## Testing Memory for Sensitive Data
@ -932,6 +1142,43 @@ In order to check this issue using Burp, after trusting Burp CA in the iPhone, y
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**](https://github.com/nabla-c0d3/ssl-kill-switch2) ****or install [**Burp Mobile Assistant**](https://portswigger.net/burp/documentation/desktop/tools/mobile-assistant/installing)\*\*\*\*
\*\*\*\*
## Misc
* In **`/System/Library`** you 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/Library`** contains data saved by the user level applications
* You can access **`/User/Library/Notes/notes.sqlite`** to 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 app
* **`iTunesMetadata.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**](https://github.com/bang590/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 t**racking 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**
\*\*\*\*

58
ios-pentesting/extracting-entitlements-from-compiled-application.md Normal file
View File

@ -0,0 +1,58 @@
# Extracting Entitlements From Compiled Application
**Page copied form** [**https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06h-testing-platform-interaction\#universal-links**](https://mobile-security.gitbook.io/mobile-security-testing-guide/ios-testing-guide/0x06h-testing-platform-interaction#universal-links)\*\*\*\*
If you only have the app's IPA or simply the installed app on a jailbroken device, you normally won't be able to find `.entitlements` files. This could be also the case for the `embedded.mobileprovision` file. Still, you should be able to extract the entitlements property lists from the app binary yourself \(which you've previously obtained as explained in the "iOS Basic Security Testing" chapter, section "Acquiring the App Binary"\).
The following steps should work even when targeting an encrypted binary. If for some reason they don't, you'll have to decrypt and extract the app with e.g. Clutch \(if compatible with your iOS version\), frida-ios-dump or similar.
**Extracting the Entitlements Plist from the App Binary**
If you have the app binary in your computer, one approach is to use binwalk to extract \(`-e`\) all XML files \(`-y=xml`\):
```bash
$ binwalk -e -y=xml ./Telegram\ X
DECIMAL HEXADECIMAL DESCRIPTION
--------------------------------------------------------------------------------
1430180 0x15D2A4 XML document, version: "1.0"
1458814 0x16427E XML document, version: "1.0"
```
Or you can use radare2 \(`-qc` to _quietly_ run one command and exit\) to search all strings on the app binary \(`izz`\) containing "PropertyList" \(`~PropertyList`\):
```bash
$ r2 -qc 'izz~PropertyList' ./Telegram\ X
0x0015d2a4 ascii <?xml version="1.0" encoding="UTF-8" standalone="yes"?>\n<!DOCTYPE plist PUBLIC
"-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">\n<plist version="1.0">
...<key>com.apple.security.application-groups</key>\n\t\t<array>
\n\t\t\t<string>group.ph.telegra.Telegraph</string>...
0x0016427d ascii H<?xml version="1.0" encoding="UTF-8"?>\n<!DOCTYPE plist PUBLIC
"-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">\n<plist version="1.0">\n
<dict>\n\t<key>cdhashes</key>...
```
In both cases \(binwalk or radare2\) we were able to extract the same two `plist` files. If we inspect the first one \(0x0015d2a4\) we see that we were able to completely recover the [original entitlements file from Telegram](https://github.com/peter-iakovlev/Telegram-iOS/blob/77ee5c4dabdd6eb5f1e2ff76219edf7e18b45c00/Telegram-iOS/Telegram-iOS-AppStoreLLC.entitlements).
> Note: the `strings` command will not help here as it will not be able to find this information. Better use grep with the `-a` flag directly on the binary or use radare2 \(`izz`\)/rabin2 \(`-zz`\).
If you access the app binary on the jailbroken device \(e.g via SSH\), you can use grep with the `-a, --text` flag \(treats all files as ASCII text\):
```bash
$ grep -a -A 5 'PropertyList' /var/containers/Bundle/Application/
15E6A58F-1CA7-44A4-A9E0-6CA85B65FA35/Telegram X.app/Telegram\ X
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.application-groups</key>
<array>
...
```
Play with the `-A num, --after-context=num` flag to display more or less lines. You may use tools like the ones we presented above as well, if you have them also installed on your jailbroken iOS device.
> This method should work even if the app binary is still encrypted \(it was tested against several App Store apps\).

63
ios-pentesting/ios-basics.md
View File

@ -100,6 +100,69 @@ if userDefaults.bool(forKey: "hasRunBefore") == false {
* When developing logout functionality for an iOS application, make sure that the Keychain data is wiped as part of account logout. This will allow users to clear their accounts before uninstalling an application.
## **App Capabilities**
**Each app has a unique home directory and is sandboxed**, so that they cannot access protected system resources or files stored by the system or by other apps. These restrictions are implemented via sandbox policies \(aka. _profiles_\), which are enforced by the [Trusted BSD \(MAC\) Mandatory Access Control Framework](http://www.trustedbsd.org/mac.html) via a kernel extension.
Some [**capabilities/permissions**](https://help.apple.com/developer-account/#/dev21218dfd6) can be configured by the app's developers \(e.g. Data Protection or Keychain Sharing\) and will directly take effect after the installation. However, for others, **the user will be explicitly asked the first time the app attempts to access a protected resource**.
[_Purpose strings_](https://developer.apple.com/documentation/uikit/core_app/protecting_the_user_s_privacy/accessing_protected_resources?language=objc#3037322) or _usage description strings_ are custom texts that are offered to users in the system's permission request alert when requesting permission to access protected data or resources.
![](https://gblobscdn.gitbook.com/assets%2F-LH00RC4WVf3-6Ou4e0l%2F-Lf1APQHyCHdAvoJSvc_%2F-Lf1AQw8W2q7BB5-il7r%2Fpermission_request_alert.png?alt=media)
If having the original source code, you can verify the permissions included in the `Info.plist` file:
* Open the project with Xcode.
* Find and open the `Info.plist` file in the default editor and search for the keys starting with `"Privacy -"`.
You may switch the view to display the raw values by right-clicking and selecting "Show Raw Keys/Values" \(this way for example `"Privacy - Location When In Use Usage Description"` will turn into `NSLocationWhenInUseUsageDescription`\).
If only having the IPA:
* Unzip the IPA.
* The `Info.plist` is located in `Payload/<appname>.app/Info.plist`.
* Convert it if needed \(e.g. `plutil -convert xml1 Info.plist`\) as explained in the chapter "iOS Basic Security Testing", section "The Info.plist File".
* Inspect all _purpose strings Info.plist keys_, usually ending with `UsageDescription`:
```markup
<plist version="1.0">
<dict>
<key>NSLocationWhenInUseUsageDescription</key>
<string>Your location is used to provide turn-by-turn directions to your destination.</string>
```
### Device Capabilities
Device capabilities are used by the App Store to ensure that only compatible devices are listed and therefore are allowed to download the app. They are specified in the `Info.plist` file of the app under the [`UIRequiredDeviceCapabilities`](https://developer.apple.com/library/archive/documentation/General/Reference/InfoPlistKeyReference/Articles/iPhoneOSKeys.html#//apple_ref/doc/plist/info/UIRequiredDeviceCapabilities) key.
```markup
<key>UIRequiredDeviceCapabilities</key>
<array>
<string>armv7</string>
</array>
```
> Typically you'll find the `armv7` capability, meaning that the app is compiled only for the armv7 instruction set, or if it’s a 32/64-bit universal app.
For example, an app might be completely dependent on NFC to work \(e.g. a ["NFC Tag Reader"](https://itunes.apple.com/us/app/nfc-taginfo-by-nxp/id1246143596) app\). According to the [archived iOS Device Compatibility Reference](https://developer.apple.com/library/archive/documentation/DeviceInformation/Reference/iOSDeviceCompatibility/DeviceCompatibilityMatrix/DeviceCompatibilityMatrix.html), NFC is only available starting on the iPhone 7 \(and iOS 11\). A developer might want to exclude all incompatible devices by setting the `nfc` device capability.
### Entitlements
> Entitlements are key value pairs that are signed in to an app and allow authentication beyond runtime factors, like UNIX user ID. Since entitlements are digitally signed, they can’t be changed. Entitlements are used extensively by system apps and daemons to **perform specific privileged operations that would otherwise require the process to run as root**. This greatly reduces the potential for privilege escalation by a compromised system app or daemon.
For example, if you want to set the "Default Data Protection" capability, you would need to go to the **Capabilities** tab in Xcode and enable **Data Protection**. This is directly written by Xcode to the `<appname>.entitlements` file as the `com.apple.developer.default-data-protection` entitlement with default value `NSFileProtectionComplete`. In the IPA we might find this in the `embedded.mobileprovision` as:
```markup
<key>Entitlements</key>
<dict>
...
<key>com.apple.developer.default-data-protection</key>
<string>NSFileProtectionComplete</string>
</dict>
```
For other capabilities such as HealthKit, the user has to be asked for permission, therefore it is not enough to add the entitlements, special keys and strings have to be added to the `Info.plist` file of the app.
## Objective-C and Swift Basics
**Objecttive-C** has a **dynamic runtime**, so when an Objective-C program is executed in iOS, it calls libraries whose **address are resolved at runtime** by comparing the name of the function sent in the message against a list of all the function names available.