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 MetaLink (while MetaLink required CSI
identification, it not not prevent any MetaLink user from examining others SQL
after it is published in the MetaLink 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.
There is also the
disclosure of exposures for SQL injection attacks (used for initial
entry). SQL injection attacks have become a major threat to any
Oracle databases that is deployed over the Internet:
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.
