The Anatomy of Web Client Attacks

is everyone doing I'm I suppose it is this this on all right can you hear me that's fine i'll just talk i'll just talk about come on this thing right you're on that it's going into the video that's well that's all that really matters right as long as everyone can hear me in the room what okay I I can talk up alright so today we're going to talk about the the anatomy of web client attacks first a little bit about me my name is Jason Gilliam security consultant at secure ideas I like to hack things and by that I I really a mean sort of the innovative problem-solving type of hacking also breaking things is fun too as long as

you have permission i'm also an open source contributor I've before i got into into the penetration testing side of things i did a lot of software development so now i use those skills to build tools to help me break into things so it's kind of kind of fun i also of note at the very bottom probably the last word on there's probably the most important thing to know about me is i am a home brewer as well so not really relevant to this talk but okay so why are we here I was you know I spent a lot of time going a typical for me is go from one location to another at a client

site or working remotely with a client and and do penetration testing so I get exposed to a lot of different people in there are different opinions of things and there are different levels of understanding and it came to my attention through this that there are some misconceptions out there about what some of the alphabet soup around web client attacks really means and this is an area I do various different types of penetration testing but web pen testing is an area that I'm very interested in more so than some of the others so I spent a lot of time in this area and so I thought I would put something together to help clear up some of this it is a

semi technical talk so i'll get into some of the details on how some of these things actually work and some of the issues with them and there's more than what's just on that slide 2 so so i'm going to talk about three different vulnerability classifications and then also some of the controls around those the three the three are in the top 10 if you is anybody not heard of a wasp no hands went up that's amazing so a wasp is is basically the go-to source for web based security we're talking about you know web applications the three vulnerabilities that I'm going to talk about today are cross-site scripting cross-site request forgery and the unvalidated redirects so and I'll also

talk about how these can be used in together in order to actually take something that you know maybe the risk was only at one level and then when you combine two of these vulnerabilities together in the same environment how the the risk to the to that environment goes up significantly so first let's talk about cross-site scripting it's number three on the lost top 10 list another quick faq about it is it's the is the cornerstone of a lot of phishing attacks so when you get that email that you're not supposed to click on that a lot of people click on anyway that's often will contain a cross-site scripting vector on there or it will lead to a site that has

a cross-site scripting vector on there so good things about cross-site scripting is it's been around long enough now that that we actually have preventive controls built into the browser's so only to an extent though and then there's also there's three flavors across the scripting we need to worry about so we have reflected I'm going to go into a little bit more detail on all this stuff in a moment so there's reflected which is basically you get a link you click on it and then whatever something that was included in that link ends up coming back on the response on that page you have stored wear your wear a cross site scripting payload is actually stored on a server

somewhere and it comes back to everybody who visits a particular page and then you have Donbass the document object model where some JavaScript actually inserts the payload onto into the DOM and that one's actually the Donbass is becoming it's not that is becoming more common it's it's already out there it's becoming more discovered i guess of late because that's one that's very hard to detect with the automated tools that we've been using for many years so we are getting better at that you pretty much your best bet at detecting dom based cross-site scripting is actually through static analysis tools okay some examples in the media so one thing i did i've been interested in doing some more

I guess research on cross-site scripting and near the beginning of this year I set up one of those google alerts where are you basically put in your search terms and every day in your Inbox you get the results and i put in the keywords cross-site scripting and xss and oddly near the beginning of the year the first time I presented this was at Carolina con and I had been getting on average maybe five or six results a day which doesn't seem that bad but I've kept the alert up there and in the last couple of months i'm averaging much higher numbers i don't know if there's an increase in awareness or across a scripting itself or what but it's it

seems to be more rampant than ever some of the big ones out there we have and this is just cross site scripting is most effective on sites where they get a lot of traffic right so IMDb it gets quite a bit of traffic another area that we find a lot of cross-site scripting flaws recently is in WordPress plugins okay we're press itself usually it's okay for the most part we you know we don't see lots and lots of issues with with WordPress like the core but the plugins oh they just keep coming up this one here yost google analytics I can't remember how many installations there are of this one but it's a very large

