Database Reference
In-Depth Information
myi:=sys.dbms_sys_sql.open_cursor();
sys.dbms_sys_sql.parse_as_user(myi,'grant dba to attacker',dbms_sql.native,0);
sys.dbms_sys_sql.close_cursor(myi);
end ;
/
To cure the above limitations, commercial third-party vendors have attempted to produce better security
monitoring solutions. Database activity monitoring systems (DAMS) are now commercially mature so that most of the
players in this market have been bought by larger companies. To generalize, they can be categorized generally as follows:
•
Shared Memory monitoring
- McAfee (Intel) and AppSecInc (Trustwave)
•
Network monitoring
- Guardium (IBM) and Imperva
Network monitoring becomes less useful now that Oracle has made network encryption free of charge.
Also, advanced attacks using tools like Meterpreter (Metasploit) will hook into memory, and third-generation
rootkits reside within memory, thus making memory-based security monitoring more important in high-security
environments. But both methods have their place, as in-depth strength reduces risk throughout all the components of
a system, including network and memory.
It is also possible to reduce a lot of the security risks using free tools, especially through judicious use of
monitoring from the root Unix account.
Additionally, Unix allows you to write new checks not currently included in third-party solutions. So, for
instance, a free solution to the problem of rootkits that I have written for this topic is an on-host integrity check
timed to run before and after the break-glass session to verify that key binaries and database objects still have a
known-good state. We will do exactly that in Chapter 15. First, let's discuss Unix access to Oracle (by Unix I mean
Unix, UNIX, Linux, and BSDs).
Unix Access to Oracle
One of the greatest advantages of Oracle database over rivals such as Sybase is the ability to access Oracle directly
from the operating system without a DB password. This is especially useful for automated cron jobs, which can access
from “root” to “oracle” Unix without the need to set up passwords and without the ability for DB sessions to stop that
job. As well as convenience, the passwordless access from
"oracle"
to SYS provides a non-negotiable method of truly
enforcing security because the Oracle DB can't lock out the securing process. Remember that when using wallets, a
DB session can DoS a wallet, thus preventing the automatic scripts from running. From a root cron job, then su'ing to
"oracle,"
the DB has very little choice over whether the security check will run or not, thus the security is enforced.
The alternative to cron'd scripts is use of Oracle wallet with autologin. This has been improved upon from the
situation of being able to copy the wallet from machine to machine and log on remotely. The wallet can be tied to
the machine by the use of the
auto_login_local
command line option, which ties the credential to that server using
orapki
command. Details of the
auto_login_local
improvement can be referred to via Doc ID 1114599.1, entitled
“How to Prevent the Secure Password Store Wallet from Being Moved to Another Host.“
The following code demonstrates
how to use the
-auto_login_local
parameter to the
orapki
command in order to affix the wallet to that host:
orapki wallet create -wallet . -pwd "welcome1"
-auto_login_local
mkstore -wrl . -createCredential <service_name> <user> <password>
sqlplus /@service_name
Use of
-auto_login_local
means that you can prevent the attack I discuss in my blog post at the following URL,
which is essentially to copy the wallet from the production machine to the attacker's machine:
