Read the original article: Malvertiser “ScamClub” Bypasses Iframe Sandboxing With postMessage() Shenanigans [CVE-2021–1801]
This blog post is about the mechanics of a long tail iframe sandbox bypass found in a payload belonging to the persistent malvertising attacker that we call ScamClub.
A Word About ScamClub
Active for at least several years now, ScamClub malvertisements are defined mainly by forced redirections to scams that offer prizes to “lucky” users, like the all too ubiquitous “You’ve won a Walmart giftcard!” or “You’ve won an iPhone!” landing pages.
For example:
ScamClub campaigns have been covered by us in depth over the years, but a great reference if you need a refresher is this post from 2018:
Malvertising Attack Hijacks 300 Million Sessions Over 48 Hours
On the tactics side, this attacker historically favors what we refer to as a “bombardment” strategy. Instead of trying to fly under the radar, they flood the ad tech ecosystem with tons of horrendous demand well aware that the majority of it will be blocked by some kind of gatekeeping, but they do this at incredibly high volumes in the hopes that the small percentage that slips through will do significant damage.
The Payload
A typical ScamClub payload has a few layers to it, starting with an ad tag that loads a malicious CDN hosted dependency . This of course is usually obfuscated in absurd ways in attempt to evade url blocklists.
Here’s a recent example:
As the payload unfurls to pull in additional layers, we are met with a mess of obfuscated nonsense that usually expands to thousands of lines of code — mostly decoy of course. A full walkthrough of a ScamClub payload is beyond the scope of this blog post, but rather we will focus on four lines of code that piqued our curiosity.
Here they are recreated:
function receiveMessage(event) { top.location.href = "http://[malicious giftcard scam]";
}
window.addEventListener("message", receiveMessage);
The thing is, it’s very normal for malvertisers to spray a bunch of redirect attempts in a single payload that try to do the redirect in different ways. It’s not uncommon to see a multilayered try catch statement try multiple top level redirects, pop-ups, etc.
The reason some attackers chose to do this is because they have partial control at best when it comes to what device or platform the payload is running on, and they want to maximize their monetization opportunity as best they can.
For example, one browser version might block redirect attempts from cross-origin frames, while the prior version lets them through, so they try all of the things including known bypasses that might have since been patched.
However, none of this explains the event listener… or does it?
We investigate by eliminating the noise and stage a simple html file that implements a cross-origin sandboxed frame and a button that dispatches our event. (payload.html is our event listener).
<iframe src="http://origin2.me/payload.html" id='targ' sandbox="allow-forms allow-pointer-lock allow-popups-to-escape-sandbox allow-popups allow-same-origin allow-scripts allow-top-navigation-by-user-activation"></iframe>
<script>
function do_it()
{
var wn = document.getElementsByTagName('iframe')[0].contentWindow; wn.postMessage('Hello!', '*');
}
do_it();
</script>
<input id="clickMe" type="button" value="clickme" onclick="do_it();" />
The `allow-top-navigation-by-user-activation` sandbox attribute, which is often lauded as one of the most vital tools in an anti-malvertising strategy should in theory prevent any redirection unless a proper activation takes place. Activation in this context typically means a tap or a click inside the frame.
This means our proof of concept shouldn’t work under any circumstances. The clickMe button is outside of the sandboxed frame after all. However, if it does redirect, that means we have a browser security bug on our hands, which turned out to be the case when tested on WebKit based browsers, namely Safari on desktop and iOS.
The Long Tail
If you’re following along, this is probably where you might shrug your shoulders and say “But so what? It’s not like these guys can place a clickable message dispatcher on the publisher site outside of their ad frame!”
This is true, but that doesn’t mean the ScamClub event listener is a complete shot in the dark. In modern web applications, messages are flying around all the time, usually with wildcard destinations, often on user interaction.
Combined with ScamClub’s large volumes and broad targeting that hits dozens of different websites, it’s all about the increased efficacy of spawning a successful redirect — even if we’re talking about a single digit percentage increase, that can mean tens of thousands of impacted impressions over the duration of a single campaign.
Over the last 90 days, ScamClub has delivered over 50MM malicious impressions, maintaining a low baseline of activity augmented by frequent manic bursts — with as many as 16MM impacted ads being served in a single day.
Disclosure Timeline
June 22, 2020 — Confiant Security Team observes event listeners in ScamClub redirect payload.
June 23, 2020 — Bug report submitted to Apple Security. Google Chrome team also notified (Chrome on iOS uses WebKit).
Dec 2, 2020 — Patched https://trac.webkit.org/changeset/270373/webkit
Feb 1, 2021 — CVE assigned and published as part of Apple’s security update: https://support.apple.com/en-us/HT212147
IOCs
Recent IOCs are all available as STIX here:
https://github.com/WeAreConfiant/security/blob/master/stix-feeds/scamclub.stix.json
S3 hosted JavaScript payloads:
xmou.s3.us-east-2.amazonaws.com/mou.js
impve.s3.amazonaws.com/create.js
dgoi.s3.us-east-2.amazonaws.com/goi.js
yflx.s3.us-east-2.amazonaws.com/flx.js
miil.s3.us-east-2.amazonaws.com/iia.js
djian.s3.amazonaws.com/jia.js
aimppv.s3.amazonaws.com/jiy.js
aylei.s3.amazonaws.com/lei.js
ajluo.s3.amazonaws.com/luo.js
apzaf.s3.amazonaws.com/zaf.js
appang.s3.us-east-2.amazonaws.com/pan.js
dkjieg.s3.amazonaws.com/jieg.js
adlya.s3.amazonaws.com/lya.js
yddof.s3.amazonaws.com/dof.js
meixop.s3.us-east-2.amazonaws.com/xop.js
aqkol.s3.amazonaws.com/kol.js
impvv.s3.us-east-2.amazonaws.com/dsd.js
mqyuj.s3.amazonaws.com/yuj.js
wpbgm.s3.amazonaws.com/bgm.js
pzhufm.s3.amazonaws.com/zhuf.js
cxpm.s3.amazonaws.com/cx.js
khpm.s3.amazonaws.com/kh.js
vcjm.s3.amazonaws.com/vc.js
lxpm.s3.amazonaws.com/lx.js
owpd.s3.amazonaws.com/ow.js
kdjm.s3.amazonaws.com/kd.js
rmbp.s3.amazonaws.com/bp.js
zhpmm.s3.amazonaws.com/zh.js
lrydy.s3-ap-southeast-1.amazonaws.com/lr.js
kiyy.s3-ap-southeast-1.amazonaws.com/ki.js
oummm.s3.amazonaws.com/ou.js
gsyyd.s3.amazonaws.com/gs.js
qqpm.s3.amazonaws.com/qq.js
nxya.s3-ap-southeast-1.amazonaws.com/nx.js
zpdk.s3.amazonaws.com/zp.js
mrptm.s3.amazonaws.com/mr.js
ktzmy.s3-ap-southeast-1.amazonaws.com/kt.js
nzdpy.s3-ap-southeast-1.amazonaws.com/nz.js
vpydy.s3-ap-southeast-1.amazonaws.com/vp.j
Domains:
goodluckpig.space
goodluckman.space
goodluckguy.space
goodluckdog.space
luckytub.xyz
luckyguys.xyz
luckyguys.top
hknewgood.xyz
hknewgood.top
usgoodwinday.top
usgoodwinday.xyz
2020workaffnew.top
vip.peopleluck.xyz
vip.fortunatefellow.xyz
vip.fortunateman.xyz
vip.fortunatetime.xyz
vip.fortunatepeople.xyz
vip.luckydevil.xyz
vip.superlucky.xyz
vip.luckydraw.space
vip.hipstarclub.com
workcacenter.space
trkcenter.xyz
trkingcenter.xyz
gotrkspace.xyz
trkmyclk.space
dbmtrk.xyz
trkmyclk.xyz
Malvertiser “ScamClub” Bypasses Iframe Sandboxing With postMessage() Shenanigans [CVE-2021–1801] was originally published in Confiant on Medium, where people are continuing the conversation by highlighting and responding to this story.
Read the original article: Malvertiser “ScamClub” Bypasses Iframe Sandboxing With postMessage() Shenanigans [CVE-2021–1801]