EC Council CEH 312-50 V11 – Website Hacking – Cross Site Scripting Vulnerabilities

1. Introduction to Cross Site Scripting?

In this lecture and the next few lectures, we’re going to talk about a vulnerability called XSS. XSS is short for cross site scripting. This type of vulnerability allows an attacker to inject JavaScript into a page. So JavaScript is a programming language and using this vulnerability, an attacker attacker would be able to execute code written in JavaScript into a certain page, into a website. JavaScript is a client side language, so when the code is executed, it will be executed on the client, on the user, on the person who is browsing the web page. It’s not going to be executed on the server. So even if your code results into giving you a reverse shell, the shell will be coming from the user who is browsing the page and it’s not going to be coming from the website.

So any code you write in JavaScript will be exploited or will run on the target user, on the people who see the pages and it’s not on the web server. So the web server is only going to be used as means of executing the code or delivering the code. There are three main types of XSS vulnerabilities persistent or stored, reflected and Dombased. The stored XSS gets stored into the database. So the code that you inject will be stored into the database or into the page, so that every time any person views that page, your code will be executed. And the reflected one, the code will only be executed when the target user runs a specific URL crafted or written by you.

So you’ll be manipulating some sort of URL and send it to a target. And when they run that target, when they run that URL, the code will be executed. The Dombased results from JavaScript code written on the client. So the code will actually be interpreted and run on the client side without having any communication with the web server. This could be very dangerous because sometimes web servers apply some sort of security and filteration to check for XSS. But with Domebased the code never gets sent to the web server. So the code will be interpreted and run on the web browser without even interacting with the web server.

And these will be present into websites that update their content without refresh. So we’ve all used websites where you put your username, for example, and it loads in straight away without having to check with the web server. Or you do you put some sort of a string and it does a search without communicating with the web server or it does something and without communicating with the web server. So if you are able to inject into that, then this injection will not be validated. So it will be executed straight away and bypass all validations.

2. Discovering Reflected XSS

So let’s talk about how to discover these kind of vulnerabilities, very similar to SQL injections. The way to do this is you browse through your target and try to inject any text box or any URL that looks similar to this. So whenever you see a URL with parameters, try to inject these parameters or try to inject into text boxes. So let’s have a look on a reflected XSS example. So these are the nonresistant non stored vulnerabilities where you have to actually send the code to the target and once the target runs the code, it will be executed on their machine. So let’s have a look on our Dvwa website and I’m just going to log in and then we’re going to have an example of a reflected XSS. So as you can see, now you can put your name here for this text box and it’s just going to say hello.

Now, this is obviously just an example, but the idea is you can inject into text boxes. Also, if you have a look at the URL here, you’ll see that it’s a get. So you can inject into DRL as well. So let me start a leaf pad and let’s try to inject XSS code on this and see if the code will be executed or JavaScript code. Sorry. So what I’m going to use is a very simple script. So we’re using the script and a slash script tag. Now, there is a lot of ways into discovering these kind of vulnerabilities and a lot of ways to bypass filters. But for now, we’re just having a look at the basic case where we can inject a normal script and I’m going to say alert, which is just a function to give an alert to give a text box. And I’m going to say XSS. So I’m going to click on submit and we’ll see if this code will be executed. And as you can see now, it’s actually executing my code.

So instead of saying hello, Zade here, it said hello and my code has been executed and it produced this XSS. So we can do the same here. If you have a look on the URL, it actually already did it for us. But if we look at the URL here, it’s just going to be a bit bigger there we can see that the name has been obviously all of these characters are just HTML escape characters. And now if you send this URL to anybody whoever views that URL, the code will be executed on their machine and it’s going to say XSS. So let me show you here. You can also inject this in the URL. I just want to show you the whole idea of that. So we have script ScriptX. If I hit enter, the code will be executed. So as I said, we can copy this and send it to a certain person and once they run that code, this code will be executed on their machine.

3. Discovering Stored XSS

Okay, now let’s have a look on a stored XSS example. Now, stored XSS is very similar to a reflected one. It allows you to inject JavaScript code into the browser. The code is executed on the people that visit the page. The only difference is with the reflected, you have to send the URL to your target. So the target had to actually click on a URL for the exploit to run or for the code to run. In the stored XSS, the code will actually be stirred into the database or into the page. So every time any person runs that page, they will see your code and your code will be executed. So you won’t need to interact with any users or send them anything. Therefore, this could be much more dangerous than reflected XSS.

So let’s have a look on this. Now, I clicked on the XSS stored here on the left and you have this page. And this page just allows you to add a message to the system. So I’m going to put my name as Zade. We’re just going to do a normal test first and we’re going to put a message body, for example. And then I’m going to sign the guest book. And you can see that Zade added a message called message body. So if we go to here into another machine, so this is a different machine into a different place. And if we go into XSS stored, we can see that there is two entries. So the entries are being loaded from the database and they contain the entries in that database.

So if we manage to inject code in here, then any person who runs this page, the code will run on it without even having to send that person anything. So let’s try to inject itself here. So let’s put my name as Dave and I’m going to try to put my code in here. So I’m going to try to inject into the message. I’m going to put it as script. I’m going to use the exact same test code that we used in the previous video. Just a message saying XSS. Again, very basic code, but it serves for the purposes of this video. And we’re going to say alert XSS. And I’m going to try to sign the guest book. And as we can see now, I got the XSS here. But the real magic happens when a normal person.

 So let’s just go home first and let’s assume this is just a normal website and people just are coming and browsing it and once they’re going to go to the guest book, JavaScript code will be executed on their system from that website. So the code is coming from that website and it’s going to be executed on every person that visits this page. Again, we’re just showing a proof of concept here. In future videos we’ll show how to further exploit this kind of vulnerability.

4. Exploiting XSS – Hooking Vulnerable Page Visitors To BeEF

Okay, so now we know how to discover XSS vulnerabilities. We haven’t seen a good way of exploiting it though. All we were doing is injecting a very simple code that just displays an alert on screen saying that this website is vulnerable. What I want to do now is I want to do something more advanced. I want to be able to control the victims and do stuff on the target code computers on the people that visit the vulnerable pages where we inject our code. We’re going to use Beef to do this. We had a look on Beef before and what we’re going to do is we’re going to use the Beef hook URL and we’re going to inject it into the stored XSS page so that everybody who visits that page will be hooked to Beef. And then we’ll be able to run all the commands that Beef allows us to on the target computer.

So I’m going to start beef here. Now, as you can see, logged into the main screen, very simple screen. And if we look at the online browsers, we have no victims at the moment. So in order to hook victims to this framework and gain access to the functionality of Beef, you need to inject this particular script instead of the alert. So remember the way we were injecting an alert script into the URL or into the page. We’re going to be injecting a script that does the following so that contains the following. So I’m going to copy this and then I’m going to go to my vulnerable website. Remember, this could be a popular website or website of a company which you’re doing a pen test for.

Just going to make sure the security is set to low. And I’m actually going to use disturbed XSS and I’m going to put the name as Beef and we’ll put the comment as the hook that we got from the terminal. And I’m going to modify the IP here to my own IP address. So instead of just IP, I’m going to put my IP address, which is 1020 14. And now it’s not letting me add any more characters because this field is configured in a way that it doesn’t allow more than this number of characters. But we can bypass this very easily by right clicking and going on inspect element. And we’re going to modify the max length to instead of 50, I’m going to set it to 500 and that’s it.

Now I can add more stuff, so I’m going to close that and I’m going to set it to 1020 14 207, which is my current IP. Now I can get my current IP by doing ifconfig 1020 14 to seven just to confirm and I’m going to sign Guestbook and that should make it work. Now if I go to my target now, right now you can see that I have my Linux computer right here, has been hooked as a target. Now obviously this is not my target. This is just me. And the hook has been executed on my browser. So our target is actually this Windows device or any person who’s going to be visiting this XSS third page. So because this is a third exercise, just like we explained, the code will be executed on any person who visits this page.

Now, if we go back, we should see the Windows device right here, as you can see, and it’s showing up in the online browsers. So we basically have hooked this device and we can run a large number of functions that Beef allows us to do. So I’m going to click on my target and I’m going to go on the commands. So right now I just want to run a specific command, which is just an alert command like we were doing before, just to confirm that everything is working. So I’m going to go on this one, which is create an alert dialog, and you can set the text in here, so you can put any text you want. I’m going to leave it as Beef alert dialog. I’m just going to click on Execute.

