Abusing Service Workers
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):
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:
No caso de abusar de um endpoint JSONP vulnerável, você deve colocar o valor dentro de var sw
. Por exemplo:
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
importScripts
em um SW via DOM ClobberingA 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
sw.js
Com DOM Clobbering
Para mais informações sobre o que é DOM Clobbering, confira:
Dom ClobberingSe 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.
Referências
Last updated