Making your website vulnerable for fun and security awareness

thank you so much Kenny for am i we really appreciate it and thank you for giving this talk today get a onsen yeah hmm let's see okay what happened now

okay let's hope it works now okay you see we have a backup I don't know if it was some type of gauge okay I'll pretend you're not there okay so my name is Kenny Johnson I'm going to speak about a topic that concerns making your website vulnerable for fun and security awareness so Who am I I'm a security manager in story Brant I help developers see offensive and defensive security so story Brown is our large largest pension fund in the Nordics it has services in pension insurance as in management and banking we have digital services supporting our business and roughly seventy in the house developers so cyber security is very high on our agenda so

today's talk about will be what if you could understand the consequence of vulnerability in your web application before it's being introduced so here we have alert boxes this is Carrie writes many developers have probably seen those in pen test reports and the thing is the developers seeing this might not have that reaction when they see that alert box and the possible consequence and etc because we have a course CSP and we have HTTP only insecure flags and we have many measures that should protect us from those and the consequences right so the risk should be low especially when there's reflects that XSS has the prerequisites that they use most click a link first but we do know that users do

click links and most web app hackers know that securing the cookie isn't really enough but but it turns out that the developers I usually work with believe that it fully protects the session if you can secure the cookie and have course CSP etc so what I've seen is if you give developers insight about how you can say from an offensive perspective then the consequence of XSS becomes much clearer so what are some ways of giving developers insides we have B whup web code vulnerable there are ones in store Brown we have conducted regular CTF events to have developers see vulnerabilities from an offensive perspective we have used online CTF services for this purpose and but the thing is if you use a

one-size-fits-all approach to try to understand the vulnerability you might not understand what it means in context of the business so last year we took this a little bit further since XSS attacks are amongst the most common these days we thought it was time to show that developers I just thought injures these exercises can be and we wanted to show it in terms of store brands business so we crane create the front and clone this is story branded I know and this is the clone they look pretty identical they are we used HDD T tracks used clone this website very simple and then we created a burnable PHP background that we linked those were nobility's to then for

showcasing the challenges we used C T FD which by the way is a really great tool for arranged in CTF so we had challenges ranging from XX e to file that was containing flags in brute force and other attacks so here was our final challenge it's involved exploiting this Sh output here which had access to some sensitive information so if you wanted to exploit this you would have to submit a very long script in the shout puts URL here to trick - output to send this information back to the attacker the results was that we had 5 out of 11 participant that managed to get last flag and we got feedback there's this was a really great way of showing how

the consequence of an exercise in an application and it really showed that the cookie doesn't protect the session as well as previously considered so but another thing with this way was that the website contained very many false positives and since it contained the false positives it was difficult to maybe know when it was a vulnerability when it wasn't etc so we thought about how we could for the next time create this in a way that you have your CTF on your real website so I did some research on this and whatever told you that I found a way you can achieve this you can use a proxy where with a Python script so if the contender would surf the web

site through a proxy and then the Python script changes everything on the on the fly you can actually achieve this thing with having vulnerabilities on your website without actually having a vulnerability there it's just the proxy in the front that makes it look like you have a vulnerability there so here is an example here is how you can rewrite a Java screen with medium proxy and the scripts so what we used here as an example is you see there the story browned chatbots has a URL after running it through that script that URL becomes that and since the browser in the java scripts dictates how the browser should behave then now everything will just go through our

vulnerable back-end which which would contain vulnerabilities but note this can be done on any web site here we have an example on how you can do this on bing so if you search for my search string on bing.com you would with this script be able to insert an XSS by use replacing what was around my search string so by doing that you could create an XSS on being calm this particular one here is within a C data tag so if you wanted this on being not calm you would have had to you would have to close that C dot attack first so let me just demonstrate here yeah here we first have you type something on

