Oracle golden gate的重要漏洞分析

在这篇文章中，我们会再一次证明过度依赖自动化工具会让人们忽视掉很多潜在危险，同时，我们也将会讨论一些有关Oracle Golden Gate技术层面的重要弱点(漏洞)，并且向大家展示又一个信息安全产业产品质量不过关的案例。

事情的起因

不久之前，在一次内部易受攻击性的评测中，我们注意到Nmap显示出了一段类似于下图、未被认出的代码。

有经验的人能够轻易认出对于标准服务要求(standard service request)，上述的未经认出的代码会导致“MGR Did Not Recognize Command”这样一则错误信息的产生。简单的网络搜索可以发现，人们在一些讨论帖上抱怨称上述的错误信息出现在Oracle Golden Gate的错误日志中。经过更深一步的研究发现，TCP/7809端口(port)是Oracle Golden Gate的默认端口，这个调查结果与之前的结果一致，这个结果给我们的研究带来了极大的信心。

引用Vendor公司网站的说明：“Oracle Golden Gate是一款在多样IT环境下做出实时数据整合并且做出相应反应的软件包。” 这也就意味着使用者可以程序化地定义在某种模式下的数据要怎样转化为另一种模式的数据，然后即便在HA switch-over(应当是专业术语)或者其他复杂环境下Oracle Golden Gate也能将这些数据安全的转移，并且保证数据的准确性。

另外，一次Nessus对于脆弱性的扫描表明：Golden Gate还是无法识别。于是我们又在Google上面进行深入调查，并且发现了一些可怕的ZDI报告：

ZDI-16-022

ZDI-16-023

CVSS(通用弱点评价系统) 10.0 表明这些弱点在没有授权的情况下，可以通过互联网被轻易地利用，而且在报告中提到的会受影响的端口也和我们的调查一致。这也就是为什么我们会建立一个测试系统或者是一个类似的版本，然后攻击他的弱点来检测这个弱点是否真实存在。但是这一次，虽然我们的测试处理了一些重要数据，但是在下一次“寒潮”来临前我们并没有足够的空间来测试甚至建立好测试系统。

我们现在能做的就是在我们的报告中涵盖有关这个问题的信息说明，并且祈祷在短时间内可以有人解决这个问题，或者架设起一些被动的监控措施。就目前来说，这个漏洞还没有被大范围利用，但我们已经开始架设测试系统，因为这个漏洞仍然在困扰着我们。

漏洞及其相关特点

这是为数不多的获取并且架设产品比找到第一个漏洞花的时间、功夫还要长的案例，一部分是因为这款软件的Linux(一个电脑操作系统，比如说Windows也是一款电脑操作系统)版本拥有完全的debug(他们肯定都懂什么意思，就是消除错误)信息，并且这些信息也被编译为二进制(储存在软件中)。因此，我们不会过多讨论这部分，也不会更多的关注某个个体特定的问题，而是将更多的注意力放在普遍的问题上。

管理器进程模拟了一个HTTP服务器并且执行了一个自定义的协议。结果是，虽然我们执行了一些权限控制(关于这一点我们之后会提到)，但是不需要任何授权。

HTTP服务器交互界面泄露了包括版本号在内大量关于服务器建立的信息，这些信息可以帮助我们确认这个目标是否已经打过补丁。当然我们想知道的还远不止于此。

我们建立HTTP服务器所用的自定义协议十分简单。其中最重要的一些细节可以从收集自初始建立阶段的测试主机中的packet dump推敲出来：

一个两字节的前缀编码了这些信息长度，其后跟随了一段TAB键(Word软件中用于每段起始错后两字节的按键，这里指图片中第二段编码比第一段错后两字节)分开，人们能够读懂的指令。而关于这段编码的回复也是同样的格式。这段样本足以在check_messages() 程式中快速定位执行于其中的二进制信息分析程序(message parser function of binary).

在确定过程创造逻辑(process creation logic)可以以某种方式激发execv()方程防止不重要的指令输入之后，我们把我们的目光移向了OBEY指令。除了那吸引人的名字之外，official documentation(官方文件)显示GG可以被脚本化，而且脚本的文件名称通常为“OBEY files”。这些文件可以包含”SHELL“指令——这个指令可以在OS解译过程中执行它自身的参数，而这使得OS成为一个完美的攻击目标。

