Database Reference
In-Depth Information
Another defense is to set a very strong SYS password, but how do compliance and security departments verify
that the password value is indeed strong? Organizations are faced with a situation in which the only real method of
verification is to brute force their own SYS passwords to see if they are being created securely, or they must place
responsibility for the control of the SYS password on a separate password management system such as PowerBroker,
CyberArk EPV or Oracle's new OPAM system. This use of a separate password management system is something we
will spend a whole chapter on later, as it is a very interesting subject with pitfalls and opportunities, which are highly
relevant to our successful 12c deployment.
So let's say that the SYS password and the new 12c derivatives SYSDG and SYSKM are all set with very complex
passwords. Can an attacker break into an Oracle database without logging on with an account or password? Again, the
answer to this is “yes”—they can do this using a TNS poisoning attack.
TNS Poison Proxy Attack
Joxean Koret has published research showing that all versions of Oracle database do not authenticate the instance to
the listener. He documents the attack at the following URL:
http://www.joxeankoret.com/download/tnspoison.pdf
Oracle's database has been designed so that the listener process runs separately and can actually be run on a
separate machine (remote listener). The problem is that the Oracle listener trusts the identity of the instance based on
the instance's name. A separate database instance can register itself to a listener as long as the name of the instance is
the same as that expected by the listener. Figure 2-2 illustrates this attack.
Orcl1
instance
Authorized
clients
Listener
Orcl2
instance
Attacking
orcl2
proxy
Figure 2-2. An illustration of the TNS poison proxy attack
The problem with this approach is that an attacker can add their own instance to a RAC database and then proxy
client connections. They can add in their own commands before forwarding back to the original database. This is a
“man in the middle” attack, proxying between the listener and the original instance. Once the attacker is in the signal
path they can inject commands such as "create user attacker identified by password" and "grant sysdba to
attacker" to create their own user and logon directly. The attacker will see a pro-rata proportion of the total traffic for
the RAC instance (e.g., in the diagram below) that will be one third of the total connections.
 
Search WWH ::




Custom Search