Web App Pentest - Part 3 Fuzzing

When We test the web application, we do not test a single page but we test lot of page of a single web application. So each page may have more than one variable so technically you will be engaging with ton of variables within your web application test. So when you inject anything to the input it is good to know what kind of effect your injection is making to the server. In this part of these article series we will look at the importance of simple alphabetic injection along with the web page encoding technology and how it does effect on our testing and result.

Simple Alphabetic Injection

So when you engage with many webpages and ton of variables, it is good to find your input after you inject. So when you give something to the webpage as a input, your input would not been used to only at one place, but it will be used to for many variables and ton of places. One of the common ways to check which are those areas where your given input is used, is to give a simple alphabetic injection. This simple alphabetic injection can be anything. As I told, I personally use Jonnybravo as a username and momma as a password. If i use any special characters within my input, it might get encoded/eliminated to prevent the injection attacks on that page. What is encoding and how does it take place that I will be covering in this part later on. Reason of using simple alphabetic as our injection is because alphabetic will never be encoded or eliminated by the server and you can find your input within the response as well as request easily.

“Webpage never encodes alphanumeric in its output compare to special characters and fancy input.”

Let us suppose if you used ‘$’ or ‘#’ within your input, then webpage might encode your input as anything such as %3D, %3E or something like that. It depends on the encoding mechanism used by the webpage. Webpage/server uses encoding libraries in which user’s malicious input is altered. However alpha numeric is not altered in all the encoding libraries of the world.

“it is a common sense that if encoding libraries start using alphabets even, than what kind of input they are asking from user !!!!”

So let’s make a request by using jonnybravo in username and momma in the password parameter in our user look up page in NOWASP mutilidae and then we will try to see in the response that where our input is passed. Intercepted request is as follows:

GET /chintan/index.php?page=user-info.php&username=jonnybravo&password=chintan&user-info-php-submit-button=View+Account+Details HTTP/1.1

Host: local host

User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Referer: http://localhost/chintan/index.php?page=user-info.php

Cookie: showhints=0; PHPSESSID=dkm54bjhm7cnqp4umdefpa6e10

Connection: keep-alive

Now we will forward this request and we will be getting 200 OK messages in the same RAW tab of burp suite. This time it will also intercept the response because I have enabled that option in burp proxy. I want to analyze the response even so I need to intercept response before it goes to my browser. So in response there will be whole HTML coding which will look like below pic.

“It is not always necessary that you have send an input parameter in your request, it has to be appear in the response. Some developers does not allow those parameters to be appear in the response for may be security concern or for other purpose.”

Now I want to find my input parameter’s value in my case it is jonnybravo and momma.  So I will use the burp’s search bar lying on the below side of the response. I will give any of these keywords and will try to find that input in response. It will look like as below figure. 

 So it’s showing that we have found only 1 match of our search and it is listing in the response body of html code. It is used in tag. In our case we have not created this username and password in our database. So if we create those and then we try to login and intercept the response we may find the both field’s value in our response. So I am registering this user in the database now. Then I will try to login as those credentials and will intercept the request.

HTTP/1.1 200 OK

Date: Tue, 31 Dec 2013 17:40:24 GMT

Server: Apache/2.4.3 (Win32) OpenSSL/1.0.1c PHP/5.4.7

X-Powered-By: PHP/5.4.7

Logged-In-User: jonnybravo

Keep-Alive: timeout=5, max=100

Connection: Keep-Alive

Content-Type: text/html

Content-Length: 42444

So if you have note that there is a new field Logged-In-User. It means our credentials are successfully authenticated. Here is the response and I am searching for momma input in the response.

You can see that I have found   code of the response. Now I am giving different username and password whose values are not in the database and will try to find that response.

Here is the request status.

POST /chintan/index.php?page=login.php HTTP/1.1

Host: local host

User-Agent: Mozilla/5.0 (Windows NT 5.1; rv:27.0) Gecko/20100101 Firefox/27.0

Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8

Accept-Language: en-US,en;q=0.5

Accept-Encoding: gzip, deflate

Referer: http://localhost/chintan/index.php?page=login.php

