Database Vault Without Database Vault

This is my presentation to the UKOUG last December on using a different method to assess whether PL/SQL code is vulnerable to attack. This method is similar to what an attacker may do

Slide 1 - Database Vault Without Database Vault

Database Vault Without Database Vault

Slide 2 - Legal notice

Database Vault Without Database Vault

Published by
PeteFinnigan.com Limited
Tower Court
3 Oakdale Road
York
England, YO30 4XL

Copyright © 2025 by PeteFinnigan.com Limited

No part of this publication may be stored in a retrieval system, reproduced or transmitted in any form by any means, electronic, mechanical, photocopying, scanning, recording, or otherwise except as permitted by local statutory law, without the prior written permission of the publisher. In particular this material may not be used to provide training of any type or method. This material may not be translated into any other language or used in any translated form to provide training. Requests for permission should be addressed to the above registered address of PeteFinnigan.com Limited in writing.

Limit of Liability / Disclaimer of warranty. This information contained in this course and this material is distributed on an “as-is” basis without warranty. Whilst every precaution has been taken in the preparation of this material, neither the author nor the publisher shall have any liability to any person or entity with respect to any loss or damage caused or alleged to be caused directly or indirectly by the instructions or guidance contained within this course.

TradeMarks. Many of the designations used by manufacturers and resellers to distinguish their products are claimed as trademarks. Linux is a trademark of Linus Torvalds, Oracle is a trademark of Oracle Corporation. All other trademarks are the property of their respective owners. All other product names or services identified throughout the course material are used in an editorial fashion only and for the benefit of such companies with no intention of infringement of the trademark. No such use, or the use of any trade name, is intended to convey endorsement or other affiliation with this course.

Slide 3 - Background

Pete Finnigan – Background, Who Am I?

• Oracle Security specialist and researcher
• CEO and founder of PeteFinnigan.com Limited in February 2003
• Writer of the longest running Oracle security blog
• Author of the Oracle Security step-by-step guide and “Oracle Expert Practices”, “Oracle Incident Response and Forensics” books
• Oracle ACE for security
• Member of the OakTable, SYM 42
• Speaker at various conferences UKOUG, PSOUG, BlackHat, more..
• Published many times, see http://www.petefinnigan.com for links

Slide 4 - Agenda

• Part 1
• What is Database Vault?
• Components of Database Vault?
• Hacking with Database Vault
• Part 2
• What can we do to simulate the features of Database Vault without Database Vault
• What is possible for free?

Slide 5 - What is Database Vault?

What is Database Vault?

Slide 6 - What Is Database Vault?

• Declarative security framework to allow fine grained access to database objects (tables, views, procedures…) grouped into realms
• Literally unlimited context based security rules can be added to control access to any (well almost any) database object or command
• Default use is to protect against SYSTEM ANY privileges
• Because it is “built-in” to the database kernel it is harder to bypass
• Pre-built shipped realms protect risky parameter changes and the data dictionary and more
• Separation of duties are added by default by creation of a security administrator, user account manager and vault owner
• SYS, SYSTEM and DBA are restricted in value
• Basic default hardening done on install

Slide 7 - Duct Tape?

• Is Database Vault really duct tape?
• Most sites use bad data security designs; excessive rights, lack of data access controls
• DV could be seen as duct tape to prevent these bad designs (threats) becoming risks
• At its core, DV is solving issues that could be solved differently
• Design least rights – revoke privileges – do not use System ANY
• SoD can be done with careful design of users and other simple protections
• Partly issues are caused also by process; “way of working”

Slide 8 - Main Database Vault Components

Main Database Vault Components

Slide 9 - The Main DV Components

• Factors
• Individual elements to use in rules (e.g. IP Address)
• Rules
• True/False questions for the database
• Rule Sets
• Groups of rules (Also results in True/False – with AND/OR)
• Realms
• Protect database objects (uses rules, factors)
• Command Rules
• Protect access to SQL commands (e.g. CONNECT) (uses rules, factors)
• Secure Application Roles (SAR)
• Protective access to enable a role (uses rules, factors)

Slide 10 - Hacking with Database Vault?

Hacking with Database Vault?

Slide 11 - Hacking The Sample Database With Realm

As an un-athenticated web user

Slide 12 - Hacking The Sample Database With Realm

As a low power database user

Connect to the database as a user with just CREATE SESSION and exploit a vulnerable package (CUSTA) owned by ORABLOG and read card details

Low privileged database user can see data in the BOF application

Slide 13 - Hacking The Sample Database With Realm

Connect as a DBA with the DBA role and simply select credit card details – no hacking needed as we use SYSTEM ANY

• DV has some effect BUT only for SYSTEM ANY
• BUT, the DBA could find a way around this by doing the same hack as a lower privileged user in the last slide

Slide 14 - Add A Mandatory Realm To ORABLOG Instead

Hmmm, the apps are now broken; we need to add ORABLOG to the realm but it defeats the object; if we hack the database again; same result

Slide 15 - DV Command Rule - Results

• The rules are not perfect as we have implemented properly only for Orablog and not BOF but BOF has no client tools installed
• The client_program_name is not set from the server so we have used instead Module – but it would be better to use the hash
• Implementing factors, rules, rule sets and command rules or rule sets for realms is a large task when a lot of controls are needed

Slide 16 - What Can We Do to Simulate DV?

