SQL Injection em base de dados Oracle

SQL Injection is vulnerability here unsanitised user’s input is used in SQL calls. This vulnerability allows an attacker to retrieve sensitive in formation from a back-­- end database. The impact of this vulnerability can vary f rom basic information disclosure t o a remote code execution and total compromise of the back-­- end systems.

This changes the SQL logic and the query r eturns all r ows from table all_objects.

Exploiting SQL Injection

Exploiting SQL injection may have different meanings from one person to another. Someone may only be after the sensitive d ata within the database (e.g. credit card details), while the others may wish to execute operating system commands on the database host in order t o completely compromise the host. The remainder of this paper will discuss these e xploitation techniques:

1. Data Extraction

The following techniques are currently known to extract data from the back-­- end database by exploiting SQL Injection from web applications:

1. Error Messages Enabled:

When the database error messages are enabled, an attacker could return the output of an arbitrary SQL query within the database error message. A number of functions (executable by the ‘public’ role) can be used for this:

Select * from all_objects where object_name =‘’ and 1=utl_inaddr.get_host_name((select user from dual))--‘

query will throw an error which will have t he output of the query which the attacker wanted to execute:

Warning: ociexecute() [

function.ociexecute]: ORA-29257: host SCOTT unknown

ORA-06512: at "SYS.UTL_INADDR", line 4 ORA-06512: at "SYS.UTL_INADDR", line

35 ORA-06512: at line 1 in C:\wamp\www\ora2.php on line 13

While this technique will work in Oracle 8, 9 and 10g, this will fail in 11g. This is due to enhanced security features in 11g which implements ACLs on p ackages which require network access s uch as UTL_HTTP, UTL_INADDR etc.

The limitation of this technique is that the query injected by the attacker must match the original query in number of columns and their corresponding data-­-types.

b) Blind Injection

Using this method an attacker will not directly see the output of the query he wants to e xecute. To enumerate the output, he needs to use a set of logical statements based on t he application’s responses. For example:

Based on the 3 responses above it can b e deduced that the output of query "select user from dual" is SCOTT.

Tools

Sqlmap, Bsqlbf, Bsqlhacker, Absinthe etc. : There are a number of tools publicly available to exploit blind SQL injection in Oracle. E.g.

c) OOB Channels

Using this method, the information is being sent to an attacker-­- controlled server using the network or the file system. There are a number o f functions available under Oracle 8, 9 , and 10g (R1 and R2) to achieve this.

UTL_INADDR.GET_HOST_ADDRESS

E.g. An attacker can make the database server issue a DNS resolution request for host

This one single request will make the database server recursively do a DNS lookup for all rows within the table. This will send all the card numbers (CCnumber) along with the corresponding first name (fname) and last name (lname) from Creditcard table to attacker’s site in HTTP r equests. These are the logs which the attacker will find in his web server’s access logs.

The restriction posed by this technique is that the outbound traffic f rom the database host should be allowed on the firewall. In practice, DNS is usually allowed and hence this technique is very useful.

SYS.DBMS_LDAP.INIT

As noted earlier, the enhanced security features introduced in 11g prohibit ‘public’ from executing packages which could cause a network connection. H owever, David Litchfield in his recent Blackhat talk showed another function (executable by public) that can be used to conduct an OOB attack under 11g.

If the SQL Injection is not w ithin a SELECT statement (e.g. INSERT Statement), then although the query injected by the attacker will get executed on the database server, it may not be possible to manipulate the output of the query as the HTTP response returned by the application will not differ.

Further, if the database has egress filtering enabled then the OOB attack will not be successful. This method is perhaps the last resource available to extract the output of the SQL query.

The application performs an insert query on the user supplied input and displays the same message "Thank You For Your Submission" irrespective of whether the query executed successfully or not. This makes it difficult to manipulate the output of logical statements issued by the attacker and hence the blind injection technique will fail here.

MS-­- SQL and MySQL have functions which can be called to make the database server sleep for a certain amount of time. Thus the output of the injected SQL query can be manipulated depending upon the time taken by the database/application server to respond. However, as there is no such function available in Oracle, a similar approach is to make the database issue a heavy query which will result in a time delay. T he end result is that the logical s tatements issued by the attacker can be manipulated as true or false d epending upon the time taken for t he HTTP response.

The above 2 requests show that the output of the attacker’s query is SCOTT

Privilege Escalation

The abovementioned techniques will allow an attacker to obtain the output of an arbitrary SQL query. The important thing to understand here is the privileges with which an attacker’s query gets executed. There can be 2 b road categories here:

1. Privileged SQL Injection

2. Un Privileged SQL Injection

1. Privileged SQL Injection:

By Privileged SQL Injection I imply that the attacker’s query gets executed as SYS user (or with DBA privileges) and thus he has access to entire database. There can be quite a few possibilities such a s:

1. Connection String has a privileged User.

2. SQL Injection is in a stored procedure which gets executed as SYS (or with DBA privileges).

Stored procedures in Oracle by default get executed with definer rights. Thus, if SYS has a vulnerable procedure which SCOTT can execute, than SCOTT can execute SQL queries as SYS.

Example:

create or replace PROCEDURE

SYS

.countpass(name IN VARCHAR2, message out varchar2)

AS

str varchar2(500);

BEGIN

str :='select count(PASSWORD) FROM SYS.USER$

WHERE NAME like ''%'||name||'%''';

Execute immediate str into message;

END;

/

Grant execute on SYS.countpass to SCOTT;

This procedure can be called from a web application. The following PHP code (ora6.php) demonstrates this:

$conn = oci_connect('SCOTT','TIGER') or die;

$sql = 'BEGIN SYS.countpass(:name, :message); END;';

$stmt = oci_parse($conn,$sql);

// Bind the input parameter

oci_bind_by_name($stmt,':name',$name,1000);

// Bind the output parameter

oci_bind_by_name($stmt,':message',$message,1000);

// Assign a value to the input

$name = $_GET['name'];

oci_execute($stmt);

// $message is now populated with the output value

print "$message";

?>

In this example although P HP uses bind variables it does not help a s the procedure is still vulnerable. Further, although the application connects to the database as an unprivileged user ( SCOTT), the injection point is in a procedure owned by SYS and therefore t he attacker c an e xecute SQL queries as SYS.

This implies that the attacker can run SQL as SYS user (access sys.user$ table) and the example demonstrates how an attacker can o btain the password hash of SYS user using b lind injection technique described earlier. What if the attacker wants to execute DDL/DML Statements such as ‘GRANT DBA TO PUBLIC’? Oracle database poses a number o f problems in e xecuting DDL/DML statements when exploiting SQL injections from web applications mainly because Oracle by design does not support nested queries.

In order to achieve t his, we must find a function which could either directly take PL/SQL and execute it as a feature or find a function which is v ulnerable to PL/SQL Injection.

David Litchfield recently showed a few functions which could allow an attacker t o achieve this:

SYS.KUPP$PROC.CREATE_MASTER_PROCESS

Affected Systems: 11g R1 and R2 (0 day)

Description:

The execution of a PL/SQL statement within this function is a feature and not a bug.

This function is not executable by PUBLIC. Any user with DBA r ole can execute this function. As our injection point was in a procedure owned by SYS, we can execute this function.

This query will now fail a s the injection is u nprivileged and the user SCOTT d oes not have access to the sys.user$ table. If the error messages are enabled on the application then the following error will be displayed:

Warning:

oci_execute() [function.oci-execute]: ORA-00942: table or view

does not exist

ORA-06512: at "SCOTT.countobject", line 8 ORA-06512: at line

1 in

C:\wamp\www\ora7.php on line 18

This is where things start getting "interesting". Those of you familiar with MS-­- SQL may recall that MS-­- SQL has a feature called Openrowset which ( if enabled) could allow an attacker to brute -­- force/guess ‘SA’ password and then run SQL queries as ‘SA’.

In Oracle a similar privilege escalation can be achieved under certain circumstances. At the time of writing this paper the following t echniques are publicly known1:

: This package has had number of functions vulnerable to PL/SQL Injection. These

functions are owned by SYS, execute as SYS and are executable by PUBLIC. Thus, if the SQL Injection is in any of the u n-­- patched Oracle database versions mentioned above then the attacker can call this function and directly execute queries as SYS.

While an effort h as been made to collect a ll p ublicly known techniques, it may be possible that there a re

other privilege escalation techniques known.

BEGIN EXECUTE IMMEDIATE ''''

grant dba to

public

