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

Gli schemi URL personalizzati consentono alle app di comunicare utilizzando un protocollo personalizzato, come dettagliato nella Apple Developer Documentation. Questi schemi devono essere dichiarati dall'app, che gestisce quindi gli URL in arrivo seguendo quegli schemi. È fondamentale validare tutti i parametri URL e scartare eventuali URL malformati per prevenire attacchi attraverso questo vettore.

Un esempio è fornito dove l'URI myapp://hostname?data=123876123 invoca un'azione specifica dell'applicazione. Una vulnerabilità nota era nell'app Skype Mobile, che consentiva azioni di chiamata non autorizzate tramite il protocollo skype://. Gli schemi registrati possono essere trovati nel Info.plist dell'app sotto CFBundleURLTypes. Le applicazioni malevole possono sfruttare questo registrando nuovamente URI per intercettare informazioni sensibili.

Application Query Schemes Registration

A partire da iOS 9.0, per controllare se un'app è disponibile, canOpenURL: richiede di dichiarare gli schemi URL nel Info.plist sotto LSApplicationQueriesSchemes. Questo limita gli schemi che un'app può interrogare a 50, migliorando la privacy impedendo l'enumerazione delle app.

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

Testing URL Handling and Validation

Gli sviluppatori dovrebbero ispezionare metodi specifici nel codice sorgente per comprendere la costruzione e la validazione dei percorsi URL, come application:didFinishLaunchingWithOptions: e application:openURL:options:. Ad esempio, Telegram utilizza vari metodi per aprire URL:

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

Metodi come openURL:options:completionHandler: sono cruciali per aprire URL per interagire con altre app. Identificare l'uso di tali metodi nel codice sorgente dell'app è fondamentale per comprendere le comunicazioni esterne.

Testing for Deprecated Methods

I metodi deprecati che gestiscono l'apertura di URL, come application:handleOpenURL: e openURL:, dovrebbero essere identificati e revisionati per le implicazioni di sicurezza.

Fuzzing URL Schemes

Il fuzzing degli schemi URL può identificare bug di corruzione della memoria. Strumenti come Frida possono automatizzare questo processo aprendo URL con payload variabili per monitorare eventuali crash, esemplificato dalla manipolazione degli URL nell'app 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

Hijacking degli URL personalizzati

Secondo questo post, le app malevole potrebbero registrare gli schemi personalizzati di altre app, quindi l'app malevola può aprire un browser che ha tutti i cookie dell'app Safari con ASWebAuthenticationSession.

Con il browser, l'app malevola può caricare una pagina web controllata dall'attaccante e TCC chiederà all'utente mobile i permessi per aprire quell'app. Poi, la pagina web malevola potrebbe reindirizzare a una pagina vittima, ad esempio un flusso OAuth con il parametro prompt=none. Se l'utente era già loggato nel flusso OAuth, il flusso OAuth invierà il segreto all'applicazione vittima utilizzando lo schema personalizzato dell'app vittima.
Tuttavia, poiché l'app malevola ha anche registrato lo schema e poiché il browser utilizzato è all'interno dell'app malevola, lo schema personalizzato sarà gestito in questo caso dall'app malevola che sarà in grado di rubare il token OAuth.

Riferimenti