At Your Service: Abusing the Service Workers Web API

welcome everybody good afternoon welcome to besides Las Vegas what is this ground breaking ground thank you this talk is at your service and our speakers today are che sahabat and Daniella Bayless a couple announcements before we get started we'd like to thank our sponsors especially our inner circle sponsors critical stackin Valley Mail and our stellar sponsors Amazon blackberry and the national security security agency it's their support along with our other sponsors and donors that make V sites possible these talks are being streamed live so as a courtesy to our speakers in the audience we ask that you set your cell phones to silent position if you have a question at the end please hold up your hand and I'll

bring you the audience mic so that we can have your question on the video for the YouTube audience and that's it let's get started please welcome Shane and Dane thank you so thanks for joining us and welcome to our talk at your service abusing the serviceworker web api my name is Daniel this is Shai we are both security researchers at the Akamai threat research team we both breathe and leave web security and if you have any questions please feel free to reach out at our Twitter accounts or after this session so about six months ago Shai and I had our usual morning discussion and unlike any Bourne discussion that we have this one was actually interesting we brainstormed how

can we enhance low-to-medium attacks using web api to make them a more meaningful and high-impact attack and that research that brainstorm led us to a research that we were presenting to you today so we're going to talk about what is the serviceworker web api and how can it enhance those low-to-medium attacks to a more meaningful a high-impact powerful attack we're going to show some abuse scenarios that we have found out during our research and some way to mitigate them so our web browsers grow on firefox and so on run JavaScript as their main programming language for the client-side application and that javascript is single threaded by nature meaning that every web page you get a

single thread to handle all the client-side operations now sometimes we have extreme load on the main thread meaning that we have some expensive tasks that are going out in our browser this can result the UI be not so responsive now there is a question how can we maintain the UI responsive and do those expensive tasks and that's where the web workers API came in it cleared us the ability to delegate those heavy lifting those heavy tasks into other threads and maintain the UI responsive so web workers are basically background threads that ran in our browsers that run JavaScript they are very similar to the main thread they share a lot of common features but they are they have

some restrictions they have to be loaded from the same origin meaning they cannot be loaded from any other third-party domain and they don't have direct Dom manipulation rights meaning that if they want to manipulate the Dom they have to communicate with the main thread using the postmessage api and then the main thread is the one that is doing the Dom manipulation now those web workers are great and they're still being used today widely over the internet but they have some limitations if we want them to be applied on every web page under our application we have to load them manually on every page which might be expensive and they are bounded just to a single page and this is where the

serviceworker api came in it has the ability to create web workers across a wide span of scope and reduce that expensive load time a serviceworker is basically a type of a web worker it sits between our application and our browser and the network it acts as a network proxy and it has a much wider scope than the web workers once we register a serviceworker it will be applied under all web pages under the scope of the serviceworker we'll touch about the scope a bit later also in terms of the lifespan of the web worker even if we shut down the browser we shut down the computer and we turn we turn it back on if we go to web

page under the scope the service circle will still be spawned under that page now why should I even use those service workers well first of all they can handle the network requests between our browser and the server means they can they can intercept and inspect they have a some sort of full visibility into the request and response this can be very good because they also support a cache API which is different from the standard browser cache API so you can cache those responses into a different cache and then return them in a later stage and they can also offer the our clients and often experience to our application using the cache we can store an offline

version of our application and where our clients are losing internet connection we can offer a different version of our web page of our web application for offline experience which is very good in terms of browser support it is widely supported over all major browsers except as you might have guessed ie it's mainly because IE doesn't support natively the promise api and service workers are a synchronous by design they cannot run any synchronous API is like xhr for example so i stood behind in terms of the life cycle of the serviceworker they have three main stages the registration installation and activation once they're done it can start listening to events and messages and once the web page is closed the

thread dies now or gets terminated now terminated doesn't mean it gets the register as I said even if we close the browser and we open it once again under the scope of the serviceworker it will be spawned once again to register a serviceworker we use the register function that gets as the first parameter the file honest on where the serviceworker file exists in the server it has to be a physical file it cannot be any memory object like a blog for example and that function returned the promise that one resolved we get information about the scope now let's finally talk about the scope the scope is a crucial concept on the service workers it determines where the

service worker will be spawned on it's the activation condition for it by default it is the path where the JavaScript file is located in the server meaning that if the file is located under let's say the static folder every webpage under that folder will be activating this service worker now we can easily reduce the scope by setting the scope parameter we an example from / - slash profile it's very easy to reduce but we can also increase it but it requires another step it requires the server to respond to to give us the file with a special response header core service worker allowed the value of that hair defines the maximum scope the browser is allowed to define

