14 DAY TRIAL // A security flaw affecting the Android version of Chrome browser can be leveraged by an attacker to direct users to malicious web pages, maintaining the appearance that resources are loaded from a legitimate location.
Security researchers have discovered that the browser does not handle 204 “No Content” responses properly and allows displaying arbitrary HTML code while the address bar points to a legitimate source.
Proof-of-concept code is available
The vulnerability, confirmed on Lollipop (Android 5.0) and earlier versions of the operating system, was discovered by Rafay Baloch, a security researcher from Pakistan, who demonstrated it on a Samsung Galaxy S5.
He collaborated with Tod Beardsley from Rapid7 for the responsible disclosure of the bug, and with software developer Joe Vennix for improving the initial proof-of-concept code.
Beardsley says the issue is a combination of improper handling of the 204 HTTP error (server receives request but there is no information to send back) and a “window.open” event, leading to rendering web pages in a misleading context.
“An attacker could use this vulnerability to convince a victim of a phishing e-mail, text, or link to enter private credentials to an untrusted page controlled by the attacker,” Beardsley wrote in a security advisory on Monday.
Baloch’s demonstration of the flaw consists in loading a fake Google login page, which states that the content is loaded from “https://www.google.com/csi,” a location that does not exist on Google’s server.
The result is that the browser’s address bar advertises that the content is loaded from a Google domain and impersonates the Google login page, but the resource is actually provided by a server controlled by the attacker.
Glitch could still be exploited
Baloch says that the success of the proof-of-concept exploit depends on triggering the timeout at the right time, and that Joe Vennix found that setting it between 1500 and 2000 may work better.
If the timeout is triggered too soon, i.e. before the “no content” HTTP response is received from gmail.com, the fraudulent page is rendered with a blank address, which is what currently happens on Android 5.1 and on Windows.
The address bar initially shows the URL for the non-existent resource on the server and then becomes blank.
Although this type of behavior could alert users and stop them from entering the credentials, in many cases, the address bar is overlooked and catching a glimpse of the seemingly legitimate domain may make the user trust the legitimacy of the content served.
If a random phishing domain name is a clear hint of malicious activity, a blank address bar, as confusing as it may be, could not trigger any suspicion in many cases.
The vulnerability was reported to Android security team on February 9 and patches became available on Lollipop and KitKat in April.
[UPDATE, April 20]: In an email conversation, Tod Beardsley explained that eliminating the vulnerability on devices running KitKat require system update, making users dependent of their carriers. On Lollipop and up, the updates have been available since April 7 via Google Play Store.
“Google replaced AOSP Browser with Chrome on KitKat. Later, updated the patching mechanisms for Chrome on Lollipop to make it much easier to maintain moving forward. Prior to Lollipop, significant updates to Chrome (specifically, the WebView component) still require an operating system level patch on KitKat,” the researcher said.
The AOSP Browser is the stock/default web browser in Jelly Bean and earlier versions of Android. The decision to discontinue its development because the technology it included could not support implementation of new features that would increase its performance.
Beardsley says that until a patch is applied, users should avoid relying on mobile Chrome to authenticate to online services, “especially when following links from untrusted or unverifiable sources.”