IBM终于对9个月前发现的严重漏洞发布缓解方案！但白帽子心里委屈

IBM终于对9个月前发现的严重漏洞发布缓解方案!但白帽子心里委屈。近日，IBM总算针对其软件产品中9个月前被发现的严重漏洞发布了修复解决方案，该漏洞存在于IBM企业备份软件中，利用该漏洞，攻击者可以从本地网络的IBM光谱系列数据存储和保护平台(Tivoli Storage Manager，简称TSM，现改名为Spectrum Protect)提权并窃取数据。为什么修复进程经历了数个月的后知后觉和慢慢悠悠?在厂商和白帽之间到底哪个环节出现了问题?我们来听听该漏洞发现者白帽子的心声。

漫长的漏洞修复进程引起白帽子不满

身为Improsec创始人的Jakob Heidelberg对IBM此举极为不满，心中一肚子冤气。原来Jakob和同事于2017年2月发现了这个漏洞并及时地向IBM产品安全响应团队(PSIRT)报送了漏洞情况，之后，IBM响应团队反应迟钝，经过反复冗长的漏洞确认、修复方案商议、软件开发方核实和多个漏洞修复期限(deadline)变化等一系列繁琐流程的两个月后，IBM响应团队却告知Jakob，其实这个漏洞早于2016年9月被另一安全研究者发现并上报了。

So，在Jakob心里也是欲哭无泪，妹的，忙活了两月你才说，而且这么长时间竟然还没修复，Jakob说：这个漏洞本身非常严重，非常容易被利用也非常容易被修复，拖了这么长时间才解决简直毫无道理可言!“，Jakob向媒体表示，好像只有以公布漏洞细节的方式威胁他们，他们才会赶快发布漏洞公告和修复方案。

白帽子Jakob Heidelberg的心声

6月2日，在IBM发布漏洞解决方案的几天后，Jakob在博客中叙述了整个事件的过程：

几个月前，我和同事Flemming Riis在研究IBM TSM产品的认证方式时，发现了其客户端程序的一个基础性漏洞Backdoors and data compromise via Backup Systems，但不久后，在此基础上，我们又发现了另一个非常严重的漏洞，之后，我们及时向IBM产品安全响应团队(PSIRT)进行了报告。以下描述可以反映该漏洞的高危隐患情况，也能说明为什么我们一直希望IBM给出漏洞修复期限deadline的原因。

攻击者可以在安装了TSM客户端的任何Windows系统中以普通用户身份，通过终端Terminal或Citrix server方式，使用TSM内置工具读取“节点ID(Node ID)”和一个经过混淆的“节点密码(Node Password)”：

以上图示了注册表中的特定权限设置，通过该设置，普通用户具备读取诸如节点密码之类的高度敏感信息权限。

有了这些信息，不论在NTFS或其它权限环境下，攻击者都可以把TSM上之前的备份文件恢复到另一台由攻击者管理控制的主机中，该主机可以是攻击者自己接入本地网络的，安装有TSM客户端程序的笔记本电脑。

除了未经授权的，诸如文档、电子表格、配置文件等访问权限之外，攻击者还能获取包含密码的SAM数据库文件、敏感的注册表键值、服务账户的明文密码等信息。恶意的内部攻击者是该漏洞的一个严重威胁，将会造成信息泄露、权限提升和凭据信息被窃取等情况。更多漏洞情况，请参考Backdoors and data compromise via Backup Systems。

白帽子Jakob与IBM之间关于漏洞披露的沟通

以下是我们和IBM安全响应团队之间关于该漏洞的反复沟通、确认、交流的漫长流程，我个人认为，从该流程中可以看出，出于对用户或供应商权益考虑，对那些存在漏洞的厂商要求严格的重要性，尤其给出一个漏洞修复期限相当重要。

2017年3月3日，向IBM PSIRT上报漏洞，并确定了7天的首个漏洞修复期限(2017年3月10日)，在此日期之前，IBM方面可以进行相关的漏洞测试和确认过程。为了给足漏洞解决时间，经商量，另外一个漏洞修复期限为2017年5月3日(也就是60天后);

2017年3月7日，IBM PSIRT对我们咨询漏洞的Advisory ID进行了确认;

