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

Los esquemas de URL personalizados permiten que las aplicaciones se comuniquen utilizando un protocolo personalizado, como se detalla en la Documentación para Desarrolladores de Apple. Estos esquemas deben ser declarados por la aplicación, que luego maneja las URL entrantes siguiendo esos esquemas. Es crucial validar todos los parámetros de la URL y descartar cualquier URL malformada para prevenir ataques a través de este vector.

Se da un ejemplo donde la URI myapp://hostname?data=123876123 invoca una acción específica de la aplicación. Una vulnerabilidad señalada estaba en la aplicación Skype Mobile, que permitía acciones de llamada no permitidas a través del protocolo skype://. Los esquemas registrados se pueden encontrar en el Info.plist de la aplicación bajo CFBundleURLTypes. Las aplicaciones maliciosas pueden explotar esto volviendo a registrar URIs para interceptar información sensible.

Application Query Schemes Registration

Desde iOS 9.0, para verificar si una aplicación está disponible, canOpenURL: requiere declarar esquemas de URL en el Info.plist bajo LSApplicationQueriesSchemes. Esto limita los esquemas que una aplicación puede consultar a 50, mejorando la privacidad al prevenir la enumeración de aplicaciones.

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

Testing URL Handling and Validation

Los desarrolladores deben inspeccionar métodos específicos en el código fuente para entender la construcción y validación de rutas URL, como application:didFinishLaunchingWithOptions: y application:openURL:options:. Por ejemplo, Telegram emplea varios métodos para abrir 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

Métodos como openURL:options:completionHandler: son cruciales para abrir URLs e interactuar con otras aplicaciones. Identificar el uso de tales métodos en el código fuente de la aplicación es clave para entender las comunicaciones externas.

Testing for Deprecated Methods

Los métodos obsoletos que manejan la apertura de URLs, como application:handleOpenURL: y openURL:, deben ser identificados y revisados por sus implicaciones de seguridad.

Fuzzing URL Schemes

El fuzzing de esquemas de URL puede identificar errores de corrupción de memoria. Herramientas como Frida pueden automatizar este proceso abriendo URLs con diferentes cargas útiles para monitorear fallos, ejemplificado por la manipulación de URLs en la aplicación iGoat-Swift:

$ 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

Secuestro de esquemas de URL personalizados

Según esta publicación, las aplicaciones maliciosas podrían registrar los esquemas personalizados de otras aplicaciones, luego la aplicación maliciosa puede abrir un navegador que tiene todas las cookies de la aplicación Safari con ASWebAuthenticationSession.

Con el navegador, la aplicación maliciosa puede cargar una página web controlada por el atacante y TCC pedirá al usuario móvil permisos para abrir esa aplicación. Luego, la página web maliciosa podría redirigir a una página de víctima, por ejemplo, un flujo de OAuth con el parámetro prompt=none. Si el usuario ya había iniciado sesión en el flujo de OAuth, el flujo de OAuth enviará el secreto de vuelta a la aplicación víctima utilizando el esquema personalizado de la aplicación víctima.
Sin embargo, debido a que la aplicación maliciosa también lo registró y porque el navegador utilizado está dentro de la aplicación maliciosa, el esquema personalizado será manejado en este caso por la aplicación maliciosa, que podrá robar el token de OAuth.

Referencias