As an Oracle consultant, I am especially paranoid about my client's privacy.  In this day-and-age of quick downloading and copying, Oracle data leakage has become a huge problem.

It's sometime malicious (data theft for re-sale, disgruntled Oracle administrators), and often accidental, but it's always a problem.  This will explore the deliberate and accidental disclosure (leakage) of sensitive information, and show the DBA methods for controlling Oracle data leakage.

Oracle data leakage tips

External Oracle data leakage is almost always the result of an "inside job" where a trusted user abuses their privileges for personal benefit.  There are several classes of external data leaks:

• Root Kits - An Oracle root kit has put at least one large corporation out of business (it was capturing new data and e-mailing it to China), and any hackers who gets root access can easily create a hidden vacuum to siphon-off your confidential data.
   

• Access abuse - Online system are abused to reveal private data (like the case of Brittany Spears medical treatment), and privileged administrators have been known to gather evidence for nasty divorce, and DBA's at universities who will alter grades for a fee.

There are several sources of external data leakage, most often Google hacking and SQL disclosure.

Google hacking for Oracle

Using Google to identify hacking opportunities has become commonplace.  When the Googlebot crawls a web site it can expose many Oracle-related vulnerabilities and exposures. 

For example, just run the Google search below to identify dozens of web-sites with a iSQL*Plus interface, the first-step by a hacker who is interested in launching a buffer overflow attack on your Oracle database:

On the heels of his bestselling book ?Google Hacking for Penetration Testers?, Johnny Long has opened many people's eyes about the power of Google when placed in the wrong hands.  There is also an excellent discussion of Google hacking for penetration testers at the red-database-security web site.

Oracle hackers find idadvertent disclosure in almost all of the Oracle forums, including MOSC (while MOSC required CSI identification, it not not prevent any MOSC user from examining others SQL after it is published in the MOSC forums).

SQL data leakage

Time and time again, I see people asking for help tuning a SQL statement where they disclose the entire SQL statement.  This is beyond malfeasance, and it's grounds for termination in most companies.  Examining production SQL is a goldmine for hackers and criminals, with many benefits ,especially learning the table and column structures, for a concerted attack after entry.

Remember, all Oracle professionals MUST respect their clients privacy and almost all employment contracts specify complete NON DISCLOSURE of any sensitive business methods including parm files, production SQL and access details.