Zirconium was one step ahead of Chrome’s redirect blocker with 0-day
On January 15, Confiant exposed the activity of the Zirconium group, spreading malicious ads via a network of fake ad agencies through 2017, in what amounted to the largest malvertising campaign of recent times.
On the day following our disclosure, the gateway running on beginads.com disappeared, marking the end of their operations. But we continued to review recent network traces and found much more information about their payloads.
Preparing for a Shift in Attack Surface
As we continued to review recent payloads of the attack, we realized that Zirconium had developed unique mechanisms to prepare for changes in the way the Chrome browser allows for automated top level navigation, a critical component that Zirconium (like the bulk of malvertising attackers) abused to forcefully redirect websites to support scams and fake install landing pages.
Aside from Chrome’s initiative, iframe sandboxing is now supported by most browsers and has slowly been gaining momentum among web publishers as a means to thwart ad-driven forced redirects.
As it turns out, Zirconium already had a sophisticated approach to tackle these threats to its business model. Below is a sample of the Javascript payloads that we found (dated January 6, 2018):
We’ve cleaned up the code and extracted the following snippet that specifically targets Chrome browsers:
Targeting Chrome: Walk-through
- Pieces of strings are assembled from small arrays, each field containing single-character strings resolved in the substitution table.
- y resolves to “%”, while [d, p, g] resolves to “pdf” which then concatenated and converted to upper case starts the header of a valid PDF document “%PDF”
- Another neat trick (~16 / 10 + em)
tilde is a javascript operator that flips all bits of the input.
“~” when performed on integers is equal to -(x + 1)
Obligatory StackOverflow link - So ~16 / 10 = -1.7 and the “em” variable is an empty array, forcing the output to be a string.
- Now we have the full header %PDF-1.7\n
- This goes on until the whole PDF document is built as a string, which is then staged on the DOM as an embed with data:// URI src.
PDF Payload Analysis
Adobe PDF has been a prime vector of exploitation over time, for its large attack surface but also as a way to perform browser operations like executing javascript, launching an executable (!) or in this case navigating to an arbitrary page.
The PDF renderer that ships with Chrome is called PDFium. PDFium is Google’s own PDF renderer (based on Foxit Software’s implementation). Although it doesn’t carry the legacy of security issues found over time in Adobe’s reference implementation, it is not immune to vulnerabilities.
PDFium implements navigation actions using Chrome’s tabs API, which provides higher privileges than regular web pages. For example, same origin policy does not apply to it. By relying on a native PDF command to navigate to a new URL, Zirconium successfully circumvented Chrome’s anti-redirect protection.
Didier Stevens — an expert in PDF security, was writing about this trick 10 years ago. We won’t paraphrase his research, please refer to his article for more details.
In his research, he also points out that strings embedded in PDF can be encoded using a hex syntax and he gives the example of %55RI being equivalent to URI (since 0x55 is the ascii value for ‘U’). It looks like the Zirconium group simply copy-pasted Didier’s work to come up with their circumvention, since that %55RI value is exactly what we found in the Zirconium payload.
Crypto-jacking = Cherry on the cake
Zirconium implemented a try/catch around their regular redirection code to handle situations where it fails. The only reason it could fail is if the redirect attempt happens from a sandboxed iframe with no allow-top-navigation attribute.
There is growing interest among web publishers to serve ads in sandboxed iframes to protect against forced redirects, but it’s still a marginal effort. In the remote case that a redirect would fail because of iframe sandboxing, Zirconium proceeded to serve a CoinHive crypto-miner as a fallback, to squeeze some extra revenue out of users’ CPU power.
The general flow of execution could be summarized as follows:
Crypto-jacking Redirection Chain
The Zirconium crypto-jacking scheme didn’t just instantiate CoinHive but moved the user session across multiple services to hinder detection. The first bitly link (found in line 14 above) generated close to one million crypto-mining sessions in a month according to Bitly stats - merely as a left-over from failed forced redirects!
Crypto-jacking Iframe, redirection chain:
→ Bitly (bitly.com/2nFCL3e — 965k clicks)
→ Google Gadgets / iframe (pagead2-opensocial.googleusercontent.com)
→ Bitly (bit.ly/2AI65eC — 3 clicks)
→ Pastebin (https://pastebin.com/raw/iYth06ne)
→ Google Gadgets / proxy (hive-opensocial.googleusercontent.com)
→ Bitly (bitly.com/jsh1ve2 — 105 clicks)
→ CoinHive (http://coin-hive.com/lib/coinhive.min.js)
Bitly
The inconsistent number of clicks recorded by the Bitly intermediate URLs (3 clicks and 105 clicks respectively) is an indication that the chain has been changing over time. We can however conclude that close to a million user sessions were funneled through CoinHive via a variety of pathways.
Google Gadgets?
Gadgets API is meant to “build light-weight apps that run on Google products and beyond”. The Gadgets API is perfect to host malicious code because it’s a rare opportunity to run arbitrary html/javascript on a Google hosted domain, and benefit from the inherited reputation.
The attackers sprinkled some additional masquerading tidbits along the way, for example by overloading the URL parameter with a genuine Google ad serving URL, that the web server ignores since it’s already defined earlier in the list of arguments:
There have been prior cases of hiding crypto-jacking behind Google Gadgets, see this instance from January as an example.
Google Chrome Vulnerability Disclosure and Resolution
We have privately notified the Chrome team of our findings but the vulnerability is still not fixed as of today. The feature being circumvented falls into the category of what Chrome calls “Interventions” and that aims at improving user experience by willingly breaking web standards. In their own words:
An intervention is when a user agent decides to deviate slightly from a standardized behavior in order to provide a greatly enhanced user experience. Because of its nature, it must be done sparingly and with extreme prudence.
Chrome’s anti-redirect protection is not yet live in Chrome Stable but can be activated via a flag. The project started in 2016 but was delayed multiple times. General availability was postponed three times since the November 2017 announcement and might come in Chrome 67 if not delayed further.
Conclusion
The simple proposition of blocking cross-origin forced redirects proves to be a significant challenge for Chrome, both from a false negative perspective as evidenced here as well as from a false positive perspective.
The Chromium team’s response to our private disclosure is that they don’t consider Zirconium’s redirect technique as a security vulnerability, claiming the feature being circumvented is itself not a security feature. Regardless, such a hole defeats its purpose and makes the protection ineffective, exposing millions of online users to security threats. We’ve decided to go public with it, in the hope of bringing much needed attention to the situation.
These findings provide additional insight into the inner workings of the Zirconium group and confirm they had been running their business with a rare level of sophistication, planning for changes in their environment and coming up with effective technical solutions to stay relevant. They have shown no activity since our research went public last month, but we have no doubt that they will come back with new tricks.
About Confiant
Confiant is a cyber security company that came out of a recognition that the world’s most sophisticated advertisers aren’t Verizon or P&G, but criminals using the industry for their own, selfish ends. These criminals are hijacking programmatic advertising and giving publishers a bad name.
Confiant protects publishers’ and platforms’ reputations, revenue, and resources with always-on anti-malware software that provides protection for desktop, mobile, and video ads. Our sole focus is on helping advertising platforms and publishers rid the world of malware. This focus enables us to evolve quickly and meet our clients’ needs for defeating the bad actors trying to undermine the industry.
We are the first to come to market with a technology that does not just detect the malicious activity, but actively blocks it. We believe in the intelligent application of this new technology to fight back and make media safe for everyone.
