Omar Minawi - Client-Side JavaScript from your nightmares: Multi-step XSS attacks and defenses

all right everybody we have our next talk right here this is Omari uh he's gonna be giving a talk on client-side JavaScript from your nightmares uh I've already seen this talk but I'm going to see it again because it was really good and I hope you guys enjoy it let's give it up for real mark

awesome thank you so much for the super kind introduction hi everyone my name is Omar uh and I'm really excited to share with you my talk where we're going to talk about some client-side JavaScript that showed up in my nightmares and now I want to show up in yours too uh yeah this is actually my first time in Knoxville and first b-sides it's been a great week and I'm really excited to share this with you okay so before we begin a little about me I'm an application security engineer at Cisco Meraki I help Empower developers to write secure code and I do this by Leading projects to assess services and applications uh in the company

um I've authored multiple Publications at the ACM swim Conference where I've published I publish papers proposing machine learning based intrusion detection systems for drones and controller area networks so if you're interested about ml based ids's or can bus stuff I'd love to chat I'm doing my masters in CS at Georgia Tech and I like snowboarding and cars specifically Porsches so in this presentation I have a a really interesting exploit chain I'm going to be walking through and this this whole presentation was inspired by real Attack chain and and what we'll do is we'll we'll start light we'll start off with an attack demo and then we'll dive into the attack vectors we'll talk about some web exploit research and then

wrap it all together with some defense in depth and some mitigations all right so in this whole presentation I'm going to be talking a lot about cross-site scripting and for those who don't know cross-state scripting is a common issue it's grouped in the injection family and with this this occurs on applications when user input is accepted and it's not encoded or sanitized upon inputs also and then the application takes it does some processing and returns it to the user and it doesn't encode or Sam has the input upon output as well and this can result in some really really funky functionality as we'll see in this presentation and in terms of impact the impact for these attacks really depends

on for example if the uh if the application has a database which pages are impacted and which functionality you're targeting and so it can really the impact can really range um so in this presentation we're going to talk about corp.com and corp.com has two sites a portal and a shop and what's interesting is we found that corp.com's portal site um is vulnerable to a reflected Crossing scripting attack in the queue parameter the Q parameter in the search method was injectable and what this means is if someone sends you a link Sun sends you a link like this and you click it you're going to get a pop-up like this because the JavaScript was accepted by the user

into the page the application didn't process it correctly it didn't encode it or sanitize it upon output when it returned it to the user and so you got this is a very a basic payload we've all learned when we first were taught about Crossing scripting on portsmokers Academy but what's interesting is the actual attack was nowhere near as simple what happened is using JavaScript the attacker set a cookie called special cookie and what they did in this cookie was scoped to allofcorp.com subdomains and what happened was the cookie had some strange payload and then and then the attacker redirected the user to the shopping site and then so for example you click on this link

we go to the portal site and then we get redirected to the shopping site and all of a sudden our cookies get dumped and we're like how did this happen I was on the shopping site One Trust domain then I got transferred to or I was on the portal then I got transferred to the shopping site and all my cookies got dumped um and this is really interesting and uh and if we take some time and we open up the cookie jar and really see what's going on that first cookie that was set in the initial reflected cross-state scripting Vector went ahead and set special cookie with some really strange content and this highlights the

rest of the investigation that we're going to go through together so looking at a deep dive I want to introduce you to one of the main stars of this presentation called Script one script one is a script that the shopping site uses for analytics it's business as usual and script one has some very interesting functionality where script one is go once the shopping site loadscript one script one is going to open up the cookies and look for a special cookie and if special cookie exists and contains a URL for a remote Javascript file it's going to fetch that URL and fetch that JavaScript and inject it directly into the page now this is you know as security folks the alarms

went off the bells are going on how can you just randomly inject scripts from the internet into your page you're asking just for bug crowd payments at this point but thankfully thankfully the folks at example.com who made script one they were really think in this day and they were like you know what we're going to limit example.com so it only accepts loading scripts that originate from example.com and so if we set the special cookie to load a script from github.com that's not going to work because GitHub does not equal example and then if we set it to load google.com and this is also not going to work but then what if we what if we find

