iOS Custom URI Handlers / Deeplinks / Custom Schemes

{% hint style="success" %} Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Support HackTricks

Check the subscription plans!
Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.

{% endhint %}

Basic Information

Custom URL schemes enable apps to communicate using a custom protocol, as detailed in the Apple Developer Documentation. These schemes must be declared by the app, which then handles incoming URLs following those schemes. It's crucial to validate all URL parameters and discard any malformed URLs to prevent attacks through this vector.

An example is given where the URI myapp://hostname?data=123876123 invokes a specific application action. A noted vulnerability was in the Skype Mobile app, which allowed unpermitted call actions via the skype:// protocol. The registered schemes can be found in the app's Info.plist under CFBundleURLTypes. Malicious applications can exploit this by re-registering URIs to intercept sensitive information.

Application Query Schemes Registration

From iOS 9.0, to check if an app is available, canOpenURL: requires declaring URL schemes in the Info.plist under LSApplicationQueriesSchemes. This limits the schemes an app can query to 50, enhancing privacy by preventing app enumeration.

<key>LSApplicationQueriesSchemes</key>
<array>
    <string>url_scheme1</string>
    <string>url_scheme2</string>
</array>

Testing URL Handling and Validation

Developers should inspect specific methods in the source code to understand URL path construction and validation, such as application:didFinishLaunchingWithOptions: and application:openURL:options:. For instance, Telegram employs various methods for opening URLs:

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

Methods like openURL:options:completionHandler: are crucial for opening URLs to interact with other apps. Identifying usage of such methods in the app's source code is key for understanding external communications.

Testing for Deprecated Methods

Deprecated methods handling URL openings, such as application:handleOpenURL: and openURL:, should be identified and reviewed for security implications.

Fuzzing URL Schemes

Fuzzing URL schemes can identify memory corruption bugs. Tools like Frida can automate this process by opening URLs with varying payloads to monitor for crashes, exemplified by the manipulation of URLs in the iGoat-Swift app:

$ 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

Custom URL scheme hijacking

According to this post, malicious apps could register other apps custom schemes, then the malicious app can open a browser that has all the cookies of the Safari App with ASWebAuthenticationSession.

With the broser the malicious app can load an attackers controlled web page and TCC will ask the mobile user for permissions to open that app. Then, the malicious webpage could redirect to a victim page, for example an OAuth flow with the parameter prompt=none. If the user was already logged in the OAuth flow, the OAuth flow will send the secret back to the victim application using the custom scheme of the victim app.
However, because the malicious app also registered it and because the used browser is inside the malicious app, the custom scheme will be handled in this case by the malicious app which will be able to steal the OAuth token.

References