Why Sandboxing Won’t Cut It When It Comes to Malvertising

A new type of redirect has been discovered by GeoEdge’s security team. This new form of malvertising attacks has cast doubt on the recent security approach known as the “sandboxing doctrine”.

The attacks are launched through legitimate ad servers and demonstrate great sophistication, enabling them to breach browser security mechanisms and bypass security companies that rely on Sandboxing.

Iframe sandbox

A few words on what Sandboxing means – Sandboxing is a software management strategy that isolates applications from critical system resources and other programs.

It provides an extra layer of security that prevents malware or harmful applications from negatively affecting your system.’

Casper Attacks 

These new attacks, known as “Casper attacks”, are the work of attackers with a deep understanding of the ad-tech industry.

The attackers leverage their knowledge and serve fake ads through legitimate ad servers, intending to generate traffic and convert low-cost CPMs into more lucrative ads through auto-redirects.

The sophistication of the code makes it very hard to track and trace lays in multiple layers of obfuscation. While the code is served in a cross-origin platform, it leverages the ability of a code served in the same origin platform by navigating through Sandboxing.

Let’s take a basic look into how they are doing it:

1 – Ad tag loads in same-origin Iframe with sandboxing for security

2 – Waterfall opens a new tag, this is a cross-origin Iframe

3 – Cross-origin Iframe performs basic checks and then loads as same-origin via post message to the original iframe. Here we can see the breach to the sandboxing environment. The moment the cross-origin iframe communicates with the same origin iframe, posing as the same origin, the original iframe receives the info for creating the redirect, hence breaking security.

4 – A <div> covering the entire page is created, once a user generates a click event it triggers the auto-redirect

 

For those of us who can take it, let’s dive into the code and see how this happens:

Stage: #1

Host: ice.360yield.com

Origin: same

In this stage we can see the Event Listener and load the ad code as cross origin script:

Stage: #2

Host: bs.serving-sys.com

Origin: cross

Stage 2 generates a malicious script that is loaded into a new iframe. Important to note, this iframe is cross origin

Stage: #3

Host: secure-ds.serving-sys.com

Origin: cross

Here we can see the first two lines of code are the ad

Under Base64 is the first stage of the malicious script which creates a func from Base64 and executes it

Here we can see an image of the ‘fake ad’

 

How exactly does the code in the attack work?

• The script starts by removing itself from the disk but staying in the memory in order to cover their tracks

     

• Checks if it runs inside of an iframe

• Checks if ‘ontouchstart’ in document element(Simple check for mobile)`

• Once all simple checks have been performed, it creates a variable that stores the main function as string

• Here is how the original iframe with sandboxing will actually create the redirect. In this stage, we can see it send the entire function to run as same-origin via post message to the original iframe

• Now the script creates a div element outside of the frame that covers the entire screen. The div has an onclick attribute that runs the function at the next step

• Once a user triggers the onclick event. The function connected to the event will open a WebSocket and send the following information:

1. window.top.location.href
2. “example.com” (macro of the domain)
3. “ce1ee7eb-838e-4f61-8069-1b7d499a2254” (impression id)
4. Empty string
5. True/False (CheckForMobile() script)
6. navigator.platform
7. True/False (Checks for companies likegeoedge)
8. True/False (Checks forgeoedge)
9. i. timestamp
10. window.top.document.referrer
11. empty string

 

• Finally, here we can see the communication with the server via websocket

For the second Stage of attack:

• The first script passes the variables above to the second stage

• Second stage checks
• Webgl check

 

• Meta tags check

• More mobile checks

• General browser checks

• checks the length of all the tags in the documents
• screen color depth
• pixel ratio
• screen width
• screen height
• full URL
• maxTouchPoints

• Checking if window object contains strings

• Finally sending information via websocket

 

“What we see in this case,” said Netanel Elbaz, Security Research at GeoEdge, “is that Sandboxing can be bypassed, and that browser security is not enough. With Casper attacks, we see that some auto-redirects are able to penetrate all security and blocking mechanisms.”

The solution, according to Elbaz, is an in-depth code analysis that traces the attack’s origin. “Ad arbitrage is highly lucrative, and hackers become more knowledgeable and sophisticated when it comes to code obfuscation. Unfortunately, Sandboxing simply won’t cut it when it comes to handling these new threats”.