SQL injection attacks (1)

A customer asks us to check his internal network, which is used by company staff and customers. This is part of a big security evaluation. Although we have never used SQL injection to crack a network before, we are quite familiar with its general concept. In this battle, we were completely successful and wanted to record every step of the process as a "vivid example ".

"SQL injection" is a specific subset of unconfirmed or unclearly identified user input vulnerabilities. "buffer overflow" is a different subset.) The goal of this idea is, convince the application to run SQL code, which is not within its purpose. If an application creates an SQL string locally in real-time mode, the result is very direct and will produce some real unexpected results.

We need to make it clear that this is a somewhat tortuous process, and there will be multiple turns of errors, the rest of the more experienced people will certainly have different-or even better-methods. In fact, we have successfully implemented the suggestions and are not completely misled.

There are also some different papers discussing the problem of SQL injection, including some more detailed articles, but this article shows that the cause of SQL injection is the same as the process of cracking.

Target Intranet

This is obviously a completely self-developed application, and we do not know it in advance, or access source code permissions: this is already a "blind" attack. After several detection times, we learned that the server runs Microsoft IIS6 and uses ASP. from this, it seems that the database is Microsoft's SQL SERVER: We believe these technologies can be applied to almost any web application, this application may be supported by any SQL Server.

The login page is a traditional user name-Password form with a link to send a password to me via email, and the latter is confirmed to be the failure of the entire system.

When you enter an email address, the system assumes that the email address exists, searches for the email address in the user database, and mails some content to the address. Because my email address is not found, it will not send me any content.

Therefore, the first test, for any SQL form, is to input a data with single quotes: the goal is to check whether they do not use the data clearing mechanism when building SQL strings. When an email with single quotes is submitted for this form, we get an error 500 Server failure.) That is to say, this "corrupted" input is actually analyzed. !

We guess the underlying SQL code may look like this:

 
 

  
  
SELECT fieldlist FROM table WHERE field = '$EMAIL'; 
 
 

Here, $ EMAIL is the EMAIL address submitted by the user through the form, and the application symbol provided by this long query is to make this $ EMAIL a real string. We don't know the exact name of this data field or the name of the relevant data table, but we know their features, and then we will get some good guesses.

When we enter steve@unixwiz.net '-pay attention to the ending quotation marks-this will generate an SQL statement built as follows:

 
 

  
  
SELECT fieldlist FROM table WHERE field = 'steve@unixwiz.net''; 
 
 

When the SQL statement is executed, the SQL analyzer finds extra quotation marks, aborts the work, and provides a syntax error. How to express this error to the user depends on the internal error fixing Process of the application, but this is usually different from the error prompt "the email address does not exist. The response to this error is the first fatal channel, which means that user input is not properly cleared, and thus the application becomes the food to crack.

Because the data we input is clearly in the WHERE substatement, let's change the meaning of this clause in a valid SQL statement and see what will happen. By entering any 'or 'X' = x statement, the SQL result is:

 
 

  
  
SELECT fieldlist FROM table WHERE field = 'anything' OR 'x'='x'; 
 
 

Because the application does not really consider such a query, rather than just constructing a string, the quotation marks we use make the WHERE clause of a single element become a double element clause, and the 'X' = 'X' clause is true, no matter what the first clause is. There is a better way to ensure "always true", which will be discussed later)

However, unlike the "real" query, a separate item should be returned at a time. This version will inevitably return every item in the member database. The only way to discover what an application will do in this situation is to try. Keep trying and notice the following results:

Your login information has been sent to the random.person@example.com.

We generally use the first row returned by the query as the primary entry for speculation. This guy did get his password back from E-mail, which may surprise him and cause suspicion.

Now we know how to play this query locally, although we still don't know how to combine the SQL structures we don't see. However, we can see three different query results through reverse engineering:

• Your login information has been sent to you by Email
• We cannot identify your Email address
• Server errors

The first two responses are valid query results, and the last one is caused by Invalid SQL statements. Response results like this will help us to better reverse the SQL statement structure used by the server for query.

Default field ing

The first step we need to do is to guess the field name. First, we reasonably assume that the query includes "email address" and "password ", therefore, the field names may be "US Mail Address", "userid", or "phone number ". Of course we 'd better execute show table, but we don't know the table name. It seems that there is no obvious way to get the table name.

Let's proceed step by step. In each example, we add our own special "segments" with known SQL statements ". We know that the end of this SQL statement is an Email address comparison. Assume that email is the field name.

 
 

  
  
SELECT fieldlist FROM table WHERE field = 'x' AND email IS NULL; --'; 
 
 

If the server response is an error, it basically indicates that our SQL spelling is wrong. However, if we get any normal response, such as "unknown email address" or "Password Sent", our field name is correct.

Note that our "And" keyword does not use the "OR" keyword. This is a simple solution. In the previous step, we didn't care which Email it was, and we didn't want to send a password reset Email to someone because they had been masked. In this case, the buddy will doubt that someone is engaged in another round on his account. Therefore, the "And" keyword is used to spell out an invalid Email address. In this way, the server always returns an empty result set, so that no Email is sent to anyone.

Submitting the preceding SQL code segment does return an "unknown email address" response. Now we confirm that the field name of the email address is email. If this is not the case, I will try again with "email_adress" or "mail" or something similar. This step is always tricky, but you have to talk about skills and methods.

The purpose of this SQL statement is to assume that the field name in the preset SQL query is email. Run it to see if it is valid. I don't care whether you have any matching Email, so I use the pseudoname "x" and "--" to indicate the beginning of SQL. In this way, SQL parsing will directly treat it as a command, and "--" will be followed by a new command, in this way, the unknown things behind the scenes are blocked.

Next, let's guess other obvious field names: "password", "userid", "name", and similar. Each time we mask only one name, if the returned result is not a "server error", it means we are right.

 
 

  
  
SELECT fieldlist FROM table WHERE email = 'x' AND userid IS NULL; --'; 
 
 

Through this step, we can see the following field names:

• Email
• Passwd
• Login_id
• Full_name

There must be more <Input name = "XXXXX"> Of the HTML page form for reference) later, I dug a bit, but did not dig out more field names. So far, we still don't know the name of the table to which these fields belong-What should we do?