Oracle TNS Listener Poison Attack

A flaw in the Oracle database listener, if not mitigated, could allow an attacker to take complete control of an Oracle database through an attack known as TNS Poison Attack. This vulnerability is remotely exploitable without authentication credentials. This classic man-in-the-middle (MITM) vulnerability has been published as security alert CVE 2012-1675 and received a CVSS base score of 7.5. It impacts confidentiality, integrity and availability of the database. Joxean Koret discovered this vulnerability in 2008 and publicly disclosed in 2012.

TNS Poison Attack vulnerability exploits Oracle listener’s database service registration functionality. Oracle database users connect to the database services through Oracle TNS Listener which acts as a traffic cop. A malicious attacker, residing on the same network as the database, registers a malicious service with the database listener with the same service name as legitimate database service. No credentials are required to register a database service with the listener. An attacker can use Oracle database software or easily available other tools to register a malicious database service.

After completion of the malicious database service registration with the same name as legitimate service name, Oracle listener has two services to choose from – a legitimate service and a malicious service. With two database services available, Oracle listener switches to the load balancing traffic cop mode, directing users alternatively to the legitimate service and the malicious service. At least, 50% of the user sessions are directed to the malicious service. Database user sessions, which are now communicating through the malicious service, can be hijacked by the attacker. An attacker is in the middle. All communication from the users to the database is now passing through the malicious attacker. Attack post stablished. Attacker has full purview of what users are communicating with the database. At a minimum, the attacker can view and steal the data. Additional SQL commands may be injected to broaden the scope or carry out additional attacks. If a database user communicating with the database happens to be a privileged user with the DBA role, then the attacker has complete control of the database. Database compromised. Mission accomplished.

TNS Poison Attack vulnerability is mitigated through Valid Node Checking Registration (VNCR) setting which permits service registration from only known nodes or IPs.

Specific mitigation steps depend on the version of the database that you are running as shown below:

Oracle Database Releases 12.1 or above: If you are running Oracle database 12.1 or above, then you don’t need to further read this article unless you are just curious. The default Oracle listener configuration in Oracle 12c would protect you against this vulnerability. Although you don’t need to specify VALID_NODE_CHECKING_REGISTRATION_<listener_name> parameter to LOCAL in listener.ora, I would suggest that you explicitly do so just to make sure, as shown below:

LISTENER_DB =


(DESCRIPTION_LIST =
   (DESCRIPTION =
     (ADDRESS=(PROTOCOL=TCP)(HOST=192.168.100.100)(PORT=1521))
   )
)

VALID_NODE_CHECKING_REGISTRATION_LISTENER_DB=LOCAL

This parameter ensures that databases that are on the same server as the listener are permitted to register services with the listener. No remote registration of the services is permitted. If a malicious attacker attempts to register a service with the listener from a remote server, you will see the following error message in the listener log:

Listener(VNCR option 1) rejected Registration request from destination 192.168.200.131
12-NOV-2015 17:35:42 * service_register_NSGR * 1182

Oracle clustering solution, Oracle RAC, requires remote registration of services. In order to protect Oracle RAC from TNS poison Attack, you also need to set REGISTRATION_INVITED_NODES_<listener name> to specify IP addresses of the nodes from which remote registration is required.

Oracle Database Release 11.2.0.4: If you are running Oracle database 11g R2 11.2.0.4, then you must mitigate this risk through listener configuration. As illustrated above, you need to set VALID_NODE_CHECKING_REGISTRATION_<listener_name> to LOCAL. Alternate values for this parameter are ON or 1 and accomplishes the same objective. The default value for this parameter is OFF, leaving the door open to an attack. As mentioned above, if you are running RAC, then you also need to set REGISTRATION_INVITED_NODES_<listener name> to allow instance registration from trusted/valid nodes.
Oracle Database Release 11.2.0.3 or older releases: Before I describe the mitigation for older releases, let me mention that you should not be running Oracle databases 11.2.0.3 or older. Oracle has already de-supported older releases. No security patches are available for older database releases. You should upgrade as soon as possible.

Oracle, however, does provide a workaround for older releases through Class of Secure Transport (COST) parameters. There are three parameters SECURE_PROTOCOL_<listener_name>, SECURE_REGISTER_<listener_name> and SECURE_REGISTER_<listener_name> that can be configured to control registration of services from valid nodes only. Please refer to Oracle documentation for more information.

Please note that COST parameters can also be used for Oracle database releases 11.2.0.4 or newer to protect against TNS Poison Attack, but the procedure is more complex and requires additional configuration.

What makes this vulnerability still relevant, even after its full disclosure 3 years ago, is that there are many many organizations running various flavors of Oracle database 11g R2 releases such as 11.2.0.3, 11.2.0.3, 11.2.0.4, etc. haven’t yet mitigated this flaw. If you haven’t, you should as soon as possible.

[su_box title=”About Jay Mehta” style=”noise” box_color=”#336588″]Jay Mehta currently works as an Information Technology Director at CTIS, Inc. Rockville MD. He has over 25+ years of progressive experience in project management, security implementation and Oracle database architecture/administration. He specializes in Oracle database security, disaster/recovery and performance tuning. He has led and managed numerous infrastructure projects including the data center move. He holds a master’s degree in Computer Science from Stevens Institute of Technology. His blogs can be found HERE.[/su_box]