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

Os esquemas de URL personalizados permitem que os aplicativos se comuniquem usando um protocolo personalizado, conforme detalhado na Documentação do Desenvolvedor da Apple. Esses esquemas devem ser declarados pelo aplicativo, que então lida com URLs de entrada seguindo esses esquemas. É crucial validar todos os parâmetros de URL e descartar quaisquer URLs malformadas para prevenir ataques através desse vetor.

Um exemplo é dado onde o URI myapp://hostname?data=123876123 invoca uma ação específica do aplicativo. Uma vulnerabilidade observada estava no aplicativo Skype Mobile, que permitia ações de chamada não autorizadas via o protocolo skype://. Os esquemas registrados podem ser encontrados no Info.plist do aplicativo sob CFBundleURLTypes. Aplicativos maliciosos podem explorar isso re-registrando URIs para interceptar informações sensíveis.

Registro de Esquemas de Consulta de Aplicativos

A partir do iOS 9.0, para verificar se um aplicativo está disponível, canOpenURL: requer a declaração de esquemas de URL no Info.plist sob LSApplicationQueriesSchemes. Isso limita os esquemas que um aplicativo pode consultar a 50, melhorando a privacidade ao prevenir a enumeração de aplicativos.

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

Testando o Tratamento e Validação de URL

Os desenvolvedores devem inspecionar métodos específicos no código-fonte para entender a construção e validação do caminho da URL, como application:didFinishLaunchingWithOptions: e application:openURL:options:. Por exemplo, o Telegram emprega vários 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
}

Testando Requisições de URL para Outros Apps

Métodos como openURL:options:completionHandler: são cruciais para abrir URLs e interagir com outros apps. Identificar o uso de tais métodos no código-fonte do app é fundamental para entender as comunicações externas.

Testando Métodos Obsoletos

Métodos obsoletos que lidam com aberturas de URL, como application:handleOpenURL: e openURL:, devem ser identificados e revisados quanto às implicações de segurança.

Fuzzing de Esquemas de URL

Fuzzing de esquemas de URL pode identificar bugs de corrupção de memória. Ferramentas como Frida podem automatizar esse processo abrindo URLs com diferentes payloads para monitorar por falhas, exemplificado pela manipulação de URLs no 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

Sequestro de esquema de URL personalizado

De acordo com este post, aplicativos maliciosos poderiam registrar esquemas personalizados de outros aplicativos, então o aplicativo malicioso pode abrir um navegador que possui todos os cookies do aplicativo Safari com ASWebAuthenticationSession.

Com o navegador, o aplicativo malicioso pode carregar uma página da web controlada por atacantes e o TCC pedirá ao usuário móvel permissões para abrir esse aplicativo. Então, a página da web maliciosa poderia redirecionar para uma página de vítima, por exemplo, um fluxo OAuth com o parâmetro prompt=none. Se o usuário já estiver logado no fluxo OAuth, o fluxo OAuth enviará o segredo de volta para o aplicativo da vítima usando o esquema personalizado do aplicativo da vítima.
No entanto, como o aplicativo malicioso também o registrou e porque o navegador usado está dentro do aplicativo malicioso, o esquema personalizado será tratado neste caso pelo aplicativo malicioso, que será capaz de roubar o token OAuth.

Referências