现在，唯一的问题就是，如何往目标的文件系统中放置一个合适的OBEY文件?一个很古老的方法可以帮助我们解决这个问题：管理器进程会把所有无效的指令记录在正在工作的ggserr.log目录文件中。既然我们可以在发送到管理器端口的指令中嵌入line break，而且脚本的语法分析程序不会在无效的line上停止，那么我们就可以在目录中加入一行以”SHELL”开头的指令，从而使管理器将它自己的log文件解读为OBEY文件，以此实现指令的执行。

同时Claudio公布了另一个漏洞(ZDI-16-022 –CVE-2016-0451)的一些细节。这个漏洞会导致文件随意被上传，从而导致人们可以更轻易的利用这个漏洞。(脚本运行速度慢是我们的方法的一大限制，这导致我们需要花很多时间搜寻被添加的指令)

如果你希望看到更多有关信息，请查看我们所发布的exploit。在Windows系统上的Single-shot exploitation可以作为读者的一个小练习。

保守的防护

Golden Gate 通过在信息语法分析中激活 MGRSEC_check_client_access() 程式来检查access(使用权，途径)。这个程式通过运行一系列的现成的规则来检查连接的客户是否被允许发送信息，对于有缺陷的版本也同样如此。而在Oracle发布的补丁中，它又添加了一些默认规定，使得只有来自于 127.0.0.1 and ::1de信息可以被接受。

当然这个办法也有很多问题：第一，这个补丁会打破原本依赖于远程管理器连接的架构。第二，即使上述的检查失败，仍然有一部分信息会被进行分析——在我们的测试中，我们意外地找到了很多未经授权的DoS问题(NULL指示器废弃NULL pointer dereferences)。第三，GG暴露了很多潜在危险(原文为expose a huge attack surface，直译为暴露了很大的攻击面，可以理解为有很多地方可被攻击)，而且基于我们对于样本编码的观察，我们猜测可能还有很多未授权(或者绕过检测的)问题还没有被发现。

因此，我们强烈建议对于所有Golden Gate端口施加严格的防火墙监控(注意!这个软件可以将上传的文件动态链接至超过7800个端口)以防止不受信任的主机的TCP连接。通过我们关于威胁的模拟，我们预测，任何已连接的主机都可以轻易地compromise(妥协，实在是理解不了这个词在这里是什么意思)GG服务器。

除了软件自身的问题之外，我们还应当注意，在ZDI公告和Oracle的补丁发布16个月、我们告知Tenable有关检测缺失的问题13个月以及公众第一次利用漏洞4个月后，我们仍然无法找到任何关于IDS/IPS工具或者弱点扫描仪器的方案(ZDI/TippinPoint可能会有)。对我们来说，这大大阻碍了我们对问题的解决及缓解。

我们理解因为信息的缺失，想要为所有的公众信息建立检测机制是不可能的，但是信息产业对公众信息泄露的漠视是众所周知的。难道我们不应该思考：这些供应商真的希望使用者的隐私不被暴露，还是说他们只是想让顾客相信他们的产品是安全的(意味着只是做表面功夫，但却从来不采取实际措施)?

不过值得庆幸的是，我们到现在都还可以收到那些关于DTLS漏洞的高危警示(讽刺，讽刺厂商只是提供警示，但是没有采取实际措施)。

积极主动研究探索的重要性

从另外一个角度来讲，这则小故事也证明了积极主动的研究调查的重要性: 如果没有这些真正想要解决问题的人(而不是那些假惺惺做出报告而不解决问题的人)的话，这些在非常重要的系统中的漏洞甚至可以一直存在。这个故事也同时证明了，如果漏洞的可利用性不高，那么这个漏洞很有可能被当作可以接受、存在的漏洞处理，而不是最终被解决。

所以，我们需要具有探索精神的人去发现并且纠正这些漏洞，否则话，人们将永远活在100%安全的谎言之下。