Analysis of Oracle Database SQL injection and protection suggestions

Anwarking

SQL injection is a common attack method in the field of information security. But most people understand SQL injection by inserting SQL commands into a Web form submission, or by adding a query string when entering a domain name, page request, and finally reaching a SQL command that deceives the server to execute a deviation from the expectation. SQL injection In this case is caused by the fact that the Web page has a lack of validation of the information entered by the user.

Many people think that only web pages can be injected into SQL, only to inject points. This is a common error understanding of SQL injection. SQL injection should be called a database SQL injection, strictly speaking. The ultimate goal of SQL injection is to obtain sensitive information stored in the database. In fact, any program that can connect to a database and perform SQL operations can implement database SQL injection, such as database clients, Web pages, and program clients with database operations. In these three kinds of programs, Web page injection is the most common, this and the development of the Web page is relatively diversified, some web developers have low security experience, the use of a large number of Web pages related.

The SQL injection of Web pages is mainly to query some sensitive information by changing the SQL query logic that the Web page sends to the background database. But often the web-linked database uses a lower user rights, and does not have access to sensitive information in the database, can only get information related to the site. An attacker who wants to obtain sensitive information from the target database will find a way to take advantage of the database's own SQL injection vulnerability to the low-privileged user that the site uses (low permissions are for database permissions). When the attacker gets DBA authority on the database, it can obtain the sensitive information in the database, and bring unpredictable economic and reputational losses to several households.

650) this.width=650; "src=" http://www.dbsec.cn/aq/gjjs/images/20160125-Oracle-gjqx-1.jpg "alt=" 20160125- Oracle-gjqx-1.jpg "/>

Web site vulnerabilities give attackers an opportunity to invade, and database vulnerabilities can really threaten your data security. An Huaqin and attack and defense laboratory comprehensive years of database attack and defense experience and accumulation in the following article, the Oracle database with the largest market share is now an example of Oracle's SQL injection threat and some protection recommendations.

Oracle database SQL injection vulnerabilities exist in functions, stored procedures, packages, and triggers written in PL/SQL. An important reason for Oracle's SQL injection vulnerability is that the two invocation permissions defined by PL/SQL result in (both the definition and the caller's permissions). The definition of permissions gives low-privileged users the possibility of having high permissions at specific times, which lays the groundwork for the right-to-power operation. Caller permissions give low-privilege user-created SQL the possibility of high-privilege execution. Oracle's SQL injection vulnerability is often exploited by attackers based on both of these permissions.

The use of Oracle SQL Injection vulnerability generally only two types of operations are ultra vires operation, one is the right to control. The right to power operation is a kind of ultra vires operation, due to the limitations of the exploit itself, some vulnerabilities only support ultra vires operation. The Oracle Classic power-up Operation command is Grant DBA to user (DBA authority for user users). The classic command of ultra vires operation is the select password from sys.user$ where name = ' sys '; (querying the DBA user's password hash) after obtaining the hash can be offline by ORABF and other software to crack the hash corresponding password plaintext.

The attacker has a direct relationship with what injection method the Oracle injection point has and the access to the database account. In general, SQL injection database accounts can be divided into three categories:

1. The acquired account has higher database permissions

2. Acquired account has permission to create a function or stored procedure

3. The access account only has the connection permission (least privilege account)

The breakdown is as follows:

650) this.width=650; "src=" http://www.dbsec.cn/aq/gjjs/images/20160125-Oracle-gjqx-2.jpg "alt=" 20160125- Oracle-gjqx-2.jpg "/>

In the first case, multiple-fingered attackers have high privileges such as create any trigger permission or create any view permission or even execute ANT procedure permissions. If an attacker has execute ANT procedure permissions, you can execute many functions or stored procedures that are created by the SYS user in the definition mode. As long as the grant DBA to user is executed with a stored procedure created by the SYS user, the process of right to DBA is completed.

For example: Call SYS. Initjvmaux. EXEC (' GRANT DBA to USER ', TRUE);

An attacker with an account that has the Create any trigger permission is also easily promoted to the DBA. This is primarily because the Create any trigger permission creates a trigger for any schema, including SYS. The only limitation is that an attacker cannot create triggers on objects owned by the SYS user. In this case, the attacker's right to take the specific steps can be divided into the following three steps:

1. Discovery phase, an attacker would determine the DBA user in the database (Oracle is not just a DBA account, for example, System is also a DBA), and determine which tables or views an attacker has insert,update, or DELETE permissions (belonging to public).

2. During the construction phase, the attacker constructs a stored procedure that contains a full statement of the caller's permissions, and tries to get the trigger to invoke the stored procedure.

3. Implementation phase, the attacker creates a trigger on the target DBA user to trigger the event. The trigger will execute with the owner's permission, allowing the trigger to use a stored procedure with the caller's permissions. Execute the CLAIM statement in the stored procedure.