another script let's say script two that also exists on example.com so this works this is really interesting functionality and then as an attacker we're kind of stumped like this is you know really strange functionality for this page Why does it process cookies and why does it fetch scripts and inject them to the page but so as an attacker we found that we have this limitation where we understand we can fetch scripts but they can only originate from example.com and our goal is to indirectly include malicious code into the shopping site so how can we do this well the whole thing changes if we can find a script that satisfies very specific conditions one it originates

from example.com and two it has some kind of vulnerability and now and then what happened is this script thankfully existed on example.com and so and this satisfies our uh this this satisfies the components we need it's vulnerable and it exists on example.com I now I'd like to introduce you to the co-star of the show script 2. now script two is very similar to script one script two is hosted on example.com once it loads it'll open up the cookie jar and if it sees special cookie the cookie called special cookie and there's a room a string for a remote Javascript file it will fetch it and inject it into the page but what's interesting is unfortunately the folks from example.com

the they missed the key check in this one the unlike script one script 2 will allow you to load scripts from anywhere on the internet and so if we set the special cookie to load script two and then and then tell script 2 to load a script from github.com that's going to work and if we set the special cookie to load us uh and we first we tell script one hey load script two and then tell script two load google.com that's also going to work you all can probably see where this is going if we set the special cookie to load script to and then put a malicious script but we'll say evil.com then this

is also going to work and this is really the big breakthrough and this is how we're able to indirectly include malicious code into the shopping site um and and really to summarize this the idea is to load a script with weak security controls to lower the overall security posture of the application and indirectly include malicious code so let's tie this whole exploit chain together first we started on the portal site and there was a reflected cross-site scripting vector and then using this reflected cross-state scripting Vector we set a malicious cookie called special cookie all using JavaScript set this malicious cookie to load script to and then load evil.com and then using JavaScript we redirected the user to the shopping site once the

user got to the shopping site it loaded script 1 which is used for analytics no problem thank you script one and then what happens is script one is going to go back and it's going to look at the special cookie re-parse it and be like oh you want me to load script too I can do that script 2 is from example.com I have high security controls no problem it load script too and then once script 2 gets loaded it's going to go back re-parse the cookie and say oh you want me to load a script from evil.com that's fine I have weak security controls uh I can do that and then that's how script 2

gets uh script 2 gets loaded loads evil.com and then that's how we can indirectly include malicious code into the marketing the shopping site resulting in a Dom based crosstrypting vulnerability all right now let's talk about some defenses and I'll kick it off by talking about defense in depth and defense in depth is really a strategy where you want to build your network or your application like a castle you know maybe previously for a castle the goal was to defend the keep and to defend the keep you out of town and then some walls and then a moat um and and really the idea is have many layers to delay the advances of attacks and maybe even once attackers go to your

castle and they see all your defenses they'll be like oh no thank you I don't want to attack Your Castle now you know for us I don't really see data centers hosted on top of hills with moats and alligators and things so in this talk I won't be talking about that we'll strictly focus on technical controls so I'm going to take us through four key defense in-depth approaches that we can think about when securing our applications to prevent clever attacks like this we'll start off by looking at web application firewalls then we'll talk about cookie protections we'll move on to content security policy and lastly secure software development life cycle and one thing I want to know and

something we should keep in mind when discussing these is every single one of these defenses has their own pros and cons and the idea isn't to find the one perfect solution it's to properly tune each solution to its Max potential and when layered they provide a strong and redundant defense story for our application so let's talk about content security policy so content security policy is an added layer of security and this helps this helps us defend against a large amount of web attacks on applications such as cross-site scripting click tracking code injection and so on and this is configured in four ways content security policy provides us a fetch directive and the fetch directive allows us to allows

us to provide an allow list of domains that we want to permit loading scripts from and so if you think about our example had we had a Content security policy that wasn't fully opened we would be able to only allow list certain domains such as corp.com and example.com exclusively excluding evil.com because that has no place on our application next we have document directives and document directives help help us enforce protections for the Dom uh this this includes changing protecting certain elements such as the base URL you know if the base URL gets changed in an injection attack this can result in Click jacking the third directive is called a navigation directive and what navigation directives do is they will

