Andy Ful

Level 62
Verified
Trusted
Content Creator
This type of attack requires a JavaScript file that contains the worker’s code. If this script is blocked, then the attack will fail. Yet, such a script may look innocent, and contain links to 3rd party domains. There are malware examples in the wild which are based on abusing Web Workers. But, this one is based on abusing Service Workers which can continue their work after closing the malicious webpage and cannot be monitored by web browser's extensions. This follows from the fact that Service Workers can be completely detached from the website (on the contrary to Web Workers).
The persistence of such attacks (via Push API) are not likely in most browsers, but can be probably obtained due to a kind of bug.

Defense:
  1. Restricting or Disabling Service Workers.
  2. Whitelist/blacklist, for example: "...service workers will be blocked, unless the domain of origin is whitelisted. These lists can initially include popular sites, which are typically considered more trusted".
  3. Forcing the user’s permission for registration and activation of a service worker — "similar to “Click to Play” mechanism ... that disables by default plug-ins, such as Flash, Java, Silverlight and others".
  4. Signature-based Detection. "For example, it could be easy to detect MarioNet messages that are exchanged between the service worker that lies in the browser and the back-end server, by monitoring the network traffic."
  5. Behavioral Analysis and Anomaly Detection via "suspicious behavior of JavaScript programs that are embedded in the web site or the service worker, ... monitoring of the utilized resources or the behavioral analysis of the executed code", comparing the suspicious code with normal code "based on heuristics for several attack types that apply code obfuscation."
Edit.
The text in italics was taken from the source article:
 
Last edited:

mathieuh

Level 1
This type of attack requires a JavaScript file that contains the worker’s code. If this script is blocked, then the attack will fail. Yet, such a script may look innocent, and contain links to 3rd party domains. There are malware examples in the wild which are based on abusing Web Workers. But, this one is based on abusing Service Workers which can continue their work after closing the malicious webpage and cannot be monitored by web browser's extensions. This follows from the fact that Service Workers can be completely detached from the website (on the contrary to Web Workers).
The persistence of such attacks (via Push API) are not likely in most browsers, but can be probably obtained due to a kind of bug.

Defense:
  1. Restricting or Disabling Service Workers.
  2. Whitelist/blacklist, for example: "...service workers will be blocked, unless the domain of origin is whitelisted. These lists can initially include popular sites, which are typically considered more trusted".
  3. Forcing the user’s permission for registration and activation of a service worker — "similar to “Click to Play” mechanism ... that disables by default plug-ins, such as Flash, Java, Silverlight and others".
  4. Signature-based Detection. "For example, it could be easy to detect MarioNet messages that are exchanged between the service worker that lies in the browser and the back-end server, by monitoring the network traffic."
  5. Behavioral Analysis and Anomaly Detection via "suspicious behavior of JavaScript programs that are embedded in the web site or the service worker, ... monitoring of the utilized resources or the behavioral analysis of the executed code", comparing the suspicious code with normal code "based on heuristics for several attack types that apply code obfuscation."
The hidden persistence should be impossible in browsers, unless of some bug in the browser implementation which should be reported.

If using the Push API for persistence, the user has
  1. Give permission
  2. Ignore recurring & visible notifications

Not exactly what I would call stealth.

As for the defense points:
1 ) & 2 ) Seems a bit heavy handed. Service Workers do not run unchecked in the background once all pages are closed. They only have very limited execution time tied to actual events and visible UI (notifications).
3 ) There is already permission required for more powerful background execution to process Push notifications.
5 ) The specs does allow this and browser will interrupt any worker that runs in the background for too long or using too much CPU without any pages visible.
 

Andy Ful

Level 62
Verified
Trusted
Content Creator
What will happen if I disable service workers?
And if I want to monitor service workers, how can I tell which ones might be malicious?
Some functionality of the webpage will not be available.
There are well known general techniques related to monitoring the network traffic and finding anomalous, unwanted or malicious behaviors. They are included in Advanced Thread Protection modules of AVs used in Enterprises. They use AI, heuristics, ML, signatures, big data analytics, etc.
 
Last edited:
Top