1
00:00:00,000 --> 00: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.

2
00:00:16,160 --> 00:00:20,800
So we've got some 1712 bourbon, so let's get it started.

3
00:00:20,800 --> 00:00:22,180
Don't fuck it up!

4
00:00:23,900 --> 00:00:31,480
So, other than that, this is normally where I try and get some crowd engagement in the talk.

5
00:00:31,760 --> 00: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.

6
00:00:43,000 --> 00: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.

7
00:00:57,140 --> 00:01:01,820
So, I realized that I need to move this webcam out of the way.

8
00:01:01,820 --> 00:01:03,400
Let's try the top right corner.

9
00:01:05,880 --> 00:01:07,760
So, I'm Ray Doyle.

10
00:01:07,760 --> 00:01:13,900
You can find me on Twitter, at DoylerSec, or my blog, Doyler.net.

11
00:01:13,900 --> 00:01:17,640
I'm currently a Senior Staff Adversarial Engineer at Avalara.

12
00:01:17,640 --> 00:01:20,760
We're a tax, software, and compliance company.

13
00:01:20,760 --> 00:01:25,060
We're always hiring, but not necessarily for security, so definitely reach out to me if you're looking for work.

14
00:01:25,660 --> 00:01:27,480
I love CTFs.

15
00:01:27,480 --> 00: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.

16
00:01:34,960 --> 00: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.

17
00:01:47,200 --> 00:01:50,900
So, definitely reach out to me about conferences or CTFs, things like that.

18
00:01:50,960 --> 00:01:53,400
And I also love collecting certifications.

19
00:01:53,400 --> 00:01:57,020
I got my OSCE last year, my OSCP a few years back.

20
00:01:57,140 --> 00: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.

21
00:02:04,380 --> 00: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.

22
00:02:11,340 --> 00:02:13,140
I figured I might as well go with the theme.

23
00:02:13,940 --> 00:02:17,780
So, a few caveats before we get into this.

24
00:02:18,200 --> 00: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.

25
00:02:31,600 --> 00: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.

26
00:02:40,840 --> 00: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.

27
00:02:53,780 --> 00:02:56,600
It's definitely going to be a lot to digest.

28
00:02:57,520 --> 00: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.

29
00:03:10,160 --> 00:03:12,920
A lot of this information is going to be from my personal blog.

30
00:03:12,920 --> 00: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.

31
00:03:22,860 --> 00: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.

32
00:03:31,340 --> 00: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.

33
00:03:42,440 --> 00: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.

34
00:03:54,020 --> 00:03:55,580
We'll see how it goes.

35
00:03:57,260 --> 00:04:03,500
So, I know that this isn't live, but definitely feel free to use the weaponized XSS hashtag on Twitter.

36
00:04:03,500 --> 00:04:07,880
I'll definitely be checking it during the conference as well as any time afterwards.

37
00:04:08,120 --> 00: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.

38
00:04:21,140 --> 00:04:24,740
So, here's a quick introduction to cross-site scripting.

39
00:04:24,740 --> 00:04:26,500
This is from OWASP directly.

40
00:04:26,520 --> 00: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.

41
00:04:45,580 --> 00:04:53,580
It's frequently used for loading malicious scripts and executing them on the target's client-side browser.

42
00:04:53,580 --> 00: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.

43
00:05:02,740 --> 00:05:07,640
So, the most basic example of going beyond Alert 1 is Alert 2.

44
00:05:07,920 --> 00: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.

45
00:05:19,000 --> 00: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.

46
00:05:34,740 --> 00: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.

47
00:05:42,660 --> 00:05:47,500
So, the first example I wanted to cover is loading external scripts.

48
00:05:47,500 --> 00:05:52,920
This is the most basic example, but it's fairly important to try and do.

49
00:05:52,920 --> 00: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.

50
00:06:03,740 --> 00:06:07,520
So, in this case, I'm loading doiler.net slash evil.js.

51
00:06:07,600 --> 00: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.

52
00:06:14,400 --> 00: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.

53
00:06:24,320 --> 00:06:31,000
So, another example of this is using staged cross-site scripting.

54
00:06:31,000 --> 00:06:37,720
So, if you find yourself injecting into an already existing script tag, you obviously cannot set the source of it.

55
00:06:37,720 --> 00: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.

56
00:06:44,800 --> 00: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.

57
00:07:01,600 --> 00:07:05,320
So, for this quick example, it's bit.ly slash example.

58
00:07:06,160 --> 00:07:10,140
And this is a payload that was created by someone.

59
00:07:10,140 --> 00:07:12,260
I've included a link to the GitHub in the comments.

60
00:07:12,260 --> 00:07:13,260
Definitely check it out.

61
00:07:13,260 --> 00:07:18,280
It's come in really handy when I've been stuck in sort of an HTML event handler, especially.

62
00:07:18,560 --> 00: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.

63
00:07:28,600 --> 00: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.

64
00:07:41,940 --> 00: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.

65
00:07:59,620 --> 00: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.

66
00:08:08,780 --> 00:08:14,420
Now, there are things that are going to protect against this, like HTTP-only cookies, things like that.

67
00:08:14,420 --> 00: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.

68
00:08:25,760 --> 00:08:27,380
So, definitely keep this one in mind.

69
00:08:27,380 --> 00:08:33,400
This is the one I've used most often in my career, and it's super simple and straightforward to do.

70
00:08:34,880 --> 00: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.

71
00:08:47,180 --> 00: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.

72
00:08:59,560 --> 00:09:07,560
What that means is you basically get to overwrite the content that your target sees for an entire website.

73
00:09:07,820 --> 00: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.

74
00:09:28,820 --> 00:09:30,680
Sorry about that, my video cut out.

75
00:09:30,680 --> 00: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,

76
00:09:45,980 --> 00: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.

77
00:09:56,140 --> 00: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.

78
00:10:06,600 --> 00:10:10,680
So, in that same vein, we have cross-site scripting phishing.

79
00:10:10,740 --> 00:10:13,240
So, this will be an actual video demo.

80
00:10:13,700 --> 00: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.

81
00:10:21,320 --> 00:10:28,760
So, as we can see, there's a basic search.php web page that has a parameter called queue.

82
00:10:28,760 --> 00:10:32,700
So, if we enter test, for example, it's reflected back to the user.

83
00:10:32,700 --> 00:10:37,060
This indicates that there could potentially be reflected cross-site scripting in this page.

84
00:10:37,060 --> 00:10:42,840
So, as you can see, if we put alert1 as our query, it reflects it back to the user.

85
00:10:43,320 --> 00: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.

86
00:10:53,000 --> 00: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.

87
00:11:07,500 --> 00:11:11,220
So, if a user were to see this, they may think that their session is invalidated.

88
00:11:11,220 --> 00:11:12,900
Try and log back in.

89
00:11:12,900 --> 00: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.

90
00:11:21,100 --> 00:11:25,240
In this case, search.php and queue equals test.

91
00:11:25,660 --> 00:11:32,740
So, we would send a link to a user like this with our malicious JavaScript payload as the query.

92
00:11:32,920 --> 00: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.

93
00:11:40,400 --> 00: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.

94
00:11:52,660 --> 00: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.

95
00:12:00,300 --> 00: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.

96
00:12:07,420 --> 00:12:09,960
Fairly long password, so they think they're secure.

97
00:12:09,960 --> 00:12:11,880
They're not going to say this password end.

98
00:12:11,880 --> 00:12:14,500
They're just redirected to your search queries test.

99
00:12:14,820 --> 00:12:20,900
But actually, on the attacker side, we see that... well, this is actually the actual server.

100
00:12:20,900 --> 00:12:22,720
So, a post was made to login.php.

101
00:12:22,720 --> 00: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.

102
00:12:31,140 --> 00: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.

103
00:12:44,770 --> 00:12:54,590
Another less common but still usually used for stuff like hacktivism or things like that is cross-site scripting defacement.

104
00:12:54,590 --> 00:13:02,150
This is very similar to the HTML injection, only the JavaScript file in question I mentioned here is Stallone.js.

105
00:13:02,290 --> 00: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.

106
00:13:14,590 --> 00: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.

107
00:13:24,830 --> 00:13:27,010
Now, it doesn't have to be this Stallone.js.

108
00:13:27,430 --> 00:13:32,510
If you find a cross-site scripting vulnerability, you can deface a website to be whatever you want.

109
00:13:33,050 --> 00:13:40,490
So, you can rewrite CNN to show your own news instead of the news you expect to read.

110
00:13:40,490 --> 00:13:41,370
Things like that.

111
00:13:41,370 --> 00: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.

112
00:13:51,070 --> 00:13:53,990
So, here's the actual code from that Stallone.js.

113
00:13:53,990 --> 00:13:55,650
I know that this is a lot.

114
00:13:55,710 --> 00:14:00,490
I've also included a link to that .js file and you can google it and find it fairly easily.