allow application developers to restrict locations where forms can be submitted to and this is important for certain forms such as such as login Pages credit cards anything with pii and if we limit the locations where forms can post information to this will allow us to prevent prevent against credential harvesting in various phishing attacks the fourth directive doesn't help us protect really against anything it's called a reporting directive and what this does is this gives insight and visibility to application application admins to understand where their content security policy is being violated and so there are multiple examples online of how to configure a reporting a reporting for CSP using serverless technology and this will allow you to analyze

violations in your policy so maybe you can catch all the times that evil.com keeps trying to get loaded and so a Content security policy is configured by using the content security policy HTTP header and most of the basic directives are supported on desktop and mobile browsers I encourage you to check out the compatibility Matrix on the Mozilla web docs and then they go into detail for which directives and which browsers and versions are are supported and if you're curious about the CSP policy on your own application that you manage or on an application that you frequently use you can use Google's CSP evaluator it's very comprehensive and one thing to note is that configuring and maintaining a valid CSP

is really hard especially for very large applications that integrate with multiple third parties and a study from 2016 from a group at Google analyzed a very large number of web pages and what they found was 14 out of the 15 of domains commonly allowed loading scripts from unsafe endpoints and as a consequence this resulted in around 75 percent of all policies and 42 percent of strict policies they contained at least one in one insecure host in their allow list um and so and so you know you go through all this effort you do the CSP and then you find evil.com snuck its way in there um and what's and what's what's important to note about this is a we

have layers and B uh defense and layers and B uh CSP is an ongoing task you can't it's not really set it and forget it as your application evolves and as the industry evolves and what you're using you need to tune it to make sure it's still correct and so as an example for how to configure a CSP let's talk about this one fetch directive what we can do is uh we can use default default Source self which says the the catch-all is my own domain so example.com and then we can say only load scripts from trusted.com and any subdomain at trusted.com that's what the star implies and then if you want a more complex policy we can think

about this where we'll only load images we can load images from anywhere we can load media from media one and two.com and we can only load scripts from userscripts.example.com and then the catch-all is anything from example.com and that's identified by the default Source itself and so now you're probably thinking where could CSP have helped us in our attack example well let's think about it so CSP would have helped us over here at the bottom had we configured a strict CSP to deny loading scripts that we don't permit this would have denied evil.com from loading and so had we gone ahead and configured CSP on shop on on the shopping site this would have negated the malicious script from being

loaded into the shopping site and prevented us from indirectly including malicious scripts because in our CSP we would have only allowed example.com and corp.com we wouldn't allow evil.com all right now let's talk about web application firewalls so a web application firewall functions as a reverse proxy and wefts they're configured to monitor requests to the server and the configuration of a WAFF is it will set inline in your application and so the user traffic will hit the wife the wife will send it over to your application server and if we can if we can consider network-based intrusion detection systems as layer 3 defenses we can think of laughs as layer 7 defense and laughs are really helpful they help

us protect against a number of web attacks such as Crossing scripting SQL injection and the various OAS top 10. and what's interesting is wife sit in a very strategic place in the network and in your application design where it's the ingest point to the application and because it sits right in front there it can provide a large number of security features for your users it can provide enough service protection rate limiting and so on because it will monitor every request that's hitting your application and similar to any Cloud product that anyone's tried to sell everyone you can deploy three ways on-prem uh cloud or a hybrid approach and one really interesting value proposition by waffs is is the managed service

offerings many service offerings and auto updating rule sets can help you have a comprehensive list of of rules to defend against it can provide zero day vulnerability protection and also this is new to me I actually just learned this Labs can also provide exposed credential checks because the Waf sits in line in the application and it can do TLS termination it can actually take a look at the credentials that are sent by the user and then using their own Dark Net monitoring or however the companies acquired the credentials they can check to make sure that your users credentials haven't been included in a leak and also again waps can provide bot detection and so if we go ahead and look back at