here we can see an example of a failed registration where the file resides as I said at the slash static folder and we try to set the scope to slash now the max scope for it by default it's where it resides which is less static if you try to set it but to slash we get an exception on the registration function here you see an example of a successful registration because as you can see wiki we have set that response header on that file so it got successfully registered now you might be wondering what happens if you have two service worker installed in our browser now if we have two of them under the same scope the most

recently one will be the one that gets activated so if you had one other scope a and now we have another one that gets registered the the most recent one is the one that will be get will be activated under every page if they we have two of them on overlapping scopes in example a slash slash upload one will visit the slash upload slash files only the innermost one will be get activated in here the slash uploads service worker now they can also import scripts from other files in example if we have any logical any logical code in other file we can import that file and that content will be loaded in runtime now this is by the way how we

maintain the legit serviceworker functionality in our malicious serviceworker that we are uploading in our abuse scenarios that we'll show in a second just like web workers once again it has to be installed under the same origin again we cannot load it from any third-party domain now once it was successfully registered the install event occurs in the serviceworker this is the perfect step to start caching if you like to open a cache and this event also occurs when the serviceworker has changed even in one bite that's the criteria for the change condition once that event is successful the activate event occurs in this stage we can clean up any older caches that were opened in the serviceworker

context so we can clean them up delete them do whatever you want and in this event we can also call a special function called clients dot claim by default open pages that were opened before we register the serviceworker are not controlled by the serviceworker if they're under the scope course so with this function we can override this behavior and claim our rights on those clients or or tabs otherwise they must be reloaded now that we have done with all the steps the registration the installation and activation we can start listening for events and messages one of the most crucial events for us it's the fetch event the fetch event occurs every time the browser tries to request a new

resource an image javascript file a web page whatever in this event we have control over the entire request meaning we can see the headers the status and the body and we can respond either with a fetch request to fetch the resource from the server or we can respond with the cached version we start on the last event specifically in chrome you can find them under the developer tools tab under the application bar you can see the service workers from all domains that exists in your browser and you will you'll be surprised how many of them exist in your browser today so we talked about why what are service workers and what are they good for but

now we'll talk how you can abuse them as we said to enhance those low-to-medium attacks the first scenario is a category called responsible education in this we have in the scenario you have a website that has two requirements the first one is that we have a file apple functionality meaning that we can upload any JavaScript file and most importantly we can retrieve them and that we have an XSS vulnerability in the app meaning that we can inject JavaScript code in the context of our victims browser now all of the following scenarios under this category abuse the fact that we can attach to this to the fetch event in our malicious Service Worker and manipulate the requested resource we start by

uploading the malicious Service Worker to the website we trigger the XSS that we have on the website to register the malicious service worker and then we attach to the fetch event in this point we can modify the response of requested resources now during our research we found three main scenarios that could apply in this category we can persist XSS we can cause local denial of service and you can surf fishing or defacement campaigns now how can you persist your XSS on the first on the last step where we have attached to the fetch event now we have control over the response for that resource so we can re-inject our code under every page under the scope of

the Service Worker meaning that we have just expanded our scope for the XSS for every page under the serviceworker scope rather than just the page suffers from the XSS in this example we have a website with the page it definitely doesn't have an XSS because it said so and now we're going to trigger the XSS on a page that suffers from the XSS as said to register the malicious service worker we open the developer tools to see that indeed we have that service worker upper running in our browser and now we'll try to go to a page that to that place it didn't have the XSS and you can see we now have the XSS upper

running under the that web page so the second abuse scenario is causing local deny of service again under the third step we can we have visibility into the fetch event now instead of modifying the response we can just deny it we can deny images we can be nice CSS files we can deny everything we want in this scenario we have the same application but now a different page refers to validate that we have no serviceworker installed under this application and as you can see we have some very interesting data now we'll try to trigger the XSS again on the page it suffers from the XSS again to trigger the register function to have the serviceworker

up and running and we have validated it is up and running and when you go to a page that definitely exists we get a 404 not found now when you go to the network tab we can see that the page itself was received from the serviceworker and it gave us that 404 not found the third one refers to fishing or defacement again on that third step instead of serving or denying that resource or injecting over our code we can just serve alternative content in this scenario within this application we have a login page we we put our our credentials and we submit the form and you can see it successfully works now we'll try to trigger again the

