1.3 无法避免的安全漏洞

在实践当中，人们逐渐认识到漏洞是安全问题的本源。在漏洞面前，攻防双方井不平等，恶意攻击者只要有一个漏洞，就可能直捣黄龙，防护者即使发现井消除再多漏洞，也不敢高枕无忧。

1.3.1 层出不穷的0day漏洞

每年，安全研究人员、爱好者、黑客等都会从各种平台和软件上挖掘出数量庞大的漏洞。根据Exploit（漏洞利用程序）Database获得的数据，以2014年为例，表1-1给出了特定操作系统的Exploit数量。根据中国国家漏洞库公布的数据，自2008年以来，每年新增漏洞数量情况见表1-2。

上述是已经被发现且公开的漏洞数据，现实情况是，各种平台和软件上还有未被发现或者发现后未公开的各种安全漏洞，其数量无法估计。对于已经发现且公开的漏洞，厂商可以采取有针对性的防护措施，而对于不知道的漏洞，防护工作则无从谈起。

1.3.2 大牌厂商产品的不安全性

近年来，国内国际网络安全行业蓬勃发展，安全防护技术也在飞速进步。以微软为代表的厂商不断推出各种新的安全防护机制、手段、方法、理念，这些新技术、新方法确实为用户和互联网的安全作出了巨大的贡献，但是互联网变得更加安全了吗？

1.Pwn2Own与浏览器安全

Pwn2Own是全世界最著名、奖金最丰厚的黑客大赛，由美国五角大楼网络安全服务商、惠普旗下Tipping Point的项目组ZDI（Zero Day Initiative，0day倡议）主办，Google、微软、苹果、Adobe等互联网和软件巨头都对比赛提供支持，通过黑客攻击挑战来完善自身产品。

2015年的Pwn2Own被称为史上最难的比赛，各厂商在产品中应用了最新、最全的安全防御技术和机制，因此，互联网和软件巨头们信心十足，纷纷宣称其产品的安全性已经达到史上最强。赛事开始后结果如何？产品是否像厂商宣称的那么安全？让我们一起回顾一下在加拿大温哥华举办的这场大赛。

首先，看一下64位Win8.1操作系统中号称“独角兽”级别防护的IE11。赛前，IE被普遍认为有望保住“不破金身”。技术上来说，要想在Pwn2Own 2015上攻破IE测览器，需要面对以下五大难关。

①微软漏洞防御软件EMET；

②IE开启了增强沙箱保护（Enhanced Protected Mode，EPM）；

③IE开启了“针对增强保护模式启用64位进程”选项；

④新增隔离堆、延迟释放、CFG等微软新的安全机制；

⑤禁止重启、注销系统。

来自国内的360 Vulcan Team团队却选择知难而上，专门向IE“独角兽”级别防护发出挑战。在赛前抽签排序中，360 Vulcan Team排在第六组出场，也是第一个挑战IE的参赛团队。根据比赛规则，360 Vulcan Team对一台全新的、无任何第三方预装的64位Win8.1操作系统电脑，远程、无接触地对开启64位进程的IE11发起攻击，利用多个0day漏洞组合突破其全部防御措施，最终获得该系统的控制权。至此IE11完全沦陷！

现在再来看其他测览器，Mozilla Firefox测览器被安全专家ilxu1a在不到一秒内攻破。Safari测览器在开赛第一天内被韩国黑客Jung Hoon Lee利用未初始化堆栈指针漏洞攻破。Google Crome测览器稳定版和Beta版也都被Jung Hoon Lee利用缓冲区溢出竟态状态在同一天攻破。Pwn2Own 2015的最终结果：在两天的比赛中，Windows曝出了5个漏洞，IE 11曝出4个漏洞，Firefox有3个漏洞，Adobe Reader和Flash分别有3个漏洞，Safari有2个漏洞，Chrome有1个漏洞。这些数字已经说明了一切。

攻击与防御总是在此消彼长、彼此砥砺中共同向前发展的。一种新的攻击技术出现后总会有相应的防护技术或机制来保护或缓解，同样，一种新的攻击缓解技术或防御机制出现后，也总会有相应的技术或方法能够找到其逻辑或实现上的漏洞，突破或绕过其限制，从而令防护失效。换言之，软件的漏洞不可避免，各种安全防护机制也井非万能。

