甲骨文公司对导致Oracle TNS Listener毒药攻击的零日漏洞处理方式，让很多管理员感到困惑，他们不知道该对数据库采取什么安全措施。在本文中，我们将研究TNS Listener漏洞的运作原理，分析Oracle的回应以及企业是否应该调整其网络防御系统以更好地保护其数据库。

    TNS Listener漏洞

    这个特殊的漏洞很容易被利用，并允许攻击者执行中间人攻击以获取对数据库服务器的完全控制：它的严重程度取决于对它的攻击深度。该漏洞暴露了TNS Listener服务，此服务将来自客户端的连接请求路由到所有版本的Oracle数据库的服务器中。安全研究人员Joxean Loret在2008年发现了这个漏洞，并向Oracle报告了此漏洞。四年后，他发布了该漏洞的细节信息，因为他以为Oracle已经解决了这个问题。

    然而，Oracle最近才针对漏洞CVE-2012-1675发布了一个带外安全警告。并且，这只是一个解决方法，而不是一个补丁，它提供了保护TNS Listener和抵御利用该漏洞发起的攻击的指导信息。2012年4月Oracle关键补丁更新也没有包含针对该漏洞的补丁。Oracle对于发布解决方案而不是补丁，给出了以下原因：

    这个补丁很复杂，这将严重影响“向后移植（backport）”或传统安装。

    这个补丁是存在回归问题的代码的关键部分。

    客户要求Oracle不要涵盖安全补丁，因为该补丁将会增加回归到CPU的机会，而这可能危及数据库的稳定性。

    Oracle TNS Listener毒药攻击漏洞可能多年来都存在于所有版本的Oracle数据库平台中，但这个漏洞只有在下一个主要版本推出时才可能会被修复。在那之前，管理员必须采用Oracle提供的解决方法，没有使用该解决方法的Oracle客户很容易受到远程未授权攻击者的攻击。

    如果在这个解决方法发布之前可能已经发生了攻击呢？不幸的事实是，恶意攻击者也许已经独立地发现这个Oracle TNS Listener毒药攻击漏洞，并可能多年来都利用它来攻击企业数据库，而管理员可能从来都没有发现。[page]
    在过去，企业将不得不进行取证调查以及分析归档日志文件，看看是否可以检测到异常命令或者网络流量来证明有人成功利用了这个漏洞。原漏洞通知时间和Oracle采取的并非完全令人信服的行动时间这么久，也让一些安全专家质疑Oracle还知道哪些其他漏洞而选择不修复。

    这种情况也阐明了为什么计算机安全专家在美国参议院军事委员会新兴威胁和功能小组委员会，告诉成员要假设美国军方计算机网络已经被渗透的原因，基于这个前提，安全工作应更专注于保护敏感数据，而不是控制访问权限。这些意见不是这个漏洞的结果，而是基于大型企业发生的数据泄露事故数量，它们的系统已经被感染几个月甚至几年。

    使用网络外围作为数据库防御

    尽管如此，管理员仍然不应该放弃其外围防御。相反地，在这些防御的基础上，还应该采用谨慎的网络分段，并为数据库连接强制使用SSL和传输层安全加密。预防永远好过补救，稳妥的企业安全团队应该假定：在网络某处存在被感染的系统，恶意软件正试图通过该系统收集和渗出重要数据到远程命令控制中心。

    为了反映这一现实，安全团队必须重新调整其优先次序、资源和时间。他们应该确保分配足够的时间和技术（例如数据丢失防护）来寻找可疑内部流量，并在当出现不符合安全政策的请求时，防止数据离开网络。

    开源工具Hone可用于追踪企业内可疑恶意活动的来源。Hone由美国能源部下属太平洋西北国家实验室发布，它是一个网络活动可视化工具，通过跟踪流量到产生流量的应用，Hone能够帮助网络经理更好地识别和理解攻击，并帮助管理员更快地识别感染来源。

    随着软件代码变得越来越复杂，供应商不能快速提供漏洞补丁的请扩将会越来越多。Oracle对TNS Listener毒药攻击的处理方式充分说明：在供应商发布下一个修复补丁之前，企业不能坐以待毙。基于这个前提，企业必须重新调整安全防御措施，监控和控制传入和传出流量，以弥补关键业务企业应用的不足。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。