XSS that we have in the application to register the serviceworker and now we can actually verify the serviceworker is installed we will reload the page and now once again we will submit the form with our credential and this time when we submit the login page were submitted to a different domain to a malicious domain because we had control over the forum itself because we had visibility into that response for that request all right all right so now that you have a better understanding of what exactly service workers are what they are used for and a couple of pretty straightforward abuse scenarios by modifying the responses let's look at a little bit more advanced abuse scenarios

so in this particular one we're going to talk about how can you leak sensitive data user sensitive data from sandbox domains now to do this you are unfamiliar with sandbox domains and what exactly they are those are domains that usually are meant to host user uploaded files untrusted user uploaded file but separately from the main application that's that's why if you have some sort of a maliciously uploaded user file into the sandbox domain it won't affect at all at the main application so the user won't be compromised there's no real firm ability to be exploited on that sandbox domain it does not hold what you can do because those sandbox domain usually don't carry any cookies

notarization information there's no way to actually connect the sensitive files back to the user I've still them or anything at all those files most of the time are publicly available meaning that if you have the path to the sensitive files you can access it without needing to login or have any cookies or anything like that now the reason that's possible is because most of the time when we upload those type of files to the sandbox domains the actual file path the file name gets heavily obfuscated or it's being completely randomized meaning the actual uploaded file name resembles nothing as the actual file that's no resides within servers as a result many vendors tend to ignore exercise

vulnerabilities on those sandbox domains because once again even if you've gotten some of an XSS on the sandbox domain most of the time it would be by uploading an HTML file containing a malicious script and that's it because once again those sandbox domains are meant to host static files use your alpha bit files so that's pretty but something this is very likely actually so there's not a whole lot you can do with an exercise you can still credential there's no sensitive data to be collected other than beep at but once again you can't really access the path unless you know it somehow a couple of examples of such semak's domain is Google User Content wishes google.com and FB cbn.com which

is facebook.com which once again you have the main application google.com which is the actual place where you operate your sensitive files which is Google User Content several different domain so in this abuse scenario we're going to presume the following the first thing is that we have main application residing in be size fortress com that would be on main gallery application and the actual sandbox domain will be called besides for the Sandberg comm and that's where all the sensitive files would be uploaded to and let's assume that we somehow find an exercise in the sandbox don't name now most of the time once again that would be by simply uploading an HTML file containing the script tag

and that's it so as you can see that's what I was just describing you have the main application business registers calm but the actual picture resides in the sandbox domains so for us to actually take abuse of that scenario and somehow leak that sensitive data you're going to upload a malicious JavaScript file if this javascript file which contains the serviceworker code like in the previous scenarios into the sandbox domain that's very plausible because of the way those sandbox domain works there are meant once again to host user uploaded files and the next thing we are going to do is trick the user to somehow visit our XSS we're just going to send him the XSS

payload under the sandbox domain and that sandbox in that XSS once triggered under the victim browser is going to install the service worker that service worker is now installing and is currently running in the victim browser so we have a service worker which is listening for all the requests and responses going to the sandbox domain might be getting where I'm going with this so the next time the user is going to visit the beside photos.com to view is cute dog pictures and click on one of the pictures which will trigger a new tab opening of the sandbox domain or whether we try to download the pictures for his own enjoyment the serviceworker will start running in the background and

remember this is a malicious serviceworker that we control once the serviceworker realizes that a research has been fetched from the sandbox the it's just going to leak that sensitive path it's sensitive publicly available path back into the user and we can just visit that file for our own enjoyment so we've got a quick demo around here to show you exactly what it would look like we have a gallery application showing the cute dog pictures which is called Chiquita and she likes the snuggle as you can see she's very cute they see my own premium and we're going to actually visit now the sandbox and domain to trigger the xs/s on the victim browser you can see now that we have a service

worker installed and running in the sandbox domain it was done via the xs/s so once you're going back into the photo gallery once again to view my queued up to get a picture and we're going to show you in the bottom our city Server listening for all the requests coming from the serviceworker and once the victim will click on one of the pictures once again to view it you can see the actual sensitive file the sensitive path being linked back to the attacker so we somehow by just abusing a service the serviceworker api and an exercise on the sandbox domain which was at the time there's not a whole lot we can do it we can link

those sensitive files back to the attacker so to recap exactly what you saw just now and what we need to do to actually abuse that scenario we need to upload the sensitive serviceworker file into the sandbox domain we need somewhere to trigger the XSS on the victim browser serviceworker will activate and start running in the background and whenever a user will click on one of these picture or download them that sensitive file will be sent back to the city server and we can actually view that sensitive file for our own enjoyment alright and on to our next abusing area this one talks about how we can actually enhance self XSS attacks and once again this is me we