2017年3月7日，我们告知IBM PSIRT希望在2017年5月3日前，我们双方可以共同合作解决该漏洞;

2017年3月10日，IBM PSIRT回复说，我们的漏洞已经被证实，将在接下来的新版本软件中解决，他们的产品团队”希望“在2017年的第三季度末第四季度初完成该漏洞解决;

2017年3月11日，我们告知IBM PSIRT已经过了事先约定的首个漏洞修复期限3月10日，我们坚持5月3日为最终漏洞修复期限，并且告知IBM方面我们可以合作解决，另外如果他们可以对CVE等其它漏洞详情给予确认的话，这个期限还可以延后;另外，我们还询问了该漏洞对非Windows系统的影响情况;

2017年3月12日，IBM PSIRT告知我们的问题已经转发给开发方人员;

2017年3月20日，我们咨询IBM方面开发方人员的回应信息;

2017年3月22日，IBM PSIRT对我们的咨询给予回复，称开发方认为漏洞修复比较复杂，需要更多时间;

2017年5月4日，已经过了第二个约定的漏洞修复期限，我们向IBM PSIRT明确表示，现在我们还没看到任何补丁发布或解决方案的承诺。忍无可忍，于是乎，我们又把deadline定为2017年6月3日，多给IBM方面30天时间以开发补丁和解决方案。同时，我们也告知IBM，希望他们在此之前能充分对他们的客户构建保护措施，哪怕是对注册表权限问题给出一个简单的解决方案;

2017年4月21日，我们再次向IBM PSIRT方请求对我们之前(5月4日)的询问信息给予确认和回应，同时要求他们对3月11日我们提及的非Windows系统影响情况给予回复;

2017年4月24日，IBM PSIRT回复称他们已经于2017年4月21日向产品团队沟通了相关情况，现在正等待其回应;

2017年4月27日，IBM PSIRT对修复延迟表示歉意，并称希望在5月的deadline前通过安全公告方式发布漏洞缓解措施，之后，实际补丁可能会在之前提及的“第三季度末第四季度初”发布。此外，IBM PSIRT还明确告知我们，该漏洞其实也于2016年9月被另一安全研究者Kęstutis Gudinavičius发现上报给他们了，但最终所有漏洞发现者都会在安全公告中给予承认致谢。我们与Kęstutis Gudinavičius从未有过任何沟通。这…..;

2017年5月23日，我们就漏洞状态更新和安全公告发布日期询问IBM PSIRT，同时，我们再次希望他们提供该漏洞对非Windows系统的影响情况;

2017年5月23日，IBM PSIRT回复说会在5月底前发布漏洞缓解措施，并声称会在之后对其它支持TSM软件的系统平台进行漏洞核实;

2017年6月1日，我们询问IBM PSIRT发布的漏洞缓解措施或安全公告;

2017年6月1日，IBM PSIRT回复提供了于前一天发布的安全公告和漏洞缓解措施。

出于对客户和供应商安全利益考虑，我们不辞口舌地与IBM方面的纠缠也真够让人看了心烦的了!啰啰嗦嗦说了以上一大堆，明显说明如果在没有漏洞修复压力的情况下，可以想像，IBM方面的修复进程会是多么缓慢!而该漏洞的首个发现者也没有向IBM方面施加过任何漏洞修复压力，最终也才导致该漏洞可以存活9个月之久，直到我们偶然发现了它!

在这长达9个月的漏洞修补空白期，IBM TSM产品客户将会面临攻击威胁。这本来就不是多么复杂的一件事，只需要一些微不足道的努力就能制订出简单的解决方案，但整个过程却让人匪夷所思。在最后几个月里，我也在思考，漏洞责任披露期限和漏洞赏金项目是否应该设立标准，不过在此，这也只是题外话而已了，我心好累。

漏洞修复建议

在IBM补丁发布之前，只有按照缓解措施进行漏洞风险消减：

1、参照CVE-2016-8939和IBM发布的漏洞解决方案，在安装有IBM TSM客户端的系统中进行相应设置;

2、限制对TSM服务器的访问权限。只有那些有备份和恢复需求的系统才能通过TCP 1500与TSM服务器通信。