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 abo