MarioNET attack lets hackers control your browser, even after you leave the attack page
The rise of web technologies opened up new possibilities on the Internet. Browsers have become more powerful as new APIs landed and support for certain features was introduced.
A new attack, called MarioNET by the researchers that discovered it, highlights that APIs may also be abused if no proper safeguards are in place (which is the case right now).
The attack relies on existing HTML5 APIs that all modern web browsers support. It does not require the installation of software or user interaction, and persists even after the user leaves the web page the attack originated on.
The attacker may abuse the resources of the computer for all kinds of activities including DDOS attacks, crypto-mining operations, or password cracking.
Update: You find a critical voice that argues against the scenario described in the research paper here. The main point of criticism is that the attack method relies on a feature called PeriodicSync and that it is not part of any specification at this point. End
MarioNET uses Service Workers, scripts that run separate from visited web pages and in the background, in the attack. The main idea behind Service Workers is to move certain computations to a separate thread so that it is not blocking or slowing down the app or web page the user interacts with.
The lifecycle of Service Workers is completely independent from the page they were created on. Service Workers don't have access to the DOM (Document Object Model) of the web page and parent page variables and functions.
The use of Service Workers isolates the system from the originating website, gives persistent control to the attacker, and makes it difficult for users to detect what is going on.
In particular, our system fulfills three important objectives:
(i) isolation from the visited website, allowing fine-grained control of the utilized resources; (ii) persistence, by continuing its operation uninterruptedly on the background even after closing the parent tab; and (iii) evasiveness, avoiding detection by browser extensions that try to monitor the webpage’s activity or outgoing communication.
MarioNET registers a service worker when a user visits a webpage attacks can originate on. Possibilities to spread the attack include creating malicious websites, hacking sites, or using advertisements.
Browsers provide little information to users about Service Workers; in fact, browsers don't highlight the creation of new service workers on sites to users. There is no alert, no prompt, and not even an option to display a prompt to ask for user permission when service workers are created.
The only request that reveals the existence of the service worker is the initial GET request at the time of the user’s first website visit, when the service worker gets initially registered. Although during that GET request a monitoring extension can observe the contents of the service worker, it will still not observe any suspicious code—the code that will carry out the malicious tasks is delivered to the Servant only after its first communication with the Puppeteer, and this communication is hidden from browser extensions
What makes MarioNET particularly troubling is that it continues to run in the background after the user closes the website the attack originated on. The control ends when the web browser is closed; the researchers found a way to overcome this as well, but it requires user interaction as it uses the Web Push API to do so.
Protection
Most modern browsers include options to display existing Service Workers. Firefox users may load about:serviceworkers or about:debugging#workers and Chrome users may load chrome://serviceworker-internals/ to do so.
You may unregister any Service Worker using functionality provided on these pages. Firefox users may disable Service Workers altogether furthermore.
Note that this may impact functionality on sites that use it for legitimate purposes. You need to set the preference dom.serviceWorkers.enabled to false on about:config.
Some browser extensions, e.g. Service Worker Detector for Chrome and Firefox, notify users when a web page registers a Service Worker.
Now You: Should browser developers implement additional safeguards? (via ZDNet)
DOM (Document Object Model) not DOM (Dynamic Object Model)
Right, thanks!
I use the add on ForgetMeNot which i configured to delete ServiceWorkers, among Plugin Data, IndexedDB, LocalStorage and so on… this does not stop the creation but configures deletion after a set amount of time…
Interesting, do you have a link?
ForgetMeNot:
https://addons.mozilla.org/firefox/addon/forget_me_not/
You find this setting under “Cleanup”:
https://addons.cdn.mozilla.net/user-media/previews/full/215/215096.png
Thank You!
Doesn’t seem to work in private browsing mode… :(
eCleaner (forget button) does the same. versions for FF, chrome and opera.
https://add0n.com/ecleaner.html
I used click and clean for years until it became garbage.
Interesting,
many social media, and shops put service workers at my browser
and …………………….I see that ghacks also put a Service Worker on my FF browser
Origin: https://deals.ghacks.net
Scope: https://deals.ghacks.net/
Script Spec: https://deals.ghacks.net/aimtell-worker.js?v=3.94298&cb=091818
Current Worker URL: https://deals.ghacks.net/aimtell-worker.js?v=3.94298&cb=091818
Active Cache Name: {e49d3f9c-3133-460b-bbf7-fc608e69202f}
Waiting Cache Name: $name
Push Endpoint: null
Please inform your readers what this SW does, and whether your are mis-using it for malware injection?
This is not malicious; not all service workers are malicious.
But we only have your word for that. Not that we have any reason to mistrust you :)
This problem is partially created by the perception of browser developers and web developers that new APIs will fail before they are adopted and get traction if users are presented with prompts they may be too quick to dismiss without even considering their merit.
Notifying users that a service worker script is being loaded will not solve the problem completely. Most users do not have the time, let alone skills, to determine what the service worker script they are allowing actually does.
Thus the question is really a wider question: should the web be a place where any functionality that can be abused requires user authorization?
Firefox has only recently applied this sort of permission system for addons.
There may well be myriad objections to doing the same for the many and varied functionality the web already provides that requires no user authorisation. Boggles the mind to even consider the scope. Probably a good place to start would be https://caniuse.com/ which is a website that tracks new features coming to maturity on the web. The title implies developers are asking “can I use” a feature in a project yet? Is that feature implemented across all browsers a developer’s project may encounter? So if anyone is looking to monitor the progress of new features coming to the web and whether they are implemented with user awareness in mind, that site may be a good place to start.
I use uMatrix which allows :
– to disable Service Workers browser wide (no-worker: * true) and to enable ;
– to enable Service Workers on site basis (no-worker: example.com false).
— FeNiXe
This is the right (and the best AFAIK) method to deal with such SW abuses. Just disabling the whole feature via a user.js pref may be also used as one fingerprinting attack vector on you if it is not Tor Browser your user agent.
We can verify the difference between these two methods on:
https://browserleaks.com/features (see the test result of *Modernizr.serviceworker*)
Make sure you don’t roll the dice with CSP headers when two or more extensions want to make changes… because only one will win
Example: use a uBlock rule to block fonts, and uM to block SWs – watch the battle, and holes appear in your defenses
Example2: CanvasBlocker: option Misc > Block data URL pages and uBO / uMatrix
Disabling Service Workers is included in ‘Ghacks user.js) :
https://github.com/ghacksuserjs/ghacks-user.js/releases
// 2302: disable service workers
lockPref(“dom.serviceWorkers.enabled”, false);
// 2740: disable service workers cache and cache storage
lockPref(“dom.caches.enabled”, false);
Sevice Workers has always been one of those Firefox features which brings little compared to its potential privacy issues : MarioNET demonstrates this.
No need for Service Workers, disabling them won’t damage at all one’s Firefox surfing experience.
That’s :
user_pref(“dom.serviceWorkers.enabled”, false);
user_pref(“dom.caches.enabled”, false);
user_pref for user.js, not lockPref. I transpose these settings in Firefox’s Autoconfig which is why I use lockPref, and copy/pasted from there.
In about:config, manually, as stated in the article, of course :
dom.serviceWorkers.enabled -> false
dom.caches.enabled -> false
Not waked up yet …
What is one legitimate example that a site would need persistent background access to your browser?! That is __NOT___ something dumb like a weather widget that continuously pulls data from their server.
Can Service Workers be used for tracking purposes? I notice there’s one for Youtube on my system.
Section 2302 of Ghacks-user.js comments about Service Workers (dom.serviceWorkers.enabled) :
“Service workers essentially act as proxy servers that sit between web apps, and the browser and network, are event driven, and can control the web page/site it is associated with, intercepting and modifying navigation and resource requests, and caching resources.
[NOTE] Service worker APIs are hidden (in Firefox) and cannot be used when in PB mode.
[NOTE] Service workers only run over HTTPS. Service Workers have no DOM access.”
They can be used for the best as for the worst.
Remember that old adage “If it works don’t change it”?
Latest technologies bring a lot of unnecessary (IMO) features which are for some vulnerable.
Nowadays I’d say, “If you don’t need it, don’t install or remove, or disable.”
No need for System Workers, just put a cover on that garbage.
@Tom Hawak:
Service workers are *disabled* by default in Pale Moon, Basilisk, and Tor Browser. (And service workers are *enabled* by default in Waterfox.)
@TelV:
The W3C Working Draft for Service Workers (at https://www.w3.org/TR/service-workers/#privacy)
says:
==========
6.6. Privacy
Service workers introduce new persistent storage features including scope to registration map (for service worker registrations and their service workers), request response list and name to cache map (for caches), and script resource map (for script resources). In order to protect users from any potential unsanctioned tracking threat, these persistent storages *should* be cleared when users intend to clear them and *should* maintain and interoperate with existing user controls e.g. purging all existing persistent storages.
==========
The fact that those italicized “shoulds” aren’t “musts” concerns me. Actually, the mere fact that users of the market’s dominant browsers should have to take *proactive steps* to guard against such tracking concerns me, because 99% of them will be utterly unaware of the potential need for it.
Another technology developed to serve the internet advertising, tracking, data collection and so on.
The poor user of the browser … He’s just a Product.
I use HitManPro.Alert to guard my browsers and apps.
What’s the difference between “dom.serviceWorkers.enabled” and “dom.workers.enabled”?
The latter is required by Startpage’s Anonymous View.
> What’s the difference?
One exists and the other was removed in FF60 ( https://bugzilla.mozilla.org/1434934 )
There is a lot of misinformation in that paper, and it’s 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. The idea never went further than a mock implementation and was never released publicly. It was behind an experimental flag in Chrome 40-48.
The design document (https://github.com/WICG/BackgroundSync/blob/master/explainer.md#periodic-synchronization-in-design) for the periodicSync API is filed under future idea (not even proposal). It also 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 :)”
A Google employee has also explained in detail that no Service Worker API should allow persistence, and if the authors of the paper indeed found a way, it’s a bug in the implementation that should be reported appropriately.
https://twitter.com/jaffathecake/status/1100319347304734721
Pale Moon and Basilisk are not vulnerable to this.
“MarioNET uses Service Workers” > It can’t affect me with Pale Moon.
It can’t affect browser developed with sanity in mind, so Basilisk, Iceweasel-UXP and Pale Moon are safe.
Oh, where are all the nice tr… people claiming Pale Moon is outdated, bad and… unsafe to use? This is a perfect example of the “modernity” of mainstream browsers: enjoy flashy, new and useless features while throwing your security and privacy out of the window.
“Should browser developers implement additional safeguards?”
I think it’s a deep and terrible mistake for the web and browser to become as capable as they’ve become. But if that’s the direction that they want to take the web, then they absolutely have to implement a lot of additional safeguards.
Even then, though, it will still be a security problem. That’s why I think that trying to be an operating system is a disastrous direction to take the web, and I won’t be following it on that path. It’s just far too much risk for very little gain.
On tapping “about:serviceworkers” I get the message “No Service Workers registered.”
I use no script and am very careful about allowing scripts on certain sites.