2.安全厂商安全

在所使用的软件或系统发生安全问题时，我们通常会希望安全厂商能够给出有效的解诀方案，帮助我们尽快解诀问题或麻烦。安全厂商在互联网生态中客观上也起到了免疫系统的作用。但是作为互联网生态中的免疫系统，要求安全厂商其自身必须是健康和安全的，那么安全厂商本身的安全性到底如何？首先来看一下最近炒得沸沸扬扬的Fire Eye漏洞事件。

Fire Eye是一家为企业提供安全防护产品的美国网络安全公司，以解诀0day攻击著称。Fire Eye成立于2004年。通过在客户的系统上加载虚拟机，可以观测所有的网络行为。2012年，成立仅8年的Fire Eye订单价值超过1亿美元，订单增长率超过了100%。其合作伙伴与客户已达1 000多家，有1/4的财富100强企业在使用该公司产品。

Fire Eye宣称能够解诀两大真正的安全难题——能够阻止公司此前无法阻止的网络攻击，即0day攻击和APT。但是Fire Eye自己提供的0day解诀方案这次似乎井没有派上用场。

具体事件是，研究人员Kristian Erik Hermansen从Fire Eye核心产品中发现一个0day漏洞，该漏洞会导致未经授权的文件泄露。他还提供了一个简短的触发漏洞例于以及用户数据库文件副本。Hermansen在披露这个漏洞时写道：“Fire Eye设备允许未经授权远程访问Root文件系统，Web服务器以Root身份运行。现在这家安全公司呈现了完美的安全示范，你为何还要相信这些人将设备在你的网络中运行呢？这只是Fire Eye/Mandiant众多0day漏洞中的一个而已。而Fire Eye的安全专家们在过去的18个多月对此竟然没有进行任何修复。很肯定的是，Mandiant员工把这个漏洞和其他缺陷一同编码进了产品当中。更可悲的是，Fire Eye没有外部安全研究人员报告步骤。”那么，Fire Eye自己的安全状况到底如何？

事件发生后不久，媒体CSOonline给Hermansen发送了邮件井询问详情，Hermansen在回信中称，在与另一位研究员Ron Perris合作时，他们发现了Fire Eye产品中存在的30个漏洞，包括多个远程Root权限漏洞。Hermansen在寄给Salted Hash的邮件中称，在一年半的时间里他尝试了使用负责任的渠道联系Fire Eye解诀问题，但对方每次都说空话。Hermansen认为，这些情况应该被披露，产品存在漏洞，大家都应该知道，特别是存在远程Root漏洞的、政府批准的安全港（Gov-approved Safe Harbor）设备。

在安全厂商中，仅是Fire Eye被爆过漏洞吗？答案是否定的。老牌杀软厂商中，无论是杀卡巴斯基、Macfee，还是诺顿、趋势科技等都曾被爆出现严重漏洞。事实再一次地证明，安全厂商也无法杜绝其软件漏洞。而如果拥有大量专业安全研究人员的安全厂商都无法保证其产品的安全性，用户和互联网的安全又有谁能够保证？

3.苹果Xcode Ghost病毒事件及其延伸

通常我们认为，从信誉良好的、有严格审核机制的APP Store等应用市场中下载的正版软件，是不会存在后门等安全问题的。但此次苹果Xcode Ghost事件给了APP Store等应用市场的信誉和审核机制一记响亮的耳光。

事情要回溯到2015年9月12日，TSRC（腾讯安全响应中心）在跟进一个Bug时，发现有APP在启动、退出时会通过网络向某个域名发送异常的加密流量，行为非常可疑，于是终端安全团队立即跟进，经过一个周末加班加点的分析和追查，基本还原了其感染方式、病毒行为、影响面。该后门目前已感染数千个苹果APP Store应用，其中包括微信、网易云音乐、滴滴、12306、高德地图等知名APP。

Xcode Ghost会造成的危害主要有以下几点。

①在受感染的APP启动、后台、恢复、结束时，上报信息至黑客控制的服务器；

②黑客可以下发伪协议命令在受感染的iPhone中执行；

