Introduction to Android WebView RCE

Android’s WebView component is a powerful tool allowing developers to display web content within native applications. Essentially, it’s a mini-browser embedded in an app. While incredibly versatile, misconfigurations or vulnerabilities within WebView can lead to severe security flaws, most notably Remote Code Execution (RCE). An RCE vulnerability allows an attacker to execute arbitrary code on the user’s device, often with the same privileges as the vulnerable application itself. This tutorial will delve into the common causes of WebView RCE, specifically focusing on the infamous addJavascriptInterface vulnerability, and provide a step-by-step guide on how to exploit it.

Understanding the Android WebView Security Model

At its core, WebView aims to isolate web content from the native application. However, bridging mechanisms allow communication between JavaScript running in the WebView and Java code in the host app. The most common of these is addJavascriptInterface(). When an object is injected into the JavaScript context, JavaScript can call public methods of that object. This power, if unchecked, can be weaponized.

The addJavascriptInterface Vulnerability Explained

The addJavascriptInterface() method allows developers to bind a Java object to the JavaScript context of a WebView. This means that JavaScript code running within the WebView can directly invoke public methods of the bound Java object. Prior to Android 4.2 (Jelly Bean MR1, API Level 17), this mechanism was inherently insecure. An attacker could use Java Reflection to invoke arbitrary methods on arbitrary classes, effectively bypassing intended restrictions and achieving RCE.

Consider an application that exposes a Java object named AppInterface to JavaScript:

public class MainActivity extends AppCompatActivity {
    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_main);

        WebView webView = findViewById(R.id.webView);
        webView.getSettings().setJavaScriptEnabled(true);
        webView.addJavascriptInterface(new AppInterface(this), "Android");
        webView.loadUrl("file:///android_asset/webpage.html");
    }

    public class AppInterface {
        Context mContext;

        AppInterface(Context c) {
            mContext = c;
        }

        @JavascriptInterface // Required for API Level 17+
        public void showToast(String toast) {
            Toast.makeText(mContext, toast, Toast.LENGTH_SHORT).show();
        }
    }
}

In this example, JavaScript could call Android.showToast("Hello from WebView!"). The vulnerability arises because, on older Android versions, the injected object’s methods were accessible, and more critically, the Java Reflection API (java.lang.Class, java.lang.reflect.Method) could be accessed through the JavaScript-exposed object’s prototype chain.

Step-by-Step Exploitation (Pre-API 17)

Phase 1: Reconnaissance – Identifying the Vulnerability

The first step is to identify if an application uses WebView and if it exposes any JavaScript interfaces. This can be done through static or dynamic analysis.

Static Analysis:

• Decompile the APK using tools like Jadx or Apktool.
• Search for addJavascriptInterface in the decompiled Java code:

grep -r "addJavascriptInterface" com/example/vulnerableapp/

• Examine the methods of the classes passed to addJavascriptInterface.

Dynamic Analysis:

• Use an intercepting proxy (like Burp Suite or OWASP ZAP) to monitor network traffic. If WebView loads remote URLs, you might intercept the web content.
• If local files are loaded, you might need root access to inspect the application’s data directory or use debugging tools.
• On a rooted device, you can use Frida or Xposed to hook addJavascriptInterface calls and inspect the injected objects.

Phase 2: Crafting the Exploit Payload

Once you identify an exposed interface (e.g., named