The Zirconium Group, comprising 28 fake advertising agencies and with its own ad platform was shutdown in January. This came after security company Confiant exposed it in a blog.
Confiant is publishing more details of its investigations into the Zirconium code. It has found evidence that Zirconium had a workaround to new user protections that Google is introducing in its Chrome browser
In 2017, Zirconium purchased 1 billion ad views as part of its malvertising campaigns. This affected 62% of websites that relied on advertising for revenue.
One of the techniques it used was forced redirect. It sends a user to a different website than the one they landed on. To prevent abuse of forced redirect, browser manufacturers have been introducing code that allows users to prevent forced redirection. Google is releasing its fixes across several versions of its browser, Chrome.
Chrome 64, which shipped between 23-24 January was supposed to have a feature to block ads from doing forced redirect. It presents users with a box that says the redirect has been blocked. On March 1st, Google announced that this feature would be delayed until Chrome 67. Chrome 65, which shipped at the end of February added code that fixed a loophole in Google’s pop-up blocker. Another feature is a new reporting tool called the Abuse Experiences Report. It allows developers to check their own websites and fix them before Google starts blocking the opening of new tabs.
According to Confiant, Zirconium was already shipping Javascript inside the Zirconium payload. This Javascript was able to circumvent the new forced redirect protections that Google has added to Chrome.
How does it work?
In brief, the code uses some clever tricks to hide the details of a PDF file. When executed, the Javascript recreates the name of PDF file. It then uses PDFium, Google’s own PDF renderer to display the file. PDFium uses Chrome’s tabs API. This means that commands are run with higher level privileges than regular web pages. This use of the API allowed Zirconium to create what is effectively a privilege escalation attack.
The sequence of events, as published in the Zirconium blog are:
- 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). This creates a StackOverflow. - 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.
This is not a new attack
Surprisingly, this is not a new method of attack. Confiant provides a link to work done by security researcher Didier Stevens. In 2008 Stevens wrote: “In this post, I show how basic features of the PDF language can be used to generate polymorphic variants of (malicious) PDF documents. If you code a PDF parser, write signatures (AV, IDS, …) or analyze (malicious) PDF documents, you should to be aware of these features.”
Interestingly, the Confiant post says: “In his research, [Stevens] 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.”
Should this attack fail it appears that Zirconium had a backup plan. If redirecting a user failed they would install the Coin Hive cryptocurrency miner onto the local machine. This would then be used to generate money for Zirconium.
Google failed to respond to this attack
Perhaps the biggest surprise here is the reaction from Google. It has invested in delivering its own anti-redirect code. It does not see this attack as being against the core code inside Chrome. Instead, the attack is against what Google calls a feature and falls into the category of an intervention. It allows developers to create interventions to improve the user experience.
Quite how forced redirect or the installation of cryptocurrency mining software without user permission is improving the experience is something only Google can explain. ET emailed the Google press office to say we were covering this story. We asked how this qualified as an intervention but have had no response.
What does this mean?
There are a number of worrying takeaways from this. The first is that an attack that was first written about 10 years ago is still effective again modern browsers. It makes a mockery of the claims by browser manufacturers, in this case Google, to be improving their security.
The second takeaway is that rather than address a 0-day attack against a security feature, Google has sidestepped it. By designating this a feature and the attack an intervention it avoids having to do anything. Once again, this makes a mockery out of its claim to be improving user security.
On top of this we have evidence that just as its world was coming to an end, Zirconium was creating 0-day workarounds to security features. It is unlikely that this is the only workaround that Zirconium had developed to defeat browser security.
The question is, who has all that code now? It may be that Confiant and others will unearth more tricks in the code that they have captured. It is also just as likely that there is a code repository with a lot of, as yet unseen, workarounds. Whoever has that code will be looking for an opportunity to monetise it.
