Intelligently Securing a Large,

Globally Distributed, Database Estate

UKOUG 2012
Paul M. Wright
With input from and thanks to Philip Weeden

1
 Plan
1. Organisational security – business value

2. Top 10 – executive summary of Oracle security

3. SYS Security – mission impossible?

4. 12c? Cloud Security –future of Oracle Security..

With “real-world” examples

Paul M. Wright OracleSecurity.Com 2
 Organisational Oracle Security
• How does Oracle Security fit into the organisation?
• NGS > Betfair > Markit > JPMC
1. Avoid being hacked - loss of share value – takeover
2. Keep internal control
3. Preparation to Pass audit (business driver is PCI, SAS70, Internal
Audits), framework to achieve 1 and 2.
• Large estates need shortlist of controls that are
– Scalable
– Measurably by audit
– Clearly of benefit to all
• Implemented by DBA UDMs in EM
• Unbiased Verification
– State checking of DBA views to to verify controls in place
– Audit trail to verify controls are working
Paul M. Wright OracleSecurity.Com
3
 Auditing to verify controls
• Auditors like logging– prereq for SOX/PCI
• For example - which account DBAs actually use?
• Create low priv account for them but all logon SYS!
• Audit trail will show these logons
• Use centralised syslogging for SYS actions
• 12c has a LAST_LOGIN column in dba_users – nice,
though the audit trail is becoming proprietorised
Top 10
1. Previous Large guides – Prioritisation and summary
->What you should be doing already - 5
2. Newer research - Risk based analysis
->Currently considering – 5 Actionable deliverables>>>
Paul M. Wright OracleSecurity.Com
4
 TNS open through firewall- 10
• More common than you would imagine
• tnsnames.ora is a client file
• Must assume that anyone and everyone has it
• Googlehacking for tnsnames.ora
– https://www.google.com/search?q=filetype%3Aora
• A lot of these are honeypots, but lots aren’t… Reasons??
– Datacentre move
– Mergers
– Firewall config not loaded correctly
• Regularly physically verify that the TNS port is not open on the
external firewall
• Both Ingres and Egres! Extrusion and reverse shell
• Who is responsible for doing this?
– Often DB Sec staff feel that they are not allowed. Why?
– Organisational. Should be Ok to verify. Please do this.
Paul M. Wright OracleSecurity.Com
5
 Unix Access- 9
• Unix security is foundation for DB security
• Can clients putty directly to the host OS
bypassing app and logon as oracle/oracle?
• Then can edit the binary to install backdoor
• Keep DBAs in OSDBA group but they can come
back out of the DB as ‘oracle’ process
• e.g. Create any directory to sysdba – remove
all public directories (note .sh listable)
• Consider the DB as a firewall to the OS
Paul M. Wright OracleSecurity.Com
6
 Application Account- 8
• App accounts commonly owned by separate team
• What if username==password on the app account?
– App owners may not want to change the pw as their apps
and scripts may break
– DBA gets blame as they have a DB account that is weak
– Organisation accountability has to be clear
– App team should be scored down for this
– Make them sign-off on the risk..
• External Attacker will come through the app
– Least privilege
– 12c has excellent new features e.g. Zero priv app
accounts
Paul M. Wright OracleSecurity.Com
7
 Public Privs to Revoke- 7
• No Deny, so bias > too many privileges in Oracle
• Revoke public execute
– Most well known
• Utl_file
• Directories public execute
• Dbms_jvm_exp_perms
– Doesn’t necessarily require the patch
– Manually Revoke Public execute –
• Easily measurable and scalable
• To see how the PUBLIC role is created:
$ORACLE_HOME/dbhome_2/rdbms/admin/dsec.bsq
• Main excuse for PUBLIC role privs - only role for Definer’s rights
• Definer’s rights has roles disabled – except for public
• 12c has real Definer’s rights roles. Great!
Paul M. Wright OracleSecurity.Com
8
 Default Passwords- 6
• Oracle has many accounts made highly usable
– Default password list at Pete’s site
– CIS guide prioritises top 30 to check
• Common gotchas are…
– Upgrade will re-enable e.g. wksys
– New app will introduce (toad/toad and perfstat)
– Expire as well as locking
– Remove preferably – support SR
• select * from dba_users_with_defpwd
• Select privs narrowed down on this view in 12c
Paul M. Wright OracleSecurity.Com
9
 Research - Oradebug- 5
• Oradebug used to directly read and write
memory
• Accessible by SYSDBA locally and remotely
through SQL*PLUS
• poke a memory address like on spectrum
• Lazlo Toth extended this here
– Silently turn off auditing (but lose noise..)
– Turn off all authentication – interesting!
• Who checks that the wrong password does not work?
• Complete lack of failed logons is suspicious sign
Paul M. Wright OracleSecurity.Com
10
 TNS Poisoning-4
• Can proxy between listener and Instance in RAC
• Man in the middle attack
• Architectural design issue for a long time
• Solutions
1. Use IPC but only single node
2. Turn off Dynamic registration but loss of availability
3. Restricted valid nodes but need to know all IPs
4. ASO/SSL – now free for RAC but quite high labour
• New builds should use ASO aka COSTS for RAC
(now freely licensed).
Paul M. Wright OracleSecurity.Com
11
 Database Links- 3
