 I have no idea what time this will be played, but thanks for coming to my virtual talk for this edition of Defcon Safe Mode, and I figured a great way to start it off since this is technically my first Defcon talk would be to take a shot. So we've got some 1712 bourbon, so let's get it started. So other than that, this is normally where I try and get some crowd engagement in the talk. Whenever you're watching this, and I will hopefully be in the discord, at least during the talk, if not around the same time, let me know if you are aware of XSS or if you're not. Hopefully most of you are, with this being the red team village, but for those of you that aren't, hopefully you'll at least learn a little bit about cross-eyed scripting as well as sort of why it's more of a severe attack than you may initially realize. So I realized that I need to move this webcam out of the way. Let's try the top right corner. So I'm Ray Doyle. You can find me on Twitter at DoylerSec or my blog Doyler.net. I'm currently a senior staff adversarial engineer at Avalara. We're a tax software and compliance company. We're always hiring, but not necessarily for security, so definitely reach out to me if you're looking for work. I love CTFs. I've actually been on two DEFCON Black Badge winning CTF teams for the wireless CTF, as well as the IoT CTF. I love them if you want to talk CTFs, as well as being a member of Team Eversack, who actually runs some CTFs, mostly in North Carolina based conferences, but a few other regional ones. So definitely reach out to me about conferences or CTFs, things like that. And I also love collecting certifications. I got my OSCE last year, my OSCP a few years back. I'm always looking for new ideas for search to take or training, so definitely let me know if you're aware of any. And also, if you couldn't tell from the Avalara orange on the slides and the last one, clearly it's our company color. I figured I might as well go with the theme. So a few caveats before we get into this. I'm not an expert in cross-site scripting. I'm not a bug bounty hunter. I'm definitely not a JavaScript expert, but I am a penetration tester who has used cross-site scripting in the past. So hopefully I'll be able to at least teach you a few tricks. This is going to be a very example, heavy and focused talk. So definitely feel free to go back over the slides, rewatch the videos. I'm going to include a lot of links in the presenter slash comments section of each slide. So if I don't post them soon enough, please reach out to me on Twitter and I'll get you a copy sooner rather than later. It's definitely going to be a lot to digest. Like I said before, I don't participate in bug bounties, but some of these payloads should help you to sort of demonstrate the severity of the vulnerabilities you find and maybe get them increased to a P1 or something like that. A lot of this information is going to be from my personal blog. I've already used a lot of these exploits and payloads before, so I will include links to that to a little more in-depth post as well as some more screenshots and things like that. I'm going to cover a ton of information, so please feel free to ask questions afterwards before or on Twitter at any point. And I'm not going to cover really how to find cross-site scripting or what really protects against it. So this is really going to be heavily focused on exploiting it once you've found it. Also another caveat, this is obviously a COVID recording of a presentation that won't be given live, so any technical issues I apologize for, I'm going to do my best. We'll see how it goes. So I know that this isn't live, but definitely feel free to use the weaponized XSS hashtag on Twitter. I'll definitely be checking it during the conference as well as anytime afterwards. If you want to talk about my technical issues, if you want to share some really cool payloads with the community, really anything just to have some sort of viewer interaction during this weird virtual conference. So here's a quick introduction to cross-site scripting. This is from OWASP directly. I'm not going to just reread it back to you, but the gist of it is that cross-site scripting is an injection-based attack in which an attacker is able to inject usually JavaScript, but can also sort of cover HTML as well as CSS. It's frequently used for loading malicious scripts and executing them on the target's client-side browser. So these aren't going to be attacking your servers as much as the people who are connecting to your websites, things like that. So the most basic example of going beyond alert one is alert two. Now while this is fairly tongue-in-cheek, I do want to quickly point out the fact that there are going to be systems, and I may move this window from time to time, I apologize in advance. So there may be systems that are alerting or filtering for very specific payloads and something like alert two could even bypass a deny list that was protecting its alert one, things like that. So when you're working on these weaponized payloads, be sure to try different variations or different ways to get them into these systems. So the first example I wanted to cover is loading external scripts. This is the most basic example, but it's fairly important to try and do. So anywhere in which you were able to inject that script alert one, generally speaking, you could also load an external JavaScript file. So in this case, I'm loading doler.net slash evil.js. Now what this allows you to do is have bigger payloads, not worry as much about things like encoding, stuff like that. So if at all possible, you should definitely try and go with an external based payload instead of keeping it in line if you're able to. So another example of this is using staged cross site scripting. So if you find yourself injecting into an already existing script tag, you obviously cannot set the source of it. Or if you find yourself in an HTML event handler, you aren't going to be able to load an external JavaScript file. In this case, what you could do is have inline JavaScript that will create a new script element inside of the document, then set the source of that script element to be your external JavaScript payload. So for this quick example, it's bit.ly slash example. And this is a payload that was created by someone I've included a link to the GitHub in the comments. Definitely check it out. It's coming really handy when I've been stuck in sort of an HTML event handler, especially. If you are in an existing script tag, you could write longer JavaScript, but you may run across payload length limits, things of that nature. So the most common payload that you'll see or hear of when discussing or attacking using cross site scripting is going to be cookie stealing. So in this example, our XSS payload writes a new image tag to the document, only this image tag has a cookie parameter that sends the document dot cookie from your local application to the attacker controlled server. So in this case, any cookies we had on our target web application would have been set to doler.net through the HTML get parameters. Now there are things that are going to protect against this like HTTP only cookies, things like that. But if you are able to successfully grab one of these cookies, you could use it for session hijacking any existing sessions and basically logging in as that user to the application without knowing their credentials. So definitely keep this one in mind. This is the one I've used most often in my career. And it's super simple and straightforward to do. So another a different way that XSS injection or technically any injection could be used is to rewrite the HTML of the page. So the example on the left sort of shows this but it creates a new div that takes up 100% of the page puts it on top and allows you to write arbitrary HTML into that div. What that means is you basically get to overwrite the content that your target sees for an entire website. So that image on the right looks like a standard Drupal login page, but it's actually a cross-site scripting vulnerability that was found in a Drupal comments section. And an attacker used that post to rewrite the HTML of the page to make it look like an access denied or an authentication page. Sorry about that, my video cut out. But what I was saying was if a user were to visit this vulnerable post that contained this malicious HTML, they would receive this login page, think that they're essentially becoming validated or they just hadn't logged in yet. They would enter in their credentials and then these would be sent off to the attacker controlled host that this form was pointing to and then they'd be redirected to maybe the actual post or something like that. So using this cross-site scripting vulnerability, an attacker could be able to basically trick users into entering into HTML forms or really anything. So in that same vein, we have cross-site scripting phishing. So this will be an actual video demo. I am going to have to talk over it as this video does not have any audio, so hopefully I'll be able to keep track and let you know what's happening. So as we can see, there's a basic search.php web page that has a parameter called Q. So if we enter test, for example, it's reflected back to the user. This indicates that there could potentially be reflected cross-site scripting in this page. So as you can see, if we put alert one as our query, it reflects it back to the user. So in this case, what we could do is we could create a XSS payload that looks like an authentication pop-up. So we're creating a new div that has a sort of a shaded background that has a pop-up window asking for the username and password and an error saying that there was an error and please log back in. So if the user were to see this, they may think that their session isn't validated. Try and log back in. The creds would be sent to our attacker-controlled server saved as creds.txt and then the user would be redirected to the page that they were expecting, in this case search.php and Q equals test. So we would send a link to a user like this with our malicious JavaScript payload as the query. And I actually need to clear this out because if you notice briefly, the phishing page is only set to display once. So as if a user keeps clicking this link again and again, they won't be confused as to why the phishing, or the, well, and they don't know, but the password authentication prompt keeps popping up again and again. So if an attacker sent this external script to a user in the payload, they would be prompted with something like this. So they may re-enter in their username and password to try and get back into the system, get to the actual query that they wanted to see, a fairly long password. So they think they're secure. They're not going to say this password. And they're just redirected to your search query's test. But actually on the attacker side, we see that, well, this is actually the actual server. So a post was made to login.php. And if we check the attackers creds.txt, we see that the user admin logged in with super secret password 12345 and a bunch of symbols. So we actually were able to trick the user into typing in their credentials into a fake login page just because we found a reflected cross-site scripting vulnerability. Another less common but still usually used for stuff like hacktivism or things like that is cross-site scripting defacement. This is very similar to the HTML injection, only the JavaScript file in question I mentioned here is Stallone.js. This is a fairly old JavaScript file that actually replaces your website content with a picture of Sylvester Stallone that says you have been Stalloned. It's been used in a few different scenarios, but I'm actually going to cover a case where this happened in real websites, a couple of them. Now it doesn't have to be the Stallone.js. You could, if you find a cross-site scripting vulnerability, you can deface a website to be whatever you want. So you can rewrite CNN to show your own news instead of the news you expect to read, things like that. So anytime you would want to rewrite the content of a website, you are able to if you find one of these cross-site scripting vulnerabilities. So here's the actual code from that Stallone.js. I know that this is a lot. I've also included a link to that.js file and you can Google it and find it fairly easily. But as I said, it sets some text to this page has been hacked. It loads a picture of Sylvester Stallone and similar to that first payload I showed, it overwrites the content of the entire page with a giant div. So like I said, back to the history lesson. So there's actually a book called XSS attacks cross-site scripting exploits and defense that contained a reference to this Stallone.js file because it was talking about how cross-site scripting can be used to deface websites and things like that. Well unfortunately on amazon.com they were vulnerable to a stored cross-site scripting via book previews. So sort of a high barrier for entry for attackers as you would have to publish a book with a cross-site scripting payload in it. But if you're writing an XSS book and you managed to upload one of these malicious payloads, you were able to actually exploit cross-site scripting on any amazon.com user that viewed your book preview. So for a bit there amazon.com and the example on the right is actually Maria Show Sharapova's website that was also vulnerable. But for a while amazon.com's preview of this book would just show the Stallone.js instead of the actual book preview. In addition to amazon.com and note that this could have been used for things other than defacement. People could have tried to steal amazon.com cookies. So the picture on the left shows the web application hacker's handbook, a very common book for web pen testing payloads, things like that. This had an example of a cookie stealing payload alert document.cookie. This also fired off on amazon.com. As you can see an amazon cookie is being displayed just because a user is previewing the book. So these attacks have occurred in the real world and users could have been exploited by technically malicious book authors. So not exactly cross-site scripting based. But if an attacker is able to perform a man in the middle attack and these this slide is based on a black hat USA talk that was given a few years back with that man in the middle talk with the disgusting title which the first link is for. I highly recommend you checking it out. But not exactly XSS related but I wanted to cover it as it is a similar style of attack. So if a man in the middle attack occurs a user could arbitrary rewrite rewrite the HTML of a page that their target is viewing. So in this case this guy overwrote a targets facebook.com with a picture of himself and a prompt that says will you go out with me that would not be bypassed until the target clicked yes or no. So not exactly XSS related but you're still able to inject HTML or JavaScript into a page that the user is viewing. So in that same vein while this is more relevant with actual cross-site scripting HTML injection I wanted to cover a sort of a scarier worst case scenario. So if you were able to inject HTML either by a man in the middle or cross-site scripting into internet explorer now this is not edge this is only internet explorer you could inject a file URI to say an image to an attacker control server. Now what this would do is if it's loaded in IE it would actually send a UNC request to for that images slash file dot jpeg. Now for those of you that are familiar with responder this would actually send a net ntlm response to this attacker controlled server after it responded with a challenge. So an attacker could actually use this XSS or HTML injection to get an a net ntlmn hash for your local or domain user that's currently logged into that browser or into that system that the browser is running under. So just by finding this vulnerability an attacker could have credentials for either a local machine or your entire domain assuming that they're able to capture and crack these hashes. So while it's easier with a man in the middle attack it is still possible with something like a cross-site scripting attack and internet explorer. So back to another video demo here I want to cover an example of password stealing using cross-site scripting so not phishing like the last one but actually stealing saved credentials within a browser. So as you can see I could start the video we have a basic login page with the username a password and a login button as well as a prompt at the bottom that says your current language. So since our very well-developed web application supports multiple languages we can set our language to en or sp and it will display at the bottom. It doesn't change the language since I'm not that great of a developer but it's just for demo purposes. So as expected it reflects the query parameter into the page so if we put alert one it shows that this page is vulnerable to cross-site scripting. So let's say our admin user had actually logged into this application they're going to save their password because they don't want to have to remember that pretty secure password it takes a lot of work. So when they log in they're redirected to a comments page and when they go back to the login page their credentials are obviously saved. So nice and convenient nothing too scary since we haven't phished their credentials. Instead what we could do is we can create a second body tag which this will still work in most browsers but is not technically valid html and in the second body tag we will call the steal creds method that we write that will create a new form with the password or the username and password fields with the same id and name as the existing fields make it invisible and then set this username and password to be the values from the previously saved or entered username and password. Once it grabs those it sends them in a get request to our attacker controlled server and the user is none the wiser that just because they saved their credentials in a login page we were able to grab them. Now note that this payload does require cross-site scripting on the login page it won't work if there was a cross-site scripting vulnerability say in that comments page. So we convert this to URL encoding just to make our lives a bit easier and we send this to our target in the language parameter. So as we can see nothing happened their credentials are still saved user is none the wiser but on our attacker controlled server we actually get a get request for the username admin and that same and b-sides password and if we take a look at the html of this new page our original form is there as well as our second body tag with that steal creds method and we see an error and we see an error that is not valid html like I said but just because a user saved their credentials on a vulnerable login page we were actually able to steal them with this cross-site scripting payload. So again I know this is very demo and example heavy please feel free to reach out to me for these slides or go back over everything. So another example that is particularly useful on login pages that's where I've used it most myself but really anywhere that you might want a key logger is a cross-site scripting key logger. So the top picture shows our javascript payload but what it does is every time any key is pressed it creates a new event handler that will send an xmlhttp request to our attacker controlled server with a post data of whatever key was pressed and if we take a look at our keylog.php file in the bottom left corner we see that if there is post data it will open the file data.txt and append whatever was in that post data so every time a user hits a key on a page after loading this malicious javascript file the attacker will get their keystrokes. So in the bottom right we see that they enter pentest as their name in the cross-site scripting the stored cross-site scripting vulnerability page and in our data.txt on the attacker controlled server we got all of those keystrokes back. So obviously on a login page this would be great because you could grab their username and password without them having saved it but really anywhere where you might want to obtain a user's keystrokes so if they're entering credit card information even just stuff like addresses or other PII this would be a useful payload for a malicious attacker to use. So another thing that you could do with a cross-site scripting payload is steal sensitive information and again I know that there's a ton of code on this page but what this does is sends a post request to the attacker controlled server containing all of the source code from the application. So say you're on some say you find a cross-site scripting vulnerability in a sensitive page so maybe an administrative console, banking application, password manager or really any sort of private pages that you want to see someone else's content. You could use the code on the left to grab the source code or the example on the right to grab a screenshot of the page and you send that off to your attacker controlled server. So maybe you want to if you find a cross-site scripting vulnerability in your bank if you were to target someone with a payload you could maybe see their bank account number their balances things like that as well as maybe admin settings on a firewall or rather things like that. So if there's sensitive information on an application that stealing would be valuable this is another use for a cross-site scripting payload. So a really fun cross-site scripting payload use that I have done personally quite a fair bit is defeating CSERF. So if you're not familiar with CSERF is I'm just going to briefly cover it it's cross-site request forgery. At its core it's sending a request from site A to site B. So a very common example would be if Amazon was vulnerable to CSERF if a user visited my malicious website while they had an Amazon session still active my malicious website could send a request to Amazon that would make them purchase an item and ship it to me for an example. Now Amazon is not vulnerable to CSERF so this attack isn't valid but that's a just a common example of it. Now there are CSERF protections like tokens or nonsense things like that that are a ideally unique value on every form that prevents an attacker from sending these malicious requests to a different server. Now a cross-site scripting vulnerability since it can read the HTML of a page the payload could read the HTML of your page grab that CSERF token and then use that to send your malicious CSERF request. So a very simple read body looks for a CSERF token parameter gets it and returns it to a different method. So this is an example that I saw that I got to use in a real engagement in which there was a reflected cross-site scripting vulnerability that I used to grab a CSERF token and then actually exploit a stored cross-site scripting vulnerability. So as you can see we have a very similar login page to all those other examples I've shown, not the most beautiful page. Our search page that reflects back the Q parameter as well as on an authenticated comment section. So we want to be able to put our stored cross-site scripting payload into that comment section as an authenticated user. So when someone logs in under admin account they're able to see the comment section of the application as you can see. So the search.php is unauthenticated and vulnerable to a reflected cross-site scripting attack. So as we can see if we enter and test it shows test again. If we test for cross-site scripting with alert one we will get our pop-up and confirm that we have pre-authentication reflected cross-site scripting. So what we can do is we can use a payload similar to this one and I know it's quite long I'm going to share it as well as give a link to it but what or actually no sorry this is the comment section that shows you have to be authenticated and it uses a shot 256 hash of the session salted with the very secret password to create a C-surf token for the comment section. So our developers secure their application the comment section is not vulnerable to cross-site request forgery we should be good. Unfortunately since we have that reflected cross-site scripting payload on the comment on the search page we can use that to grab this very secure looking value for that C-surf token. So as we see if we post test it works fine since we're authenticated and we had the C-surf token. So what we can do next is use the reflected cross-site scripting vulnerability to grab that C-surf token use that C-surf token to send a coast request to the comment section and then put error payload on that page. So that top read body method looks just like the one I showed a few slides ago grabs that C-surf token from the body of our target page and returns it to a different method that we want to use it for and I apologize if some of the audience let the off of these videos as I said I recorded these videos a while ago and it was not able to keep the audio with them. So once we get this C-surf token well first we have to send first this payload will send a get request for the comment section so the authenticated user will send back the comment section comments page then we'll grab the C-surf token and then we will use that in our post request. So yeah sorry about that I did not quite plan the audio rate on this one and the screen capture took a little too long but I will share this code it is going to be a lot easier for me to share it than talking over it line by line as I originally planned to do but once we have the C-surf token okay so now that we're done looking over that exploit.js file well once we load that externally into this search.php page which is what I'm doing now the user will not see the requests in the background but we're actually able to post to the comment section as that user now so if we refresh this comment.php page we actually see a stored cross site scripted payload of alert one written by C-surf test which was what that payload does that I was showing before so if we quickly search for C-surf test as we see their comment was script alert one and now we upgraded from our slightly less severe reflected cross site scripting payload to a more severe stored cross site scripting payload so as you can see it sent a post request with the name the comment and the C-surf token now I just want to briefly touch on the difference between reflected and stored cross site scripting at its core reflected cross site scripting is usually going to require some sort of malicious link or something of that nature that you send to your specific targets and they're going to need to click it so not quite a severe requires some user interaction usually stuff like that now a stored cross site scripting is like what we saw in the comment section so our cross our cross site scripting payload will now execute on any user that goes to that comments.php page so it's more persistent it targets more users and it basically lasts for more than and requires zero user interaction outside of them visiting our vulnerable pages so in addition to generic payloads you can also use cross site scripting attacks for application specific payloads so this one is a quick example of the damn vulnerable web app using cross site scripting to sign the guest book under a different user so a similar idea to the C-surf cross site scripting example from a previous application but this can be done anything that a user could do within your application an attacker could do if they found a cross site scripting vulnerability so for instance changing your wireless password if an attacker found a cross site scripting vulnerability in your router firmware they can use that to change your WPA passphrase things like that so this is a great repository from hack luke but it contains a number of application specific payloads as you can see there's a Drupal one my bulletin board and a few for WordPress so if you are able to find cross site scripting in a WordPress post or a WordPress plugin you could do something like send a malicious cross site scripting payload to an administrative user and use that payload to add a new user into the WordPress application and there's a great blog by TrustedSec about weaponizing XSS in this manner that goes through all of the steps they would use to create the new user grab any WordPress specific nonsense things like that and the second link for those of you not familiar with WordPress is a list of all of the CVEs that have been found in the past while I personally love WordPress it has been known to be vulnerable in the past especially the plugins that people use so this is not an uncommon attack vector one thing I do want to note is if a user is able to exploit a cross site scripting vulnerability and create a new user if that user has high enough privileges they could then use that to privilege escalate even one more step to a system level shell because WordPress posts contain PHP if you want so they could write a PHP command shell use that to escalate to a system level shell and now they turned a potentially reflected cross site scripting vulnerability into a shell access on your web server so a very common framework when talking about cross site scripting and one that I at least wanted to touch on a little bit is beef the browser exploitation framework this is a cross site scripting framework of payloads and exploits designed it's an open source piece of software designed for penetration testers to exploit browser-based vulnerabilities so beef can be used to effectively have a botnet of browsers that you can control and monitor in the top left image you're able to execute any JavaScript on these client side devices so the middle image shows grabbing the IP of the host that you've hit with your exploit any browser information so the bottom left shows what is enabled what's installed any user agents window sizes things like that so effectively any html or javascript that could have been executed by this web browser could be executed by beef on the back end now the most value I've found from beef is actually upgrading from a browser based exploit to a system level exploit so there's over 500 metasploit modules so if a user is running an old or an out-of-date browser you could just use beef to exploit or yeah to use a to exploit a metasploit payload and escalate to a reverse shell from that user for example so here's a bunch of firefox examples but there's a a ton in beef and it's great for escalating from cross site scripting to command access as I said there's a ton of payloads I'm not going to cover them all here's a few examples note that anything beef can do you could also do with your own cross site scripting payloads if you wanted to be a little quieter or learn javascript or just get a more controlled feel for it that said it does make your life a lot easier as it's just a matter of right clicking the browser and then clicking on keylogger stuff like that but as I said a ton of awesome payloads I highly recommend you at least check it out um it is going to be more for if you find cross site scripting during your penetration test things like that to quickly exploit it as opposed to um needing to weaponize it for bug bounties things like that um that said if you can load any external.js file you could load a beef hook and get all of this quickly and easily so I briefly want to touch on blind cross site scripting mention what it is and include a few references it is easily a topic that could be it's at least one talk on its own but at its core blind cross site scripting is job the cross site scripting javascript payload executes somewhere that you cannot see it hence the name blind so for example if a login page was vulnerable to cross site scripting but only administrative users could see your payload or if it was on a web forum that you didn't have access to um maybe an administrative panel has logs um a chat application that's different for the help desk technician than it is for the end user um firewall logs that you never get to see as an attacker but that execute malicious javascript payloads things like that so testing for blind cross site scripting requires a bit more work as you are going to not be able to quickly test it easily and see the results in your browser um I highly recommend checking out stuff like xss hunter or sleepy puppy from netflix these are really fun tools for finding blind cross site scripting and especially for your bug bounty hunters these are going to be vulnerabilities that aren't going to be found right away especially by tools like burp or things like that so I highly recommend taking a look at blind xss learning what it is and trying to find it potentially during your engagements but especially during stuff like bug bounty hunting and things of that nature so now that I've covered a ton of different payloads let's take a quick trip down memory lane for some