iOS Custom URI Handlers / Deeplinks / Custom Schemes

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.

Grundinformationen

Benutzerdefinierte URL-Schemata ermöglichen es Apps, über ein benutzerdefiniertes Protokoll zu kommunizieren, wie in der Apple Developer Documentation beschrieben. Diese Schemata müssen von der App deklariert werden, die dann eingehende URLs gemäß diesen Schemata verarbeitet. Es ist entscheidend, alle URL-Parameter zu validieren und alle fehlerhaften URLs zu verwerfen, um Angriffe über diesen Vektor zu verhindern.

Ein Beispiel wird gegeben, bei dem die URI myapp://hostname?data=123876123 eine spezifische Anwendungsaktion auslöst. Eine festgestellte Schwachstelle war in der Skype Mobile-App, die unzulässige Anrufaktionen über das skype://-Protokoll ermöglichte. Die registrierten Schemata finden sich in der Info.plist der App unter CFBundleURLTypes. Bösartige Anwendungen können dies ausnutzen, indem sie URIs neu registrieren, um sensible Informationen abzufangen.

Registrierung von Anwendungsabfrage-Schemata

Seit iOS 9.0 erfordert canOpenURL:, um zu überprüfen, ob eine App verfügbar ist, die Deklaration von URL-Schemata in der Info.plist unter LSApplicationQueriesSchemes. Dies begrenzt die Schemata, die eine App abfragen kann, auf 50 und verbessert die Privatsphäre, indem es die Auflistung von Apps verhindert.

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

Testing URL Handling and Validation

Entwickler sollten spezifische Methoden im Quellcode untersuchen, um den Aufbau und die Validierung von URL-Pfaden zu verstehen, wie application:didFinishLaunchingWithOptions: und application:openURL:options:. Zum Beispiel verwendet Telegram verschiedene Methoden zum Öffnen von 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

Methoden wie openURL:options:completionHandler: sind entscheidend, um URLs zu öffnen und mit anderen Apps zu interagieren. Die Identifizierung der Nutzung solcher Methoden im Quellcode der App ist der Schlüssel zum Verständnis externer Kommunikationen.

Testing for Deprecated Methods

Veraltete Methoden zur Handhabung von URL-Öffnungen, wie application:handleOpenURL: und openURL:, sollten identifiziert und auf Sicherheitsimplikationen überprüft werden.

Fuzzing URL Schemes

Fuzzing von URL-Schemata kann Speicherbeschädigungsfehler identifizieren. Tools wie Frida können diesen Prozess automatisieren, indem sie URLs mit unterschiedlichen Payloads öffnen, um auf Abstürze zu überwachen, veranschaulicht durch die Manipulation von URLs in der iGoat-Swift-App:

$ 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 von benutzerdefinierten URL-Schemata

Laut diesem Beitrag könnten bösartige Apps andere benutzerdefinierte Schemata von Apps registrieren, dann kann die bösartige App einen Browser öffnen, der alle Cookies der Safari-App mit ASWebAuthenticationSession hat.

Mit dem Browser kann die bösartige App eine von Angreifern kontrollierte Webseite laden, und TCC wird den mobilen Benutzer um Erlaubnis bitten, diese App zu öffnen. Dann könnte die bösartige Webseite auf eine Opferseite umleiten, zum Beispiel einen OAuth-Fluss mit dem Parameter prompt=none. Wenn der Benutzer bereits im OAuth-Fluss angemeldet war, wird der OAuth-Fluss das Geheimnis über das benutzerdefinierte Schema der Opferanwendung zurücksenden. Da die bösartige App es jedoch auch registriert hat und da der verwendete Browser innerhalb der bösartigen App ist, wird das benutzerdefinierte Schema in diesem Fall von der bösartigen App behandelt, die in der Lage sein wird, das OAuth-Token zu stehlen.

Referenzen

• https://mas.owasp.org/MASTG/tests/ios/MASVS-PLATFORM/MASTG-TEST-0075/

• https://evanconnelly.github.io/post/ios-oauth/

Lernen & üben Sie AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE) Lernen & üben Sie GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

HackTricks unterstützen

• Überprüfen Sie die Abonnementpläne!

• Treten Sie der 💬 Discord-Gruppe oder der Telegram-Gruppe bei oder folgen Sie uns auf Twitter 🐦 @hacktricks_live.

• Teilen Sie Hacking-Tricks, indem Sie PRs an die HackTricks und HackTricks Cloud GitHub-Repos senden.