our attack sample where could a wife have helped us here well had we configured a WAFF in front of the shopping site when the reflected Crossing scripting attack was initially set and then uh redirected the user to the shopping site the WAFF would have caught this and it would have cut the connection and it wouldn't have allowed the redirect to go through and if the redirect didn't go through now the shopping site wouldn't have when it loads it wouldn't have the malicious special cookie in the in the user's browser thereby going ahead and continuing the whole attack and so that would negate that wouldn't allow setting delicious cookie script one would never load script to and then script 2 would

never have loaded evil.com and then that would have prevented the dawn based cross-site scripting uh just as a note depending on how corp.com is architected ideally you should put the WAFF in front of allofcorp.com and not just your shopping site but that's another topic okay let's talk about cookie protections so cookie protections are very relevant for session management and one of the first attributes I'll cover is the secure attribute and the secure attribute is set by the server and on and when this is set for a cookie this will only allow cookies to be sent on https connections and why this is why this is important is cookies contain sensitive information and I mean this

can prevent against a man in the middle attacks which can take place if there's an https downgrade attack and then if the cookie is sent over HTTP a man in the middle you can read the cookie next we'll talk about HTTP only so HTTP only will prevent JavaScript from accessing the cookie using the document.cookie object and this is very interesting because the first Vector the reflected Crossing scripting Vector actually set the cookie using document.cookie um and uh and what's interesting is using this this doesn't this isn't a foolproof protection for cookies because a crosses scripting attack chained with a valid csrf attack can in fact disclose the cookie even if you have the HTTP only flag configured

next following on csrf let's talk about same site the same site attribute is used to prevent against cross-site request forgery and this will help us determine which domains we include the cookie in when we uh when we do cross-site requests domain and path these are flags used to define which domains and which paths in the application can process and receive the cookie and lastly very important for session management expiring max age depending on their use this is useful to help determine and enable and disable persistence so I've talked about a lot about cookies so let's talk some more have you ever considered a scenario where you have an application that uses that references cookies in directors cookies using

JavaScript but these cookies aren't set by the user for me before seeing this attack I never thought of this this is a very strange design pattern to me however this is really how this attack happened is the server didn't set special cookie the the attacker set the special cookie using their first vector and then the server and then the application by its own logic always check special cooking no matter who sets it and then we think okay well we talked about HTTP only would that help us here unfortunately no well actually no it would it would break the application um but um and it would break the application because the inherent use of the application is it will actually use

document.cookie to fetch the content of special cookie and then see if it has um a URL for your remote Javascript file and so if we use this it would break the application and prevent the attack but um sometimes when you know that that advice doesn't go too far and so now we're kind of thinking you know what what could we have used uh we can't use HTTP only we have very strange functionality for this application how can we prevent cookie misuse and to that I'd like to present content security policy for cookies this doesn't exist also um and um and so this directive is obsolete however in 2016 the w3c working group published a document that

supported CSP cookies and unfortunately this didn't make it to csp3 I think I know why it kind of encourages poor design patterns such as the one we see here and but what it did is it defined mechanisms that allow developers to limit the ways in that cookies can be interacted with on their application and so for example if we set the content security policy header and we did cookie scope none what this would do is this would prevent cookies from being set using the set cookie header or even document.cookie and this is what we could have used in our example so um also there's a lot of ifs for this one if csb cookies existed and if we

configure them and if we did them correctly then it would have blocked the cookie from being set in the initial Vector because the payload on the portal site would not the second part of the payload where I set the cookie wouldn't have gone through because we defined such a tight cookie scope and so in that case it sort of prevented setting the cookie script one can't parse it script scripts you also can't parse it and then evil.com uh won't make it on the page so now let's talk about secure software development life cycle uh so secure software development lifecycle has a number of key benefits and the idea is it's important to do uh these actions in parallel with normal

development work and this life cycle is heavily supported by automation developers go ahead and provide thousands of commits a day and what we can do is leverage automation to provide high quality feedback at scale and as an appsec team this is really important because we're able to put the power in the hands of devs and give them and and give them the ability to own the end-to-end security for their product we can give them the tools for automation we can give them the feedback that they need and ideally providing the feedback for these security tools in the same place that they're actually developing codes so it's easier for them and and what's awesome about this is this helps

