Over A Billion Malicious Ad Impressions Exploit WebKit Flaw to Target Apple Users
The infamous eGobbler hacking group that surfaced online earlier this year with massive malvertising campaigns has now been caught running a new campaign exploiting two browser vulnerabilities to show intrusive pop-up ads and forcefully redirect users to malicious websites.
To be noted, hackers haven’t found any way to run ads for free; instead, the modus operandi of eGobbler attackers involves high budgets to display billions of ad impressions on high profile websites through legit ad networks.
But rather than relying on visitors’ willful interaction with advertisements online, eGobbler uses browser (Chrome and Safari) exploits to achieve maximum click rate and successfully hijack as many users’ sessions as possible.
In its previous malvertising campaign, eGobbler group was exploiting a then-zero-day vulnerability (CVE-2019-5840) in Chrome for iOS back in April, which allowed them to successfully bypass browser’s built-in pop-up blocker on iOS devices and hijack 500 million mobile user sessions in just a week to show pop-up ads.
|Malicious sample pop-up ad showing how attackers social engineer victims|
Though Google already patched the vulnerability with the release of Chrome 75 in June, eGobbler is still using the flaw to target those who haven’t yet updated their Chrome browser.
eGobbler Exploits WebKit Flaw to Redirect Users to Malicious Sites
However, according to the latest report published by security firm Confiant, the eGobbler threat actors recently discovered and started exploiting a new vulnerability in WebKit, the browser engine used by Apple Safari browser for both iOS and macOS, Chrome for iOS and also by earlier versions of Chrome for desktop.
The new WebKit exploit is more interesting because it doesn’t require users to click anywhere on legit news, blog or informative websites they visit, neither it spawns any pop-up ad.
Instead, the display ads sponsored by eGobbler leverage the WebKit exploit to forcefully redirect visitors to websites hosting fraudulent schemes or malware as soon as they press the “key down” or “page down” button on their keyboards while reading the content on the website.
“This time around, however, the iOS Chrome pop-up was not spawning as before, but we were, in fact, experiencing redirections on WebKit browsers upon the ‘onkeydown’ event,” the researchers said in their latest report.
“The nature of the bug is that a cross-origin nested iframe is able to ‘autofocus’ which bypasses the ‘allow-top-navigation-by-user-activation’ sandbox directive on the parent frame.”
“With the inner frame automatically focused, the keydown event becomes a user-activated navigation event, which renders the ad sandboxing entirely useless as a measure for forced redirect mitigation.”
Though Apple’s app store guidelines restrict all iOS apps with web browsing ability to use its WebKit framework, including for Google Chrome for iOS, mobile users are still less likely to be impacted by the redirection flaw as the ‘onkeydown’ event doesn’t work on the mobile OS.
However, the eGobbler payload, often delivered through popular CDN services, also includes code to trigger redirections when visitors of a targeted web application try to input something in a text area or search forms, likely “to maximize the chances of hijacking these keypresses.”
As researchers believe, “this exploit was key in magnifying the impact of this attack.”
Between August 1 and September 23, the threat actors have been seen serving their malicious code to a staggering volume of ads, which the researchers estimate to be up to 1.16 billion impressions.
While the previous eGobbler malvertising campaign primarily targeted iOS users in the United States, the latest attack targeted users in Europe countries, with a majority being from Italy.
Confiant privately reported the WebKit vulnerability to both the Google and Apple security teams. Apple fixed the flaw in WebKit with the release of iOS 13 on September 19 and in Safari browser 13.0.1 on September 24, while Google has yet to address it in Chrome.