How this de-anonymization attack works is hard to explain, but relatively easy to understand once you get the gist. Someone carrying out the attack will need a few things to get started: a website they operate, a list of accounts associated with people they want to have visited that site, and content posted to the platforms of the accounts on their target list that either allows the targeted accounts to view that content or blocks them from viewing it – the attack works both ways.
The attacker then embeds the aforementioned content on the malicious website. Then they wait and see who clicks. If someone on the targeted list visits the site, the attackers know who they are by analyzing which users can and cannot see the embedded content.
The attack takes advantage of a number of factors that most people probably take for granted: many major services, from YouTube to Dropbox, allow users to host and embed media on a third-party website. Regular users usually have an account with these ubiquitous services and, crucially, they often remain logged in to these platforms on their phones or computers. Finally, these services allow users to restrict access to content uploaded to them. For example, you can set up your Dropbox account to privately share a video with one or a handful of other users. Or you can publicly upload a video to Facebook but block certain accounts from watching it.
These “blocking” or “allowing” relationships are at the heart of how the researchers discovered they can reveal identities. For example, in the “allow” version of the attack, hackers can silently share a photo on Google Drive with a Gmail address that may be of interest. They then embed the photo on their malicious web page and lure the target there. When visitors’ browsers try to load the photo via Google Drive, the attackers can accurately deduce whether a visitor has access to the content, i.e. whether they have control over the affected email address.
The existing privacy protections of the major platforms prevent the attacker from directly checking whether the site visitor was able to load the content. But the NJIT researchers realized they could analyze accessible information about the target’s browser and their processor’s behavior as the request occurs to draw a conclusion about whether the content request was allowed or denied.
The technique is known as a “side channel attackbecause the researchers found they could make this determination accurate and reliable by training machine learning algorithms to parse seemingly unrelated data about how the victim’s browser and device process the request. Once the attacker knows that the only user they allowed to view the content did (or that the only user they blocked has been blocked), they deanonymize the site visitor.
Complicated as it may sound, the researchers warn that it would be easy to execute once the attackers have done the preparatory work. It would only take a few seconds to potentially expose any visitor to the malicious site – and it would be virtually impossible for an unsuspecting user to detect the hack. The researchers developed a browser extension that can fend off such attacks and is available for Chrome and Firefox. But they note that this may affect performance and is not available for all browsers.
Through a major disclosure process to numerous web services, browsers and web standards bodies, the researchers say they have started a larger discussion about how to address the issue comprehensively. Currently, Chrome and Firefox have not made any comments public. And Curtmola says fundamental and likely unfeasible changes in the way processors are designed are needed to address the problem at the chip level. Still, he says joint discussions through the World Wide Web Consortium or other forums can eventually lead to a broad solution.
“Sellers are trying to see if it’s worth fixing this,” he says. “They need to be convinced that it’s a serious enough problem to invest in solving it.”