How to get DBA authority through Dbms_sql

Anwarking

The goal of a database attack is ultimately to get the valuable data in the database, and the most effective way to get the data is to get DBA authority directly. Through a classic vulnerability in Oracle database, this paper demonstrates the process of extracting power from ordinary users to DBA authority, and DBSEC Labs Database Security Lab gives specific protection advice.

Oracle Vulnerability Analysis

CTXSYS.DRILOAD.VALIDATE_STMT is a classic Oracle vulnerability. Appears in Oracle9i and is repaired starting from 10g. This vulnerability is a direct injection of the vulnerability of the representative. The vulnerability occurs in stored procedure validate_stmt in the Driload package created by Ctxsys. First we unpack the way to open validate_stmt observation source.

The VALIDATE_STMT structure is as follows:

CREATE OR REPLACE Package BODY Driload is

PROCEDURE validate_stmt (sqlstmt in VARCHAR2)

Is

...

...

BEGIN

SRC: = Dbms_sql. Open_cursor;

Dbms_sql. PARSE (SRC, sqlstmt, Dbms_sql. NATIVE);

RET: = Dbms_sql. Execute_and_fetch (SRC);

Dbms_sql. Close_cursor (SRC);

...

...

END validate_stmt;

In the source code, you can visually see that the stored procedures are mainly used in the Dbms_sql package of the various stored procedures and functions. This indicates that validate_stmt's vulnerability is primarily a dbms_sql vulnerability.

Since the problem is dbms_sql, it is necessary for us to have a preliminary understanding of its function and usage scenarios. Dbms_sql is primarily used to solve problems that require the dynamic processing of data or table structures. For example, a batch of table data processing, or batch creation of tables, indexes, triggers, and so on, can be operated through the Dbms_sql package. Official from Oracle reveals the overall logic of the Dbms_sql runtime.

650) this.width=650; "src=" http://www.dbsec.cn/aq/gjjs/images/20160329-0.jpg "alt=" 20160329-0.jpg "/>

Based on the analysis of stored procedures and functions in the Dbms_sql package, it is concluded that only dbms_sql can be injected into the function with extra long parameters. PARSE.

The parameter statement in this function should be an injection breakout, because the VARCHAR2 type in this parameter can accommodate a longer string, which makes it possible to embed the command in a string.

Vulnerability verification

The author constructs the right statement as follows:

SYS. Dbms_sql. PARSE (SRC, ' GRANT DBA to Public ', Dbms_sql. NATIVE

Constructs the right statement, wants to pass the sys.dbms_sql. Parse to execute, you also need to construct an intrusion function block as required by the Dbms_sql processing DLL, as shown in the following example:

DECLARE

SRC number;

RET number;

BEGIN

SRC: = Dbms_sql. Open_cursor;

SYS. Dbms_sql. PARSE (SRC, ' GRANT DBA to Public ', Dbms_sql. NATIVE);

RET: = Dbms_sql. Execute_and_fetch (SRC);

Dbms_sql. Close_cursor (SRC);

END;

The actual attack effect is as follows:

650) this.width=650; "src=" http://www.dbsec.cn/aq/gjjs/images/20160329-1.jpg "width=" "height=" 223 "alt=" 20160329-1.jpg "/>

The SQL block of the right statement is executed on the low-privileged user, and the power display fails. The reason for this is because Oracle specifically sets the Dbms_sql. Parse is Authid current_user (caller privilege). Caller permissions determine Dbms_sql. Parse will determine whether the user currently executing it has permission to invoke him (DBA authority) before executing it.

But here Oracle simply lowers the Ctxsys permissions, not the Dbms_sql. Parse does an effective defense treatment. Although Dbms_sql. Parse is protected by the caller's rights and cannot be injected directly. However, if a DBA account establishes a stored procedure or function that defines the permissions of the user (this stored procedure is called a), Dbms_sql is called. PARSE. and give the executive permission of a to public. Then the low-privileged user has the opportunity to call Dbms_sql through a. PARSE.

The following tests are performed on Oracle 11.2

First check the number of DBA users, for the last as a control group

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

The dbms_sql is called in the middle of the setup of the stored procedure a,a the DBA account sys. PARSE, and assign the Execute permission of stored procedure a to public. Enables all users to execute a.

650) this.width=650; "src=" http://www.dbsec.cn/aq/gjjs/images/20160329-3.jpg "alt=" 20160329-3.jpg "/>

