Database Reference
In-Depth Information
Following are some possible alternative solutions to put in place to protect yourself against the attack:
•
Use IPC, but this only works for single node
•
Turn off dynamic registration, but this results in a loss of availability
•
Restrict valid nodes, but you will need to know all IPs
•
Implement ASO/SSL between listener and instance, now free for RAC, but involves quite high
human labor time and also has higher performance overhead due to encryption
The best solution is to use COST (Class of Secure Transport) SSL to have certificated authentication between
the instances and the listener. Using COST-based SSL is a well-practiced technical procedure, is reasonably reliable,
and is a good idea for new installs. The license cost has been waived by Oracle, but there is still a labor cost, especially
when creating and managing the certificates, as well as the change-management expense and downtime of changing
a current production system, which means that this solution tends to be used only for initial installation of
sensitive servers.
Given all the above issues, it is reasonable to assume that, if a moderately skilled person wished to break into
the average Oracle database, they probably could. Of course most reasonably skilled people do not wish to break into
databases, but some do, and relying on the goodwill of others is not a robust security posture for military, banking,
energy companies, or for an increasing number of other organizations.
Once a weak account has been gained by an attacker, what next? The answer would normally be an escalation of
privilege, in terms of both the account's power and its geographic distribution.
Privilege Escalation
If an attacker has gained only a low or mediumly privileged account then they will probably look to escalate their
privileges to SYSDBA. This can be done through PL/SQL injection, which is well documented. Newer examples of
privilege escalation are still being published by David Litchfield at Blackhat, such as the ability to use an Oracle index
in order to escalate to SYSDBA. This attack will be extended to a new level in the following chapters.
Another method of escalating privilege is using OS access from a database session to edit the OS files that control
the database. Oracle's basic design means that any process coming out of the database will do so with the privileges
and identity of the Oracle process itself, usually as the operating-system user named
oracle
. This fact means that a
session that is able to interact with the OS can overwrite files that control access to the database, e.g., the password
file. DB to OS escalation is platform specific. On Linux and Unix, file overwriting and executing requires pre-existing
executable files that can be overwritten, but that is not the case on the Windows platform. This is one of the many
reasons why Oracle on Windows is less secure than Oracle on *nix. See this URL with information by the author for
more detail:
Once a session has escalated from the DB to the OS, the
oracle
process can be used to reverse a shell back to the
attacker's source machine. The author has previously explained how to do this at his website here:
http://www.oracleforensics.com/wordpress/wp-content/uploads/CREATE%20TABLE%20to%20OSDBA%20reverse%20
If an Oracle DB session writes to the OS, it does so as the “oracle” *nix process, so if it then invokes SQL*Plus and
comes back into the database, the attacker's code is
SYS
. So privilege escalation in Oracle is as simple as exiting to the
OS and then programmatically connecting into the database again using SQL*Plus.
After privilege escalation an attacker will often seek to gain wider access to other servers and database instances,
sometimes using the same user account and password used to break into one database instance on other machines,
or by following database links.
