iOS Custom URI Handlers / Deeplinks / Custom Schemes

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks

Informazioni di Base

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 è dato 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 gli URI per intercettare informazioni sensibili.

Registrazione degli Schemi di Query dell’Applicazione

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 impiega 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 di schemi URL personalizzati

Secondo questo post, le app malevole potrebbero registrare 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 l’ha anche registrato 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

Tip

Impara e pratica il hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica il hacking GCP: HackTricks Training GCP Red Team Expert (GRTE) Impara e pratica il hacking Azure: HackTricks Training Azure Red Team Expert (AzRTE)

Supporta HackTricks