1. DBLink password decrypted through ku$_dblink_view
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

2. Max SCN DoS threat actually from 2009 , maintenance issue for high transaction estates

3. Anonymised reconnaisance through Links

between Prod/Dev and separate business unit subnets
Need to be able Identify incoming DBLinks: sys.aud$.comment$text (ref Tammy Bednar)
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)

Can forensically verify the above event even if the link is dropped by reading the hex from the SYSTEM01.DBF
See - http://www.oracleforensics.com/wordpress/wp-content/uploads/2012/11/database_link_security.pdf
Paul M. Wright OracleSecurity.Com
12
“Stealth password cracking”vulnerability-2
• Can crack hash without needing to logon
• Stealth (before audit trail starts) 05 logon
– http://marcel.vandewaters.nl/oracle/security/cryptographic-flaws-in-oracle-
database-authentication-protocol
– http://threatpost.com/en_us/blogs/flaw-oracle-logon-protocol-leads-easy-
password-cracking-092012
– http://www.openwall.com/lists/john-users/2012/09/29/2
• Fixed in 11.2.0.3 by reverting back to O3logon
• And Fixed in 12c with new version of the protocol
• Can secure against this by having a complex password
• This is controlled by Oracle profiles and verification-function
– Most important tool to reduce the greatest amount of real risk
• Which account would be the likely target?
Paul M. Wright OracleSecurity.Com
13
 SYS security - “Sys is special” - 1
• SYS is Guaranteed target! Always present and un-lockable.
– Password hash can be cracked remotely without logon
– Can be brute forced directly “Orabrute”
• SYS is least defended account in Oracle!
– No profiles on SYS so can’t enforce strong pw
– No failed logon delay - can brute force remotely quickly
– SYS can turn off it’s own audit with oradebug – SYS is Wild!
• Only defence is relying on DBA setting a strong password
• But DBA may not even be using the pw (osdba thru Unix)
• Remote SYS/SYSDBA pws cannot be verified as secure!
• The most important controls on the most important
account are unusable. This is bad and still in 12c!
Paul M. Wright OracleSecurity.Com
14
12c Cloud Consolidation – security risk
• 12c will have native encryption builtin–
– so less external threat….but..
• Consolidation of resources
– Also Many small databases plugged into a larger
centralised server
• -> Greater Internal threat.
– Saboteurism
– Staff collecting together crown jewels before move
– Sys can backdoor future access.
What’s the defence for the SYS account?
One answer is - Stop using SYS.. because it is “magic”?

Paul M. Wright OracleSecurity.Com

15
 SYS Security
SYS has to be used for many tasks:
1. Schema changes to SYS e.g. new password function.
2. Avoiding public Syns for executing packages.
3. DBMS_STREAMS_AUTH.GRANT_ADMIN_PRIVILEGE
http://kr.forums.oracle.com/forums/thread.jspa?threadID=540770
4. Dataguard and Grid
5. DBMS_CRYPTO
6. SYS.USER_HISTORY$
7. GRANT SYSDBA
8. Purge DBA recyclebin
9. Start and Stop DB (Sysoper as well)
10. dbms_lock.sleep
11. x$ tables for perf data
Not exhaustive..but you get my point…SYS security is not so simple.

Paul M. Wright OracleSecurity.Com

16
 How to Secure SYS?
1. Internal - Time based access control
• 15 char random pw under Breakglass
• Automatically reset by breakglass server daily
• Breakglass == Time-based access control
• Privileged access control management..
– OPAM and CyberArk’s EPV
• Problem -> 5 mins is enough to install a backdoor
• Need backdoor checker – work in progress…
• Objection to decreased efficiency caused
• Security measures are statically fixed at high level
• Perhaps security readiness should vary with threat
Paul M. Wright OracleSecurity.Com
17
 How to Secure SYS?
2. External - Adaptable Database Security
• Sys_throttler trigger, dbms_lock.sleep(1)on failed logons.
• Availability and performance objections..resistance to change..
• Turn on delay when higher threat level e.g lots of failed logons
• Use syslog to link databases audit trails together – mutual
protection – nearest neighbour audit trail. Decentralised.
• Triggers on the shared audit trail to increase failed logon delay
• Mutually Adaptable Database
• Already implemented and all the code is documented in paper
here… http://www.journalofdatabasesecurity.com/
• Concept really is -> We are more secure when we work together.
• Similar concept can be used for other security configs e.g.DBLinks
• Lessons learnt from project – database schedulers are unreliable
 Best to call DB jobs from *nix cron (or autosys)
Paul M. Wright OracleSecurity.Com
18
19
 Conclusion
• Database estates have relatively low probability of a hack,
but if it happens catastrophic!
• Low frequency and high impact like Nuclear power station
• In the future we have Mutually Adaptable Database Defence,
but now we have to keep steady attention or get burnt
• Role of audit processes important to keep us on our toes
• I succeeded in PCI, SAS70 and Internal preparations
> Every org needs a DB Security Architect!
- Either permanent or virtual i.e. consultant/contractor especially for
audit preparation.
PaulMWright@OracleSecurity.com
Questions and Thank You!

Paul M. Wright OracleSecurity.Com

20