How To Protect Oracle Database Vault

In Esteban Martinez Fayo's "Hacking and Protecting Oracle Database Vault" session at Black Hat USA in Las Vegas a couple weeks ago, he used several exploit methods that could be used to disable Oracle Data Vault. Each exploit provided an avenue by which he could hack the database. With each exploit he performed the same hack: rename the dynamically linked library that implemented all Oracle Database Vaults functions.These are known exploits, and in the case of the buffer overflow attack, a patched problem. The demonstration was not some tricky new exploit, but common attack vectors. The real point of the presentation is not about a particular exploit, but the fact that Database Vault functions could be removed entirely should any of these exploits -- or valid permissions -- be available. Once the DLL is renamed, the next database restart will occur normally, but the database will resume operation without Database Vault functions.

Some of the people I spoke with after the show did not understand how this could be the case, but unless you are looking at the log files to detect this type of system event, it will go entirely unnoticed. User access, DBA roles, and multifactor authentication requirements simply vanish.

My interest in pointing this out is not the novelty of the attack, but rather to point out that you probably have tools in your house to detect or even prevent this type of exploit. The presentation lacked some of the detection and prevention tactics, so I will mention a few here:

1. Every commercial database vulnerability assessment scanner on the market checks for the exploits mentioned above. New variations may be found, but most of the avenues for exploitation can be checked and verified fixed.

2. This is why constantly checking for patches and keeping current is so important -- two of the three attacks could be thwarted with current patches.

3. Injection attacks launch code with the same privileges that the database runs under, so it's not like access controls are going to help with that. 4. Stored procedures, external or internal, are a handy tool for administrators. And they are really dangerous. They remain a principle avenue for exploit, so external stored procedures should be disabled and changes to internal procedures carefully monitored.

5. File-permissions monitoring, either through assessment, database assessment, or file monitoring tools, will detect the attack.

6. Permissions monitoring is a pain in the -- well, you know. But checking stored procedure settings and user access maps to stored procedures is necessary. There are commercial tools to automate, or you can write some simple scripts to detect, but make sure this is in your arsenal.

If you are not sure your policies cover this threat, then go check.

Adrian Lane is an analyst/CTO with Securosis LLC, an independent security consulting practice. Special to Dark Reading.