Monday, November 23, 2015

SQL Injection in your ASP.NET web applications–Inline Dynamic Sql Query

In order to teach how to prevent a SQL Injection attack, it is necessary to teach how a SQL Injection attack works.  This means you will learn how to initiate an attack.  If you have followed my blog, you know that I am a once black hat.  Fortunately for me, I like money more than I like freeing data or digital knowledge. Thus I have grown up and have professional employment, besides the fact that prison at my age is extremely unappealing. 

DISCLAIMER: I am not responsible for anything you do with the knowledge contained in this post! You assume all responsibility for your actions. Be an adult.

The idea behind a SQL Injection is to change the way a query was intended to work.  Let’s see how we can make this happen.

Inline SQL Query

In order to get a query we need something to query.  So let’s fire up the old  trusty dusty Northwind database.  I have setup a website that utilizes an inline dynamic query:

DAL -
image
BLL -
image
Code-Behind -
image
HTML -
image

This is the complete code for the site.  So now a would-be hacker is asking himself if this site is susceptible to a SQL Injection attack.  First, we need to know the dynamics of the query (what a resultset looks like).  This will play a major factor later on in the process.  So we need to have a ‘true’ query -
This is what our website looks like when it is running -
image
Now we need to get a resultset from it to see what the query returns -
image 
AHA! As a hacker, I am looking at the number of columns and likely data types.  Hmm, EmployeeID looks like it can either be a varchar or an int.  LastName, FirstName, Title and Address are most definitely varchar.  I take notes on this and now, I need to see if the site is vulnerable.  I can do this with a little bit of innocent code that if it throws an error that gets logged, will not directly point to an intrusion attack.  How do we do this?  We insert into the field a command that we can visually see if it processes the command.  I have chosen the DELAY command.  Here I will enter ‘; WAITFOR DELAY ‘0:0:30’ --
What does this do?  Well in bad search coding, the SQL command will most likely be performing a LIKE command in the WHERE clause.  So the single quote closes that open single quote in the query.  Then I issue the WAITFOR command to make the server wait 30 seconds and finally the - - (double hyphen) closes out the rest of the query.  So essentially, I am searching for nothing which will return nothing but I am issuing a follow-up command to tell the server to wait for a delay.  If this works, I will notice that the return takes an extraordinary amount of time in addition to not receiving an error -
image
MAN!! That search took forever!  Here is the result -
image
YES!!! WHOOP WHOOP!!!! This site is vulnerable! I did not receive an error and the query took forever for a return because of the WAITFOR DELAY command.  The server is now mine! But wait, how do I get access to the data?  Well now that we know
A) That it is vulnerable
B) Likely data types
C) The resultset
I will inject my own data into the query and make sure I have the correct data types.  I do this by knowing that strings (when they can) are converted into the correct data types on the SQL server.  Thus, if I assume EmployeeID is a varchar and it is actually an int, SQL will convert it for me.  So what value can either be a varchar or int?  How about a numeric value that is in (single) quotes making it a varchar.  Like ‘1’ or ‘2’ or ‘1000’.  So if I inject five ‘1’s (one for each column) whether it is an int or varchar, SQL will handle it.  For instance, Select ‘1’,’1’,’1’,’1’,’1’.  This command will not actually work because of the inline command.  I don’t know the entire nature of the inline command so how do I either nullify or add to the command?  How about we use the UNION command?  If we perform a UNION command, no matter what the server returns, our values will be added to it and we should see a resultset -
image
So let’s see what SQL returns to us -
image
No WAY!!! I controlled the resultset.  This might appear to do nothing for us as hackers, but what if we tried to get other information instead of constant values.  Let’s try to get the table names from the database.  That will certainly help us in our quest to understand their data model.  Let’s see if we can do that by querying sysobjects and what we come up with -
image
What does it return?  All the tables from the Northwind Database -
image
Rut row.  This isn’t good.  I now have my first piece of the puzzle in getting the information that I need.  So now that we know the table names, what we need next is to know what columns are in a table.  As a hacker, the Customers table looks really interesting to me.  I want to know everything there is to know about that table.  So now I need to query that table to get the columns -
image
Now what is our resultset -
image

Double rut row.  I now have access to the entire customer information contained in the database.  Remember the Ashley Madison customer hack and how damaging it was for some people to show up in their list?  Well now imagine if this was your run of the mill site and this table contained bank or credit card information?  We aren’t actually there yet. So let’s complete the hack and see what we get -
image
From this query, we should be able to obtain all the customers in the database, where they work, phone number and address.  Let’s see if this works -
image
Well it is a good thing that Northwind does not store banking or credit card information.  I’m not sure how thrilled Art Braunschweiger would be to receive a call from a hacker that knows where he works and his address… and as in the case with Ashley Madison, just having proof of their name and personal information associated might be damaging enough.

Here we have seen that it can be extremely damaging if you are not filtering your queries.  This is actually a pretty common method of Sql Injection and developers need to understand how to protect their data against this type of attack.  The obvious answer is to filter the input search field using REGEX or simply do not use inline dynamic Sql.  Next we will look at the vulnerabilities of other SQL query methods.

 

Håþþ¥ .ñꆆïñg…

No comments:

Post a Comment