number it's a widely used plugin so when something like that happens and it gets out there and becomes public knowledge of course all those websites running it have cross-site scripting flaws in their websites bugzilla is another one I got a couple more here I'll just read them a little bit i know they're probably a little bit small we have a couple of CVS there ones for IBM rational Quality Manager and the one right below it is is a SharePoint SharePoint's actually been riddled with cross-site scripting flaws over the years it's always had some so but this one here all of these are 2015 they're all you know pretty pretty recently discovered the one at the

bottom is I thought was ironic national vulnerability database vulnerable to cross-site scripting so and that was this week

so let's talk a little bit more about what cross-site scripting is and hopefully if you're a little unsure of exactly what it is or how it works I'll be able to help clear that up in the next couple of slides so wikipedia says I'll just read this part cross-site scripting is the type of computer security vulnerability typically found in web applications XSS enables attackers to inject client-side script into web pages viewed by other users and that is is pretty accurate I'm pretty happy with that description one thing that I will point out though is is we say cross-site scripting all the time that's that's what it's called that's what it was called way back when but in

reality it's a bit of a misnomer because cross the term cross-site scripting kind of implies that something is going across from one site to another but that's not always the case in fact it's often not the case so I actually when I'm hear the term cross-site scripting I'm thinking browser script injection that's the way I perceive this particular type of vulnerability because what we're trying to do is we're injecting some kind of a script into the browser page and it's going to run for whatever whoever the the victim is so what kind of script are we going to put in there probably JavaScript that's that's the most common type of script that we can inject vbscript will also

work on internet explorer though so there are cases where a particular defensive filter mechanism may be filtering out JavaScript payload but an equivalent vbscript payload might work so it's just something to keep in mind especially if you're on the defense well I guess if you're on the defensive side you want to be aware of this but if you're also if you're if you're doing a penetration test at some point don't forget about that one there are a lot of companies that standardized still an Internet Explorer so if that's your target you can make use of vbscript so for browser script injection or cross-site scripting to work we really need two components to it first of all

we need the right context it has to you have to be able to inject the script into some location on the page where where it's actually interpreted as a script as something executable and the second component of course is we need actual execution it's possible to get script onto a page that's in a supposedly executable context yet if it happens you know after the page is processed or you know through if you end up with certain other like just the order of things that happen you might not actually have execution of that script and I've actually found that in a lot of cases like sometimes you'll have JavaScript libraries that are loading other libraries that are loading other

libraries and you have this ripple effect and it just depends on the order of how things are loaded and where they come in as to whether or not you might actually have execution of your injection for awesome point is if you're doing this as a penetration test you need to be able to come up with a proof of concept something that actually shows that the injection is in a an executable location and that it's executed so how does it work I'll go over the absolute basics here this will just take a couple of moments so and I noticed the website here chaha if you're if you're in Charlotte and you're interested in hacking stuff go to the chaha or

Charlotte hackers website because we on a monthly basis we get together and Dave mentioned this earlier we talked about hacking things and and have a bit of a social hour as well so it's pretty cool but we have okay so you have a page there's a parameter on there this one's name equals Bob okay it gets passed in and in the response of course Bob comes back and shows up on the page so when you have cross-site scripting this again is the most simplest of examples we are able to add javascript onto that parameter and then that javascript gets inserted on the page and so it comes back and what happens of course is in this case here

we have an alert pop-up box comes up with the number one in it I use often will use it so this is basically a litmus test this says can can we get injection that's actually executing and although a pop-up box is really not that big a deal by itself the reality is of course if you can get a pop-up box you can do anything else you can do with JavaScript so if you are in a position where you have to convince an executive or a mentor senior manager that this pop-up box is dangerous enough that we gotta go fix that flaw you know you might want to look at doing something other than pop-up boxes and I'll get to

some examples later on but it's really hopefully comes down to a conditioning that when they see this alert pop-up box they recognize okay this is bad even though when Papa box itself isn't you'll also notice that I used just one by itself I didn't put a string quote in there sometimes you'll see quotes XSS I'll often when I'm doing a test just do the number one by itself because it's not a string I don't have to worry about whether or not the quotes are filtered so that's why I did it that way so JavaScript brief history I won't spend all day on this but basically JavaScript's been around for about 20 years just about as long as the web