developers spend more time working on features that customers value and and things they and things they want to work on as well and so this is really characterized by the shift left initiative and again the idea instead of appending secure software development life cycle to the end of the traditional sdlc we go ahead and run it um we move it down and run them in parallel and so going into each of these stages let's think about the requirement stage in this stage developers are are thinking about you know what does their application need what kind of what kind of information should it accept and what requirements are trying to fill and here this is a great time for us to identify

key security functionality are we collecting user data in this feature are we collecting pii are we doing any cryptography and so this allows us to perform a risk assessment very early on in the application next at the design stage this is where developers have the requirements they know what they need and how to get there and now they're wondering how to put the pieces together and during the design stage at least for cloud architecture these stages are the design is still very new it's very fresh and malleable this is a great time to think about threat modeling and do design reviews because the architecture can still be changed it's not expensive to change some I mean sometimes expensive but

maybe not too expensive to change things early on in the in the process and so what we can do is identify architecture concerns and we can provide mitigations to provide security for the rest of the process and third during during the development stage this is where we can heavily lean on our SAS and software composition analysis tools where we leverage automation uh to provide feedback to developers and detect against insecure coding patterns and so on and then we have during the testing stage uh hopefully developers run a unit tests for their application and when they are this is a great time to consider a critical feature tests and so let's say the project is secure file

storage and we have this rule for secure file storage where user 1 cannot access files of user 2. this is a traditional unit test however security has has a key investment in this specific test case because it validates the security posture for the application and so this is an example of a critical security test critical feature test that security has interest in at the stage and lastly we have the deployment stage and during the stage we can think about patching new vulnerabilities maintaining the application and potentially doing routine assessments based on your organization's needs or compliance requirements and so let's let's go back to our example uh where could secure software development lifecycle have helped us

here well to be honest it could have helped everywhere uh but we got to focus so we will focus on the applications that we control head uh head the portal site gone through the entire secure software development life cycle we would have been able to we would have been able to determine that there was a reflected cross-site scripting vulnerability in the page it would have gone through the design review and it also would have gone through our threat model ants and the SAS tools would have caught this and then if we look over on the right for the shopping site had the shopping site also gone through this uh we a part of the design review and threat model is

taking a look at what the third-party applications are and during this instance we would have been able to take a closer look at example.com and understand their functionality and how it works and this is how we can make sure that the strange third-party advertising scripts don't uh don't make their way into our application or if they do we lock them down real hard and so um and so more or less this would negate the reflected cross-site scripting vector and the dawn based Crossing scripting Vector which means that the entire uh the entire exploit chain would be mitigated and so now uh now let's think you know what does our defense and depth Story look like for all of corp.com we talked

a lot about these attacks we talked a lot about these defenses let's put it all together okay so let's start with CSP what if we configured the CSP at the bottom and we used a fetch directive to only permit loading scripts from example.com and uh incorp.com this would have prevented loading the script from evil.com and then what if we use the WAFF and we positioned the WAFF in line with the application for the shopping site the wife would have detected the reflected cross-site scripting payload when the user was redirected to the shopping site and it would have cut that connection and then lastly what if we use the secure software development lifecycle and we put the

portal and the shopping site through all of through all the rigor and uh and steps that we've all discussed and so at this point we can Pat ourselves on the back and rest easy because this is how we can prevent and defend against multi-step cross-state scripting attacks that show up in our nightmares thank you [Applause] thanks and I'd like to give a special thanks to the Meraki Security Group particularly my manager Natalia cracker and Tech lead Brett Bergen um any questions all right over here here you go it's um clearly an anti-pattern to learn from a cookie so how can you detect that in say static analysis or dynamic analysis to catch like other teams

trying to do that yeah that's a great question uh to paraphrase the question was it's an anti-pattern to load a script uh from a cookie and so how can this be detected and how this can be detected is the way the script is loaded it's using a JavaScript method to fetch to fetch a certain URL and um and usually this can be picked up that specific fetch call and also um you know I haven't tested this but I assume JavaScript referencing document.cookie should also throw a flag maybe not a red one maybe a yellow one but if you chain that with the flag for the for the the uh the HTTP call to the other script that fingers crossed will

get picked up yeah thank you any other questions all right can we get another round of applause for our Omar [Applause]