have a couple of things we need to help just like in the previous one we need to have some sort of file upload functionality for us to be able to upload the malicious serviceworker javascript file by previously so we assume we have found some sort of a self XSS and to those of you're unfamiliar exactly with what the self XSS is that's an XSS it most of the time can only be exploitable under our own counts so it is bound to an account and for that reason you can't you exploit it on any other victim it is bound to your account there's not a whole lot you can do with it you can start financials

because you need the victim to somehow log into your account and even then what you're going to steal here on cookie not a whole lot you can delete it the next thing you're going to need to have is a login and logout CSRF so to those if you're unfamiliar once again login logout CSRF we just I mean it's just a way for the attacker to first apply log out the victim out of his own attack accounts and login back into the attacker account so that's why we can trigger the XSS on the victim while it's still on self XSS so the abuse trainer who looks something like that we're going to upload the malicious JavaScript

Service Worker file just in the previously into the main application we're next going to trick the victim into visiting our own evil application we're just going to send him a link that application will in turn host an iframe which would cause the victim to log out of his own attack account so now the victim is logged out and we're going first ugly logging in into the attacker account which as you remember we have a soft XSS already in so once he's going to login into his the attacker accounts and visit the page containing the selfic success the exercise is going to trigger lock previously it's going to install the malicious service worker and that service worker is going to run in the

background under the normal application but currently he's logged in as the attacker so once again not a whole lot we can do but because we have an XSS and we have a service worker installed we can once again log the user out of is the out of the application and the next time period is going to visit the application logging in into his own account our service worker is just going to push an XSS payload like you saw in the previous of your scenario and now we have an XSS under the victim browser victim account so we elevated that suffix that says something that we usually can't really exploit in some way into something that is exploitable so

that's nice we're going to show you a little demo of exactly how this attack is going to actually look like we have the victim logging in to his own account using his own credential you can see the actual profile page let's call it for the victim not whole lot of information in there the next thing we're going to do is have the victim visit our malicious website with the iframe to actually log the victim out of his own account as you can see and then we log in back into the attacker account triggering the XSS and we're going to redirect him back into the application after reversibly log him out as you can see the XSS has already

popped up meaning we now have an XSS in the victim browser now the victim is going to regain back into his own account but now the XSS is triggering under the victim account and not the attacker account so we elevated that self XSS into a normal exercise and even a persistent XSS under the victim profile which is pretty nice so to recap exactly what we've heavy and how we can actually use that we need to set up a domain with an iframe to log out and login the user into the attacker accounts we need to trick the user to log in to visit the bat site we just set up we can just set him a link or pick

your favorite fishing way we need the actual iframe to trigger log out the user logging in to the attacker account we need a service worker to register via the suffix SS already in the attacker account and that's it just choose your payload choose what your exercise is going to do and you have a normal XSS now a couple of caveats because while those scenarios does look promising there's a couple of things you need to take into account the first thing as Daniel mentioned is the scope we need to make sure that the actual page we want to attack and the actual place where the javascript file we've uploaded and anine are having the same scope or pretty

similar scope we can if we'd the actual page we want to attack resides deeper in the tree then the place where the serviceworker file has been uploaded to is not a whole lot we can actually do the second thing there is is the mime type when we're uploading the javascript file it has to be returned from the server with a javascript mime type so mostly application javascript or text javascript but if that jaws feud file is going to return with the text plane mime type for example that's not going to cut it the browser will refuse to install the serviceworker because of the incorrect mime type so keep that in mind

okay so we've showed you what our service workers how you can abuse them but now we're going to show you how you can mitigate those attacks or try to mitigate those attacks first of all you can enforce the scope you can set the uploaded files depth deeper in the tree meaning that if you have User Content that is being uploaded try to make that a path deeper in the tree so if someone uploads a service worker or malicious Service Worker it will have less effect over other files in sandbox domain you can try to pick the path hierarchy to be very unique and even if it has like timestamps or random strings or guids or

stuff like that so after the files will only affect the file itself and no other file under the file hierarchy refrain from using slash as this scope with a response header we have seen developers doing a very lazy work and putting that response header on every service jarasskiss file because they didn't want to specify it only on the specific Service Worker so every uploaded Service Worker we had the global activation on your victims browser which is great for us which is bad for them you can also monitor requests that are coming with the Service Worker request header which gets appended when you try to register new service workers that header is being offended every time you try to register

