Improving Practical Oracle Database Security Posture with guidance from Trustwave’s SpiderLabs! Part 2..

Trustwave Skillz Middle East Dr. Dieter Hovorka Stefan Magnusson SpiderLab Agnieszka Borkowska Paulina Skrzypińska

This is part two of a two part series. See part one first!

Recently I was tasked with analyzing and improving the security of an Oracle 12.1.0.2 database running on Solaris Operating system for a customer.

In part one we focused on updating outstanding software updates to reduce the exposure. This managed to reduce from 46 High Risk vulnerabilities down to 9!

?Trustwave’s AppDetectivePRO is a handy solution to scan the instance for any known vulnerabilities and misconfigurations for a multitude of databases, wherever you run it. Now we will focus on elimination the outstanding 9 High Risk issues.

Failed Login Attempts

The permissible number of failed login attempts can be specified when creating the profile using the CREATE PROFILE statement or later by executing the ALTER PROFILE statement. AppDetectivePRO lists all occurrences that needs to be updated:

To fix this, connect to the database and issued the below commands:

~> sqlplus connect as sysdba
SQL*Plus: Release 12.1.0.2.0 Production on Wed Jan 15 08:04:07 2025
Copyright (c) 1982, 2014, Oracle.  All rights reserved.
Connected to:
Oracle Database 12c Enterprise Edition Release 12.1.0.2.0 - 64bit Production
With the Partitioning, OLAP, Advanced Analytics and Real Application Testing options        

SQL> ALTER PROFILE DEFAULT LIMIT FAILED_LOGIN_ATTEMPTS 3;
Profile altered.        

SQL> ALTER PROFILE PROFILE_TEST LIMIT FAILED_LOGIN_ATTEMPTS 3;    
Profile altered.        

SQL> ALTER PROFILE EXTERNAL_USER_USER_PROFILE LIMIT FAILED_LOGIN_ATTEMPTS 3;
Profile altered.        

SQL> ALTER PROFILE AUTO LIMIT FAILED_LOGIN_ATTEMPTS 3;
Profile altered.        

SQL> ALTER PROFILE MAGMA_USER_PROFILE LIMIT FAILED_LOGIN_ATTEMPTS 3;
Profile altered.        

AppDetectivePRO can also generate these sql statements automatically by running a remediation "Fix Scripts" report as per below:

Next identified issue relates to database links.

After carefully reviewing the the list of users with access to read or modify the SYS.LINK$ table and revoking the permissions from any user that should not have access. I then manually instructed AppDetectivePRO to whitelist the permissible users:

EXECUTE on JAVA Packages GRANTED to PUBLIC

The PUBLIC role has been granted the EXECUTE privilege, this is considered a security risk.

SQL> REVOKE EXECUTE on SYS.DBMS_JAVA from PUBLIC;
Revoke succeeded.        

Privilege to execute UTL_FILE granted to PUBLIC

SQL> REVOKE EXECUTE ON SYS.UTL_FILE FROM PUBLIC;
Revoke succeeded        

Default database passwords found

Any accounts you do not need, should be deleted. Accounts that you do need should be renamed if possible.

Passwords should follow the following best practices in order to provide good security and prevent brute forcing attacks:

- Be at least 8 characters or more in length

- Can not be found in a dictionary

- Contain a combination of upper and lower case letters, numbers and special characters

- Are not the same or similar to the username

ADMIN_RESTRICTIONS flag not set

If the listener service is not properly protected, an attacker can read and write files on the operating system. To alleviate this issue, Oracle added a new parameter called ADMIN_RESTRICTIONS. The ADMIN_RESTRICTIONS flag disables the ability of the listener controller to set parameters, thereby not allowing remote users to set parameters. After setting this parameter, you must edit the listener parameters directly in the listener.ora file.

Fix Information: Set the flag by adding ADMIN_RESTRICTIONS_[listener name] = ON in the 'listener.ora' file. The [listener name] is the listener alias specified in the 'listener.ora' file. Then use the 'lsnrctl' utility to stop and start the Oracle listener or to reload the parameters. This will stop any value from being dynamically set.

TKPROF not removed from system

~> cd $ORACLE_HOME/bin
/u01/app/oracle12/product/12.1.0/db_1/bin> ls -all tkprof
-rwxr-x--x   1 oracle12 oinstall  127328 Oct 31  2016 tkprof

/u01/app/oracle12/product/12.1.0/db_1/bin> chmod o-x tkprof
/u01/app/oracle12/product/12.1.0/db_1/bin> ls -all tkprof
-rwxr-x---   1 oracle12 oinstall  127328 Oct 31  2016 tkprof
        

Patching addresses many vulnerabilities but not all.

Therefore it is extremely important to periodically review the security posture to make sure you are up to date with the monthly knowledge base.

Status after remediation:

We still have one High risk vulnerability left! Lets deep dive:

The Oracle version 12.1.0.2 on Solaris x86 does not receive any updates after October 2022, so either move it to the Linux, Solaris SPARC or AIX platforms or upgrade to a recent release like 19c for best protection!

I used the example of Oracle 12.1.0.2 database on purpose, to demonstrate that you may not be able to completely eliminate all known vulnerabilities due to life cycle or other unexpected relationships.

Conclusion: Hopefully this series of articles highlight the value of periodic scan of your databases to ensure they are as good as it gets when it comes to static defense against the evil hackers out there!

Our expertise and partnership originate with Oracle, through our network we can also support SAP HANA and MSSQL along with the 30 other databases supported by Trustwave’s AppDetectivePRO.

Please connect and lets talk about it!