Problem solve Get help with specific problems with your technologies, process and projects.

Using the network to prevent an Oracle TNS Listener poison attack

Expert Michael Cobb details the Oracle TNS Listener poison attack and tells how enterprises can use the network to defend vulnerable applications.

Oracle Corp.'s handling of the zero-day vulnerability that led to the Oracle TNS Listener poison attack has confused...

many administrators and is leading them to question the security posture they should take with regard to their databases.

The unfortunate reality is that malicious hackers could have independently found the Oracle TNS Listener poison attack vulnerability and exploited it for years to attack enterprise databases, and it's unlikely that administrators would have ever known.

In this tip, we'll examine how the TNS Listener vulnerability works, analyze Oracle's response and consider whether enterprises should adjust their network defenses to better safeguard their databases.

Inside the TNS Listener vulnerability

This particular vulnerability is easily exploitable and allows an attacker to perform a man-in-the-middle attack to gain full control over a database server: It's as serious as it can get. The vulnerability exposes the TNS Listener service, which routes connection requests from clients to the server on all versions of Oracle databases. Security researcher Joxean Koret discovered and reported this vulnerability to Oracle in 2008. He released the details about it four years later because he thought Oracle had addressed the issue.

Oracle, however, has only recently issued an out-of-band security alert for what's known officially as vulnerability CVE-2012-1675. This is a workaround, not a patch; it offers instructions on securing TNS Listener and protecting it from attacks exploiting the vulnerability. The April 2012 Oracle Critical Patch Update Advisory did not contain a patch either. Oracle has given the following reasons for issuing a workaround instead of a patch:

  • The fix is complex, and it is extremely risky to backport, or address with legacy installations.
  • The fix is in a sensitive part of the code where regressions are a concern.
  • Customers have requested that Oracle not include security fixes that increase the chance of regressions into CPUs, as they could endanger the stability of a database.

The Oracle TNS Listener poison attack vulnerability likely has existed in every version of Oracle's database platform for several years, but it will be fixed only with the next major release. Administrators must apply workarounds until that release, and every Oracle customer that doesn't apply the workaround will be left vulnerable to an attack by a remote unauthenticated attacker.

But what about attacks that might have occurred before this workaround? The unfortunate reality is that malicious hackers could have independently found the Oracle TNS Listener poison attack vulnerability and exploited it for years to attack enterprise databases, and it's unlikely that administrators would have ever known.

They would have to carry out a forensic investigation and work through archived log files to see whether they could detect abnormal commands or network traffic that could be connected to someone having exploited the vulnerability successfully in the past. The lengthy gap between the original vulnerability notification and this not-entirely-convincing action by Oracle also has led some security experts to question just what other flaws Oracle is aware of and choosing not to patch.

This situation clarifies why computer security experts testifying before the U.S. Senate Armed Services Subcommittee on Emerging Threats and Capabilities told members to assume that U.S. military computer networks have been penetrated, and that, based on that premise, security efforts should focus more on protecting sensitive data, not on controlling access. Those comments are not the result of this vulnerability but are due to the number of breaches being discovered at major organizations whose systems have been compromised for months and even years.

Using the network perimeter for database defense

Still, administrators shouldn't abandon their perimeter defenses just yet. Instead, those defenses should be supported by careful network segmentation and the enforced use of SSL and transport-layer security encryption for database connections. Prevention is always better than remediation, but a prudent enterprise security team nevertheless should assume there are compromised systems somewhere on the network where malware is trying to collect and exfiltrate valuable data to a remote command-and-control center.

From the editors: More on database security

Discover effective methods for searching log files.

Determine whether to perform full-packet capture or just capture network flow data.

To reflect this reality, security teams should refocus some of their priorities, resources and time. They should make sure to allocate sufficient time and technology, such as data loss prevention, to look for suspicious internal traffic and prevent data from leaving the network if a request does not comply with security policy.

The open source tool Hone can be used to track down the source of suspected malicious activity inside an enterprise. Released by the U.S. Department of Energy's Pacific Northwest National Laboratory, Hone is a network-activity visualization tool that, by tracing traffic to the application that originated it, enables network managers to better recognize and understand attacks, and helps administrators identify the source of a compromise more quickly.

As software code grows increasingly complex, instances of a vendor saying it cannot easily or quickly provide a patch for a vulnerability will become a more frequent occurrence. Oracle's handling of the TNS Listener poison attack serves as a perfect example of why enterprises can no longer skate by until the next patch from a vendor arrives. Security defenses need to be reorganized based on this admittedly frustrating premise, and incoming and outgoing traffic needs to be monitored and controlled to compensate for the mission-critical enterprise applications that aren't as secure as they should be.

About the author:
Michael Cobb, CISSP-ISSAP, is a renowned security author with more than 15 years of experience in the IT industry and another 16 years of experience in finance. He is the founder and managing director of Cobweb Applications Ltd., a consultancy that helps companies both to secure their networks and websites and to achieve ISO 27001 certification. He co-authored the book IIS Security and has written numerous technical articles for leading IT publications. He also is a Microsoft Certified Database Administrator and a Microsoft Certified Professional.

This was last published in July 2012

Dig Deeper on Database Security Management-Enterprise Data Protection