An attacker with an account that has the Create any view permission is not difficult to elevate to the DBA. The method is similar to create any TRIGGER. An attacker could simply create a view in the database administrator's mode, and then have a user with a high privilege access to the view for the purpose of power-up.

High-privileged users are often not restricted by the vulnerability, so users must pay attention to the Web Access database account permissions, too high a privilege to your database security brings great hidden trouble. In Oracle, a user with the Create any XXX permission is likely to get DBA authority on the database, so unless the business must otherwise never grant the page link database user create any XXX permissions.

In the second case, where an attacker has an account with permissions to create a stored procedure, function, and so on, an attacker could invoke it by constructing a stored procedure or function that performs a command of the call, and invoking it through a stored procedure or function with a SYS (or other high-privileged user)-defined permission.

The attacker has the right to create a function (created functions), which is equivalent to any action they can make to the database. An attacker could write the PL/SQL code that they want to execute into a custom function that they created (for example, add Grant DBA to USER in a custom function) and put the function into an SQL statement. Attackers simply set the function they create as the caller's permission (AUTHID current_user), so that when a stored procedure or function defined by a high-privilege user invokes a function created by an attacker, the person who actually executes the function created by the attacker would be a high-privileged user. At the same time, the attacker-defined function must use Autonomous+transaction's compilation instructions. This compilation can indicate to the compiler that the function will execute an event inside its subroutine regardless of the stored procedure or function that called it. Finally, just look for a high-privilege stored procedure or function in the database that has the public execute permission.

For the third kind of permission, it is also the most common case that the current database user has only a lower permission and does not have permission to create a user-defined stored procedure or function. In this case, there are three main ways to attack attackers:

1. Inject anonymous PL/SQL blocks

2. Cursor Snarf attack

3. Take advantage of dbms_jvm_exp_perms logic vulnerabilities to get Java execution permissions to control the entire database or the entire system

The first way an attacker could not create a stored procedure or function can only be restricted to perform select or DML operations, but an attacker could inject a stored procedure or function that executes an anonymous block to achieve the right to power. Anonymous blocks are special stored procedures that exist in memory and can only be called once. Attackers can bypass the limitations of ordinary stored procedures by performing Select, DML, DDL, and so on. What an attacker needs is to find a system function that can accept input from the exception and does not validate user input.

A potentially vulnerable function has the following 4-point feature: Security personnel can make some adjustments to functions that have the following characteristics (such as turning off public permissions to prevent low-privileged users from invoking)

1) The problem function exists through the string Connector (| |) Connection functions so that the injection may be implemented correctly.

2) The problem function cannot contain an out parameter because the injection process cannot provide an out type parameter.

3) The problem function must return a simple data type, complex data types can cause errors because complex data types cannot be automatically converted to a simple data type during string concatenation.

4) The problem function must provide a mechanism that allows an attacker to execute a certain length of PL/SQL statements.

The second approach was proposed by David Litchfield to invade Oracle through SNARF. The main occurrence is a security risk if a high-privileged user does not properly or actively close an explicit cursor. Cursors created by high-privilege users are stuck in database memory, and low-privileged users can use stranded cursors to attack Oracle. The most common way is for an attacker to guess a hanging cursor with a loop loop. After locating the suspended cursor, reclaim it and re-bind the high-privileged user, and then execute the query to gain unauthorized access to sensitive information that is highly privileged to the user.

The third approach is to leverage Oracle-supported Java. The root of the problem is that Oracle defaults to Dbms_jvm_exp_perms, Dbms_java, and dbms_java_test and other dangerous package execution permissions directly to public, causing any user to execute JAVA programs. And then control the entire database and even the entire operating system. This similar problem occurs not only in Oracle's Java services, but also in other Oracle services. If the business does not require the use of Java services, it is recommended to delete directly. Shutting down useless services is a good way to put an end to the loopholes.

Both the Web site and the application layer of the information system need anti-SQL injection, while the database needs anti-SQL injection, data security and database security are closely related. Faced with the threat of database SQL injection, An Huaqin and Database Defense Lab experts give the following three points of protection advice:

First of all, Database DBA Limited account access is the most critical precaution. It is also difficult for attackers to obtain different levels of account for subsequent injections. Lower account privileges the more difficult an attacker is to use it to obtain sensitive information in the database;

Second, removing unused Oracle default services helps reduce the number of vulnerabilities that can be exploited by attackers.

Finally, it is necessary to upgrade the database periodically. Regular upgrades help to fix vulnerabilities and reduce the number of vulnerabilities. Databases that cannot be upgraded in a timely manner because of constraints such as stability constraints should also set up a database firewall with Vpatch (virtual patching) capabilities between the database and the application. At the same time, the encryption of sensitive data is also an effective means to strengthen data security.

This article is from the Database security blog, so be sure to keep this source http://schina.blog.51cto.com/9734953/1739281

Analysis of Oracle Database SQL injection and protection suggestions