Oracle Databases: Some Simple Security Steps!

BANGALORE, INDIA: Databases are secure enough, or at least they can be made secure by employing encryption and other standard techniques. Every data admin thinks that way! So more often than not, majority of the database administrators will happily install a new Oracle database, port the schemas and data to it and proceed worry-free, unaware of the potential threats and risks involved.

Talk about security? Well yes, they do follow the usual routines such as keeping the software updated with the latest update patches, using hard-to-guess passwords and perhaps employ that odd bit of encryption. Apparently, with just a few minor tweaks, database admins can go beyond that and make their data secure.

Oh No! those abundant privileges

Not so long ago, in Oracle 10g, the privilege to read/write across the network without even using the command line was given to every user, by default. For instance, with execute privileges on the UTL_TCP database package, a user could do virtually anything with TCP/IP — alter/modify web pages, download/edit entire website, and of course generate spam — all without the knowledge of the database administrator.

And ever since Oracle 11g-R2, such execute privileges on UTL_TCP, UTL_HTTP and UTL_SMTP have by default been made PUBLIC, that is, accessible to all database users. Therefore, such privileges won't work unless a database administrator himself allows the database to connect and resolve the network access layers (using the DBMS_NETWORK_ACL_ADMIN package). Sounds secure? Not yet. What if a user installs his own Oracle database and becomes the SYS user, simply to spam others? The remedy? Simple! Restrict the PUBLIC access privileges to the minimum.

Where are you, SCOTT!

We all know Oracle has a demo user named SCOTT with the password TIGER. Little do we notice that this demo user has CREATE TABLE, CREAT DIRECTORY privileges and access to the UTL_FILE package. Thus, logically, SCOTT can map a directory to the $ORACLE_HOME/sqlplus/admin directory and replace the glogin.sql script with one that contains malicious code, such as a command like “GRANT DBA TO SCOTT”. In all versions of Oracle, both glogin.sql and login.sql run whenever an admin logs in.

Click here to read more!