So if we go on our target computer, we can see that the alert dialogue is working. Now, I just did that to show you that everything is working perfectly. Now, anybody who browses our target website, the vulnerable website, will get hooked to Beef and you can run all the commands that we’ve seen before. So all the commands that we’ve seen in the client side attacks, like a full access, using a fake notification bar, using the pretty theft, getting the screenshot injecting a key logger. You can do all of these attacks on any person who visits the vulnerable page because we injected our hook into that browser, into that page, not into the browser, and it’s part of the page. So every time the page loads by anyone, they will be hooked to Beef.

5. Preventing XSS Vulnerabilities

Now let’s talk about how we can prevent XSS vulnerabilities. The way these vulnerabilities happen is because whenever a user enters something into a text box or into a parameter, that input is displayed into the HTML. So it’s treated as if it’s part of the page, and therefore if there is JavaScript in it, the code is being executed. So to prevent this exploit, the best thing to do is to try and minimize the usage of untrusted input. So anytime a user inputs something or anytime something’s input from parameters, try to minimize that. Also make sure that you always escape whatever that’s going to be displayed or used into the HTML page.

Because XSS can not only be injected into places where things are displayed on the page, but it can also be injected into parameters of certain elements of the HTML page. So what I mean by scaping is converting each of these characters to what they would be represented by in HTML. You can do that using scripts and you can do that using your own script. Now let me show you how this happens. Now I’m here at my vulnerable web page that we were using and I’m going to go to this third one. And obviously you can see that every time we click on that, the XSS runs. So let’s inspect this element.

Now this element is where we injected our alert and if we right click and go on inspect element, it will show us the HTML of this page or the HTML of this particular element right here highlighted. So I’m going to make this bigger. And if we look at it right here, you’ll see that we have the name that’s Zade and then the other input, which is the message, it’s a script. And the script what the script does, it does alert XSS. So it’s exactly what we injected into it when we did the comment. So every time we run this page, this piece of code gets executed.So what we need to do is we need to make sure every time a user enters something and that something will be displayed on a page or that something will be used somewhere in the elements.

So even the ID here, or even the ID is just for example, is a parameter of the div, it’s not the state. You never see this ID, but this can be injected as well. So hackers can actually try to inject stuff into the parameters. They can try to inject stuff into the image attributes. For example, they can do an image and inject stuff into the source or into the URL. So this is just an example here and every time a user’s input is going to be used anywhere on the page. So even if you don’t see it, if you usually don’t see it, you need to make sure that you escape that input and make sure that it does not contain any code.

And if it contains any code, then it’s converted to an equivalent that the code will not be running. So it’s converted to its Http equivalent so that once you escape this, you’ll actually see this in the message. So you see the message as script alert XSS, but it will never be executed. This script will never actually be executed on the target person once they run it. Now, as a user to prevent yourself from being used into an XSS attack. Now the URL coming to you will probably look like a URL of a trusted website. For example, let’s assume that you work in a company and there was an excess in your company and you are logging into your company and the code gets executed on you, then there isn’t much you can do yourself.

But you need to be careful. So with Beef we saw in order to exploit the vulnerabilities, we were showing, for example, a fake update. So make sure if you get a message always that there is an update. Make sure you actually go to the website that provides that application. So Firefox said that there is an update. Go to the website of Firefox and see if there is actually an update and if there is, download it from that website. Don’t download it from the notification that you got. Also make sure you’re downloading it from a Https website and once you download it, you can inspect it and check it the same way that we’ve seen before to make sure that there is no backdoors or anything in it.

You can also check the MD Five sum to make sure that the file hasn’t been manipulated while it was being downloaded. The same when we did the fake Facebook login when you were with Beef. So what you can do is whenever you are told that you got logged out and please log back in again, ignore that. Go to Facebook. com, make sure it’s going through Http and then log into Facebook. So always try to be careful with notifications popping up, telling you you need to do stuff. Always be wary and never trust them.