Android app WebView hijacking via MITM

Stealing user logins by hijacking a vulnerable webview implementation in a mobile app

Many mobile apps are simply webview wrappers around a website, often with some additional native features to better integrate with the OS. While bug bounty hunting, I was analyzing an app like this. The program has a long list of domains, plus an android app, and I had a feeling the android app would be a good place to start hunting for overlooked issues. The app was simple and easy to decompile and analyze. I quickly found that when opened, the app would go through a few steps:

1. Check SharedPreferences for a cached URL and test connectivity; if it succeeds, load this page in the webview
2. If there’s no cached URL or it isn’t reachable, fetch a list of domains from one of 5 hardcoded IPs
3. Check those IPs for connectivity, load the first one that works

The Vuln

This is a simple process used to keep the app working if one domain is unavailable. I believe this was done due to some domains being geoblocked. The problem with their implementation is that this request to fetch the domain list is done over plain HTTP, making it susceptible to a man-in-the-middle attack that intercepts the request and responds with malicious domains. However, that wasn’t all that was needed to hijack the webview. The app did have a filter, but it was exceptionally weak. All it checked for was that the URL contained a value from a whitelist of strings, all of which are variations on the company’s name. The string didn’t even have to be in the domain name, just somewhere in the URL, meaning attacker.com/COMPANY_NAME would work just fine. The attacker doesn’t even need to bother buying a new domain for the bypass.

Proof of Concept

As a proof-of-concept, I wrote a simple mitmproxy script that fetches the domain list from the IP, then blocks any requests to the legitimate domains. This causes the app to make a request for new domains from the hardcoded IP addresses over plain HTTP. The proxy is configured to intercept those requests and respond with a URL on my own domain that hosts a page mimicking the real site’s login page. With this running, every instance of the app whose traffic passes through the proxy would be redirected to the malicious site. A victim who opens the app would assume their session expired and enter their credentials, at which point their login would be sent to my server and the malicious page would redirect the victim to the real site. Since the app’s webview doesn’t display the URL, the victim would have no way to know they entered their credentials on a malicious page. Making matters worse, the app would cache the malicious URL, sending the victim to the fake page every time. Even if the victim changes their password, the site would simply prompt them for another login.

Response

After reporting this, the company decided not to fix the issue, responding that they “don’t have a choice regarding some goals of the app”. I completely disagree with this decision; there are options available to continue using this method of requesting URLs from a hardcoded IP while also securing it. Either adding the IP to their existing SSL certificates as a SAN or at least using a self-signed certificate would be huge improvements.