时光荏苒，距离MS08-067漏洞的出现已经过去十年了，与其它安全事件不同，MS08-067漏洞经历了辉煌的一页，具有里程碑意义，就连当时负责处理该漏洞的人都印象深刻记忆犹新。基于微软威胁情报总经理 John Lambert的回忆 ，我们采访了当时处理该漏洞响应事件的一线工程师，力求从他们那里得到关于MS08-067漏洞的最真实感受，全面回顾这个引发Conficke蠕虫的严重安全事件。（ 点此参考 微软关于MS08-067的技术分析回顾） 采访嘉宾介绍 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蠕虫变体，算是我们处理过的最严重的安全事件了，前后持续了数月之久。
Phillip： 那个时候，我是微软软件安全响应事件流程（SSIRP）机制的危机处理领导，负责对监测到的一些主动攻击，进行一些安全动员和响应。在该角色工作中，我主要实施了风险理解的推动和一些相关的技术性工程计划，以及协调整体的应对措施。 Q: 你们当时对MS08-067漏洞有什么难忘的回忆？
Dustin: 当时看到微软的各个部门通力合作来处理这个漏洞，我个人还是比较惊讶的，我们微软总部、印度和欧洲的分公司团队几乎都是在全天候工作状态模式。有一件事我印象特别深刻，当针对MS08-067漏洞进行首次安全响应事件流程（SSIRP）会议时，会议室里坐满了15多人，还有很多专家是通过电话会议专线接入的，当Phillip解释完这个漏洞的相关情况之后，会议气氛突然陷入了瞬时的沉默，因为我们知道伴随这个漏洞而来的将是大量的蠕虫病毒。
从那一刻起，我们明白战斗已经开始了。没有经历过这种大场面的人可能没有那种体会，当时房间里坐着的都是一众信息安全专家，他们都曾亲自应对过Melissa、Nimda、Slammer、Sasser和Code Red等超级蠕虫病毒。另外比较有意思就是，出于应急优先，我只要解释一下MS08-067漏洞的情况，就能马上协调调配工作人员来参与响应处理。
我当时谈的更多的是，是否要基于这个漏洞做一些中等风险的评级，所有人都清楚其中的利害关系。针对这个漏洞，当时微软所有人不分昼夜地进行了17天的应对处理工作。另一个引人注目的事情是，其广泛的漏洞影响范围，基于NT的系统都涉及其中，除Windows Server 2008 Core外，所有Windows系统，包括Windows 2000/XP/Server 2003/Vista/Server 2008的各个版本，甚至还包括测试阶段的Windows 7 Pro-Beta。我们甚至还被要求针对Windows ME 和Win 98这两个古老系统制作相关的漏洞补丁，甚至我还听说，为了应对史蒂夫鲍尔默即将召开的Win 7测试版发布会，我们需要加紧重新制作新的系统DVD安装盘，以备现场分发的Win 7光盘系统不受影响。
Ziv: 首先是，John Lambert领导的微软可信计算团队向我们提供了这个惊人的Windows 0-day漏洞消息，他们的团队研发出了从崩溃报告中判断识别未知0-day漏洞的方法，利用该方法，他们能跟踪利用MS08-067漏洞进行攻击尝试的崩溃次数，一旦识别出了相当的次数，微软恶意软件防护中心（MMPC）的分析师就会立即进行相应的防病毒签名开发，以帮助我们发现其漏洞利用代码。当时，尽管我们维护着一个大型的恶意软件库，但好在没有发现太多基于MS08-067漏洞的传播类非复制型恶意软件样本。之后，配合微软官方发布的MS08-067安全更新，我们也对外公布了针对该漏洞的公共签名，帮助企业和个人用户能更好地防护攻击识别线索，以最大程度地减少受影响范围。
我们知道，随着社会公共领域的不断信息化，将会有更多的恶意软件随之而来，在安全补丁尚未打全之前，坏人和犯罪份子绝不会错过这种漏洞利用的良机。也就在MS08-067漏洞事件期间，我也应景地写了一篇官方博客，标题就叫做 “ 赶快打补丁，要快！ ”。
不出所料，微软发布的这个重要的带外安全更新（Out-Of-Band Update）迅速引发了媒体关注，就连当时还为《华盛顿邮报》撰稿的Brian Krebs也 发布了文章进行跟进报道 。
接着，在接下来的几天内，我们屏住呼吸，每小时不间断地检查监测数据，网络中出现了大量的系统崩溃报告反馈，很明显，有人正利用这个漏洞对目标系统进行攻击尝试。在MS08-067出现后一个月的11月初，基于该漏洞新的恶意软件变体出现了，但好在其传播感染性不高。但就在几周之后，基于MS08-067漏洞的Conficker蠕虫大量爆发了，这点可以在后续的访谈中我们再作讲述。
Phillip: MS08-067应该算是第一起在大面积传播感染之前，我们能够在早期发现一些攻击线索的事件。我记得，当时我们发现了阻止其造成广泛攻击的方法，非常兴奋，也正是这一机会促使我们公司内部抓紧研发了漏洞解决方案。我们分散在世界各地的团队共同合作，从漏洞出现到补丁发布，前后只用了17天的时间，在当时这已经算是非常快的速度和节奏了。此外，MS08-067漏洞事件给我的另外一个记忆就是，直接导致了之后微软对重要带外安全更新的发布增加。在漏洞出现之初，我们检测到每天只有一两次的该漏洞利用攻击，显然一开始它造成的网络攻击不算广泛，后来在10月15日左右，我们从监测数据上可以看到，其攻击已经上升为每天12次了。诚然说，尽管12次并不算什么大数字，而且我们监测到的攻击也都是一些失败的攻击利用尝试， 但这说明一种跳跃性的波动趋势，至少从风险层面来说，它存在一种大的波动可能。
我们所监测到的网络攻击者，与像Slammer或Blaster这样的传播感染蠕虫之间的不同之处就在于，攻击者利用漏洞攻击带有一定的意图，当我们在讨论补丁发布和修复方案时，我也在会上重复强调了这个问题。最终，我们决定了一个风险优先的平衡快速修复方案。只是在补丁发布之后，当我们从攻击者利用的网络基础设施中进行信息提取时才发现，早前我们监测到的攻击正处于增长趋势，是后续大规模攻击的前期铺垫（可以从 这里的报告中 看到具体变化）。
MS08-067漏洞给我另外记忆较深的事就是其补丁发布，其提前公告描述（Advanced Notification Summary）是在正式补丁发布前一天就公布的，短短的五句话让业界措手不及。
那个时候，这种带外安全更新非常少见，常常与一些野外攻击相关。当时引起的反应就是，反恶意软件供应商们都在争先恐后地寻找攻击线索，但确实当时只有微软观察到了这些攻击。在在面积攻击发生之前，我们使用的技术和监测手段派上了用场，提供了重要的参考。从某种层面上说，我们也限制住了攻击者，一旦安全更新发布，攻击者利用的网络基础设施就会被识别发现，该漏洞就不能再继续被利用了。所在，在MS08-067漏洞造成大面积攻击之前，我们能及时发布更新补丁，多少还是非常欣慰的。 Q: 你认为对MS08-067衍生攻击的应急响应如何？
Dustin: 对我来说，有两件事非常明显，首先，一开始我们做的漏洞公告是1.0版的，在下载我们发布的安全更新之后，系统中的修复会很快生成，剩下的时间就是系统的一些修复测试，它会确保漏洞能被有效修复，且不会产生其它问题。和我其它的工作经历相比，我认为MS08-067事件是微软全力以赴共同保护客户的一个典型案例。
另外，我们做得好的就是如何来说清楚这件事。通常的漏洞更新会统一放在星期二的更新公告日中，但对于这个漏洞来说，我们做了三个公告，每个公告都是对60多个问题回答的综合描述。我们全力与公关和营销伙伴合作，尽量让大众知道安装此更新的重要性，我们甚至把更新公告放到了msn.com首页上，反正我们想出了任何可以提醒人们安装该重要更新的方法。
我们这么煞费苦心，是有原因的，从这一点上来说，也可以反映出后期基于MS08-067的Conficker蠕虫变化规律，刚开始出现的Conficker.A版本造成的影响有限，仅使用了服务漏洞进行传播，后期的Conficker.B就加入了NetBIOS感染方式，成为了所谓的互联网猛兽。
Ziv: 当MS08-067事件发生时，我已经在微软恶意软件保护中心工作了五年多，在该响应事件中，我看到微软和安全社区的运作方式有了显著改善，能积极对这种事件做出响应。MS08-067事件时，微软的整个响应过程已经很成熟了，包括微软安全响应中心、可信计算团队、微软恶意软件保护中心、客户支持团队、Windows产品团队、安全通信、现场和政府外联人员在内的各部门，都能做到有序高效的运作，应急过程包括明确参与团队的代表人员，然后根据需要在短时间内发起协调动员，而且，安全响应事件流程（SSIRP）的战时会议效率很高，通常15分钟左右就会召开一次会议。
创新为成功做出了重要贡献， John Lambert领导的团队能从数百万份崩溃报告中识别出了潜在未知的0-day漏洞，这种方法非常厉害，能提早预防MS08-067此类高危漏洞的广泛利用，我们可据此发布安全更新，及时为Windows客户提供安全保护。
就当时，对于我所在的团队MMPC来说，底层基础设施在过去几年中有了显著改善，能很好地支持了我们的技术需求。每天都有大量恶意可疑的文件被收集、扫描并存储在我们的系统中，这使得我们能够快速识别新的恶意软件，并对其进行分析，获得必要的技术信息，例如它利用了哪些漏洞，它是如何传播的，以及它连接到了哪些恶意服务器或URL链接。在有些情况下，其它安全供应商和机构也会向我们提供恶意软件样本，进一步加强了我们阻止疫情蔓延的能力。MMPC利用全球数亿台用户计算机系统的综合兼容性技术（Microsoft Compatibility Telemetry）来收集数据，其中最流行的工具就是微软恶意软件删除工具 (MSRT)，但我们也受益于其它安全产品，如OneCare和Forefront系列产品，此类客户系统数据让作为一名响应协调员的我，能够评估漏洞爆发的规模及其在全球的蔓延程度，这一点上，客户系统崩溃数据和来自客户现场的报告反馈，能帮助公司决策如何从战略上应对这一事件。
Phillip: 回顾对MS08-067漏洞的应急响应，我觉得有两个方面我们做得非常好，那就是响应速度和为不同受众获取正确的风险数据。首先，就像之前他们说到的，我们动用了公司世界级的努力来制作漏洞补丁，那时候，微软大多数服务工程师都集中在总部的华盛顿雷德蒙德和印度的海德拉巴，从地域上来说是完全分开的，但是，公司的各个工程师团队都竭尽全力夜以继日地开干，最终完美地完成了补丁的开发和测试工作。这些团队投入的奉献精神和辛勤工作令人瞩目，我由衷地向他们致敬，感谢他们为更好地保护客户所做的一切努力。
其次，是我们能从该事件中总结经验，把整个事件中涉及的相关信息和风险数据都作了归纳整理。十年过去了，我忘记了当时对MS08-067漏洞响应付出的详细努力，当时应用了一些新的通信工具，如高级通告服务（Advanced Notification Service）、微软主动保护计划( MAPP )和我们的官方博客，同时，这些措施和手段也帮助微软定义了未来几年的安全对策。那天，我们坚持了信任和保护客户的原则，而这些都来源于可信计算的价值所在，也是微软在21世纪初艰难前行过程中吸取的经验教训。
Q: 从这次事件的结果中， 我们 希望吸取或总结出什么好的经验教训？Dustin: 我从中得到的经验是，向客户传达实际风险非常重要。对大多数人来说，安全更新通常被认为是带有一点干扰性或令人讨厌的东西，有些人对他们不太友好信任，但充分的证据表明防止系统遭受攻击入侵的最佳方法也就是及时安装可用的安全更新。对身处行业中的我们来说，我们需要更好地制作出高质量的安全更新，并且需要一种公开坦率地解释安全更新所能缓解的风险。
Ziv: 我的经验就是，遇到这种事情时，需要进行一些内部的漏洞和恶意软件相互关系的交流，其次，更重要的是进行一些与外部的沟通，因为这样才能为其它组织机构和团队提供更多有参考价值的信息。MS08-067漏洞事件时，我们当时发布了很多漏洞公告、技术博客和分析文章，有成千上万的点击阅读量。很明显的是，在这几个月中，有很多安全从业人员和团队需要从各种渠道，来获取可靠的信息和指导方针，而他们利用我们发布的这些信息，可以最大程度地降低缓解资产系统的安全风险。
Phillip: 如果说需要从这个事件中吸取一个教训的话，我认为就是在当时的2008年，整个基于微软的生态系统是存在漏洞和风险的，亟需进行相应的系统缓解加固和修复。当我们在2017年为WannaCry 和 Petya 撰写技术博客时，我觉得那种场景和当时的MS08-067漏洞事件似曾相识，九年之后这种感觉再次浮