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
- 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”