WEBVTT 00:00.000 --> 00:16.160 I have no idea what time this will be played, but thanks for coming to my virtual talk for this edition of DEF CON SAFE MODE, and I figured a great way to start it off, since this is technically my first DEF CON talk, would be to take a shot. 00:16.160 --> 00:20.800 So we've got some 1712 bourbon, so let's get it started. 00:20.800 --> 00:22.180 Don't fuck it up! 00:23.900 --> 00:31.480 So, other than that, this is normally where I try and get some crowd engagement in the talk. 00:31.760 --> 00:43.000 So, 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. 00:43.000 --> 00:55.680 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-site scripting, as well as sort of why it's more of a severe attack than you may initially realize. 00:57.140 --> 01:01.820 So, I realized that I need to move this webcam out of the way. 01:01.820 --> 01:03.400 Let's try the top right corner. 01:05.880 --> 01:07.760 So, I'm Ray Doyle. 01:07.760 --> 01:13.900 You can find me on Twitter, at DoylerSec, or my blog, Doyler.net. 01:13.900 --> 01:17.640 I'm currently a Senior Staff Adversarial Engineer at Avalara. 01:17.640 --> 01:20.760 We're a tax, software, and compliance company. 01:20.760 --> 01:25.060 We're always hiring, but not necessarily for security, so definitely reach out to me if you're looking for work. 01:25.660 --> 01:27.480 I love CTFs. 01:27.480 --> 01:34.820 I've actually been on two DEF CON Black Badge winning CTF teams, for the Wireless CTF, as well as the IoT CTF. 01:34.960 --> 01:46.960 I love them, if you want to talk CTFs, as well as being a member of Team Eversec, who actually runs some CTFs, mostly in North Carolina-based conferences, but a few other regional ones. 01:47.200 --> 01:50.900 So, definitely reach out to me about conferences or CTFs, things like that. 01:50.960 --> 01:53.400 And I also love collecting certifications. 01:53.400 --> 01:57.020 I got my OSCE last year, my OSCP a few years back. 01:57.140 --> 02:02.460 I'm always looking for new ideas for certs to take or training, so definitely let me know if you're aware of any. 02:04.380 --> 02:11.340 And also, if you couldn't tell from the Avalara orange on the slides and the last one, clearly it's our company color. 02:11.340 --> 02:13.140 I figured I might as well go with the theme. 02:13.940 --> 02:17.780 So, a few caveats before we get into this. 02:18.200 --> 02:31.240 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. 02:31.600 --> 02:40.840 This is going to be a very example-heavy and focused talk, so definitely feel free to go back over the slides, re-watch the videos. 02:40.840 --> 02:53.500 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, reach out to me on Twitter and I'll get you a copy sooner rather than later. 02:53.780 --> 02:56.600 It's definitely going to be a lot to digest. 02:57.520 --> 03:09.180 Like I said before, I don't participate in bug bounties, but some of these payloads should help you to demonstrate the severity of the vulnerabilities you find and maybe get them increased to a P1 or something like that. 03:10.160 --> 03:12.920 A lot of this information is going to be from my personal blog. 03:12.920 --> 03:22.360 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. 03:22.860 --> 03:30.920 I'm going to cover a ton of information, so please feel free to ask questions afterwards, before, or on Twitter at any point. 03:31.340 --> 03:41.480 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. 03:42.440 --> 03:54.020 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. 03:54.020 --> 03:55.580 We'll see how it goes. 03:57.260 --> 04:03.500 So, I know that this isn't live, but definitely feel free to use the weaponized XSS hashtag on Twitter. 04:03.500 --> 04:07.880 I'll definitely be checking it during the conference as well as any time afterwards. 04:08.120 --> 04:20.160 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. 04:21.140 --> 04:24.740 So, here's a quick introduction to cross-site scripting. 04:24.740 --> 04:26.500 This is from OWASP directly. 04:26.520 --> 04:45.340 I'm not going to just re-read 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. 04:45.580 --> 04:53.580 It's frequently used for loading malicious scripts and executing them on the target's client-side browser. 04:53.580 --> 05:01.640 So, these aren't going to be attacking your servers as much as the people who are connecting to your websites, things like that. 05:02.740 --> 05:07.640 So, the most basic example of going beyond Alert 1 is Alert 2. 05:07.920 --> 05:18.940 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. 05:19.000 --> 05:34.740 So, there may be systems that are alerting or filtering for very specific payloads, and something like Alert 2 could even bypass a deny list that was protecting against Alert 1, things like that. 05:34.740 --> 05:41.280 So, when you're working on these weaponized payloads, be sure to try different variations or different ways to get them into these systems. 05:42.660 --> 05:47.500 So, the first example I wanted to cover is loading external scripts. 05:47.500 --> 05:52.920 This is the most basic example, but it's fairly important to try and do. 05:52.920 --> 06:03.740 So, anywhere in which you were able to inject that script Alert 1, generally speaking, you could also load an external JavaScript file. 06:03.740 --> 06:07.520 So, in this case, I'm loading doiler.net slash evil.js. 06:07.600 --> 06:14.400 Now, what this allows you to do is have bigger payloads, not worry as much about things like encoding, stuff like that. 06:14.400 --> 06:22.920 So, if at all possible, you should definitely try and go with an external-based payload instead of keeping it inline if you're able to. 06:24.320 --> 06:31.000 So, another example of this is using staged cross-site scripting. 06:31.000 --> 06:37.720 So, if you find yourself injecting into an already existing script tag, you obviously cannot set the source of it. 06:37.720 --> 06:44.480 Or, if you find yourself in an HTML event handler, you aren't going to be able to load an external JavaScript file. 06:44.800 --> 07:01.600 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. 07:01.600 --> 07:05.320 So, for this quick example, it's bit.ly slash example. 07:06.160 --> 07:10.140 And this is a payload that was created by someone. 07:10.140 --> 07:12.260 I've included a link to the GitHub in the comments. 07:12.260 --> 07:13.260 Definitely check it out. 07:13.260 --> 07:18.280 It's come in really handy when I've been stuck in sort of an HTML event handler, especially. 07:18.560 --> 07:25.700 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. 07:28.600 --> 07:41.580 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. 07:41.940 --> 07:59.620 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.cookie from your local application to the attacker-controlled server. 07:59.620 --> 08:07.780 So, in this case, any cookies we had on our target web application would have been sent to doload.net through the HTML get parameters. 08:08.780 --> 08:14.420 Now, there are things that are going to protect against this, like HTTP-only cookies, things like that. 08:14.420 --> 08:25.440 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. 08:25.760 --> 08:27.380 So, definitely keep this one in mind. 08:27.380 --> 08:33.400 This is the one I've used most often in my career, and it's super simple and straightforward to do. 08:34.880 --> 08:46.900 So, another... a different way that XSS injection, or technically any injection, could be used is to rewrite the HTML of the page. 08:47.180 --> 08:59.560 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. 08:59.560 --> 09:07.560 What that means is you basically get to overwrite the content that your target sees for an entire website. 09:07.820 --> 09:28.820 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. 09:28.820 --> 09:30.680 Sorry about that, my video cut out. 09:30.680 --> 09:45.980 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 their session had become invalidated or they just hadn't logged in yet, they would enter in their credentials, 09:45.980 --> 09:56.020 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. 09:56.140 --> 10:06.260 So, using this cross-site scripting vulnerability, an attacker could be able to basically trick users into entering into HTML forms or really anything. 10:06.600 --> 10:10.680 So, in that same vein, we have cross-site scripting phishing. 10:10.740 --> 10:13.240 So, this will be an actual video demo. 10:13.700 --> 10:20.300 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. 10:21.320 --> 10:28.760 So, as we can see, there's a basic search.php web page that has a parameter called queue. 10:28.760 --> 10:32.700 So, if we enter test, for example, it's reflected back to the user. 10:32.700 --> 10:37.060 This indicates that there could potentially be reflected cross-site scripting in this page. 10:37.060 --> 10:42.840 So, as you can see, if we put alert1 as our query, it reflects it back to the user. 10:43.320 --> 10:52.960 So, in this case, what we could do is we could create a XSS payload that looks like an authentication pop-up. 10:53.000 --> 11:07.500 So, we're creating a new div that has a sort of a shaded background that has a pop-up window asking for their username and password and an error saying that there was an error and please log back in. 11:07.500 --> 11:11.220 So, if a user were to see this, they may think that their session is invalidated. 11:11.220 --> 11:12.900 Try and log back in. 11:12.900 --> 11:21.100 The creds would be sent to our attacker-controlled server, saved as creds.text, and then the user would be redirected to the page that they were expecting. 11:21.100 --> 11:25.240 In this case, search.php and queue equals test. 11:25.660 --> 11:32.740 So, we would send a link to a user like this with our malicious JavaScript payload as the query. 11:32.920 --> 11:40.400 And I actually need to clear this out because if you noticed briefly, the phishing page is only set to display once. 11:40.400 --> 11:52.220 So, if a user keeps clicking this link again and again, they won't be confused as to why the password authentication prompt keeps popping up again and again. 11:52.660 --> 12:00.280 So, if an attacker sent this external script to a user in the payload, they would be prompted with something like this. 12:00.300 --> 12:06.420 So, they may re-enter their username and password to try and get back into the system, get to the actual query that they wanted to see. 12:07.420 --> 12:09.960 Fairly long password, so they think they're secure. 12:09.960 --> 12:11.880 They're not going to say this password end. 12:11.880 --> 12:14.500 They're just redirected to your search queries test. 12:14.820 --> 12:20.900 But actually, on the attacker side, we see that... well, this is actually the actual server. 12:20.900 --> 12:22.720 So, a post was made to login.php. 12:22.720 --> 12:31.080 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. 12:31.140 --> 12:40.300 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. 12:44.770 --> 12:54.590 Another less common but still usually used for stuff like hacktivism or things like that is cross-site scripting defacement. 12:54.590 --> 13:02.150 This is very similar to the HTML injection, only the JavaScript file in question I mentioned here is Stallone.js. 13:02.290 --> 13:14.210 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. 13:14.590 --> 13:24.110 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. 13:24.830 --> 13:27.010 Now, it doesn't have to be this Stallone.js. 13:27.430 --> 13:32.510 If you find a cross-site scripting vulnerability, you can deface a website to be whatever you want. 13:33.050 --> 13:40.490 So, you can rewrite CNN to show your own news instead of the news you expect to read. 13:40.490 --> 13:41.370 Things like that. 13:41.370 --> 13:49.130 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. 13:51.070 --> 13:53.990 So, here's the actual code from that Stallone.js. 13:53.990 --> 13:55.650 I know that this is a lot. 13:55.710 --> 14:00.490 I've also included a link to that .js file and you can google it and find it fairly easily. 14:00.590 --> 14:13.290 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. 14:14.990 --> 14:18.510 So, like I said, back to the history lesson. 14:18.510 --> 14:33.390 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. 14:33.650 --> 14:44.930 Well, unfortunately, on Amazon.com, they were vulnerable to a stored cross-site scripting via book previews. 14:44.930 --> 14:51.610 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. 14:51.610 --> 15:05.150 But, if you're writing an XSS book and you manage 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. 15:05.250 --> 15:13.330 So, for a bit there, Amazon.com, and the example on the right is actually Maruta Sharapova's website that was also vulnerable. 15:13.450 --> 15:20.290 But, for a while, Amazon.com's preview of this book would just show the Stallone.js instead of the actual book preview. 15:22.350 --> 15:27.810 In addition to Amazon.com, note that this could have been used for things other than defacement. 15:27.810 --> 15:31.150 People could have tried to steal Amazon.com cookies. 15:31.310 --> 15:38.910 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. 15:38.910 --> 15:43.550 This had an example of a cookie stealing payload, alert-document.cookie. 15:43.710 --> 15:46.410 This also fired off on Amazon.com. 15:46.410 --> 15:51.510 As you can see, an Amazon cookie is being displayed just because a user is previewing the book. 15:51.510 --> 15:59.770 So, these attacks have occurred in the real world, and users could have been exploited by, technically, malicious book authors. 16:02.130 --> 16:25.600 So, not exactly cross-site scripting-based, but if an attacker is able to perform a man-in-the-middle attack, and 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 a disgusting title, which the first link is for, 16:25.600 --> 16:27.360 I highly recommend you checking it out. 16:27.620 --> 16:34.880 But not exactly XSS-related, but I wanted to cover it as it is a similar style of attack. 16:34.880 --> 16:44.780 So, if a man-in-the-middle attack occurs, a user could arbitrarily rewrite the HTML of a page that their target is viewing. 16:44.840 --> 16:52.900 So, in this case, this guy overwrote a target's Facebook.com with a picture of himself and a prompt that says, will you go out with me? 16:52.900 --> 16:57.560 That would not be bypassed until the target clicked yes or no. 16:57.680 --> 17:06.280 So, not exactly XSS-related, but you're still able to inject HTML or JavaScript into a page that the user is viewing. 17:07.800 --> 17:18.140 So, in that same vein, while this is more relevant with actual cross-site scripting and HTML injection, I wanted to cover a sort of a scarier, worst-case scenario. 17:18.320 --> 17:36.510 So, if you were able to inject HTML, either via 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-controlled server. 17:36.880 --> 17:46.000 Now, what this would do is, if it's loaded in IE, it would actually send a UNC request for that images-slash-file.jpg. 17:46.000 --> 17:57.080 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. 17:57.080 --> 18:10.300 So, an attacker could actually use this XSS or HTML injection to get a net-ntlmn hash for your local or domain user that's currently logged or into that system that the browser is running under. 18:10.480 --> 18:19.360 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. 18:19.560 --> 18:28.560 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. 18:31.370 --> 18:39.110 So, back to another video demo, here I want to cover an example of password stealing using cross-site scripting. 18:39.110 --> 18:43.890 So, not phishing like the last one, but actually stealing saved credentials within a browser. 18:45.450 --> 18:59.530 So, as you can see, we have a basic login page with a username, a password, and a login button, as well as a prompt at the bottom that says your current language. 18:59.890 --> 19:07.910 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. 19:07.950 --> 19:13.570 It doesn't change the language since I'm not that great of a developer, but it's just for demo purposes. 19:13.910 --> 19:18.770 So, as expected, it reflects the query parameter into the page. 19:18.770 --> 19:23.050 So, if we put alert 1, it shows that this page is vulnerable to cross-site scripting. 19:23.550 --> 19:27.190 So, let's say our admin user had actually logged into this application. 19:29.750 --> 19:33.110 They're going to save their password because they don't want to have to remember that pretty secure password. 19:33.110 --> 19:34.330 It takes a lot of work. 19:35.170 --> 19:38.130 So, when they log in, they're redirected to a comments page. 19:38.690 --> 19:41.790 And when they go back to the login page, their credentials are obviously saved. 19:41.970 --> 19:43.770 So , nice and convenient. 19:44.390 --> 19:47.290 Nothing too scary since we haven't phished their credentials. 19:47.850 --> 19:54.990 Instead , what we can do is we can create a second body tag, which this will still work in most browsers, but is not technically valid HTML. 19:55.750 --> 20:20.890 And in this second body tag, we will call the steel 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. 20:21.450 --> 20:32.390 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. 20:32.590 --> 20:38.290 Now, note that this payload does require cross-site scripting on the login page. 20:38.290 --> 20:45.470 It won't work if there was a cross-site scripting vulnerability, say, in that comments page. 20:45.470 --> 20:56.310 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. 20:57.330 --> 20:59.210 So, as we can see, nothing happened. 20:59.210 --> 21:00.390 Their credentials are still saved. 21:00.390 --> 21:01.770 User is none the wiser. 21:01.770 --> 21:10.050 But on our attacker-controlled server, we actually get a get request for the username, admin, and that same and b-size password. 21:10.310 --> 21:21.350 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. 21:21.870 --> 21:25.130 And we see an error that is not valid HTML, like I said. 21:25.250 --> 21:36.030 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. 21:40.150 --> 21:45.230 So, again, I know this is very demo and example heavy. 21:45.230 --> 21:49.630 Please feel free to reach out to me for these slides or go back over everything. 21:52.120 --> 22:05.580 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 keylogger is a cross-site scripting keylogger. 22:05.580 --> 22:10.520 So, the top picture shows our JavaScript payload. 22:10.520 --> 22:25.060 But what it does is every time any key is pressed, it creates a new event handler that will send an XML HTTP request to our attacker-controlled server with a post data of whatever key was pressed. 22:25.800 --> 22:37.180 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. 22:37.180 --> 22:46.280 So, every time a user hits a key on a page after loading this malicious JavaScript file, the attacker will get their keystrokes. 22:46.460 --> 22:54.340 So, in the bottom right, we see that they enter pentest as their name in the stored cross-site scripting vulnerability page. 22:54.380 --> 22:59.500 And in our data.txt on the attacker-controlled server, we got all of those keystrokes back. 23:00.200 --> 23:05.800 So, obviously on a login page, this would be great because you could grab their username and password without them having saved it. 23:05.800 --> 23:20.080 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. 23:23.680 --> 23:32.380 So, another thing that you could do with a cross-site scripting payload is steal sensitive information. 23:32.520 --> 23:45.240 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. 23:45.400 --> 24:03.860 So, 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. 24:03.860 --> 24:13.320 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. 24:13.440 --> 24:28.840 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 router, 24:28.840 --> 24:29.900 things like that. 24:29.900 --> 24:38.240 So, if there's sensitive information on an application that stealing would be valuable, this is another use for a cross -site scripting payload. 24:41.130 --> 24:51.030 So, a really fun cross-site scripting payload use that I have done personally quite a fair bit is defeating CSERV. 24:51.070 --> 24:55.070 So, if you're not familiar with what CSERV is, I'm just going to briefly cover it. 24:55.070 --> 24:57.610 It's cross-site request forgery. 24:57.630 --> 25:02.610 At its core, it's sending a request from Site A to Site B. 25:02.610 --> 25:19.550 So, a very common example would be if Amazon was vulnerable to CSERV, 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, 25:19.550 --> 25:20.650 for an example. 25:20.750 --> 25:27.010 Now, Amazon is not vulnerable to CSERV, so this attack isn't valid, but that's just a common example of it. 25:27.490 --> 25:40.570 Now, there are CSERV protections like tokens or nonces, things like that, that are an ideally unique value on every form that prevents an attacker from sending these malicious requests to a different server. 25:40.810 --> 25:54.090 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 CSERV token, and then use that to send your malicious CSERV request. 25:54.310 --> 26:02.690 So, a very simple read body looks for a CSERV token parameter, gets it, and returns it to a different method. 26:03.190 --> 26:16.750 So, this is an example 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 CSERV token and then actually exploit a stored cross-site scripting vulnerability. 26:17.950 --> 26:23.230 So, as you can see, we have a very similar login page to all those other examples I've shown. 26:23.450 --> 26:25.370 Not the most beautiful page. 26:25.430 --> 26:32.570 Our search page that reflects back the kube parameter, as well as on an authenticated comment section. 26:33.030 --> 26:40.250 So, we want to be able to put our stored cross-site scripting payload into that comment section as an authenticated user. 26:41.070 --> 26:46.730 So, when someone logs in under their admin account, they're able to see the comment section of the application, as you can see. 26:48.330 --> 26:57.170 So, the search.php is unauthenticated and vulnerable to a reflected cross-site scripting attack. 26:57.170 --> 26:59.990 So, as we can see, if we enter a test, it shows test again. 26:59.990 --> 27:09.510 If we test for cross-site scripting with alert1, we will get our pop-up and confirm that we have pre-authentication reflected cross-site scripting. 27:10.430 --> 27:15.850 So, what we can do is we can use a payload similar to this one. 27:15.850 --> 27:16.950 And I know it's quite long. 27:16.950 --> 27:20.070 I'm going to share it, as well as give a link to it. 27:20.070 --> 27:24.710 But what... or actually, no, sorry, this is the comment section that shows you have to be authenticated. 27:24.710 --> 27:34.950 And it uses a SHA-256 hash of the session, salted with the very secret password, to create a CSERF token for the comment section. 27:34.950 --> 27:37.790 So, our developer secured their application. 27:37.950 --> 27:41.190 The comment section is not vulnerable to cross-site request forgery. 27:41.190 --> 27:42.770 We should be good. 27:43.350 --> 27:56.490 Unfortunately, since we have that reflected cross-site scripting payload on the search page, we can use that to grab this very secure-looking value for that CSERF token. 27:57.110 --> 28:02.670 So, as we see, if we post test, test, it works fine since we're authenticated and we had the CSERF token. 28:05.240 --> 28:20.040 So, what we can do next is use the reflected cross-site scripting vulnerability to grab that CSERF token, use that CSERF token to send a POST request to the comment section, and then put error payload on that page. 28:23.970 --> 28:27.930 So, that top read body method looks just like the one I showed a few slides ago. 28:28.270 --> 28:36.210 Grabs that CSERF token from the body of our target page and returns it to a different method that we want to use it for. 28:39.390 --> 28:42.890 And I apologize if some of the audio is slightly off of these videos. 28:42.890 --> 28:47.590 As I said, I recorded these videos a while ago and was not able to keep the audio with them. 28:49.670 --> 28:58.390 So, once we get this CSERF token... well, first, we have to send... first, this payload will send a GET request for the comment section. 28:58.410 --> 29:07.170 So, the authenticated user will send back the comments page, then we'll grab the CSERF token, and then we will use that in our POST request. 29:25.860 --> 29:27.220 So, yeah, sorry about that. 29:27.220 --> 29:34.760 I did not quite plan the audio right on this one and the screen capture took a little too long, but I will share this code. 29:34.760 --> 29:40.120 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. 29:40.420 --> 29:45.160 But, once we have this CSERF token... I'm not able to skip, unfortunately. 29:53.020 --> 30:14.880 Okay, so, now that we're done looking over that exploit.js file, 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. 30:14.920 --> 30:28.220 So, if we refresh this comments.php page, we actually see a stored cross-site scripting payload of alert1 written by CSERFTest, which was what that payload does that I was showing before. 30:28.220 --> 30:33.100 So, if we quickly search for CSERFTest, as we see, their comment was scriptalert1. 30:33.120 --> 30:42.160 And now we upgraded from our slightly less severe reflected cross-site scripting payload to a more severe stored cross-site scripting payload. 30:43.240 --> 30:49.460 So, as you can see, it sent a POST request with the name of the comment and the CSERF token. 30:49.660 --> 30:55.080 Now, I just want to briefly touch on the difference between reflected and stored cross-site scripting. 30:55.340 --> 31:06.300 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. 31:06.580 --> 31:12.480 So, not quite as severe, requires some user interaction usually, stuff like that. 31:12.480 --> 31:15.960 Now, stored cross-site scripting is like what we saw in that comment section. 31:16.060 --> 31:23.580 So, our cross-site scripting payload will now execute on any user that goes to that comments.php page. 31:23.580 --> 31:25.600 So, it's more persistent. 31:25.600 --> 31:35.700 It targets more users, and it basically lasts for more than... and it requires zero user interaction outside of them visiting our vulnerable pages. 31:37.160 --> 31:38.300 So, 31:41.590 --> 31:50.410 in addition to generic payloads, you can also use cross-site scripting attacks for application-specific payloads. 31:50.550 --> 31:59.490 So, this one is a quick example of the damVulnerableWebApp using cross-site scripting to sign the guestbook under a different user. 31:59.490 --> 32:15.310 So, a similar idea to the Csurf 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. 32:15.470 --> 32:19.010 So, for instance, changing your wireless password. 32:19.010 --> 32:25.850 If an attacker found a cross-site scripting vulnerability in your router firmware, they can use that to change your WPA passphrase. 32:25.850 --> 32:27.030 Things like that. 32:29.570 --> 32:38.130 So, this is a great repository from HackLuke, but it contains a number of application-specific payloads. 32:38.130 --> 32:42.450 As you can see, there's a Drupal one, MyBulletinBoard, and a few for WordPress. 32:42.650 --> 33:00.950 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. 33:01.890 --> 33:14.870 And there's a great blog by TrustedSec about weaponizing XSS in this manner that goes through all the steps they would use to create the new user, grab any WordPress-specific things like that. 33:15.770 --> 33:22.590 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. 33:22.790 --> 33:30.950 While I personally love WordPress, it has been known to be vulnerable in the past, especially the plugins that people use. 33:30.950 --> 33:34.530 So, this is not an uncommon attack vector. 33:35.130 --> 33:53.370 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. 33:53.390 --> 34:09.150 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. 34:15.460 --> 34:25.980 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. 34:25.980 --> 34:33.080 This is a cross-site scripting framework of payloads and exploits. 34:33.640 --> 34:39.640 It's an open-source piece of software designed for penetration testers to exploit browser-based vulnerabilities. 34:40.360 --> 34:50.320 So, BEEF can be used to effectively have a botnet of browsers that you can control and monitor in the top left image. 34:50.320 --> 35:00.900 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. 35:01.020 --> 35:09.660 Any browser information, so the bottom left shows what is enabled, what's installed, any user agents, window sizes, things like that. 35:10.400 --> 35:20.420 So, effectively any HTML or JavaScript that could have been executed by this web browser could be executed by BEEF on the back end. 35:20.640 --> 35:29.600 Now, the most value I've found from BEEF is actually upgrading from a browser-based exploit to a system-level exploit. 35:29.600 --> 35:38.060 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 35:42.060 --> 35:48.400 a Metasploit payload and escalate to a reverse shell from that user, for example. 35:48.400 --> 35:56.620 So, here's a bunch of Firefox examples, but there's a ton in BEEF and it's great for escalating from cross-site scripting to command access. 35:58.100 --> 35:59.960 As I said, there's a ton of payloads. 35:59.960 --> 36:01.940 I'm not going to cover them all. 36:01.940 --> 36:03.640 Here's a few examples. 36:03.900 --> 36:15.040 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. 36:15.040 --> 36:22.700 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. 36:22.920 --> 36:24.140 Stuff like that. 36:24.400 --> 36:27.000 But as I said, a ton of awesome payloads. 36:27.000 --> 36:29.320 I highly recommend you at least check it out. 36:30.180 --> 36:44.200 It is going to be for if you find cross-site scripting during your penetration tests, things like that, to quickly exploit it as opposed to needing to weaponize it for bug bounties, things like that. 36:44.380 --> 36:52.860 That said, if you can load any external .js file, you could load a BEEF hook and get all of this quickly and easily. 36:54.540 --> 37:00.760 So, I briefly want to touch on blind cross-site scripting, mention what it is, and include a few references. 37:00.780 --> 37:06.200 It is easily a topic that could be at least one talk on its own. 37:06.220 --> 37:17.420 But at its core, blind cross-site scripting is the cross-site scripting JavaScript script payload executes somewhere that you cannot see it, hence the name blind. 37:17.420 --> 37:42.800 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, maybe an administrative panel has logs, a chat application that's different for the help desk technician than it is for the end user, 37:42.800 --> 37:50.500 firewall logs that you never get to see as an attacker but that execute malicious JavaScript payloads, things like that. 37:51.020 --> 38:00.140 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. 38:00.160 --> 38:04.540 I highly recommend checking out stuff like XSS Hunter or Sleepy Puppy from Netflix. 38:04.540 --> 38:10.200 These are really fun tools for finding blind cross-site scripting and especially for your bug bounty hunters. 38:10.200 --> 38:17.140 These are going to be vulnerabilities that aren't going to be found right away, especially by tools like Burp or things like that. 38:17.140 --> 38:29.100 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. 38:34.950 --> 38:40.730 So, now that I've covered a ton of different payloads, let's take a quick trip down memory lane for some