There has been a lot of coverage here in Australia recently about one of our popular telco’s getting hacked due to a lapse in security. So I thought I’d share a security horror story that I encountered with a customer recently. I’d love to say that I’m sharing this due to my philanthropic nature but let’s be real – if someone running an Oracle database has a security breach, then it looks bad for the customer, but it also looks bad for Oracle, so we all have some skin in this game..
Anyway…onto the details and oh my …
This customer uses an application from a vendor for capturing data (Yes, I know that’s vague, but I’m not in the name-and-shame business here, I’m doing this as a warning to others). The vendor app contains an embedded Oracle database to hold the data that is collected. The vendor also provides a “reporting toolkit” to allow some pre-packaged analysis to be executed.
With a little closer inspection, the reporting toolkit is a zip file containing
SQLcl,
some SQL script files,
some Linux shell and Windows batch files
Customers then just run the shell/batch appropriate to their platform and reports appear magically. The shell/command files were just a simple:
sql.exe user/password@connection_string @appropriate_script_name.sql
Needless to say, having a password hard-coded in a shell/batch file is not a great idea, especially when these files are readily available to anyone in the company. This is big mistake #1
Then I fired up SQLcl and connected with the user/password credentials that were in the shell/batch files and looked at the data dictionary:
SQL> select table_name
2 from user_tables;
TABLE_NAME
------------------------------
[snip]
253 rows selected.
You guessed it. The freely available username and password was the schema that owned all of the database objects for this application. This is big mistake #2.
I must admit, at this point, I was pretty confident I already knew what was going to happen when I ran my next query. I took at look at the privileges I had within my session
SQL> select *
2 from session_privs;
PRIVILEGE
----------------------------------------
ALTER SYSTEM
AUDIT SYSTEM
CREATE SESSION
ALTER SESSION
RESTRICTED SESSION
...
...
CREATE HIERARCHY
CREATE ANY HIERARCHY
ALTER ANY HIERARCHY
DROP ANY HIERARCHY
CREATE ANALYTIC VIEW
CREATE ANY ANALYTIC VIEW
ALTER ANY ANALYTIC VIEW
DROP ANY ANALYTIC VIEW
237 rows selected.
Boom! Pretty much every privilege you could think of, just sitting here waiting to be exploited by anyone in the organization. This is big mistake #3. Of course, anyone with any familiarity with security in the Oracle Database know that is is unlikely that such an expansive list of privileges was explicitly granted, and a quick check of session_roles confirmed my biggest fear:
SQL> select *
2 from session_roles;
ROLE
-------------------------------
DBA
SELECT_CATALOG_ROLE
EXECUTE_CATALOG_ROLE
EXP_FULL_DATABASE
IMP_FULL_DATABASE
DATAPUMP_EXP_FULL_DATABASE
DATAPUMP_IMP_FULL_DATABASE
GATHER_SYSTEM_STATISTICS
EM_EXPRESS_BASIC
EM_EXPRESS_ALL
SCHEDULER_ADMIN
HS_ADMIN_SELECT_ROLE
HS_ADMIN_EXECUTE_ROLE
XDBADMIN
WM_ADMIN_ROLE
JAVA_ADMIN
OLAP_XS_ADMIN
OLAP_DBA
And there it is! The DBA role, given to the schema owning account, with the never expiring user and password details hard-coded into batch files on a network shared drive that is available to every single person in the company.
This post is just a reminder to us all – security is the responsibility of everyone in the organisation. A simple security shortcut that someone in your IT team takes now, could easily end up being the death knell for your company in the future.
Please at least ensure that anyone in your department that is using an Oracle Database, is familiar with the Security Guide.
“Lets be careful out there”