312-50 EC Council CEH – Website Hacking – Discovering Vulnerabilities Automatically

1. Automatically Scanning Target Website For Vulnerabilities

So far we learned how to manually discover a number of very dangerous vulnerabilities. We’ve seen how they work and how to exploit them. In today’s video, I’d like to show you a tool that will allow you to automatically discover vulnerabilities in web applications. It will allow you to discover the vulnerabilities that we learned, plus us much more. The reason why I didn’t teach you this at the start, because I wanted you to learn how to do it manually. And I also wanted you to know how these vulnerabilities occur, so to understand the reason behind them. Also these are just tools. So this program is just a tool. It can make mistakes and it can show false positives. It can also miss vulnerabilities in some cases.

Therefore, I wanted you to know how to do this stuff manually. So if the program doesn’t work, or if the program misses something, then you’ll be able to find it. The best way to use these programs is as a backup or as just a tool to help you with your penetration testing. So using the tool is very simple. I’m going to go on my applications and then I’m going to type in Zap and it’s asking me if I want to save the current session when I search for something. So I’m going to say no. And this is the main view of the tool. So on the left here, you’ll see the website that you’re targeting.

On the right you can attack and set the website URL. And in here you’ll see the results for your attacking or for your scan. If we go here on the cog on the left, it will allow you to modify the options for the program. So you can modify certain aspects of it. The way the fuzzer works, the way the spider works, the way the scan works. I’m going to leave everything the same. Another thing that you can modify is the policies used in this case.

So something similar to this cans that we were using with Nmap, the intense scan and all that. So I’m going to press on the plus I’m going to press on the active scan and if you press on this on the left here, and I’m going to press on the default policy. Now you can create your own policies by using the add button. I’m going to press on the default one and I’m going to go on Modify to see you to show you the aspects that you can modify. So right here you can modify the name, the threshold and the strength for the global policy. Clicking on each of these categories will allow you to modify the specific scans that will be performed. For example, in the injection tab here, we can see all the injection scans that the program is going to try. For example, we can see SQL injections. Here you can see cross site scripting here and pressing on the threshold right here we can set this to default low, medium, or high. Setting it to the default will just default to the value selected here, which is medium right now.

Or you can have, for example, if SQL injection is what you’re looking for, if what you’re looking for is access for the database, then you can set this to high so that it’ll try everything and it will try to find it in even difficult places. So I’m going to close all of this. I’m leaving everything the same, and I’m going to start my attack against the Matilde script. So we have it in 1020 14 to four running in the metasploitable machine. And if we go on Matilda right here, that’s the URL. So literally, I’m just going to copy this and paste it here. And then I’m going to attack. Now, the tool is first going to try to find all the URLs and then it’s going to try and attack these URLs based on this current policy that we used. I’m going to pause the video and resume it once this scan is over.

2. Analysing Scan Results

So the scan is over now and you can see on the left here we have our website clicking on it will show you some results of the spider when it was looking for the files. The very interesting part is the alerts here. Right here you can see all the vulnerabilities that have been discovered. On the left here you can see that we have seven red flags. So these are the high priority alerts. We have three orange flags and five yellow flags and zero blue. So these are organized in the order of their severity. Clicking on any of these categories will expand it and show the threads that have been found related to that thread.

For example, clicking on the path traversal, you’ll see all the URLs that can be exploited to read files from the server. Clicking on any of these you’ll see the Http request that was sent in order to discover this. You’ll see the response. That why the tool thinks that this is vulnerable. And we can see that in the response the tool was able to get the contents of etc password. Right here you can see the URL that the tool used to exploit this vulnerability.

And in here you can see a description of what the current vulnerability is and how it has been exploited. In here you can see the risk of it. So this is very high. You can see the confidence. So how confident the tool about the existence of this vulnerability. You can see that it’s been injected into a page and the attack is trying to get etc password. So let’s try and right click on this and open it in browser. And as you can see now, it exploited it for us and it showed us the output for this vulnerability. And we can read the contents of etc password and you can see that the exploit is being exploited in this URL right here. Let’s have a look on another example. For example, a cross site scripting. And again, the tool also checks for post and get parameters. So sometimes when the parameter, when the injection is sent into text boxes or even sent without text boxes, if it’s sent in a post parameter, you won’t see it in the URL.

