首页 > 安全 > 企业安全 > 正文
IBM终于对9个月前发现的严重漏洞发布缓解方案!但白帽子心里委屈
2017-06-10 09:21:19       个评论      
收藏    我要投稿

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服务器通信。

点击复制链接 与好友分享!回本站首页
上一篇:如何处理仍未解决的MongoDB安全问题?
下一篇:企业被黑客攻击,“怼回去”合法吗?
相关文章
图文推荐
文章
推荐
热门新闻

关于我们 | 联系我们 | 广告服务 | 投资合作 | 版权申明 | 在线帮助 | 网站地图 | 作品发布 |
版权所有: 88bifa.com--致力于做实用的IT技术学习网站