'''';END;'';END;--','SYS',0,'1',0)--

This request will result in the query ‘GRANT DBA TO PUBLIC’ getting executed as SYS. This function allows PL/SQL because of a flaw (PL/SQL injection) .Once this request is successfully executed, the PUBLIC gets DBA role thus escalating SCOTT’s privileges and now our SCOTT user can query sys.user$

Bsqlbf has this feature of doing privilege escalation first and then extracting data with DBA privileges. After extracting data it revokes the DBA role from PUBLIC.

While there are no other publicly known techniques by which a n attacker can become DBA from ju st CREATE SESSION privilege by exploiting SQL injection from web applications, t here are still a few attack vectors with which an attacker can execute operating system commands without having DBA role (with JAVA privileges). This is discussed below.

3. OS Code Execution

The following attack vectors are currently publicly known for executing operating system commands against the Oracle database while exploiting SQL injection from web applications:

The list of java permissions available to the user can be obtained by issuing the following query:

select * from user_java_policy where grantee_name ='SCOTT'

3. With SYS Privileges

As noted under the section Privileged SQL Injection, when the injection point is in a procedure owned by SYS (AUTHID Definer), t hen the attacker can use a number of functions for executing Operating System Commands, including the 2 techniques mentioned above (DBMS_EXPORT_EXTENSION, JAVA Privileges). However, another way to achieve this is by using DBMS_REPCAT_RPC.VALIDATE_REMOTE_RC. As noted earlier, this was fixed in January 2009 by Oracle.

DBMS_REPCAT_RPC.VALIDATE_REMOTE_RC

Affected Versions

: Oracle 8, 9,10g R1, 10g R2, 11g R1 (Fixed in CPU July 2009)

Privilege required

: SYS

Description

: As noted earlier this function is not available to ‘public’ and can only b e executed by SYS user. Hence only a SQL Injection in a procedure owned by SYS can call this function. As this function is vulnerable to PL/SQL injection, it can be used to execute O S code by a number of methods s uch as:

If the injection point is such that the attacker’s q uery gets executed with D BA privileges then he can use this function to execute OS code.

SYS.KUPP$PROC.CREATE_MASTER_PROCESS

Affected Versions:

11g R1 and R2 (0day at the time of writing)

Privilege required:

DBA2

Description

: While the VALIDATE_REMOTE_RC was fixed by Oracle in J uly 2009,

DBMS_EXPORT_EXTENSION in 2006 and DBMS_JAVA (DBMS_JAVA_TEST) will be fixed soon, this one is still un-­- patched and works on 11g (R1 and R2). As noted earlier, the PL/SQL execution from this function is a ‘feature’ and not a bug. Hence, if Oracle does not patch/remove this function, this may be one universal way for executing OS code when exploiting SQL Injection from web (injection point in procedure owned by user h aving DBA role). As I have already shown OS code execution by J ava, let’s take a different approach this time. The example below shows O S code execution based on DBMS_SCHEDULER (all oracle versions, including XE):

In Oracle there is another class of vulnerability which is similar to SQL Injection but more dangerous. This happens when unsanitised user’s input is used in construction of an anonymous PL/SQL block which then gets dynamically executed.

Let’s look at one such example:

CREATE OR REPLACE PROCEDURE SCOTT.TEST( Q IN VARCHAR2) AS

BEGIN

EXECUTE IMMEDIATE ('BEGIN '||Q||';END;');

END;

The following php script (ora9.php) calls this procedure:

$conn = oci_connect('

SCOTT','TIGER') or die;

$sql = 'BEGIN

scott.test(:name); END;';

$stmt = oci_parse($conn,$sql);

// Bind the input parameter

oci_bind_by_name($stmt,':name',$name,1000);

// Assign a value to the input

$name = $_GET['name'];

oci_execute($stmt);

?>

In this example the v ulnerable procedure is owned b y SCOTT (hence unprivileged). A lthough Oracle does not support nested query in SQL, it does so in PL/SQL. Hence exploiting this is quite straightforward.

Privilege Escalation

Whatever we inject within this PL/SQL Injection, it will get executed either with the privileges of the procedure owner or invoker (AUTHID DEFINER or CURRENT_USER respectively defined w ithin vulnerable procedure). However, as now we can issue nested queries, t hen we can exploit the vulnerable packages held within the back-­- end database to escalate privileges. David Litchfield recently showed a 0 day by which a user with just CREATE SESSION privileges can become DBA (applies to 10g R2, 11g R1, 11g R2), so let’s use the same a ttack vector to e xploit this vulnerability and first grant our user java IO privileges.

This will grant Java privileges to our SCOTT u ser (only create session privileges are r equired). With these privileges we can become DBA (if we want) or just directly execute Operating System Commands.

Sumit Siddharth (Sid) works as a principal security consultant for 7 Safe where he heads the Penetration Testing department. He specialises in application and database security and has been a speaker at many security conferences including Defcon, Troopers, OWASP Appsec, Sec-­- T etc. He also runs the popular IT security blog.http://www.notsosecure.com