being not calm it's no response this is a non burnable setup it doesn't go through the fruity browser nothing happens when you run alert now we have a second one this is set up to go through our proxy so now when you type script alert on here on bing now you will pop the alert box but we did have a whole talk about how it's very ineffective to pop alert boxes to get the point across so what if we want to provide some more insight well here's a demo that might give some more insight Bing has a search history page so you can search for something on bing not common and it will end up in profile slash

history you don't need to log in to have this you if used are on being a common search you will have a session and so how can this be used in a scenario where you show some more insight on what an XSS could be do on on being calm let me run this so here we have an attacker email client the attacker prepares an email he's gonna send this to the Cookie Monster he's gonna say he's being support he provides a link there he has a logger where everything when the Cookie Monster clicks on there it will be sent back so here we have the Cookie Monster's client he's on on Firefox he checks his email he he receives the

email you've been subjected to phishing click here now best regards Bing he clicks and let's see what happens he gets here there's some strange stuff he doesn't really understand what this means and let's see what attacker has gained from this

well here's the tacky awesome data he has actually received all the search history of the Cookie Monster the flag is there so this is an example how you would use this in our CDF event so how did we do this we want to steal from the following URL which is the history then we want to send this to the attackers logger which is set up on this link here so you send this XML HTTP requests script within the XSS and it will achieve your lot so this was our full link it's pretty complex but I mean when it's inside an email client it wouldn't look that complex it could have also been of course linked to another URL

which redirects to this link or whichever you could have used for example you could have loaded a script of course but if you load the script you subject to course CSP etc same a region so that wouldn't really work very well so let me show this demo once again now that we have some insight how it was done so you send the email to the Cookie Monster where from from being support containing this link has a logger to receive the what's being sent

the Cookie Monster looks at his email and he he's urged to click on a link because he's been subject to phishing he does that gets to this and by the way I mean he this could have displayed anything this this is just for demo purpose anything could have been viewed here but the the fact means the fact remains that by the user clicking on that link now the attacker got all his search history so let me end with a very boring slide here but with some key advantages of making our website vulnerable it's I believe it increases awareness of what risk a certain nobility could mean to your business its allows for a better understanding of the

impact of future vulnerabilities on your websites very understanding of your organization's defense mechanisms protects the users with CSP course HTS etc it's a better understanding all the users protects the how the browser protects the user on your website and it's a rather easy to setup a fun and good looking CTF tailored to your environment your business your data instead of running and I genuinely Eric web up where the gonna call is exploitation of vulnerabilities with little business context if done in a live environment who knows someone might find a real vulnerability so I think I ended on about 12 minutes I had some technical difficulties but I think we have some minutes for questions if

anyone would have one

have any questions ready to go home and hack your own websites let your employees get in there what did that the developers say from the from the feedback from the developers well the feedback from developers was there was a great way of showing how when abilities on your website I mean how the cookie doesn't protect the user session very well because it's it's such a common belief that you have all those measures on your website everything should be protected everything should be ok but then again if you do some more advanced exercise attacks it it may not all right thank you very much Kenny all right great talk Kenny could you just repeat what did you use to set up

the CTF and how hard was it to set up a CTF like that for you are you speaking about the first one now yeah all the one where we used where the clone was which was like the new research which is actually much easier both okay so the first one you used to use hdt track which is a tool to clone all front-end web application very easy here's type HD track and the website you want to clone and then you have that clone you put this into a docker image and we have this in the docker image you surf the web site and you basically look where would be it'd be a good place to

have to put in to put in vulnerability on this website so then you would just rewrite the JavaScript or whichever on the front end which will then put the browser into another direction and you of course would then have our response in the back end that would reply if you wanted to do this with a clone you would just use a Python script that does simply a match and replace for example and you can do this for XSS you can do it for SQL injection in case you actually have a back-end SQL the point here is to put the vulnerabilities on on a place whether but are the vulnerabilities a place where it would have typically been

because we as pen testers or from an offensive point of view usually see it from that way so that we can get the developers to from an offensive perspective see where the vulnerability would typically be and how it can be exploited etc yeah great thank you very much Kenny [Applause] all right