Attacking a website

People will sometimes attack random websites for their own reason. DotNetHints, being a random website, was bound to become a target of attacks as well. As far as I can tell there has been no damage on either the website or the database. Since all the things I've learned proved quite useful as well as interesting, I decided to write an article containing a list of interesting attack tools, using the attacks made on DotNetHints as a guideline, mentioning what was the purpose of each and every one of them.

 

 

If you would like to read a few basic things concerning attack patterns, you can read this previous article. Now, let's talk about SQL Injection attacks. An SQL Injection is an attack where text inserted as input can be translated as malicious SQL statements.

 

For example, DotNetHints gets the value of the blog article to show using the query string, let's say http://dotnethints.com/blog?id=53. We could assume that number 53 is passed through the database into a command that looks like 

SELECT * FROM Blogs WHERE ID = 53

If a malicious user replaced "53" with "53; DROP TABLE Blogs;" then the SQL statement created would look like

SELECT * FROM Blogs WHERE ID = 53; DROP TABLE Blogs;

and that would easily delete our table (supposing we had a table called Blogs).

 

 

 

However though it may seem easy for us to create malicious SQL statements, the attacker has no clue what his commands are supposed to look like. So he starts off by guessing. He usually creates SQL statements that will cause the server code to fail and using the exception messages or any random piece of info he can get, he forms an image of our database little by little.

 

Keep in mind that SQL Injections have a hard time getting through parameterized SQL queries. That is because in case a BlogID parameter is expected to be an integer, inserting string value will cause an exception to be thrown instead of messing up your database. However even if the variable is expected to be of string type, an SQL parameter will isolate that variable from the rest of the statement, so everything will still be OK. Yet, keep in mind that if you use stored procedures you may not be protected, depending on the stored procedure's syntax. Apart from SQL protection, using an error page is a good idea as well, since the attacker will have nothing straight in his hands.

 

So, if a website contains flaws concerning all that is said, it is vulnerable. Now let's move on and see how an attacker may actually create an attack.

 

 

To make things simple all SQL Injection attacks will be aimed to the current page's ID ( http://dotnethints.com/blog?id=53; that makes it 53 ). The attacker may presume the SQL statement I'm using looks like this 

SELECT * FROM Blogs WHERE ID = '53'

since that is a common way to get data from a table. Yet, the attacker cannot be sure what kind of statement is actually used, so he tries to get as much info as possible. In this section, the attacker is trying to find out if the website is vulnerable. In fact all the attacks mentioned below are up against the same thing.

 

53' / '53

Adding an apostrophe inside the statement will cause no harm to the database. The resulting statement looks like 

SELECT * FROM Blogs WHERE ID = '53'' / SELECT * FROM Blogs WHERE ID = ''53'

 

Supposing the website had security issues the exception returned would mention something like

Unclosed quotation mark after the character string '53''.

Now the attacker knows that the website is vulnerable and is ready to move on.

 

53' and 'x'='x

The resulting statement looks like 

SELECT * FROM Blogs WHERE ID = '53' and 'x'='x'

This time, using the apostrophe, that attacker tries to end the opened string and then add code of his own. 'x'='x' will always result true. So adding this value the result should be the same as if the inserted value were 53. If the attacker gets the same result when adding his code then he knows the website is vulnerable. 

 

Any true expression would do.

53 and 1=1

If the attacker gets the same result as using 53 then he knows that both our site is vulnerable and our statement looks like SELECT * FROM Blogs WHERE ID = 53 (in contrast to the previous assumption, this query does not use apostrophes).

 

Instead of using an expression that is always true he could use one that is always false. 

53' and 'x'='y

The resulting statement looks like 

SELECT * FROM Blogs WHERE ID = '53' and 'x'='y'

 

This time the expression will never return results. Likewise, if the attacker notices system failure, then the site is vulnerable.

Any false expression would do, for example.

53 and 1>1

 

One more point of interest is the following input

999999.9 

that creates the seemingly harmless SELECT * FROM Blogs WHERE ID = 999999.9. This will most probably return no rows and is probably used to see if the website is vulnerable. If you see that, you are about to encounter an evil foe. Havij.

 

 

 

"Havij is an automated SQL Injection tool that helps penetration testers" according to its production company. Well, none could prove them wrong. Yet a hacker is nothing more than a penetration tester who has no permission granted from a website's owner. In other words Havij (and other similar products) is like a knife - you can use it inside your kitchen or you can you use it to attack people. Havij consists of an easy to use Windows environment. This makes it a very popular choice as even people who have no idea what SQL stands for can use it. And in case the website is vulnerable they can get anything out of it.

 