So it actually checks for post and get. And you can see here it found a vulnerability in a post request in the register page and it also found one in a get page. Again, right click and open in browser will execute it for us and we can see the code has been executed. Again, we can have the URL of the execution right here if you wanted to use it with beef or any other tools. And we can see it in here as well, the URL that’s being used to exploit this vulnerability. Let’s just have one more example of an SQL injection. Again click on it, it will show you why it believes that there is an SQL injection. Here it will show you the URL and it will show you the attack that used.

And one equals one, and it’s in the parameter password. And if you remember, we actually did exploit this parameter. Opening this in the browser will show us that the injection is working and it’s using a username and a password called app. So the tool is very simple, very powerful and very useful. You can play around with it, you can play around with the proxy and with the options and see how you can enhance the results and achieve even better results.

3. Website Hacking / Penetration Testing Conclusion

So far. In the website hacking section, we learned how to gather information about a target website, how to discover a number of vulnerabilities in the web application, and how to exploit these vulnerabilities to gain access. I actually cover more vulnerabilities and more advanced techniques in my website Hacking course. This is just an introductory course to most hacking fields without diving too deep in any, check out the bonus lecture, the last lecture of the course for more information. But in all of the previous lectures I knew what kind of vulnerability I’m going to use and that’s because I’m teaching you these specific vulnerabilities.

So people usually ask me at the end of this section, so how do I know which vulnerability to use or how do I know which vulnerability to try? And the answer is try all of them. I only try a specific vulnerability per lecture because I’ve already done my tests and I’ve already, and I already know what to try and what to show you, so I don’t waste your time. But if you’re pen testing a specific website, you’re going to have to try every single vulnerability that you learned.

So the basic methodology would be to, first of all, gather as much information as possible about the target as usual, discover all of the subdomains, all of the hidden directories, all of the web applications installed on it. And then for every domain or subdomain, we’re going to click on every single link. We basically want to use every single feature of the website and get an understanding of how this website works so when we break it, we know we actually broke this and it might be vulnerable.

Then for every link, for every page that we browsed, we’re going to try all of the vulnerabilities that we learned by testing the parameters in this page. And what I mean by the parameters is the input boxes that you see on the page and you want to test the data that is sent over the URL after the equal sign. So let me show you a quick example of what I mean. Let’s assume that you’re trying to discover vulnerabilities in Google. com.

You’re going to come to Google. com, we’re going to discover every single subdomain on Google. com. So you’re going to have to go to Accounts, Google. com, At, Sense, Google. com and so on. And for every page that we get in here, we’re going to click on every single link. So for example, we have the House Search Works link in here. We’re going to open it in a new tab and we’re going to come to it. You’ll notice that in this page, again, we have more links. So we’re going to have to click on every single link of these. And then for every page that we get, we’re going to first of all try to use it to see what the page does, to get an idea of the features that this page has.

And then we’re going to try to discover the vulnerabilities that we learned by manipulating the inputs. So we’re going to first play with the inputs in here in the URL. So you can see this URL we have, FG is equal to one. So after the FG equals one, we can actually try to inject stuff. We can test for SQL injections, we can test for XSS and so on. And we can also go ahead and test this input box for XSS. Google was actually vulnerable to an XSS and they paid a huge bounty.

I can’t remember what it was to the person that found it. So don’t think that these vulnerabilities don’t exist in big websites like Google. So the main things we’ll be testing is the input boxes and the things that we see after the equal sign. And you’ll basically have to test literally every single vulnerability that you learned. Like I said, there is no way to know by simply looking at a page that it’s going to be vulnerable to an SQL injection or to and XSS, for example.

• Category: Uncategorized