Database Reference
In-Depth Information
For instance, it is reported that when load balancing is implemented on 12c with container databases enabled,
there are issues in reliably identifying which container is being connected to. There is, at the date of writing, a new
patch for 12.1 that addresses some of the initial teething issues, but as 12c moves towards a second major release
(12.2) with a stable code base, the biggest challenge will be that of controlling the highest privilege that DBAs most
often use, that of SYSDBA.
12c has improved by separating out the privileges of SYS, but JAVA_ADMIN can run operating system commands
as the Oracle software owner. JAVA_ADMIN can thus add an attacker's SSH key to the Oracle key ring and log on as the
Oracle owner. Or the JAVA_ADMIN role can overwrite .bash_profile and the standard glogin.sql to run commands
as if they were being executed by the Oracle software owner. Nearly all the *ANY* privileges can be escalated, and even
ADVISOR monitoring privilege can be escalated as shown previously. So sub-dividing SYS does not prevent privilege
escalation or the uncontrolled use of SYS. Oracle's solution to controlling SYS is Database Vault.
Database Vault
Database Vault is a cost option that can be turned off from “ oracle ” Unix. “ Oracle ” commands can be run by either
JAVA_ADMIN or by CREATE TABLE privileges from within the database. This is the command using the Oracle binary
located in $OH/bin :
ch opt disable dv
The key thing to know is that Database Vault can only be turned off when the database instance is down.
Therefore, the attack process for turning off Database Vault from the database would be to first reverse a shell back
from the database to the operating system and then back to the attacker's terminal. That way the instance can be shut
down, then the commands can be issued to turn off Database Vault, and then the database can be restarted.
An example of how to reverse an “ oracle ” Unix shell back from CREATE TABLE privilege is shown in this following
paper, and the same principle can be applied to JAVA_ADMIN privilege in order to turn off DV. To make DV secure
it would make sense to require root privilege in order to turn it on and off. Relying on DB sessions not being able
to execute “ oracle ” Unix commands is not a good idea. I demonstrate how to reverse a shell using CREATE TABLE
privilege in my blog post at:
http://www.oracleforensics.com/wordpress/wp-content/uploads/CREATE%20TABLE%20to%20OSDBA%20reverse%20
shell.pdf
Even if the data files are encrypted using TDE and then controlled by Database Vault, it is still possible to grep
through /dev/shm/ora_orcl_* files for the plaintext version of that data, so it really is quite difficult to control the
Oracle software owner under Unix. Instead of giving DBAs the software owner login and having them come into the
database as SYS, the quest for 12c designers has been to implement the least privilege by separating out sub-privileges
at the operating system level.
Splitting SYS at the OS in 12c
SYSDBA is the “top dog” database privilege and is commonly accessed from the operating system to enable backups,
key management, database creation, and startups, as previously outlined. In 12c Oracle has attempted to sub-divide
SYSDBA/OSDBA into smaller chunks of privilege. The idea is that an OS group will be able to map to a privilege lower
and more specialized than SYSDBA.
 
Search WWH ::




Custom Search