almost so it's been around for a long time the other date on this particular slide that's important is to know it is is the one at the bottom 2005 so that's when that term Ajax was coined so everyone's heard about Ajax this is your dynamic xml over a dynamic JavaScript and XML so basically this is we have a page we have some piece of JavaScript on that page is going to make a call out to somewhere else and and pull information in and then dynamically update part of the page instead of the whole thing right supposed to make everything faster and flashy r and more dynamic the reality there though I'll point out and I don't

have the exact date where it was first used but web remoting was around before the term Ajax was actually coined so this thing that we call html5 where the web's all dynamic has actually been around or parts of it have been around for much much longer pretty much as long as we've been using using javascript which is you know a very long time so there's a lot of vulnerabilities floating out there that we still haven't found so what's a good for what can we do with javascript and I need JavaScript developers in the room probably know better than idea got a couple so you can do a lot of stuff with with JavaScript here's just a few examples you basically

you can manipulate the page itself you can read headers and cookies which is kind of cool especially if the session cookie or something else that has some sensitive information in there you can do some level of key logging as well some you have some level of control over the the media devices that are attached to your laptop leave the camera you can do some some streaming you can take some screenshots you can have a certain degree of access over the the microphone speakers so you know there's there's a bunch of things that we can do with it so now if you've been listening so far and this is not really familiar to you then you might the paranoia might be

setting in a little bit you know this is you can do a lot of things with cross-site scripting and it seems to be all over the place it's been around for a long time why isn't the entire internet compromised by cross-site scripting flaws and the reason why it isn't primarily is this thing called same-origin policy ok so the same origin policy before i get into the policy itself let's define what we mean by an origin same origin policy is considers an origin to be the combination of your protocol your host in your pork so if any of those are different any component of the origin is different then you're talking about a different origin which means for example

in this case here we have chaha on port 8080 if you also have Alice HTTPS version running on I don't know important we just say port 443 then that's a completely different origin even though it's the same host so what the policy does it's a browser enforce security feature so the browser's all have this built-in on how they do things and it basically makes sure that it's that's running in the document on one page if meant from origin any document from a different so that's where you still get your dynamic HTML and everything working there but it can't in general go out and fetch content from somewhere else and see it and interact with it and get cookies from and all of

that if it could then the whole internet would probably be compromised by cross-site scripting so in general this is a pretty good control except once in a while we have other problems that crop up here's a this happened this year that Internet Explorer had something that was was pitched as a universal cross-site scripting flaw which wasn't actually a universal cross-site scripting flaw at all what it was was the same origin policy bypass so this policies in place is supposed to protect us from scripts being able to just run anywhere and in access documents anywhere and Internet Explorer the latest version at the time when it was announced was vulnerable to the same origin policy bypass

and I played around with this the the they had a proof of concept out there for this thing and in the proof of concept you had to I think you had to click on a couple of different things so it made it look like it really wasn't that big a deal because you'd probably noticed pop ups and he have to click here but I actually tinkered with it a bit more and was able to get a working proof of concept that required no user interaction at all for the same origin bypass which means anybody who would be attacked by this running a vulnerable version of internet explorer be able to essentially pull their session cookies

so I'll use that as a probably one of the more critical examples from any other website they visited in the same browser so some cool stuff there and no I didn't publish that it's not something I really want running around rampant on the internet for script kiddies to get ahold of so there are some exceptions to the same origin policy the first one is built into HTML itself there are certain things that don't use the same origin policy for example the script tag when it loads a source you can load scripts from other other resources it doesn't have to be the same origin and those scripts will still run I mean that's how we get if you look at for example jquery

libraries and other other things like that they're often hosted somewhere else and we just bring them into the pages and there's nothing special you have to do for that because that's that's a built-in to h2 in HTML itself where it doesn't make use of the same origin policy the other one is something called the course cross-origin resource sharing and this is an area that I found that's a little fuzzy to some people is it anybody here not really sure what it is you know I've seen a few hands go up so basically let me go on to the next slide and I'll explain what it is so the course or cross-origin resource sharing is another type of policy it's sort of

an override to the same origin policy but just with respect to JavaScript calls so when you're doing your ears sort of ate your Ajax type stuff so it's what makes html5 mashup type code actually work it gets us away from having to load content into iframes so you can actually get content from somewhere else onto your page as long as it conforms to the coors policy so the policy itself is it's defined on a server and that would be the server hosting the content that you want to pull on to your site and it's it's the browser that actually enforces it so if you look at the speck for this and I don't have a spec number here but the