115
00:14:00,590 --> 00: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.

116
00:14:14,990 --> 00:14:18,510
So, like I said, back to the history lesson.

117
00:14:18,510 --> 00: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.

118
00:14:33,650 --> 00:14:44,930
Well, unfortunately, on Amazon.com, they were vulnerable to a stored cross-site scripting via book previews.

119
00:14:44,930 --> 00: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.

120
00:14:51,610 --> 00: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.

121
00:15:05,250 --> 00: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.

122
00:15:13,450 --> 00: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.

123
00:15:22,350 --> 00:15:27,810
In addition to Amazon.com, note that this could have been used for things other than defacement.

124
00:15:27,810 --> 00:15:31,150
People could have tried to steal Amazon.com cookies.

125
00:15:31,310 --> 00: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.

126
00:15:38,910 --> 00:15:43,550
This had an example of a cookie stealing payload, alert-document.cookie.

127
00:15:43,710 --> 00:15:46,410
This also fired off on Amazon.com.

128
00:15:46,410 --> 00:15:51,510
As you can see, an Amazon cookie is being displayed just because a user is previewing the book.

129
00:15:51,510 --> 00:15:59,770
So, these attacks have occurred in the real world, and users could have been exploited by, technically, malicious book authors.

130
00:16:02,130 --> 00: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,

131
00:16:25,600 --> 00:16:27,360
I highly recommend you checking it out.

132
00:16:27,620 --> 00:16:34,880
But not exactly XSS-related, but I wanted to cover it as it is a similar style of attack.

133
00:16:34,880 --> 00: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.

134
00:16:44,840 --> 00: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?

135
00:16:52,900 --> 00:16:57,560
That would not be bypassed until the target clicked yes or no.

136
00:16:57,680 --> 00: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.

137
00:17:07,800 --> 00: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.

138
00:17:18,320 --> 00: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.

139
00:17:36,880 --> 00: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.

140
00:17:46,000 --> 00: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.

141
00:17:57,080 --> 00: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.

142
00:18:10,480 --> 00: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.

143
00:18:19,560 --> 00: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.

144
00:18:31,370 --> 00:18:39,110
So, back to another video demo, here I want to cover an example of password stealing using cross-site scripting.

145
00:18:39,110 --> 00:18:43,890
So, not phishing like the last one, but actually stealing saved credentials within a browser.

146
00:18:45,450 --> 00: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.

147
00:18:59,890 --> 00: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.

148
00:19:07,950 --> 00: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.

149
00:19:13,910 --> 00:19:18,770
So, as expected, it reflects the query parameter into the page.

150
00:19:18,770 --> 00:19:23,050
So, if we put alert 1, it shows that this page is vulnerable to cross-site scripting.

151
00:19:23,550 --> 00:19:27,190
So, let's say our admin user had actually logged into this application.

152
00:19:29,750 --> 00:19:33,110
They're going to save their password because they don't want to have to remember that pretty secure password.

153
00:19:33,110 --> 00:19:34,330
It takes a lot of work.

154
00:19:35,170 --> 00:19:38,130
So, when they log in, they're redirected to a comments page.

155
00:19:38,690 --> 00:19:41,790
And when they go back to the login page, their credentials are obviously saved.

156
00:19:41,970 --> 00:19:43,770
So , nice and convenient.

157
00:19:44,390 --> 00:19:47,290
Nothing too scary since we haven't phished their credentials.

158
00:19:47,850 --> 00: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.

159
00:19:55,750 --> 00: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.

160
00:20:21,450 --> 00: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.

161
00:20:32,590 --> 00:20:38,290
Now, note that this payload does require cross-site scripting on the login page.

162
00:20:38,290 --> 00:20:45,470
It won't work if there was a cross-site scripting vulnerability, say, in that comments page.

163
00:20:45,470 --> 00: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.

164
00:20:57,330 --> 00:20:59,210
So, as we can see, nothing happened.

165
00:20:59,210 --> 00:21:00,390
Their credentials are still saved.

166
00:21:00,390 --> 00:21:01,770
User is none the wiser.

167
00:21:01,770 --> 00: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.

168
00:21:10,310 --> 00: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.

169
00:21:21,870 --> 00:21:25,130
And we see an error that is not valid HTML, like I said.

170
00:21:25,250 --> 00: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.

171
00:21:40,150 --> 00:21:45,230
So, again, I know this is very demo and example heavy.