so you can take a look of the file name itself if you see any irregular file names you can try to make a rule to block those requests you can also try to implement real user monitoring or run for shorthand run is a passive monitoring technique that basically give you it gives you visibility into the experience of your clients of your web clients you can measure the experience of your clients so if you have a client that suffers from poor performance one of the reasons could be local denial of service vs service workers again it is under some restrictions the local dinner service has happened only on static content and not just the webpage itself you can also try to

monkey patch the register function to try to log any unusual activity on that function on your clients browsers you can look if someone is invoking that method with a file name that doesn't suit your legit service worker in in your application if that if that happens you can alert your sock team or you can just deny that invocation you would also like to note some past work on service workers mainly some great guides from Google which are targeted for developers but they have assisted as much doing this research they are very thorough and very functional so what we want you to take away from this presentation first of all I hope we introduced you a new

web API that you can use and abuse and they are very useful and they give clients a very good web experience they can enhance dramatically the experience of your web clients but they can also cause harm so we should use them carefully in your application also sandbox domain were treated for a long time as sandbox for sure because many thought they didn't had any probabilities but sandbox domains are just a method not the actual result all always try to monitor those sandbox domain for unusual activities thank you very much [Applause] question thank you for the presentation it was really good I was keep thinking about how this could be applicable to the vendor attacks supply chain kind of attack so let

safety and vendor got compromised and now many web sites are actually loading javascript files formed vendors so can compromise vendor inject service worker requests which will be loaded up on our site and every time someone visits or actually every time the victim visit our site and this search I'm sorry this service worker sorry will work in the background like I hope you understood my question yeah my god basically one of the limitations for service workers is they had to be loaded from the same origin so supply chain attacks usually refer to third-party scripts that third-party domains are hosting now if those third-party domains have some sort of a malicious Joseph code injected they can register a service worker but the

file itself must reside on the actual application domain so they had initially have to upload the malicious Service Worker into the application itself then they could actually register the Service Worker but they have a pre resist of uploading that file into the application into the server of the main application they can register it but they have to be the file has to be same origin ok anybody else

say you were subject to this attack and you knew about it and you wanted to like remove all the service workers that have permission list maliciously installed on a user's browser is that easy to do once you've like regained control definitely well the service worker object under the navigator object has other functions then it's just registered you can see all the installed service workers and you can unregister those from the browser so if you have expected such activity you can push a fix to unregister those malicious service workers and hopefully it that will be enough so they're not that persistence

next question

just to follow up to that so presumably a service worker would not be able to inject something into the response which would stop the unregister coming in in a new file that make sense yeah that's why I said hopefully because once the service worker has a foothold on your clients browser they can dynamically remove the piece of code that actually removes the air service server from the browser but they have to be very aware of that piece of code okay so that's like a catch-22 for that matter does it service work or persist through like incognito mode so we does work in incognito the only way it doesn't work it's over HTTP it has to be over secured

channel but it does work in incognito so to remove other service workers what level of permissions do you need to be running and to be able to see all the other service workers there is no special permission I mean in the web every job that most of the JavaScript code runs on on the same level so you don't have like to be in a very special you know special ring for that it's so if I manage to distribute my Bitcoin miner I could go cancel all the other service workers that we're running and yeah Park the CPU but you should take a thing in consideration that by eliminating the existence of other like legit service workers you're going to

affect the experience of the actual website so users might see like a degraded experience and notice that something is going wrong other than the CPU is going on fire so yeah I think they would probably just call IT and say it's not working so you'd have some amount of time right yeah

so a service worker can intercept requests when your honor on the website and modify the responses or change headers if if you've installed a service worker can it do anything when the victim is not at that website like can it run in the background when there's no tabs for that site open so that's a good question actually the service workers are bounded to a page service worker needs clients to be operative clients are considered either tabs or new windows open under that scope and if there are no clients there is no need for the service worker to be alive so it usually gets terminated anybody else

thanks a lot for the presentation Mike I guess my question is since you have the mechanisms to kind of figure the kind of browser that the end user is using to visit the website or the service are there any browser specific implementations that you should look out for say hey we should prioritize Firefox Safari over chrome or any other browser even if it's like diminishing the end user experience it should kind of overhaul the security overall the alpi of the service basically is there anything we can do browser specific or is that pretty much standardized well the w3c has submitted the RFC for the Service Worker API and most of the vendors have implemented it some sort of

the same they all share the same functionalities but obviously the source code is different so every browser is brought to different attacks there is usually like a cat and mouse scenario where like in three years ago someone found out an ability to bypass the scope restrictions so after chrome has patched it every other vendor like was hurt Apache that that's one ability after that so they sure basically the same function is the same security though

any more questions I guess not let's give a big hand to our speakers Daniel and say thank you very much [Applause]