Cookie: showhints=0; PHPSESSID=mq79soql2ua71rae63vjdc2qt6

Connection: keep-alive

Content-Type: application/x-www-form-urlencoded

Content-Length: 68

username=spiderman&password=spidergirl&login-php-submit-button=Login

So here my credentials are highlighted in yellow color and below pic shows the response I got. As these credentials are not there in database, so that won’t be authenticated and we can expect some ‘Authentication error’.

 

As you can see we got and error, but it didn’t responded back the credentials as username ‘spiderman’  and password ‘spidergirl’ are not correct.

“It is not the case all time, it depends on the developer how he has created that web application. So sometime you may get sometimes you may not.”

Scenario of Fuzzing

When we fuzz a web application we are giving each of those characters and special characters to each and every parameter that we can think of. Not only special characters but we may input the sequences of special characters in those parameters. We give this input in order to find that does it make any impact on the backend database or not. Sometimes attacker does use special characters which are used in javascript in order to see that are those characters are being encoded or not. However you can choose your own technique for this, your main aim should be to create some kind of reaction with the backend server. So before fuzzing you need to understand which kind of special characters are being used in SQL commands. To check that I am typing here random SQL commands and then we will try to identify different specials characters from that.

  SELECT COUNT(column_name) FROM table_name;  - Identified Specials Characters are _ ( ; )

     SELECT COUNT(*) FROM table_name; - Identified Specials Characters are *

·  SELECT ProductName, Price FROM Products WHERE Price>(SELECT AVG(Price) FROM Products); - Identified Specials Characters are > ,

(Source : http://www.w3schools.com/sql/ )

So if we sum up all these results then we are having a bunch of special characters which are being used by SQL queries. These specials characters are ‘_’, ’>’, ’*’, ‘”’, ’;’ etc.. Let us go to authentication page and lets input these special characters in order to see the result. I am inputting below specials characters: --/-‘\\*'.

Once I gave this all characters in login username, it reacts with the backend database and here it is giving me error messages.

 

If you see messages related to configuration, coding, syntax or other which supposed to be from or for developer’s side, then it can be called as vulnerability. People do give different names to that. I mainly tell it “Improper Error Handling Vulnerability.” If you have marked closely then there is vulnerability. It is “path disclosure vulnerability”. It also discloses partial application so we have found vulnerability named “Application Disclosure”.

This is the system path of internal web server of this application in our case we hosted this application on xampp server’s htdocs folder. That is why it is showing this path. Now as I told we have found application disclosure vulnerability which is as follows:

  

Message box shows the application disclosure. We have also got SQL message disclosure in our “Trace” box which shows SQL errors. The injection that we have given, we can find that at multiple places shown in below figure.

By watching this error message we can also identify that where our injection is lying in between the query. So you can see that our injection is at the end of the query which is not the case always. We are on authentication page so page will only find username from database that is why our injection is in the end.  To illustrate it lets us see normal query to find users from database.

SELECT username FROM accounts WHERE username-‘chintan’;

So we injected our context(--/-‘\\*') instead of chintan. Now let’s find database error which shows this kind of SQL error messages in which our context lies in between the query. So I am going to user look up page and ideal query running in backend database should be like this:

SELECT * FROM accounts WHERE username='jonnybravo' AND password='momma'

So let us inject username with our context and let’s see what error messages we get from database. As usual we are not able to do successful authentication in order to see the user lookup and we have got an error page which is as follows:

As you can see here, our injection is in between the whole query it lies in username variable and there is a query before our injection and after our injection.

Conclusion

So it was all about the introduction to fuzzing and how fuzzing works with the backend database and what kind of reactions we see at client side on our browser. In my next article of this series, I will talk about the various types of fuzzing including what is suffix and what is prefix in these context or SQL statements and much more. Stay tuned. Thank you.

References

1.       http://www.w3schools.com/sql/

2.    https://www.owasp.org/index.php/Testing_for_SQL_Injection_(OWASP-DV-005)
3. 1.http://asset-b.soup.io/asset/2979/4742_b7be.jpeg