MS08 | 您所在的位置:网站首页 › 系统漏洞叫什么 › MS08 |
*本文中涉及到的相关漏洞已报送厂商并得到修复,本文仅限技术研究与讨论,严禁用于非法用途,否则产生的一切后果自行承担。
Dustin Childs,2008年时任微软安全应急响应中心(MSRC)安全项目经理(SPM),现任职趋势科技Trend Micro Zero Day Initiative。 Ziv Mador,2008年时任微软恶意软件防护中心(MMPC)高级项目经理,现任Trustwave公司Spiderlabs安全研究副总。 Phillip Misner,2008年时任微软安全应急响应中心(MSRC)安全项目经理(SPM),现任微软安全应急响应中心首席安全经理。 Q:在对MS08-067漏洞的处理应对中,你们当时的角色是什么?Dustin:当时是2008年的10月,我那会在任微软安全应急响应中心(MSRC)任职安全经理,我的工作就是协调影响Windows操作系统漏洞的各种响应事件,另外还负责漏洞公告的编写发布。最终,MS08-067漏洞的各种工作也交到了我的手上,前后我一共发布了11条漏洞公告,但其严重的带外安全更新(Out-Of-Band Update)我没负责。这是我当时经手过的最严重的安全事件,可以说有些措手不及,并且我还自己亲手去编写漏洞公告。那个时候社会对信息安全的认知理解非常落后,我们还一度被《大众科学》杂志评比为第六名最令人作呕的工作,他们认为,我们微软安全人员的工作只比生物实验室中做动物防腐处理的人员稍好一些,还说我们是雷德蒙德(微软总部)土地神(Redmond security gnome)。 带外安全更新(Out-Of-Band Update):是指在正常发布时间以外的某个时间发布的更新,例如,微软通常会在每个月的第二个星期二,发布当前Windows产品存在的安全更新,以此来敦促用户下载更新进行系统修复。发布带外补丁的通常原因是出现了意想不到的、广泛的、破坏性强的漏洞,可能会引发病毒、蠕虫或特洛伊木马,对大量互联网用户造成影响。通常,0-day漏洞更新就会采用带外安全更新方式来进行补丁修复。 Ziv: 回想2008年,那时我任职微软恶意软件防护中心(MMPC)高级项目经理,我的工作职责就是代表恶意软件防护团队,在软件安全响应事件流程(SSIRP)中进行处理协调相关事宜。其中,会与微软安全应急响应中心(MSRC)和恶意软件分析师团队共同合作,进行一些漏洞和潜在利用代码的识别了解,以此制订恶意软件检测规则,收集采集数据评估恶意软件的传播方式和规模。可以说,MS08-067漏洞和之后的Conficker蠕虫变体,算是我们处理过的最严重的安全事件了,前后持续了数月之久。
Dustin: 当时看到微软的各个部门通力合作来处理这个漏洞,我个人还是比较惊讶的,我们微软总部、印度和欧洲的分公司团队几乎都是在全天候工作状态模式。有一件事我印象特别深刻,当针对MS08-067漏洞进行首次安全响应事件流程(SSIRP)会议时,会议室里坐满了15多人,还有很多专家是通过电话会议专线接入的,当Phillip解释完这个漏洞的相关情况之后,会议气氛突然陷入了瞬时的沉默,因为我们知道伴随这个漏洞而来的将是大量的蠕虫病毒。 从那一刻起,我们明白战斗已经开始了。没有经历过这种大场面的人可能没有那种体会,当时房间里坐着的都是一众信息安全专家,他们都曾亲自应对过Melissa、Nimda、Slammer、Sasser和Code Red等超级蠕虫病毒。另外比较有意思就是,出于应急优先,我只要解释一下MS08-067漏洞的情况,就能马上协调调配工作人员来参与响应处理。
Ziv: 首先是,John Lambert领导的微软可信计算团队向我们提供了这个惊人的Windows 0-day漏洞消息,他们的团队研发出了从崩溃报告中判断识别未知0-day漏洞的方法,利用该方法,他们能跟踪利用MS08-067漏洞进行攻击尝试的崩溃次数,一旦识别出了相当的次数,微软恶意软件防护中心(MMPC)的分析师就会立即进行相应的防病毒签名开发,以帮助我们发现其漏洞利用代码。当时,尽管我们维护着一个大型的恶意软件库,但好在没有发现太多基于MS08-067漏洞的传播类非复制型恶意软件样本。之后,配合微软官方发布的MS08-067安全更新,我们也对外公布了针对该漏洞的公共签名,帮助企业和个人用户能更好地防护攻击识别线索,以最大程度地减少受影响范围。 我们知道,随着社会公共领域的不断信息化,将会有更多的恶意软件随之而来,在安全补丁尚未打全之前,坏人和犯罪份子绝不会错过这种漏洞利用的良机。也就在MS08-067漏洞事件期间,我也应景地写了一篇官方博客,标题就叫做 “赶快打补丁,要快!”。 不出所料,微软发布的这个重要的带外安全更新(Out-Of-Band Update)迅速引发了媒体关注,就连当时还为《华盛顿邮报》撰稿的Brian Krebs也发布了文章进行跟进报道。
我们所监测到的网络攻击者,与像Slammer或Blaster这样的传播感染蠕虫之间的不同之处就在于,攻击者利用漏洞攻击带有一定的意图,当我们在讨论补丁发布和修复方案时,我也在会上重复强调了这个问题。最终,我们决定了一个风险优先的平衡快速修复方案。只是在补丁发布之后,当我们从攻击者利用的网络基础设施中进行信息提取时才发现,早前我们监测到的攻击正处于增长趋势,是后续大规模攻击的前期铺垫(可以从这里的报告中看到具体变化)。 MS08-067漏洞给我另外记忆较深的事就是其补丁发布,其提前公告描述(Advanced Notification Summary)是在正式补丁发布前一天就公布的,短短的五句话让业界措手不及。
Dustin: 对我来说,有两件事非常明显,首先,一开始我们做的漏洞公告是1.0版的,在下载我们发布的安全更新之后,系统中的修复会很快生成,剩下的时间就是系统的一些修复测试,它会确保漏洞能被有效修复,且不会产生其它问题。和我其它的工作经历相比,我认为MS08-067事件是微软全力以赴共同保护客户的一个典型案例。 另外,我们做得好的就是如何来说清楚这件事。通常的漏洞更新会统一放在星期二的更新公告日中,但对于这个漏洞来说,我们做了三个公告,每个公告都是对60多个问题回答的综合描述。我们全力与公关和营销伙伴合作,尽量让大众知道安装此更新的重要性,我们甚至把更新公告放到了msn.com首页上,反正我们想出了任何可以提醒人们安装该重要更新的方法。 我们这么煞费苦心,是有原因的,从这一点上来说,也可以反映出后期基于MS08-067的Conficker蠕虫变化规律,刚开始出现的Conficker.A版本造成的影响有限,仅使用了服务漏洞进行传播,后期的Conficker.B就加入了NetBIOS感染方式,成为了所谓的互联网猛兽。
创新为成功做出了重要贡献, John Lambert领导的团队能从数百万份崩溃报告中识别出了潜在未知的0-day漏洞,这种方法非常厉害,能提早预防MS08-067此类高危漏洞的广泛利用,我们可据此发布安全更新,及时为Windows客户提供安全保护。 就当时,对于我所在的团队MMPC来说,底层基础设施在过去几年中有了显著改善,能很好地支持了我们的技术需求。每天都有大量恶意可疑的文件被收集、扫描并存储在我们的系统中,这使得我们能够快速识别新的恶意软件,并对其进行分析,获得必要的技术信息,例如它利用了哪些漏洞,它是如何传播的,以及它连接到了哪些恶意服务器或URL链接。在有些情况下,其它安全供应商和机构也会向我们提供恶意软件样本,进一步加强了我们阻止疫情蔓延的能力。MMPC利用全球数亿台用户计算机系统的综合兼容性技术(Microsoft Compatibility Telemetry)来收集数据,其中最流行的工具就是微软恶意软件删除工具 (MSRT),但我们也受益于其它安全产品,如OneCare和Forefront系列产品,此类客户系统数据让作为一名响应协调员的我,能够评估漏洞爆发的规模及其在全球的蔓延程度,这一点上,客户系统崩溃数据和来自客户现场的报告反馈,能帮助公司决策如何从战略上应对这一事件。
其次,是我们能从该事件中总结经验,把整个事件中涉及的相关信息和风险数据都作了归纳整理。十年过去了,我忘记了当时对MS08-067漏洞响应付出的详细努力,当时应用了一些新的通信工具,如高级通告服务(Advanced Notification Service)、微软主动保护计划( MAPP )和我们的官方博客,同时,这些措施和手段也帮助微软定义了未来几年的安全对策。那天,我们坚持了信任和保护客户的原则,而这些都来源于可信计算的价值所在,也是微软在21世纪初艰难前行过程中吸取的经验教训。 Q: 从这次事件的结果中,我们希望吸取或总结出什么好的经验教训?Dustin: 我从中得到的经验是,向客户传达实际风险非常重要。对大多数人来说,安全更新通常被认为是带有一点干扰性或令人讨厌的东西,有些人对他们不太友好信任,但充分的证据表明防止系统遭受攻击入侵的最佳方法也就是及时安装可用的安全更新。对身处行业中的我们来说,我们需要更好地制作出高质量的安全更新,并且需要一种公开坦率地解释安全更新所能缓解的风险。 Ziv: 我的经验就是,遇到这种事情时,需要进行一些内部的漏洞和恶意软件相互关系的交流,其次,更重要的是进行一些与外部的沟通,因为这样才能为其它组织机构和团队提供更多有参考价值的信息。MS08-067漏洞事件时,我们当时发布了很多漏洞公告、技术博客和分析文章,有成千上万的点击阅读量。很明显的是,在这几个月中,有很多安全从业人员和团队需要从各种渠道,来获取可靠的信息和指导方针,而他们利用我们发布的这些信息,可以最大程度地降低缓解资产系统的安全风险。 Phillip: 如果说需要从这个事件中吸取一个教训的话,我认为就是在当时的2008年,整个基于微软的生态系统是存在漏洞和风险的,亟需进行相应的系统缓解加固和修复。当我们在2017年为WannaCry 和 Petya 撰写技术博客时,我觉得那种场景和当时的MS08-067漏洞事件似曾相识,九年之后这种感觉再次浮现。九年之中,整个安全行业在技术和应急响应以及承载系统方面都有了大幅度的提升发展,但尽管如此,感觉我们在更新修复和系统保护方面还没有走在前面。我希望在未来几年中,当另一次攻击出现时,我们行业构建的整个安全生态系统能做到更好更充分的应对和准备。 MS08-067漏洞事件的反思今年是MS08-067漏洞事件的整整十周年,我们的反思和回忆,并不代表该事件对整个安全生态、行业响应或我们个人的职业生涯造成了影响,而是我们认为,该事件是安全史上的一个典型时刻,值得我们去深入了解。非常感谢John Lambert在几年前发表的MS08-067漏洞事件回忆录,它帮我们认识到,即使身处今天这样复杂的攻击威胁下,MS08-067漏洞事件仍然具有参考和借鉴意义。 Q: Dustin,关于对该事件的回顾,你还有什么想要说的吗?Dustin: 就这样吧,当时我不能确定 “我微软职业生涯的顶峰”是什么,但MS08-067的漏洞公告和之后的应急响应相关措施绝对可以在安全史上排名前五,我个人很自豪当时是这个团队的一员,就连现在,我仍然还会和别人说,MS08-067的漏洞公告是 “我的” 公告。 Ziv: MS08-067漏洞响应处理是我个人经历独特的体验,它是集创新、奉献和协调为一体,并以保护客户免受即将到来的攻击为前提的一次工作经历,我们这些亲身参与其中的人,对在当下危机中扮演的角色有着强烈的自豪感。 好吧,谢谢三位嘉宾的真实分享,也感谢大家的捧场和阅读。希望在信息生态系统面临新威胁时,我们能综合总结到一些非常有用的经验。在下一篇博客中,我们将讨论Conficker蠕虫的爆发,Conficker蠕虫利用了MS08-067漏洞,对当时全球大量组织机构造成了破坏性影响。下次见! *参考来源:spiderlabs,clouds编译,转载请注明来自FreeBuf.COM |
CopyRight 2018-2019 实验室设备网 版权所有 |