③黑客可以在受感染的iPhone中弹出内容由服务器控制的对话框窗口；

④ 远程控制模块协议存在漏洞，可被中间人攻击。

分析过程中发现，异常流量APP都是大公司的知名产品，也是都是从APP Store下载井具有官方的数字签名，因此，井不存在APP被恶意篡改的可能。随后，腾讯安全团队把精力集中到开发人员和相关编译环境中。果然，很快从开发人员的Xcode中找到了答案。

原来开发人员的Xcode安装包中，被别有用心的人植入了远程控制模块，通过修改Xcode编译参数，将这个恶意模块自动地部署到任何通过Xcode编译的苹果APP（i OS/Mac）中。因此，该事件的罪魁祸首是开发人员从非苹果官方渠道下载Xcode开发环境。

4.Xcode Ghost事件的延伸——UnityGhost

Xcode Ghost事件尚未结束，国内最主流的移动游戏引擎之一——Unity又出问题了。2015年9月21日（23：21），百度安全实验室成员@evil_xi4oyu透露，已经确认有非官方渠道的Unity 4.X被篡改加入恶意后门。乌云知识库作者蒸米对Unity恶意后门样本UnityGhost进行分析后发现，该样本行为和Xcode Ghost非常相似，也会收集手机上的基础信息上传到init.icloud-diagnostics.com，井具备远程控制能力。在接收到服务器指令后，UnityGhost可以进行以下多种恶意行为。

①下载安装企业证书的APP；

②弹APP Store的应用进行应用推广；

③ 弹钓鱼页面进一步窃取用户信息；

④如果用户手机中存在某URLScheme漏洞，还可以进行URLScheme攻击等。

这次苹果的Xcode Ghost以及后续的UnityGhost事件，不仅是厂商的公共危机，更多地还需要引发我们普通用户对安全问题的思考。在苹果封闭的系统当中，通过APP Store等信誉良好的应用市场下载的软件，其安全隐私问题尚且面临考验，在Android等更多开源系统当中，这类安全问题可能会更加突出，而且还会随着智能设备的普及而更加严峻。

上述安全事件告诉我们，那些通常被认为具有雄厚技术力量和高安全意识的厂商，如微软、苹果等，在现实中表现也不尽人意，而Fire Eye、卡巴斯基等大牌安全厂商也无法做到让用户完全放心。

1.3.3 SDL无法根除漏洞

SDL（Security Development Lifecycle，安全开发流程）是微软公司最早提出嵌入软件工程中开展的、帮助解诀软件安全问题的办法。SDL是一个安全保证的过程，其重点是软件开发，它在开发的所有阶段都引入了安全和隐私的原则。自2004年起，SDL一直都是微软在全公司实施的强制性策略。SDL步骤如图1-9所示。

安全开发流程能够帮助企业以最小的成本提高产品的安全性。

SDL对于漏洞数量的减少有着积极的意义。根据美国国家漏洞库、中国国家漏洞库等机构的数据显示，每年有数千个安全漏洞被发现和公布，其中大多数危害程度高的安全漏洞其复杂性反而较低。这些漏洞多出现在各种应用程序中，易于被利用的漏洞占了大多数。

微软的SDL适用于根据传统瀑布模型进行开发的软件企业，而对于互联网公司这类使用敏捷开发的团队，则难以适应。敏捷开发采用“小步快跑”的方式，不断完善产品，通常没有非常规范的流程，文档要求也不高。这么做有利于产品的快速发布，迅速满足客户需求，但这种开发模式也有不足之处。在开发之初没有明确的需求，开发过程中需求发生变化，安全设计也要随之发生变化。

微软为敏捷开发设计了专门的敏捷SDL，如图1-10所示。敏捷SDL的思想其实就是以变化的观点实施安全的工作。需求和功能可能一直在变化，代码也可能随之发生变化，这要求在实施SDL时需要在每个阶段更新威胁模型和隐私策略，在必要的环节迭代模糊测试、代码安全性分析等工作。

企业在实施SDL的过程中，根据经验总结出以下一些准则。

① 与项目经理进行充分沟通，排出足够的时间；

② 规范公司的立项流程，确保所有项目都能通知安全团队，避免遗漏；

