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_throttler and Distributed Database Forensics


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

2 Responses to “sys_throttler and Distributed Database Forensics”

  1. 1
    fredp:

    Why do you think SYS does not have profiles and failed connection throttling?

  2. 2
    Paul Wright:

    Hi Fred,
    Good question. I think it is because Oracle’s design priorities for the DB have always been performance and availability first, security second – which was understandable in the past but more recently is less understandable. Oracle spend a lot of money promoting extra security products as bolt-ons but have chosen not to act on feedback that the most privileged account is the least secured i.e SYS.
    Hopefully this can improve in future.
    Cheers,
    Paul

Leave a Reply

You must be logged in to post a comment.