there there is no requirement at all for the server to actually obey its own policy so if if a if a browser makes a request for some content and it it's actually outside of the policy that requests it still may actually return that content it's up to the browser to then put that the code into its exception block instead of the success block and I've actually played around with that and that's exactly what happens in some cases I would imagine each server is probably treated differently there might be some that that obey their own policies but so far I haven't had much luck with that so a little illustration of how this this actually works if we have two sites so

we have foo that's the site that you're visiting and then we have this other site bar that has the chorus policy on it what's going to happen is when you make that xmlhttprequest object inside of javascript it and when you when you make the request with that is the browser is going to add that origin header onto the onto it you can go ahead and look inside your intercepting proxy and you'll see that just it's not something you have control over the header just goes there when the the server any server that supports kors sees that header it will reply with its policy whatever is defined on there and so we have down in that the bottom

right-hand corner there you can see some example headers the the one at the top is the most common one that will see access control allow origin okay if you're if you're using scanning tools i'll use burp because that's the tool that I use a lot and it actually has a finding that pops up sometimes where the access control allow origin is star and it calls that OS as an issue the the reality is at least in I experimented with several browsers that's not an issue because the the the third header on there the one at the bottom access control allow credentials if that's set that means that a request can be made for content where the session cookies

will also be sent well any cookies will be set sent that's what that means allow credentials what they mean is allow cookies so in that case we're making our XML HTTP requests to a different origin and as long as the origin is in that list the access control allow origin list the if the access control allow credentials is also set to true then what will happen is you can the food the requests that was put together on foo is going to actually have the browser will send cookies to bar in that case as well except if the origin is star so they were a little smart on how they implemented that if you say that the

access control allow origin a star then the allow credentials gets disregarded so that's actually not as big an issue what is a bigger issue is cases where you have a site that's pulling content from somewhere and and if that site has basically what happens is is any vulnerabilities on foo become vulnerabilities of bar as well because you basically extended the the origin of bar through its course policy it makes sense I'll have a little bit more on that in a second so going back to cross-site scripting and our pop-up boxes if you're interested in trying to figure out okay well what are some other options I know I had a list up there earlier as has anyone ever even heard of

beef the browser exploitation framework if you haven't heard of beef or played around with beef then I recommend that you do it's especially for getting into cross-site scripting if you're doing like awareness training for fishing in your company that's it's also something that you want to play around with they're basically it what it does is it creates zombies that's what that funny yellow sign there that's actually supposed to be a zombie caution sign that's what i was told anyway so it it creates zombie browsers and then you can you can basically send commands to them it kind of like a command-and-control sort of thing and that's available on you'll find that on Cali and Samurai web

testing framework and other places or you can just install it it's it's got some pretty cool functionality I'm not going to go through all that hero take a while I want to move on to a couple of other things so redirects and forwards so so far all I've talked about is cross-site scripting but there are other vulnerabilities that we can find in browser code one of them is as unvalidated redirects and forwards so redirects and forwards by themselves that's a normal part of how the web works we're always forwarding pages to other pages really common one to see and all use this as an example a moment is you go to a website and you get

redirected to the login page okay it automatically is trying to help you out it's not going to make you click on another link if it doesn't have to just say okay well you're not logged in i'm going to redirect you to the login page and in addition to that will redirect you to the login page i will also let's just look at the example here i will also keep track of the URL that you first click done so that once you've logged in i can bring you back to where you were trying to go in the first place right so that's basically what we're doing there with it with a redirect now when we have so that's normal this is we

see this all all over the place this is not a vulnerability by itself what is a vulnerability is unvalidated redirects and forwards so in this case here we're passing in a URL that's not actually part of the site it's to somewhere dangerous and evil and and what's going to happen of course is the user will get if they click on this link they'll get the login box they'll log in and then they'll end up over at evil hacks or dot org and trying to think of the tax scenarios where where this is particularly bad and I'll pick on the login form because that's my favorite place to find this we have something that I call the evil twin login so what

we can do is take the original login page and replicate it somewhere else somewhere that we control and the user experience in this case is first they're going to get the they'll click on something they'll see the log in the log in and then they'll see the log in again it's like okay well maybe I typed it wrong or something right so they'll retype in their username and password and then they'll go back to wherever it is they were supposed to go in the first place what's happened of course underneath the covers is that second time they've logged in their URL changed so now they're actually sitting on evil hacker org and logged in with their

