Massive eGobbler Malvertising Campaign Leverages Chrome Vulnerability To Target iOS Users
As publishers have become increasingly aware over the last week, there’s a series of rampant malvertising campaigns on the loose targeting iOS users.
We’ve attributed the flurry of activity to a known threat actor called eGobbler — so named after the huge volumes of hits that their campaigns generate.
gob·bler1 : noun — a person who eats greedily and noisily.
This group has a tendency to ramp up their buying around holidays and weekends. Typically these campaigns peak in volume over a period of 36–48 hours before going into a state of hibernation until the next big push.
For this wave of attacks, eGobbler is easily recognized by their use of the “.world” TLD for their landing pages.
Here’s an example:
Malvertisers Hijack User Sessions
Session hijacking is the primary goal for the majority of malvertisers (including eGobbler). A session can be described as hijacked when a user is unwillingly, and through no action of their own, moved to another website or landing page.
Techniques for hijacking vary — often users are redirected via a JavaScript directive similar to this:
top.window.location = hxxp://malvertiser/landingpage.html
However, other mechanisms such as pop-ups can be leveraged to achieve a similar effect as well. A pop-up is defined as the spawning of a new window or tab.
Both methods have their own pros and cons from a malvertising perspective. For example, redirects can be performed from cross-origin iframes if sandboxing is absent. In addition, modern browsers have builtin pop-up blockers that are increasingly effective at killing new windows that are spawned uninitiated. Chrome also has some anti-redirect functionality builtin.
According to Confiant data, 35% of all ads are served through sandboxed cross-origin iframes.
Because native browser pop-up blockers are typically very effective, it’s quite unusual to see malicious campaigns that lean on pop-ups as the primary hijack mechanism.
eGobbler’s Atypical Payload
Like other bad actors, eGobbler leverages cloaking techniques and obfuscation to make their payloads look like legitimate ads, but a closer look at the payload behind these recent attacks reveals a very special twist.
We were already aware from our internal blocking metrics that the campaign is iOS targeted. Normally this would not be alarming, as this is common among malvertisers for varying reasons. However, given the volume of this attack we decided to inspect it with extra scrutiny.
We tested the payload across over two dozen devices, both physical and virtual. The tests included variations in platform, operating system, browser, desktop, and mobile. The malicious code itself has hard-coded logic that targets iOS, so we removed that condition in order to see the results of the full execution on all of the devices that we tested. We also split test this experiment between sandboxed and non-sandboxed iframes.
Right away we were surprised to find that the payload’s main session hijacking mechanism was pop-up based, and furthermore, Chrome on iOS was an outlier in that the built-in pop-up blocker failed consistently.
Revealing A Chrome Security Bug
From here we underwent the tedious process of reverse engineering the payload, where we discovered techniques that took advantage of iOS Chrome’s detection around user activated pop-up detection, resulting in the circumvention of pop-up blocking.
We will be offering an analysis of the payload and POC exploit for this bug in a future post given that this campaign is still active and the security bug is still unpatched in Chrome as of this blog post.
The Chrome team was notified of the bug with a working POC on April 11th and is currently investigating the matter. They responded in a timely manner within several hours of the report. We look forward to eventually sharing how this circumvention was accomplished.
Breaking The Sandbox
Perhaps the most fascinating thing about the malvertising exploit leveraged by eGobbler is that it’s not preventable by standard ad sandboxing attributes.
Sandboxing is a set of additional attributes that can be applied to an iframe in order to restrict the actions and APIs available to the content from within that iFrame.
These restrictions can include directives like disallowing JavaScript or blocking top level navigation unless prompted by user action. Sandboxing tends to have a pretty substantial impact as far as malicious ad mitigation is concerned, though it’s not a panacea.
A large majority of sandboxed cross-origin ad serving happens to come from Google — this includes both AdX and EBDA.
We tested the eGobbler payload against the standard set of sandboxing attributes as they exist in 90% of Google’s ad serving products. The attributes include:
allow-forms
allow-pointer-lock
allow-popups
allow-popups-to-escape-sandbox
allow-same-origin allow-scripts
allow-top-navigation-by-user-activationWhile on the surface the allow-popups directives seem like there’s nothing special about eGobbler’s payload, this is not true, because these actions should only be possible as a result of direct user interaction — a requirement that the eGobbler exploit successfully circumvents.
The fact that this exploit is able to bypass that need for user interaction should be impossible according to the same-origin policy as it pertains to cross-origin iframes.
Furthermore, this completely circumvents the browser’s anti-redirect functionality, as the attacker no longer needs to even spawn a redirect in order to hijack the user session.
We believe that this exploit was key in magnifying the impact of this attack. Where standard sandboxing rules like the ones above would ultimately succeed in blocking certain redirections, they consistently failed to protect users from this campaign on iOS Chrome
eGobbler’s Campaign By The Numbers
The overall push lasted 6 days starting on Saturday, April 6th and was composed of 8 individual campaigns and over 30 fake creatives.
Each of these had its own targeting, which was primarily US based, but European publishers saw significant impact as well.
The fake ad campaigns themselves had lifespans in the 24–48 hour range, which is common with eGobbler.
We estimate that over 500MM user sessions have been exposed beginning Saturday, April 6th.
Even though eGobbler has recently been seen on many buy-side platforms, this entire campaign ran on just one the whole time.
More On eGobbler’s MO
The typical entry points for eGobbler campaigns are legitimate ad servers that they infect coupled with one or more buy-side platforms.
They use cloaked intermediate CDN domains as part of their ad delivery. Quite often these domains sit behind at least a single layer of client-side fingerprinting.
In attempt to fly under the radar, eGobbler attempts to smuggle their payloads in popular client-side JavaScript libraries such as GreenSock.
The 8 individual campaigns that were introduced during the big storm following April 6 were staggered with new ones appearing approximately every two days. Each campaign had its own targeting, and its own lifespan:
Domain First Seenlafabriqueaviva.global.ssl.fastly.net 2019-04-06
1444653862.rsc.cdn77.org 2019-04-06
peugeot.gcdn.co 2019-04-08
1154077226.rsc.cdn77.org 2019-04-08
1309184171.rsc.cdn77.org 2019-04-09
bouyguestelecom.gcdn.co 2019-04-09
1437342803.rsc.cdn77.org 2019-04-10
d3mu1cz5v06qvx.cloudfront.net 2019-04-10
This really was a standout campaign compared to the others that we track based not only on the unique payload, but the volumes as well. After a brief pause, the campaign saw a strategic pivot on April 14 to another platform and is currently still active under “.site” TLD landing pages. With half a billion user sessions impacted, this is among the top three massive malvertising campaigns that we have seen in the last 18 months.
