A browser bug in Google Chrome has been discovered that lets bad actors uncover private data stored on Facebook, Google sites and other platforms, by using video and audio HTML tags, and the filtering functions in websites.
The bug in question exists in the Blink engine, which is used to power Chrome. The vulnerability allows attackers to inject specialized hidden video or audio tags into the browsers of unsuspecting visitors to a malicious site.
According to Imperva, which identified and reported the flaw, the attack flow would start with a malefactor enticing a user to visit this malicious site, which has the injection script with the tags running. If the victim also has Facebook open, that script could then send requests to a Facebook page that has audience restrictions on it – for instance, perhaps only people from the state of Texas are allowed to view it. The attacker can then assess if the victim is from Texas based on whether or not he or she would have access to the page. This same method could be used to deduce the age, sex, likes or the location history of a user – essentially, the attacker can play “20 questions” to profile the victim.
Put more technically, these A/V HTML tags are used as part of a script that generates requests to a target resource within a web application that’s also open on the victim’s desktop, such as Facebook. In turn, the responses to those requests can be used to infer data about the infected user.
“In its essence, the bug allows attackers to estimate the size of a cross-origin page using the video or audio tags,” explained Ron Masas, security researcher at Imperva, in an interview.
He added, “The attacker can start ‘asking Facebook’ yes or no questions by sending requests to specific Facebook posts and estimating their size (small response = false, big response = true). I managed to find creative ways to make Facebook reflect all sorts of information using a post’s audience restrictions and Facebook graph-search endpoints.”
Attackers could thus establish the exact age or gender of a person, or any other information saved on Facebook, regardless of his or her privacy settings.
The script creates a hidden audio element that requests a given resource, tracks the number of times the `onprogress` event was triggered and returns the value of the counter once the audio parsing fails.
The data is thus extracted based on side-channel information, Masas told Threatpost.
“The progress events fired from the video/audio tags were proven to be linked to the requested resource size – the page size can also be treated as side channel information – allowing us to deduce private information about the user,” he explained.
The attack may seem labor-intensive, but with several scripts running at once — each testing a different and unique restriction – the bad actor can “relatively quickly mine a good amount of private data about the user,” Masas said. And since the attack is performed on each of the victim’s browsers, scaling it is just a matter of getting more people to visit the malicious site running the injection script.
Beyond social-media privacy, there are more serious concerns. If the attack script is running while the victim has a site open that requires email registration — an e-commerce or cloud-application site, for instance – an attacker could correlate the private data lifted from social media with a login email address, for even more extensive and intrusive profiling.
“I think the biggest danger with this kind of attack is data enrichment (connecting information like age, gender, Facebook likes, etc. to existing users),” Masas said.
For an exploit to work, the target user would need to have the threat actor’s malicious website with the scripts running open in the browser; and, he or she would need to at the same time have Facebook or other web applications open that the script can query.
The flaw affects Chrome 67 and older versions of the browser – Google patched it in Chrome 68, released in July, so users should update, if they haven’t already.