credentials and gave them to me great place to find this sort of thing is on single sign-on solutions okay you probably won't find that too much on the big enterprise solutions that are sold out there now but but you know sometimes we find single sign-on solutions that are homegrown and users are accustomed to logging in on a fairly regular basis the same screen pops up all the time so if you can make use of that during a pen test it's one way to gather credentials pretty quickly you can combine the unvalidated redirects with cross-site scripting attacks or if you can then things might get a little more interesting you have potentially more convincing fishing links so you can you

can bring them to a server that they that's part of their organization first and use the redirect flow net to get them on to some other server that has a cross-site scripting flaw so they'll see the link that they trust and they'll click it you may also be able to make use of this to help facilitate running across a scripting payload inside of the authenticated space and that that really goes to you know can can you add it on to that login URL so that the person logs in and then they activate the cross-site scripting flaw afterwards all right so redirects and forwards the next one the last one that we're going to talk about is cross-site request forgery

csrf sometimes you'll see it excess RF basically this is a type of vulnerability that's its I think become there's a lot more awareness around it now I'm seeing in my pen test a lot of people will have controls for it built in to prevent it which is good to see but basically this has been around for a long time cross-site request forgery has been around as long as browsers have basically had tabs so it takes advantage of the fact that your browser is keeping track of multiple sessions at the same time

okay so a cross-site request is a very normal part of the way the web works we do this sort of thing all the time right we have cases where we have content that's being put into an iframe or we have script tags or images these are all things where there's a request that goes out to some other site or can go out to another site and pull content into your page and that's it's set up that way so naturally we want to look at as you know hackers we want to look at what we can do to take advantage of what's normal and see if we can do something a little less normal with it so the forgery

really begins with the sessions with the cookies okay so what we need and specifically I guess what we're really talking about here is is not the fact that there's cookies but the fact that the cookies our session cookies are often protecting functionality that's sensitive in nature so that could be your email it could be banking maybe healthcare records or you know a lot of the other stuff that's that's on the web anything that you log into the second component that we have need for cross-site request forgery to work is predictability and what I mean by that is we're trying to run a function and are the parameters for that function something that an attacker can guess

because in general unless it's combined with with another vulnerability your cross site scripting is our your sorry your cross-site request forgery is not going to result in the attack or actually seeing the results of the requests that are forged that request is made from the victim's browser and it goes out to another tab so an example might be let's say I'm browsing the state let's say have logged in to my online banking account wherever it is and and then I've left that tab and I'm doing something else right we all multitask we got I don't know about you guys sometimes I have 20 or 30 browser tabs open at the same time which is really bad practice makes

you kind of open to this sort of thing a little bit more but we all do it and so I go to another one I go to a site that's been compromised and inside that site the an attacker has put together a a vector where they have let's say it's an iframe call or an image call back to a function on my online banking so it's maybe it's a post or a get that transfers funds over to their account what's going to happen of course is the browser's going to see that call it's going to say okay well it's coming from you you're already logged in i'm going to go ahead and send any cookies that

belong to to that origin that i'm sending them to and and basically it gets processed behind-the-scenes the victim never sees the response their browser does but we can craft it so that they don't and as far as the browser is concerned it's a normal function it was supposed to be that way some key points about cross-site request forgery it you don't need any scripting at all to do across at request forgery attack I already said you can just put that inside of a source tag for like an iframe or an image so there's there's ways to construct cross-site request forgery with no scripting at all it also is not subject to the same origin policy

because we can make use of this those mechanisms that I just mentioned that I previously said these things are not part of the same origin policy same origin policy does not apply so now there are situations where you might have cross-site scripting and cross-site request forgery combined together and that's those can be a lot of fun so really useful when you have the cross-site scripting and the cross-site request forgery on the same within the same origin if you think about it if you can inject a script and you have predictable sensitive functionality on there then you can even bypass most cross-site request forgery controls so something that previously might have been considered not vulnerable all of a

sudden becomes vulnerable because if I can run a script on there that means I can make one call get let's say there is protected by a random token I can make a call get the random token resubmit that random token with with the sensitive function data and lo and behold I'm able to execute that function from within my cross-site scripting payload the other place where cross-site scripting and cross-site request forgery combined are pretty cool is when you have a chorus policy set up so I mentioned this before if if I have a course policy on a server that allows certain other servers to connect to it then vulnerabilities cross-site scripting vulnerabilities on those other servers basically become my