172
00:21:45,230 --> 00:21:49,630
Please feel free to reach out to me for these slides or go back over everything.

173
00:21:52,120 --> 00: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.

174
00:22:05,580 --> 00:22:10,520
So, the top picture shows our JavaScript payload.

175
00:22:10,520 --> 00: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.

176
00:22:25,800 --> 00: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.

177
00:22:37,180 --> 00: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.

178
00:22:46,460 --> 00: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.

179
00:22:54,380 --> 00:22:59,500
And in our data.txt on the attacker-controlled server, we got all of those keystrokes back.

180
00:23:00,200 --> 00: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.

181
00:23:05,800 --> 00: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.

182
00:23:23,680 --> 00:23:32,380
So, another thing that you could do with a cross-site scripting payload is steal sensitive information.

183
00:23:32,520 --> 00: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.

184
00:23:45,400 --> 00: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.

185
00:24:03,860 --> 00: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.

186
00:24:13,440 --> 00: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,

187
00:24:28,840 --> 00:24:29,900
things like that.

188
00:24:29,900 --> 00: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.

189
00:24:41,130 --> 00:24:51,030
So, a really fun cross-site scripting payload use that I have done personally quite a fair bit is defeating CSERV.

190
00:24:51,070 --> 00:24:55,070
So, if you're not familiar with what CSERV is, I'm just going to briefly cover it.

191
00:24:55,070 --> 00:24:57,610
It's cross-site request forgery.

192
00:24:57,630 --> 00:25:02,610
At its core, it's sending a request from Site A to Site B.

193
00:25:02,610 --> 00: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,

194
00:25:19,550 --> 00:25:20,650
for an example.

195
00:25:20,750 --> 00: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.

196
00:25:27,490 --> 00: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.

197
00:25:40,810 --> 00: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.

198
00:25:54,310 --> 00:26:02,690
So, a very simple read body looks for a CSERV token parameter, gets it, and returns it to a different method.

199
00:26:03,190 --> 00: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.

200
00:26:17,950 --> 00:26:23,230
So, as you can see, we have a very similar login page to all those other examples I've shown.

201
00:26:23,450 --> 00:26:25,370
Not the most beautiful page.

202
00:26:25,430 --> 00:26:32,570
Our search page that reflects back the kube parameter, as well as on an authenticated comment section.

203
00:26:33,030 --> 00: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.

204
00:26:41,070 --> 00: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.

205
00:26:48,330 --> 00:26:57,170
So, the search.php is unauthenticated and vulnerable to a reflected cross-site scripting attack.

206
00:26:57,170 --> 00:26:59,990
So, as we can see, if we enter a test, it shows test again.

207
00:26:59,990 --> 00: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.

208
00:27:10,430 --> 00:27:15,850
So, what we can do is we can use a payload similar to this one.

209
00:27:15,850 --> 00:27:16,950
And I know it's quite long.

210
00:27:16,950 --> 00:27:20,070
I'm going to share it, as well as give a link to it.

211
00:27:20,070 --> 00:27:24,710
But what... or actually, no, sorry, this is the comment section that shows you have to be authenticated.

212
00:27:24,710 --> 00: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.

213
00:27:34,950 --> 00:27:37,790
So, our developer secured their application.

214
00:27:37,950 --> 00:27:41,190
The comment section is not vulnerable to cross-site request forgery.

215
00:27:41,190 --> 00:27:42,770
We should be good.

216
00:27:43,350 --> 00: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.

217
00:27:57,110 --> 00: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.

218
00:28:05,240 --> 00: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.

219
00:28:23,970 --> 00:28:27,930
So, that top read body method looks just like the one I showed a few slides ago.

220
00:28:28,270 --> 00: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.

221
00:28:39,390 --> 00:28:42,890
And I apologize if some of the audio is slightly off of these videos.

222
00:28:42,890 --> 00:28:47,590
As I said, I recorded these videos a while ago and was not able to keep the audio with them.

223
00:28:49,670 --> 00: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.

224
00:28:58,410 --> 00: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.

225
00:29:25,860 --> 00:29:27,220
So, yeah, sorry about that.

226
00:29:27,220 --> 00: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.

227
00:29:34,760 --> 00: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.

228
00:29:40,420 --> 00:29:45,160
But, once we have this CSERF token... I'm not able to skip, unfortunately.

229
00:29:53,020 --> 00: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.

230
00:30:14,920 --> 00: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.

231
00:30:28,220 --> 00:30:33,100
So, if we quickly search for CSERFTest, as we see, their comment was scriptalert1.

