Android WebView and OEM Customizations Are Leaking Your Sensitive Data

TLDR: Researchers at Black Hat 2023 demonstrated that Android applications often bypass permission models to exfiltrate sensitive device identifiers like IMEI, IMSI, and ICCID. By exploiting insecure WebView implementations and OEM-specific system property access, malicious code can track users across applications and even after factory resets. Pentesters should prioritize auditing WebChromeClient implementations and monitoring IPC calls for unauthorized access to device-unique identifiers.

Mobile security often feels like a game of whack-a-mole where the OS vendor adds a new permission, and developers find a new way to circumvent it. The research presented at Black Hat 2023 regarding sensitive information collection on Android is a stark reminder that the platform's security model is only as strong as its weakest implementation. While Google has spent years tightening the screws on access to hardware identifiers, the reality is that the ecosystem remains fragmented, and third-party SDKs are frequently the primary culprits in data exfiltration.

The WebView Permission Bypass

The most critical finding in this research centers on how applications handle WebChromeClient and onPermissionRequest within a WebView. Developers often assume that because they have requested a permission in the AndroidManifest.xml, the WebView will automatically handle the user prompt. This is a dangerous assumption.

When a WebView loads a third-party URL, it can be tricked into granting access to sensitive resources like the camera, microphone, or location without the user ever seeing a prompt. The researchers showed that by failing to properly implement the onPermissionRequest callback, an application can inadvertently grant a malicious web page full access to the device's hardware.

Consider this snippet of a vulnerable implementation:

@Override
public void onPermissionRequest(PermissionRequest request) {
    // This blindly grants all requested permissions
    request.grant(request.getResources());
}

In a real-world engagement, this is a goldmine. If you are testing an application that uses WebView to render content from an external source, your first step should be to inspect the WebChromeClient. If you find an implementation that calls grant() without checking the origin or the specific resource requested, you have found a path to bypass the entire Android permission system. This falls squarely under OWASP A01:2021-Broken Access Control, as the application fails to enforce the intended security boundaries between the web content and the host device.

OEM Fragmentation and Identifier Persistence

Beyond the WebView issues, the research highlighted how OEM-specific customizations create massive security holes. Android is not a monolithic OS; it is a collection of AOSP code modified by manufacturers. These modifications often introduce custom APIs to access hardware identifiers that are supposed to be restricted.

The researchers identified several instances where OEMs stored sensitive data in system properties that were readable by any application on the device. Because these properties are often set at the factory level and are not cleared during a standard user-initiated factory reset, they act as a persistent, immutable tracking ID. This is a massive privacy failure.

The list of affected devices and identifiers is extensive, and the researchers linked these vulnerabilities to specific CVEs, including CVE-2021-0428, CVE-2021-25344, and CVE-2021-25515. These are not theoretical bugs; they are real-world implementation flaws that allow an attacker to maintain a persistent fingerprint of a device, regardless of the user's attempts to reset their privacy settings.

Detection via Dynamic Instrumentation

For those of us in the field, static analysis is often insufficient because of the way these identifiers are constructed and accessed. The researchers proposed a dynamic instrumentation approach using Frida to hook the string constructors and IPC calls. By hooking the String constructor, you can monitor every string created by the application. If that string contains a known device identifier, you have identified a potential exfiltration point.

A simple Frida script to monitor these calls looks like this:

Java.use("java.lang.String").$init.overload('[B', 'int', 'int').implementation = function(bytes, offset, length) {
    var str = this.$init(bytes, offset, length);
    var result = Java.cast(this, Java.use("java.lang.String"));
    if (result.contains("IMEI") || result.contains("IMSI")) {
        console.log("[!] Sensitive identifier detected in string: " + result);
    }
    return str;
};

This technique is highly effective during a pentest. By running this script while interacting with the application, you can quickly see if the app is constructing strings containing sensitive hardware identifiers. If it is, you then need to trace where those strings are being sent. Are they being logged to Logcat? Are they being sent to a remote server via an HTTP request?

The Path Forward for Researchers

Defenders need to move away from relying on the OS to protect these identifiers. If you are developing an Android application, you must assume that the underlying OS might be compromised or that the OEM has introduced insecure APIs. Implement strict origin checking in your WebView and never trust data coming from a WebView to perform sensitive operations.

For the research community, the takeaway is clear: the battle for mobile privacy is shifting from the OS layer to the application layer. We need to be more aggressive in auditing how applications interact with the system and how they handle the data they collect. The next time you are on an Android engagement, don't just look for hardcoded API keys. Look for how the application handles its WebView and whether it is reaching into the system properties to pull identifiers that it has no business accessing. The fragmentation of the Android ecosystem is a feature for attackers, and it is our job to expose the gaps it creates.