At Your Service - Abusing the Service Workers Web API
•Download as PPTX, PDF•
0 likes•5,314 views
This document summarizes ways that service workers can be abused to compromise websites. It discusses how uploading a malicious service worker and using an existing cross-site scripting (XSS) vulnerability, an attacker can modify responses, persist XSS attacks, conduct denial of service attacks, and conduct phishing. It also describes how data can be leaked from sandboxed domains if an XSS is present. Potential mitigations discussed include enforcing service worker scope, real user monitoring, and monitoring service worker registration events.
More Related Content
What's hot
What's hot (19)
Similar to At Your Service - Abusing the Service Workers Web API
Similar to At Your Service - Abusing the Service Workers Web API (20)
Recently uploaded
Recently uploaded (20)
At Your Service - Abusing the Service Workers Web API
- 1. At Your Service Abusing the Service Workers Web API
- 2. ~$ whoami ● Daniel Abeles ○ Sr. Web Security Researcher @Akamai ○ Pythonista ○ ❤️ Breakings things ○ @Daniel_Abeles ● Shay Shavit ○ Sr. Web Security Researcher @Akamai ○ Bounty Hunter (MVP @bugcrowd) ○ @Chapakpuk
- 3. How did we get here?
- 4. Agenda
- 5. Current State of the Browser
- 6. Web Workers API ● “Web Workers are a simple means for web content to run scripts in background threads.” (from MDN) ● Most of the standard features are available ○ No direct DOM manipulation ○ Must be same origin
- 8. What Are Service Workers?
- 9. Primary Uses of Service Workers • Handle Network Requests • Caching Agent • Store content for Offline Experience
- 10. Browsers Support
- 11. Lifecycle
- 12. Registration
- 13. The Scope ● Crucial concept of Service Workers. ● Determines from which path the Service Worker (SW) will be activated ● Defines the activation condition for the service worker.
- 14. The Scope ● By default - it is the path where the service worker JavaScript file resides. ● Can be easily reduced (/profile/ instead of /) ● Can be increased (requires the response header - Service-Worker- Allowed) Failed Success
- 15. Scope Gotcha’s #1 ● If there are 2 registered service workers under the same scope, the most recently registered one will be activated. ● If there are 2 registered service workers on overlapping scope, the innermost will be activated. ○ / vs /uploads when visiting /uploads/files
- 16. Scope Gotcha’s #2 ● A service worker can load other scripts using the importScripts function ○ This is how we can load our malicious SW while maintaining the original SW functional ● Has to be installed on same origin
- 17. Installation ● Once the browsers registers a SW, the install event occurs. ● Also occurs when SW is new / changed.
- 18. Activation ● Once the installation was successful, the “activate” event occurs. ● Opened pages are not controlled by the SW (must be reloaded). ○ Can be overridden by using the self.clients.claim function
- 19. Fetch ● Fires every time a resource is requested ● Control over what is being sent / received. ○ Headers ○ Status ○ Body
- 20. Where to find them? ● Developer tools ● chrome://serviceworker-internals
- 21. Abuse Scenarios
- 23. General Scenario Requirements All of the following scenarios depend on the following: ● The website has a file upload functionality. ○ We can upload arbitrary JavaScript files there (and retrieve them). ● There’s an XSS vulnerability in the app ○ We can inject JavaScript code in the context of the victims browser. All of the scenarios abuse the fact that we can attach to the fetch event (of the service worker) to manipulate requested resources.
- 24. • Upload the malicious service worker to the website Upload • Using our XSS we register the malicious service worker Trigger • Attach to the fetch event. • We can modify the response of requested resources. PWN Response Modification
- 26. • Upload the malicious service worker to the website Upload • Using our XSS we register the malicious service worker Trigger • Reinject our code • Expand our scope PWN XSS Persistency Response Modification
- 28. • Upload the malicious service worker to the website Upload • Using our XSS we register the malicious service worker Trigger • Deny every requested resource PWN Denial of Service Response Modification
- 30. • Upload the malicious service worker to the website Upload • Using our XSS we register the malicious service worker Trigger • Serve alternate content. PWN Phishing / Defacement Response Modification
- 32. Data Leakage from Sandboxed Domains
- 33. What Are Sandbox Domains? ● Generally host various types of files ● Ment to isolate user uploaded content from the main application ● Are different than the main application domain ● Files on the sandboxed domain are usually publicly available
- 34. What Are Sandbox Domains? ● The file names are heavily obfuscated / random (does not resemble the file content or owner) ○ /super-random-and-unique-path-1337 ● Many vendors tend to ignore XSS findings in those domains since no cookies are shared among the sandboxed domain and the main application domain, like ● google.com vs googleusercontent.com ● facebook.com vs fbcdn.com ● etc.
- 35. Data Leakage from Sandboxed Domains Consider the following scenario: ● There's a website called “bsides-photos.com” which handles sensitive information ● The uploaded sensitive data is stored in a sandboxed domain called “bsides-photos-sbx.com” ● There is an XSS in the sandboxed domain (boring, right?)
- 36. Data Leakage from Sandboxed Domains bsides-photos-sbx.combsides-photos.com
- 37. Data Leakage from Sandboxed Domains bsides-photos-sbx.com
- 38. Data Leakage from Sandboxed Domains bsides-photos-sbx.com XSS Victim
- 39. Data Leakage from Sandboxed Domains bsides-photos.com bsides-photos-sbx.com C2 Server
- 40. DEMO
- 41. Upload Trigger Activate Leak Data Leakage from Sandboxed Domains
- 43. Enhancing Self XSS In this scenario we have: ● File upload functionality. ● A self XSS finding (low impact) on the /profile page. ○ A XSS that is triggered only on pages that are visible to us. ● Login / logout CSRF ○ Login and logout functions are not protected by CSRF tokens. ○ An attacker can force login/logout the victim. Enhancing Self XSS
- 45. evil-domain.com example.com/logoutexample.com/login (as attacker) example.com/profile XSS Enhancing Self XSS Victim
- 46. DEMO
- 47. Enhancing Self XSS Enhancing Self XSS Setup Visit Logout/Login Register PWN
- 48. Caveats Although this scenario looks promising, we are bounded under the following restrictions: ● Service Worker scope - if the uploaded service worker resides deeper in the page tree than the page we want to inspect, we won’t have effect on it. ○ Since the service worker won’t be activated there. ● Mime Type - the uploaded file must be served with the correct mime type for JavaScript files “application/javascript”
- 49. Mitigations
- 50. Scope Enforcement ● Set the uploaded files depth deeper in the tree. ● In sandboxed domain - pick unique path hierarchy for every file ○ Timestamp / random-string dependent ● Refrain from using “/” as the scope (Service-Worker-Allowed response header) ○ Which allows global activation of the service worker ● Monitor requests with “Service-Worker” header (appended on register). Mitigations
- 51. RUM (Real User Monitoring) ● RUM (real user monitoring) is a passive monitoring technique that records all the user interaction with the web application. ● It can be used to measure your clients web experience. ● When we observe a very poor performance on a specific client, one of the reasons could be DOS via Service Worker. Mitigations
- 52. Browser Events Monitoring ● Monitor the navigator.serviceWorker.register function for new unauthorized register events. Mitigations
- 53. Past Work on SW Prior Research ● Shadow Workers - https://github.com/shadow-workers/shadow-workers ● Marionet Attackd - https://love2dev.com/pwa/marionet-attack/ Guides ● Service Worker 101 - https://developers.google.com/web/fundamentals/primers/service-workers/ ● FAQ - https://dev.chromium.org/Home/chromium-security/security-faq/service- worker-security-faq Vulnerabilities ● %2f Vuln - https://alf.nu/ServiceWorker ● CSRF - https://ahussam.me/Amazon-leaking-csrf-token-using-service-worker/
- 54. Key Takeaways Service workers can be useful for web application They can also cause mayhem Sandboxed domains could be not that sandboxed
- 55. Thanks!
- 56. Questions?
Editor's Notes
- * add twitter
- 6 months ago Morning discussion Brainstormed on how to take low-med attacks and combine them into Meaningful high impact attack This is where this research was born
- Were going to talk about How SW API can enhance those low-med attacks into High impact, featureful attack Abuse scenarios Mitigations
- Browser run JS JS is single threaded Every tab has a thread – main thread On extreme load on the main thread we want responsive UI Delegate to other threads Web Workers API
- Main: // init new worker let worker = new Worker('worker.js'); // handle the message event worker.addEventListener('message', (e) => { console.log(e); }) // post some data postMessage({ name: 'BsidesLV' }); Worker: // handle the message event addEventListener('message', (e)=>{ // print out the data console.log(e.data); // send it back to the main thread postMessage(e.data); });
- Web Workers are bounded the a single page They have to be registered every time Expensive load time
- Type of web worker (no DOM) Proxy Scope Lifespan
- Supported on most browsers IE is still behind (like always)
- Registration Installation Activation Events Terminate != Deregistered
- Include a script tag inside the page Tells the browser where the SW is Returns a promise, when resolved Scope is logged The Browser only completes the register is the SW is new/updated Actual File (not in memory) https://carbon.now.sh/?bg=rgba(171%2C%20184%2C%20195%2C%201)&t=monokai&wt=none&l=javascript&ds=true&dsyoff=20px&dsblur=68px&wc=true&wa=true&pv=0px&ph=0px&ln=true&fm=Hack&fs=18px&lh=142%25&si=false&es=4x&wm=false&code=%252F%252F%2520main.js%250A%250Anavigator.serviceWorker.register(%27%252Fsw.js%27)%250A%2520%2520.then((reg)%2520%253D%253E%2520%257B%250A%2509console.log(%2560Registered!%2520Scope%253A%2520%2524%257Breg.scope%257D%2560)%250A%2520%2520%2520%257D)%253B
- Default We set the scope to /profile/ The SW will control /profile/* NOT for higher https://carbon.now.sh/?bg=rgba(171%2C%20184%2C%20195%2C%201)&t=monokai&wt=none&l=javascript&ds=true&dsyoff=20px&dsblur=68px&wc=true&wa=true&pv=0px&ph=0px&ln=true&fm=Hack&fs=18px&lh=142%25&si=false&es=4x&wm=false&code=%252F%252F%2520main.js%250A%250Anavigator.serviceWorker.register(%27%252Fsw.js%27%252C%2520%257B%250A%2509scope%253A%2520%27%252Fprofile%252F%27%250A%257D)%253B
- Good for caching https://carbon.now.sh/?bg=rgba(171%2C%20184%2C%20195%2C%201)&t=monokai&wt=none&l=javascript&ds=true&dsyoff=20px&dsblur=68px&wc=true&wa=true&pv=0px&ph=0px&ln=true&fm=Hack&fs=18px&lh=142%25&si=false&es=4x&wm=false&code=%252F%252F%2520sw.js%250A%250Aself.addEventListener(%27install%27%252C%2520(event)%2520%253D%253E%2520%257B%250A%2509%252F%252F%2520handle%2520installation%250A%257D)%253B
- Cleanup stale data https://carbon.now.sh/?bg=rgba(171%2C%20184%2C%20195%2C%201)&t=monokai&wt=none&l=javascript&ds=true&dsyoff=20px&dsblur=68px&wc=true&wa=true&pv=0px&ph=0px&ln=true&fm=Hack&fs=18px&lh=142%25&si=false&es=4x&wm=false&code=%252F%252F%2520sw.js%250A%250Aself.addEventListener(%27activate%27%252C%2520(event)%2520%253D%253E%2520%257B%250A%2509%252F%252F%2520handle%2520activation%252C%2520like%2520cleanup%2520of%2520old%2520SW%250A%257D)%253B
- Can respond also with cache https://carbon.now.sh/?bg=rgba(171%2C%20184%2C%20195%2C%201)&t=monokai&wt=none&l=javascript&ds=true&dsyoff=20px&dsblur=68px&wc=true&wa=true&pv=0px&ph=0px&ln=true&fm=Hack&fs=18px&lh=142%25&si=false&es=4x&wm=false&code=%252F%252F%2520sw.js%250A%250Aself.addEventListener(%27fetch%27%252C%2520(event)%2520%253D%253E%2520%257B%250A%2520%2520%2509console.log(%2560URL%253A%2520%2524%257Bevent.request.url%257D%2560)%253B%250A%2520%2520%250A%2509event.respondWith(%250A%2509%2509fetch(event.request)%253B%250A%2520%2520%2520%2520)%253B%250A%257D)%253B
- Visit a page w/o XSS Go to vuln page w/ XSS XSS triggered SW installed Back to page YES XSS!
- Go to page w/ some data No SW Trigger XSS Register SW Go to page No data SW responds 404 on that page
- Go to login page See that is successful Trigger XSS Install SW Installed verified Reload page Login again Submitted to malicious website
- Theres a website X that holds sensitive photoss Those photos are not hosted directly on X rather on Y (which is sandboxed)
- First, we upload the SW to the website (trivial since its sandbox)
- Then, we trigger the XSS on the victim Installs the SW
- Now, when the victim visits X and previews and image, the request is being made under the Y domain The service worker kicks in URL leaked
- Go to gallery See Images Trigger XSS Install SW Back to gallery Show
- Upload We upload the malicious SW to the sandboxed domain Trigger Using the XSS we register the SW Activate On every page under the scope, the SW is activated Leak Leak the image
- First, we upload the SW to the website (trivial since its sandbox)
- The victim goes to our page The page has an iframe Logout Login (attacker creds) Redirect to the actual site Trigger XSS Install SW
- Login as victim Show Victim Visiting attacker domain logout login redirect Login as Victim (again) PWN
- https://carbon.now.sh/?bg=rgba(171%2C%20184%2C%20195%2C%201)&t=monokai&wt=none&l=javascript&ds=true&dsyoff=20px&dsblur=68px&wc=true&wa=true&pv=0px&ph=0px&ln=true&fm=Hack&fs=18px&lh=142%25&si=false&es=4x&wm=false&code=%252F%252F%2520main.js%250A%250Alet%2520oldReg%2520%253D%2520navigator.serviceWorker.register%253B%2520%250A%250AObject.defineProperty(navigator.serviceWorker%252C%2520%27register%27%252C%2520%257B%2520%250A%2520%2520%2520get%253A%2520function()%2520%257B%2520%2520%250A%2520%2520%2520%2520%2520%2520console.log(%27will%2520be%2520invoked%2520before%2520every%2520register!%27)%253B%2520%250A%2520%2520%2520%2520%2520%2520return%2520oldReg%253B%2520%250A%2520%2520%2520%257D%2520%250A%257D)%253B