Database Reference
In-Depth Information
The assumption within the security community is that OS access as any of the above OS groups is likely to result in the
ability to access the DB as SYS. OS files that can be used to gain that escalation are listed below and therefore need to
have their Unix permissions as tight as is functional. That may mean removing the ability of
"oracle"
Unix to write to
some of these files directly:
•
config.c
- Attacker could change the effective osdba group from “dba” and access as OSDBA.
•
orapwd<sid>
- Attacker could add a new SYSDBA or change the SYS password.
•
*.sso
wallet - Attacker could copy and edit the wallet, or delete it to remove security checks.
•
sqlnet.ora
- Can change the server parameters, such as removing encryption from SQL*NET.
DBVAULT binaries - Attacker could turn off DBVAULT.
•
•
Oracle binary itself - Attacker could add a backdoor to the DB binary itself
•
glogin.sql
- Attacker inserts SQL to create new DBA account, which will be executed by all.
•
SQL*PLUS
- Backdoor sqlplus to run arbitrary SQL.
•
system01.dbf
- Dictionary data files themselves, which contain the DB objects and the
permissions tables, can edit privileges in the
system01.dbf
data file directly. The system
tablespace cannot be set to “read only.”
As you can see, splitting high privilege is not an effective control. The alternative is time-based access control
systems such as break-glass, which do the following:
1.
Associates a personal identity with the use of a privileged system account for a specific
time window (e.g., Fred was SYS on Tuesday).
2.
Requires pre-authentication of that individual and blanket pre-authorization before being
able to check out that system credential.
3.
Requires post-incident approval from line of management after that specific checkout on
the basis of the work that was required and done.
4.
Automatically changes all system passwords to a new random value every day, from a
centralized software PAC “robot,” thus forcing DBAs to check out the current value from
the break-glass server.
5.
Enables emergency access and maintenance through a separate account used to reset
admin password in the event of the password becoming “out of sync”.
This type of system is already in place within financial institutions and some medical facilities, but the major
weakness of this type of system is that the high-privileged session can be used to install a backdoor that persists
indefinitely afterwards.
Let's recap with this summary of potential protections against backdoor installation during privileged sessions:
Centrally monitored terminal hub
- inconvenient, can be bypassed, and is a single point
of failure (discussed in previous chapter)
Native auditing
- can be turned off by SYS privilege either with a normal restart or by
oradebug poking the audit memory address to off
Security monitoring to alert to installation of a rootkit
- bypassed by network encryption, and
obfuscated and does not understand SQL traffic (Oracle's DB firewall is better in this respect)
We have already discussed the pros and cons of centrally monitored hubs for PAC, so now let's do the same for
auditing and monitoring.