What Can We Do to Simulate DV?

Slide 17 - What If: No Database Vault Available?

• If we do not have DV or It is not possible (i.e. SE/SE1/SE2) what can we do?
• Replicate the technical features of DV?
• Remove as much of the “problem” as possible that is solved by Database Vault?
• Start with a good security design
• Aim for least rights
• Aim for lock down
• Aim for proper data access controls
• Add context based security without DV
• Do not use defaults
• Consider application design changes
• Code and data access levels

Slide 18 - What Do We Need To Do To Replicate DV?

• There are a lot of features in DV that we could use: Declarative API’s, factors, realms, rules, SARs, Command rules and within these protect objects, commands, SoD, parameters and much much more…
• If we focus on three simple tasks to consider for replication:
• SET ROLE, DBMS_SESSION.SET_ROLE to be able to create a SAR
• ALTER SYSTEM to be able to detect a parameter change
• System ANY to detect use of SELECT ANY TABLE (for instance)
• There is no way (supported) to “Trap” SET ROLE, ALTER SYSTEM or SELECT ANY TABLE
• ALTER SYSTEM is DDL But it is not trapped by a DDL trigger
• There is no simple way to detect SELECT and act upon it in real time
• Some actions can be detected such as CREATE, ALTER, DROP and most DDL
• There are many gaps in available techniques in a core database to replicate Database Vault

We need a SELECT TRIGGER

Slide 19 - Blocking A Select Statement

Looks like a Realm!

Slide 20 - A Secure Application Role in SE

A Secure Application Role in SE

Slide 21 - What Can We Do for Free?

What Can We Do for Free?

Slide 22 - But What Are We Really Trying to Achieve?

• Are we really trying to replicate DV in its technical functionality?
• Or are we really trying to replicate the results of applying DV?
• Or even do better?
• YES, We want to replicate the results not the technical design
• We can achieve this with:
• Careful security design
• Some code
• Privilege management especially around SYS, SYSTEM, DBA…
• We can do context based security without DV
• What is the risk trying to simulate DV?
• Should be low provided we have a good base design anyway

Slide 23 - Why Do We (Perceive We) Need System ANY

• Needed for development/deployment of code?
• Solutions used often is SYSTEM ANY for deployment as it is simple
• There is no grant select on orablog.tables.* so system ANY is a good replacement BUT gives access to all data (except SYS)
• What other solutions exist:
• Log on as the schema to deploy code
• Use SYSTEM ANY but via a schema/protected PL/SQL API that you create – complex and hard to maintain
• Direct grants on the schema objects but issues arise
• How to create new objects in the same schema
• Maintainability of rights
• Proxy to the schema

As an example of one DV feature

Slide 24 - Context: View Based Security

• We can create VIEW BASED security to limit access to read data
• A PL/SQL function allows tests to be made to check whether access is allowed or not
• We could also check in this PL/SQL whether the privilege used is SELECT ANY by checking the users actual rights
• This can block some ANY privileges
• BUT system ANY for select can access the base table. Solution:
• Revoke system ANY except for sys
• Block SYSDBA access – The first versions of DV did this

Slide 25 - Context: DML Based Security

• We can apply the same “Realm” type ideas to block DML
• This cannot be overridden as this is added to the base table and this is not view based
• Again we could check for System ANY in the PL/SQL code by looking at the callers rights
• We can also make a mandatory realm – in part at least with context based code

Slide 26 - Separation of Duties (SoD)

• Separation of Duties does not need DV to enforce it
• Even with DV real people and database accounts need to be designed and a SoD matrix created to ensure separation exists for all interactive users
• Identify and make decisions on separation
• Account Manager, Audit Trail Admin, Security Admin, Audit Viewer
• All of these can be implemented with design, least privilege
• Custom DBA role should be created
• SYSTEM should be locked, SYS should be blocked out as SYSDBA
• Reduce, remove SYSTEM ANY
• Use technical solutions to enforce security – DDL, ALTER… type system triggers
• Accountability and audit are needed

Slide 27 - Context: Blocking Parameter Changes

• Limit ALTER SYSTEM
• Audit use of ALTER SYSTEM
• Limit even from the DBA (should have custom role anyway and limited rights – NOT DBA, SYSDBA)
• Release SYS when needed but audit use of account
• Triggers on database start and stop to detect that a parameter has changed whilst database is up? – put it back?
• We could also protect spfile with chattr to make the file immutable but only on Linux

Slide 28 - Command Rule: Block SQL*Plus - Webserver

• We can perfectly replicate the protection we had in DV with a logon trigger
• We can also use valid node checking but this is not granular
• In this example the httpd still works but SQL*Plus from the webserver is blocked

Slide 29 - Conclusions

• Good security design is needed from the start
• Good lock down is needed from the start
• Don’t use SYSTEM ANY
• Don’t use SYS, SYSTEM and DBA
• Make changes via proxy to the schema
• Do not allow DBAs to look at data
• Database Vault is Duct Tape if you do not take care to lock down and secure your data first
• Even if you use DV it must be added on top of good secure design
• So we MUST ALWAYS DESIGN SECURITY FIRST before using additional tools such as DV or not with SE
• DV is built-in so harder to bypass

Slide 30 - Questions?

Any Final Questions?

Slide 31 - Database Vault Without Database Vault

Database Vault Without Database Vault