iOS Custom URI Handlers / Deeplinks / Custom Schemes
Reading time: 4 minutes
tip
Impara e pratica l'Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos di github.
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
- https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0075/
- https://evanconnelly.github.io/post/ios-oauth/
tip
Impara e pratica l'Hacking AWS:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica l'Hacking GCP: HackTricks Training GCP Red Team Expert (GRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos di github.