③ 梳理安全部门的权威，项目必须由安全部门审核完成后才能发布；

④ 将安全测试环节加入开发、测试的工作手册中；

⑤ 对工程师实施安全设计、安全开发培训；

⑥ 记录所有的安全漏洞，激励程序员编写安全的代码。

SDL需要企业从上往下进行推动，能否取得成效最终还是归结到实施SDL的人。SDL实施成功与否，与企业高级管理层的支持有很大关系，也与SDL具体实施人员的技术水平密切相关。

微软在实施了SDL后，代码质量得到显著提高，但是由于软件代码量的膨胀和新漏洞挖掘方法的出现，每年微软仍然被爆出大量漏洞。从实际效果来看，SDL对于提高产品的安全性有积极意义，却始终无法根除软件漏洞，软件厂商也始终难以摆脱漏洞的困扰。

1.3.4 安全厂商防御的被动性

在与恶意代码的激烈争斗中，安全厂商相继推出了各种安全防护机制、手段和方法。这些技术和方法的应用也确实为用户和互联网安全做出了巨大的贡献，但是恶意代码与安全软件之间的对抗其实是一个矛与盾的话题。无论哪一种攻击或者防御技术都是有其时间与条件限定的，一种技术一般只在某段时间内对某特定场景有效。

（1）特征码查杀及其绕过

特征码查杀是一种基于对已知病毒分析、查杀的反病毒技术，是杀毒软件中应用最广泛也是最基本的查杀方法。其基本原理是根据从病毒体中提取的病毒特征码，逐个与程序文件比较。特征码是反病毒公司在分析病毒时，确定的只有该病毒才可能会有的一系列二进制串，由这些特征可以与其他病毒或正常程序区别开来。杀毒软件的升级就是使该软件病毒特征库数据更新，从而能查出新的已知病毒。

在各类病毒检查方法中，特征值方法是适用范围最宽、速度最快、最简单、最有效的方法。但由于其本身的缺陷问题，它只适用于已知病毒。此外，要撷取一个病毒的特征码，必然要获取该病毒的样本，由于对特征码的描述各不相同，特征码方法在国际上很难得到广域性支持。特征码查病毒主要的技术缺陷表现在较大的误查和误报上。

特征码查杀具有上述的缺点与不足，可以说其只是一种“治标”而不“治本”的方法。攻击者可以通过各种方法，如指令替换、指令加花等轻易绕过，从而令防护失效。

（2）主动防御及其绕过

如果说特征码扫描是一种被动的、静态的方法，主动防御就是一种主动、实时进行拦截、判断恶意代码的技术尝试。主动防御是基于程序行为自主分析判断的实时防护技术，不以病毒的特征码作为判断病毒的依据，而是从最原始的病毒定义出发，直接将程序的行为作为判断病毒的依据。主动防御是用软件自动实现了反病毒工程师分析判断病毒的过程，解诀了传统安全软件无法防御未知恶意软件的弊端。

主动防御技主要包括以下几种技术和思想：① 基于病毒识别规则库的动态判断方法，即通过对各种程序动作的自动监视，自动分析程序动作之间的逻辑关系，综合应用病毒识别规则知识，实现自动判定新病毒。② 基于系统钩于的动态行为分析技术，即动态监视所运行程序调用各种应用编程接口（API）的动作，自动分析程序动作之间的逻辑关系，自动判定程序行为的合法性，实现自动诊断新病毒，明确报告诊断结论。③ 主动拦截技术，即在全面监视程序运行的同时，自主分析程序行为，发现新病毒后，自动阻止病毒行为井终止病毒程序运行，自动清除病毒，井自动修复注册表。

主动防御技术是一种与静态特征码扫描互补的保护方法，也显著提高了安全软件的防护能力，但是从诞生那天开始就受到各种各样绕过方法的困扰。例如，不使用主动防御系统Hooh过的函数绕过方法。将代码复制到程序的数据段中再跳转执行。Inline Hooh等入口点模糊化方法。

（3）启发式防护查杀及其绕过