Cut to the low-privileged Scott to execute the SYS.A and change the parameter to the right-hand statement grant DBA to public.

650) this.width=650; "src=" http://www.dbsec.cn/aq/gjjs/images/20160329-4.jpg "alt=" 20160329-4.jpg "/>

Although the program error, but actually has implemented the power of command. The failback sys user queries the DBA user again and discovers that there is more than one DBA user public. Public is formally granted the right through the grant DBA to public command.

650) this.width=650; "src=" http://www.dbsec.cn/aq/gjjs/images/20160329-5.jpg "alt=" 20160329-5.jpg "/>

This right to the DBA succeeds.

Cause of vulnerability

There are four key points in the process of using the Dbms_sql vulnerability for DBA authority over Oracle Caller privileges:

1.DBA The user creates a function or stored procedure that defines the permissions of the person. (The definition permission allows any user to gain DBA authority in the runtime of the calling function or stored procedure.) In the example, the stored procedure A is the definition of the user's permissions. A low-privileged user, Scott, has DBA authority with the creator of a in call A's runtime. Causes the Dbms_sql to fail the caller privilege protection mechanism.

2.DBA the function or stored procedure created by the account assigns execution permissions to public. If the Execute permission of a is not public,scott at all, the A cannot be called, and no subsequent exploits will occur.

3. Restrictions on input parameters and defense are not enforced, which makes certain non-predictable parameters.

4. The user's identity is not judged. To enhance the identification of the user can prevent the low-privileged user from illegally extracting the rights to a certain extent.

Vulnerability Protection recommendations

The following are some of the things you can do to protect against database vulnerabilities:

1. You do not create a vulnerability by using a more secure function or stored procedure. You can use Dbms_sys_sql instead of dbms_sql.

The author found dbms_sys_sql in practice. Parse_as_user This stored procedure can replace Dbms_sql. Parse this dangerous stored procedure. Parsing call relationships is not difficult to discover Dbms_sql. Parse and Dbms_sys_sql. Parse_as_user actually calls the Icd_parse in the Dbms_sys_sql. But the difference is that the calling Icd_parse has a different parameter.
Dbms_sql. The parse call is:

Icd_parse (C, STATEMENT, Language_flag MOD Parse_as_user_flag, NULL);
and Dbms_sys_sql. The Parse_as_user call is:

Icd_parse (C, STATEMENT, Language_flag MOD Parse_as_user_flag + parse_as_user_flag, USERID);

It is not difficult to compare the two carefully to find the last parameter userid is different. Dbms_sql. Parse corresponds to NULL, and Dbms_sys_sql. The parse_as_user corresponds to the userid of the current user. Use UserID to determine whether the current user's permissions can parse the statement, rather than run-time permissions to determine whether the statement can be resolved.

The comparison shows that the stored procedure Q uses Dbms_sys_sql. Parse_as_user, the stored procedure p uses dbms_sql. PARSE. The only difference between the stored procedure p and Q is that Dbms_sys_sql is used separately. Parse_as_user and Dbms_sql. Parse to parse the SQL statement.

650) this.width=650; "src=" http://www.dbsec.cn/aq/gjjs/images/20160329-6.jpg "alt=" 20160329-6.jpg "/>

The stored procedure p successfully implemented DBA advance operation. The stored procedure Q uses Dbms_sys_sql. Parse_as_user, successfully prevented the low-privileged user from the power-up operation.

650) this.width=650; "src=" http://www.dbsec.cn/aq/gjjs/images/20160329-7.jpg "alt=" 20160329-7.jpg "/>

2, the use of third-party database security hardening products and solutions

The best solution to a known database security issue is to upgrade the database, but there are many risks and complex preparations for upgrading the database. Even a series of complex tests, such as upgrade testing, minimized testing, functional testing, integration testing, performance testing, capacity and load stress testing, can still lead to difficult-to-predict problems for some applications or components.

In the case of not upgrading the database itself, you can use virtual patching (Vpatch) technology to complete the protection of database system vulnerabilities. Database virtual patching technology is generally integrated in the database firewall products, can effectively prevent through the database itself vulnerability to the database attack behavior. Effectively solve the production scenario under the database upgrade is not timely to the user's database potential threat. In order to achieve the security standard of the database, the bug is patched and protected without the deep operation of the database.

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

How to get DBA authority through Dbms_sql