problem as well so be very careful really the takeaway from that is be very careful with with your chorus policies don't don't accept origins that you can't trust right so another thing i mentioned beef before go back to beef and take a look at the the list of exploits on there and you'll probably notice i put red boxes around several of them here and this is just a partial list cross-site request forgery shows up a lot it's just it's a very common vector very common for if you can execute cross-site scripting flaws to make use of that to get elevated privileges or create a new account new admin account or something like that you see a lot of these on devices on your

routers and it's basically just make taking advantage of these weaknesses together in a in a web interface so and I have one last little bit here one last combination we have cross-site request forgery along with an unvalidated redirect so cross-site request forgery i mentioned that's when you have multiple tabs open remember i always said i had to log into my online banking first and then if i then went to across that request for a page with a cross-site request forgery flaw in it it would be executed against that and send the cookies and activate the function so what a unvalidated redirect allows you to do is and again i'm picking on the login one is if you have the debt again

on a part of a login functionality which is extremely common to have it then we're in a situation where we can ensure that the user actually logs in they authenticate first we can we can send them a fishing link they authenticate then the crossing request forgery flaw gets activated we transfer funds to ourselves and and then the victim is is unaware of anything that happened because they get redirected back to where they're supposed to be afterwards so from their perspective all they really see is it kind of flickered somewhere and then i came back to where i was supposed to be anyway so it's probably no big deal so it makes sense so there are some

different ways you can combine things I actually put together this little sort of cheat sheet summarize everything that we talked about today I can make this available afterwards if anyone wants it and that's basically that's all I have so one thing I you know just like Dave I do have some giveaways here so I don't know if we have do you guys have questions let's do let's ask the questions for the giveaways first and then I'll come back and yes yep I guess I'm not understanding so basically the server it was so I'm not sure exactly where the flaw was in this case for IMDb but yes okay yeah so it could be a compromise library or it

could be a flaw in how the how the website itself is designed so what we where we often run into this is store cross-site scripting where it's maybe a comment field or something along those lines that seems like that might be the case for the IMDb so if if there's somewhere in there where and I'm just I have no idea if this is where the flaw was I'm just guessing but but let's say I was able to comment on a particular movie and or an actor or something like that it then if I could actually put script tags into that comment and those script tags get executed to everyone else who views my comment and what

happens is if I haven't it's not like I've compromised the server itself I've compromised the content on the website on that specific page right and so then it becomes a problem because everybody who visits that now they have my malicious code running inside their browser so you

oh so how do you so question I think is is a how do you determine if if the if a cross-site route you know you're talking about the redirects

is there any way to identify whether or not it's a legitimate login really the only thing is the browser itself so what what we usually do is we'll recommend if you're implementing it's a flaw in the implementation of the single sign-on so really the fix is to fix that flaw and then people don't have to worry about it but as an individual running across this if you're logging into something just check the URL bar make sure that you're actually logging into what you think you're logging into because it's really easy for me to take the HTML content off of any login page and replicate that on my own server right I just kind of an

exercise and copy paste so cross-site request forgery that one that one can't be the user usually is a completely unaware so there's there's not anything that you can do as a individual to protect against that it's up to the organization and the onus usually falls on on the organization that's hosting that to ensure that that they don't have open cross-site request forgery flaws on there because that's going to impact them financially most likely or from a reputational standpoint to have something like that on there

yeah so if you're looking at ways to protect against it go to again I mentioned at the beginning a loss so if you go to the olas website and look up cross-site request forgery defenses or or controls they have a pretty good description on there on the types of things that you can put in place to prevent that in your own code it's it's relatively easy fix for most people which is basically you have a token inside of inside of your form that's random in nature and then you check that token once once a form has been submitted to make sure that it matches what was in the in the hidden field and the reason is because we've gotten way

remember I said predictability is is key to making cross-site request forgery work so all you need to do is make something that's not predictable to an attacker and and you have a control in place that will mitigate most cross-site request forgery attacks anything else all right i'll be in and around all day so if you have any other questions about web stuff or anything else or homebrewing even let me know let's do our giveaways