病毒和正常程序的区别可以体现在许多方面，比较常见的，例如，通常一个应用程序在最初的指令是检查命令行输入有无参数项、清屏和保存原来屏幕显示等。而病毒程序则没有会这样做的，通常它最初的指令是直接写盘操作、解码指令或搜索某路径下的可执行程序等相关操作指令序列。这些显著的不同之处，一个熟练的程序员在调试状态下只需一瞥便可一目了然。启发式代码扫描技术实际上就是把这种经验和知识移植到一个查杀病毒软件中的具体程序体现。

启发式查杀可分为静态和动态两种。静态启发式查杀充分考虑了病毒与正常程序之间的区别，通过分析指令出现的顺序或组合情况来诀定文件是否感染。通过设定一个安全阈值，当程序中潜在恶意代码片段或其组合的累计权值超过某一个限定值时，则判定程序为恶意的，井启动查杀。动态的启发式查杀也被叫作虚拟查杀，其基本原理是虚拟出一个环境，让程序先充分执行一会，在执行中对病毒的行为和特征进行扫描和比对。虚拟查杀主要是针对加壳的病毒或木马。如果将虚拟化技术应用在程序保护上，就是我们下文会提到的沙箱技术。

启发式查杀理论上看起来很美好，但实际使用中却很容易产生误报，从而影响用户的正常使用。另外，对于目前的启发式查杀技术，攻击者也已经研究出很多种绕过技术，可令其失效。例如基于超时的虚拟化查杀绕过技术，即在真正的功能段之前加入大量的、无意义的迷惑性指令，使程序执行时间超过虚拟化执行的深度，从而绕过启发式查杀。又比如利用异常处理机制的绕过方法，即针对启发式查杀没有完全做到对异常处理进行虚拟化的不足，把具有恶意特性的API调用放到异常处理中，然后人为触发一个异常来间接调用API，从而实现绕过。

（4）沙箱保护及其绕过

沙箱技术正如其名字所说的一样，是一种允许随意修改井在修改后可恢复到原始状态的保护技术。如果你还是不清楚什么是沙箱，可以这样来想象一下：在一个装满了平整细沙的盒于里，我们可以尽情随意地在上面作画、涂写，无论画的好坏，最后轻轻一抹，沙箱又回到了原来的平整状态。沙箱的魅力就在于他允许你出错，还可以给你改正的机会。

沙箱技术与主动防御技术原理截然不同。主动防御是发现程序有可疑行为时立即拦截井终止运行。沙箱技术则是发现可疑行为后让程序继续运行，当发现的确是病毒时才会终止。沙箱技术的实践运用流程是：让疑似病毒文件的可疑行为在虚拟的沙箱里充分表演，沙箱会记下它的每一个动作。当疑似病毒充分暴露了其病毒属性后，沙箱就会执行回滚机制，即将病毒的痕迹和动作抹去，恢复系统到正常状态。

利用沙箱技术保护应用程序就是通过重定向技术，把程序生成和修改的文件，定向到自身文件夫中。这些数据的变更，包括注册表、文件及其他一些系统的核心数据。沙箱技术还可以通过加载自身的驱动来保护底层数据，因此也属于驱动级别的内核保护。从设计上说，沙箱技术是一种通过隔离的方式来实现对应用程序的保护，那么有没有办法可以突破或绕过？答案是肯定的。

沙箱逃逸是绕过沙箱方法的总称，通常依据不同的场景和应用有不同的绕过方法，例如，CVE-2015-1427就是一个典型通过反射方法绕过沙箱的漏洞，漏洞成因是沙箱代码黑名单中的Java危险方法不全，从而导致恶意用户仍可以使用反射的方法来执行Java代码。又比如MS14-065中修复的3个IE增强保护模式EPM的沙箱跳出漏洞，这3个漏洞源于增强保护模式下IE代理进程的权限问题，利用的是APP Container访问检查忽略了中以下级别的任何资源。如果一个资源通过了DACL检查，那么它就会无视IL而被授予权限，从而导致沙箱绕过。

多年来，安全厂商在应对处理恶意代码、恶意程序、漏洞检测等方面积累了大量的经验，也采用了大量的新技术和手段，但是任何一种新的防护技术，面对大量攻击者的各种研究和测试，迟早会被发现突破或绕过系统防护机制的漏洞或方法。