232
00:30:33,120 --> 00: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.

233
00:30:43,240 --> 00:30:49,460
So, as you can see, it sent a POST request with the name of the comment and the CSERF token.

234
00:30:49,660 --> 00:30:55,080
Now, I just want to briefly touch on the difference between reflected and stored cross-site scripting.

235
00:30:55,340 --> 00: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.

236
00:31:06,580 --> 00:31:12,480
So, not quite as severe, requires some user interaction usually, stuff like that.

237
00:31:12,480 --> 00:31:15,960
Now, stored cross-site scripting is like what we saw in that comment section.

238
00:31:16,060 --> 00:31:23,580
So, our cross-site scripting payload will now execute on any user that goes to that comments.php page.

239
00:31:23,580 --> 00:31:25,600
So, it's more persistent.

240
00:31:25,600 --> 00: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.

241
00:31:37,160 --> 00:31:38,300
So,

242
00:31:41,590 --> 00:31:50,410
in addition to generic payloads, you can also use cross-site scripting attacks for application-specific payloads.

243
00:31:50,550 --> 00: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.

244
00:31:59,490 --> 00: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.

245
00:32:15,470 --> 00:32:19,010
So, for instance, changing your wireless password.

246
00:32:19,010 --> 00: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.

247
00:32:25,850 --> 00:32:27,030
Things like that.

248
00:32:29,570 --> 00:32:38,130
So, this is a great repository from HackLuke, but it contains a number of application-specific payloads.

249
00:32:38,130 --> 00:32:42,450
As you can see, there's a Drupal one, MyBulletinBoard, and a few for WordPress.

250
00:32:42,650 --> 00: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.

251
00:33:01,890 --> 00: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.

252
00:33:15,770 --> 00: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.

253
00:33:22,790 --> 00:33:30,950
While I personally love WordPress, it has been known to be vulnerable in the past, especially the plugins that people use.

254
00:33:30,950 --> 00:33:34,530
So, this is not an uncommon attack vector.

255
00:33:35,130 --> 00: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.

256
00:33:53,390 --> 00: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.

257
00:34:15,460 --> 00: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.

258
00:34:25,980 --> 00:34:33,080
This is a cross-site scripting framework of payloads and exploits.

259
00:34:33,640 --> 00:34:39,640
It's an open-source piece of software designed for penetration testers to exploit browser-based vulnerabilities.

260
00:34:40,360 --> 00: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.

261
00:34:50,320 --> 00: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.

262
00:35:01,020 --> 00: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.

263
00:35:10,400 --> 00: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.

264
00:35:20,640 --> 00: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.

265
00:35:29,600 --> 00: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

266
00:35:42,060 --> 00:35:48,400
a Metasploit payload and escalate to a reverse shell from that user, for example.

267
00:35:48,400 --> 00: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.

268
00:35:58,100 --> 00:35:59,960
As I said, there's a ton of payloads.

269
00:35:59,960 --> 00:36:01,940
I'm not going to cover them all.

270
00:36:01,940 --> 00:36:03,640
Here's a few examples.

271
00:36:03,900 --> 00: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.

272
00:36:15,040 --> 00: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.

273
00:36:22,920 --> 00:36:24,140
Stuff like that.

274
00:36:24,400 --> 00:36:27,000
But as I said, a ton of awesome payloads.

275
00:36:27,000 --> 00:36:29,320
I highly recommend you at least check it out.

276
00:36:30,180 --> 00: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.

277
00:36:44,380 --> 00: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.

278
00:36:54,540 --> 00:37:00,760
So, I briefly want to touch on blind cross-site scripting, mention what it is, and include a few references.

279
00:37:00,780 --> 00:37:06,200
It is easily a topic that could be at least one talk on its own.

280
00:37:06,220 --> 00: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.

281
00:37:17,420 --> 00: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,

282
00:37:42,800 --> 00:37:50,500
firewall logs that you never get to see as an attacker but that execute malicious JavaScript payloads, things like that.

283
00:37:51,020 --> 00: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.

284
00:38:00,160 --> 00:38:04,540
I highly recommend checking out stuff like XSS Hunter or Sleepy Puppy from Netflix.

285
00:38:04,540 --> 00:38:10,200
These are really fun tools for finding blind cross-site scripting and especially for your bug bounty hunters.

286
00:38:10,200 --> 00: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.

287
00:38:17,140 --> 00: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.

288
00:38:34,950 --> 00: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