Casper Attacks: 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.
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.’
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 postmessage 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:
In this stage we can see the Event Listener and load the ad code as cross origin script:
Stage 2 generates a malicious script that is loaded into a new iframe. Important to note, this iframe is cross origin
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 postmessage 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:
- “example.com” (macro of the domain)
- “ce1ee7eb-838e-4f61-8069-1b7d499a2254” (impression id)
- Empty string
- True/False (CheckForMobile() script)
- True/False (Checks for companies likegeoedge)
- True/False (Checks forgeoedge)
- i. timestamp
- 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
- 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”.