Havij is no magic tool. It uses standard SQL injection attacks. However since it is a software program it can make things work much faster than a single person can. You can find a very interesting description of Havij's basic application on this video entitled Hacking is child's play - SQL injection with Havij by 3 year old. 

 

So what Havij is trying to do in a few words is, create exception throwing statements that hold important database info such as tables and columns names on the resulting messages. If the website does not give away exception messages, still Havij can create blind SQL injection attacks and things will end up the same way.

 

Even though I can't be sure, since the attacks I have described so far could have been created by a single person as well, it is probable that I have been the target of a Havij user all the time. Anyway let's see how Havij tried to mess up with the database.

 

999999.9 union all select 0x31303235343830303536,0x31303235343830303536,0x31303235343830303536--

 

OK, so there are three parts in the following SQL statement.

SELECT * FROM Blogs WHERE ID = 999999.9 union all select 0x31303235343830303536,0x31303235343830303536,0x31303235343830303536--

 

1) 999999.9 will return no rows but still carries the table schema

2) union all select 0x31303235343830303536,0x31303235343830303536,0x31303235343830303536 will try to create a union with a three column rows

3) will comment out possible remaining code

 

So, in case our table had four columns the previous statement would throw the following exception.

All queries combined using a UNION, INTERSECT or EXCEPT operator must have an equal number of expressions in their target lists.

 

OK, so the table does not have three rows. Let's try out four of them.

999999.9 union all select 0x31303235343830303536,0x31303235343830303536,0x31303235343830303536,0x31303235343830303536--

 

This time the result could be the union created row.

Now, if the table consisted of more than four columns Havij would not mind, as it likes creating requests one after the other adding one more row to the previous one's union each time, till it gets to the bottom of it. In my case it tried out to test if the returning data contained up to 23 columns.

 

I have no idea why but Havij is really fond of numbers 999999.9 and 0x31303235343830303536 as I have found many people who have been attacked by exactly the same numbers.

 

Apart from the standard values already mentioned, Havij may also use actual id values instead of 999999.9 and null values instead of hexadecimal numbers.

53 union all select null--

This method is similar to the previous one and will return two rows in case it spots the exact number of columns.

 

 

 

Time based attacks are SQL Injections as well, however they consist of requests whose response time depends on the SQL statement execution. They are composed of time delaying statements that will usually work if a condition is true. In a few words, if the response takes longer than usual, the attacker knows that his attempt was successful. Look at the following example

 

53; if (1=1) waitfor delay '00:00:01'--

This generates the following SQL statement

SELECT * FROM Blogs WHERE ID =53; if (1=1) waitfor delay '00:00:01'--

 

WAITFOR DELAY is an SQL Server delay function that is created to test if time based attacks can be used against a website. Since 1=1 is always true, if the site is vulnerable, the client should wait a second more than usual to get his response. Time based attacks can be used to bypass the error page defense, in case a site is actually vulnerable.

 

Since an attacker is not sure what database management system the website uses, it makes sense that he should try out some MySQL statements as well.

 

53 and if(1=1,BENCHMARK(208000,MD5(A)),0)

SELECT * FROM Blogs WHERE ID =53 and if(1=1,BENCHMARK(208000,MD5(A)),0)

BENCHMARK is a MySQL statement that repeats an expression a number of times. In the previous example MD5(A) will be executed 208000 times. MD5 is a MySQL function that creates a hash value, in our case the hash value of 'A', and will need some time do so.

 

Using BENCHMARK on MySQL is similar to using WAITFOR DELAY on SQL Server. Both statements will always create time delays so the attacker will know if such an attack can be used.

 

Time based attacks show up in similar forms such as

53' and if(1=1,BENCHMARK(208000,MD5(A)),0) and 'x'='x or

53' AnD BeNChMaRK%(2999999%,MD5(NOW()))

that generate

SELECT * FROM Blogs WHERE ID =53' and if(1=1,BENCHMARK(208000,MD5(A)),0) and 'x'='x' and

SELECT * FROM Blogs WHERE ID =53' AnD BeNChMaRK%(2999999%,MD5(NOW())) respectively.

 

The time based attacks I've described have no actual effect on the database. They are nothing more than simple tests. Yet things could have been different if the website had turned out to be vulnerable.

 

 

 

 

/WebResource.axd?d=9_aSpQG4otBYJW7wtbgWFn2DTTp5tmDDQLn8KCN2pl3HSkkYcOL6Y5XdP692KHs5mtz1ed72yS

_Ulz7TstrWAxxxcmXpmHVo_-1svjD1wJ01&t=635195661120000000

 

Padding oracle is an attacking tool discovered a while ago where the attacker takes advantage of web resource files in order to get hold of your website encryption method. This vulnerability has been removed through a security update released soon after but as there could be servers that have not yet applied it, it sounds fair enough that attackers would give it a try. Still there are counter measures you can take yourself to make your application safe. Since padding oracle attack would require a lot of pages to be thoroughly described, the following part will be nothing more than a summary of this method. If you would like to know more concerning this you can look it up on the internet.

 

A Web Resource file is a file containing reference to embedded resources within your application. For example if you use ASP.NET's validation controls then the web resource is used to retrieve proper JavaScript files. 

 

A web resource's URL looks like that

WebResource.axd?d=SbXSD3uTnhYsK4gMD8fL84_mHPC5jJ7lfdnr1_WtsftZiUOZ6IXYG8QCXW86UizF0&t=632768953157700078

The t parameter refers to time stamp value. What we are interested in is the d parameter which consists of the encrypted identifier. The padding oracle attack is using this identifier to get a hold of your encryption mechanism. Here's how this is done.

 

When a string is encrypted, it has to fit in into eight byte sized blocks. The empty bytes left on these blocks are called padding. Padding has to be filled with something and this something will be the hexadecimal number of the remaining bytes. 

 

So supposing there are three bytes left on the block, each one of these will contain data 0x03. When we are trying to decrypt the message, in case one of these blocks contained 0x02, that would cause an error thrown. Padding oracle is the method described. It is the mechanism we can use to check if an encrypted message is correctly encrypted.

 

OK, so far we know what padding oracle is and that a web resource file contains encrypted data. Now what?

 

An attacker can create multiple requests, using a different encrypted identifier each time. If the result is acceptable he gets an OK response, if not he gets an error. After a lot of requests the attacker can get hold of the initialization vector and, from that moment on, create his own encrypted messages or decrypt already encrypted text. Even worse the attacker can even download the application's web.config file.

 

OK, so far I have probably convinced you that padding oracle is some evil thing to deal with. The first question to answer is if a website is vulnerable to padding oracle. To answer that, you must imitate the padding oracle attack.

 

Get your web resource file URL e.g. http://mywebsite.com/WebResource.axd?d=jzjghMVYzFihd9Uhe_arpA2

If you request that, you should get an OK response containing your resource info.

 

Now the attacker would use another identifier  http://mywebsite.com/WebResource.axd?d=acun

If you get anything but an OK response, then the attacker can tell this identifier was not suitable and use another one. So the response should in that case be OK as well.

 

The same applies in case of missing identifier http://mywebsite.com/WebResource.axd?d= where the response would normally be Not Found.

 

So how do we deal with it in case in case something wrong showed up on the previous test? Let's follow these simple steps.

 

1) Use a custom error in your web.config file.

2) Set redirectMode to ResponseRewrite in your web.config file.

3) Add some random sleep delay to your error response.

 

The first step will return an OK page instead of an Error page.

Second step will return an OK instead of a Redirect page.

Even if you always get an OK page someone may guess if an error has occurred based on the time it takes for the response to get. Adding random sleep delay eliminates this issue as well.

 

Keep in mind that getting requests concerning resource files is not always a sign of padding oracle attack. Pods crawling over your website may also cause a "This is an invalid webresource request." exception to be thrown which is no reason to worry about.

 

 

 

There are tons of tools a malicious person can use against your website. Whenever something odd comes up administrators should be on the lookout for what it may cause. This is one strange kind of attack that I would like to mention.

 

7 [PLM=0][N] GET http://dotnethints.com/forum_post?id=7 [0,14770,13801] -> [N] POST http://dotnethints.com/forum_post?id=7 [R=302][8880,0,522]

 

Even though I have made quite a search concerning the previous attack, it got me nowhere. This type of attack does exist, as many people have been wondering, but none of them has a straight idea what it is for. I am really not sure myself yet I might guess that the attacker is trying to post something to the page as this page contains a form to insert input.

 

Anyway if there is anybody out there who knows what this whole thing is about, I would be really happy to know about it.

 

One last thing to point is the following alarming request I would get

 

/blog?id=41&sa=U&ei=kL7iVOelC43VPIuegOgF&ved=0CBYQFjAA&usg=AFQjCNED6y6PaalihyN0XUzcfDo4KvXuEA

 

Fortunately this one is no attack. It is actually caused by some browser add-on called Google Enhancer when using search engine. So, that drops the threats couter by one. 

 

SQL Injections are attack tools that have to do with creating malicious SQL statements through input and can be neutralized using parameterized SQL commands. An attacker will usually test to find out if a website is vulnerable before moving on to actual attacks. Using Havij, simple computer users can create effective SQL Injection attacks. Time base attacks are SQL Injection attacks base on the response time. Padding Oracle attack takes advantage of resource files to get access to our encryption methods.