New browser attack lets hackers run bad code even after users leave a web page

silversurfer

Level 85
Thread author
Verified
Honorary Member
Top Poster
Content Creator
Malware Hunter
Well-known
Aug 17, 2014
10,048
Academics from Greece have devised a new browser-based attack that can allow hackers to run malicious code inside users' browsers even after users have closed or navigated away from the web page on which they got infected.

This new attack, called MarioNet, opens the door for assembling giant botnets from users' browsers. These botnets can be used for in-browser crypto-mining (cryptojacking), DDoS attacks, malicious files hosting/sharing, distributed password cracking, creating proxy networks, advertising click-fraud, and traffic stats boosting, researchers said.
In their research paper, the research crew also describes methods through which MarioNet could avoid detected by anti-malware browser extensions and anti-mining countermeasures, and also puts forward several mitigations that browser makers could take.

The MarioNet attack will be presented today at the NDSS 2019 conference in San Diego, USA. More details about MarioNet are available in an accompanying research paper entitled "Master of Web Puppets: Abusing Web Browsers for Persistent and Stealthy Computation," available for download in PDF format from here.
 

shmu26

Level 85
Verified
Honorary Member
Top Poster
Content Creator
Well-known
Jul 3, 2015
8,150
It is all happening in the browser, it is not invading the system. So Sandboxing will not help at all, until you empty the sandbox, at least. SRP and HIPS don't help, because their job is to protect the system.
 

plat

Level 29
Top Poster
Sep 13, 2018
1,793
I get it, the malware stays in the browser but its persistence is ended once you close it out (if you're smart and set the box to auto-delete), right? And limit the sandbox's access to browser. The bad thing is, the length of time--some people keep their browsers open for hours and hours. The thing is the damage it can do while you're still actively browsing, sandboxed or not.
 

TairikuOkami

Level 35
Verified
Top Poster
Content Creator
Well-known
May 13, 2017
2,452
MarioNet relies solely on already available HTML5 APIs, without requiring the installation of any additional software.
Towards this direction, the aim of this work is to increase the awareness of developers and browser vendors about the provided powerful (but also potentially risky) capabilities of modern HTML, and hopefully lead to the deployment of restrictive policies that will adequately secure the user-side environments of future web applications.
HTML5, which can not be blocked as easily as flash. Who would have thought. And this is just the beginning, so much for the hated flash. :cautious:

Persistence across Browser Reboots: MarioNet runs in the background as long as the browser is open. After that, the victim has to re-visit the malicious domain or render the malicious iframe where the malicious domain resides, in order to reactivate the service worker and allow the Servant to continue its operation. To increase persistence even further, we have developed a technique that allows MarioNet to persist even after the browser has been restarted. This can be achieved by utilizing the Push API.
It seems to utilize iframes like crypto-mining malware, so blocking them should help, like popup blockers do.
 

TairikuOkami

Level 35
Verified
Top Poster
Content Creator
Well-known
May 13, 2017
2,452
Does it say it can survive a reboot?
If you allow push notifications for the infected webpage.

You can probably check for a possible infection by checking service workers. They can not be disabled, but they can be unregistered.

browser://serviceworker-internals/
chrome://serviceworker-internals/

I had 55 of them, I unregistered all, just to be sure. Still, this brings fileless malware to another level, since there is nothing to detect.
I also find worrying, that it can avoid being detected by content filtering extensions, since they are unable to monitor service workers.
 

Attachments

  • capture_02252019_230807.jpg
    capture_02252019_230807.jpg
    135 KB · Views: 281

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
A good reason to sandbox the browser, and deny its access to cookies, history, passwords, etc.:cautious: Strangely, the article stated this won't work on Internet Explorer, the one browser I wouldn't be caught dead using.
The sandbox will not help much. This method is based on the legal HTML5 APIs. It simply will use your processor or your browser will be used to attack servers, until you will close the web browser.
 
F

ForgottenSeer 69673

The sandbox will not help much. This method is based on the legal HTML5 APIs. It simply will use your processor or your browser will be used to attack servers, until you will close the web browser.

Andy are you talking of closing a sandboxed browser, because the article says it remains persistent after closing the browser. That is why I recommend Shadow Defender.
 

Andy Ful

From Hard_Configurator Tools
Verified
Honorary Member
Top Poster
Developer
Well-known
Dec 23, 2014
8,040
Andy are you talking of closing a sandboxed browser, because the article says it remains persistent after closing the browser. That is why I recommend Shadow Defender.
Read it again.:giggle:(y)
"Academics from Greece have devised a new browser-based attack that can allow hackers to run malicious code inside users' browsers even after users have closed or navigated away from the web page on which they got infected."
 

mathieuh

Level 1
Feb 25, 2019
3
There is a lot of misinformation on the paper and article. The paper seem to actually be full of speculation and extrapolation without actual samples.

  • ServiceWorker do indeed run in a separate thread or process, and independently from the web page of a website, but they do not run indefinitely and uncontrolled. A basic WebWorker will be killed off when all pages for which website it's responsible are closed. The browser stays in control of the process, and can chose to terminate it at any point.
  • The paper mentions WebRTC as a way to generate network traffic for DDOS or host darknet content, however the WebRTC APIs are not available in ServiceWorker. The author don't seem to detail their use of WebRTC besides hypotheticals.
  • The whole persistence seem to rely on the periodicSync API, which is just a proposal from the Chrome team and not a standard WebWorker API. It will thus not run cross browsers. Furthermore, the idea never went further than a mock implementation and was never released. A stackoverflow answer confirms that as of last year the API was not available.
    Furthermore the design document for the periodicSync API is filed under future idea (not even proposal), and indicates that the browser should require user permission for the usage of the API.
  • Finally, there are provisions in the ServiceWorker spec allowing the browser to prevent the ServiceWorker execution if it detects malicious use (high CPU usage, long execution times, etc.)
The document above specifically mentions this:
Like all ServiceWorker events, 'sync' and 'periodicsync' may be terminated if they're taking an unreasonable amount of time or CPU. This is not a tool for distributed bitcoin mining :)
 

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.

Top