漏洞挖掘的高级方法.docxVIP

PAGE 1 PAGE 1 漏洞挖掘的高级方法  本篇文章首先我会从一个较高的角度总结于我眼中何谓漏洞挖掘，然后具体争论在软件漏洞挖掘过程中我们需要把握的技能以及需要的学问和工具等。  前言  在此文中我将叙述我在软件漏洞挖掘的实践中学到的技术及方法，不过这些内容并非那些前沿的技术，大多是基础类型的技术及方法。对于初学者而言，期望能够赐予入门的指导，对于经验丰富的漏洞挖掘工作者而言，我认为也可以从中获得一些启发。  受限于我个人的学问水平及能力，这篇文章并不可能做到面面俱到，也期望阅读者能够与我积极交流，对于其中的错误不吝赐教。  我将会把此文分为三个章节，分别阐述我的观点。首先我会从一个较高的角度总结于我眼中何谓漏洞挖掘;然后具体争论在软件漏洞挖掘过程中我们需要把握的技能以及需要的学问和工具等;最终我将谈谈一些我认为有利于漏洞挖掘但是却并非纯技术性的想法。  一.什么是漏洞挖掘  从某个角度来讲，我们可以将漏洞挖掘工作比作玩迷宫游玩，不同的是，这个迷宫与我们平常所见的游玩中的迷宫略有不同：  1.你无法马上看到它整体的外观  2.随着漏洞挖掘工作的深入，这个迷宫的外形渐渐扩大  3.你将会拥有多个起点及终点，但是无法确定这些点详细在哪里  4.最终这个迷宫可能永久也无法100%的完整，但是却能够弄清晰A点至B点的一条完整路径  可以用下面这张图来进行描述：  详细一点的描述，我们可以将漏洞挖掘工作归结为三个步骤：  1.枚举程序入口点(例如：与程序交互的接口)  2.思索可能出现的担心全状态(即漏洞)  3.设法使用识别的入口点到达担心全状态  即是说，在这个过程中，迷宫是我们研究的应用程序，地图是我们堆程序的理解程度，起点是我们的入口点(交互接口)，终点为程序的担心全状态。  所谓入口点，既可以是UI界面上直观可见的交互接口，也可以是特别模糊与透明的交互接口(例如IPC)，以下是部分安全研究员较为感兴趣的关注点：  1.应用程序中比较古老的代码段，并且这一部分随着时间的推移并没有太大的变化。  2.应用程序中用于连接由不同开发团队或者开发者开发的程序模块的接口部分  3.应用程序中那些调试和测试的部分代码，这部分代码本应在形成Release版本时去除，但由于某些原因不小心遗留在程序中。  4.C-S模式(带客户端和服务端)的应用中客户端及服务端调用API的差异部分(例如网页表单中的hide属性字段)  5.不受终端用户直接影响的内部恳求(如IPC)  我认为从攻击面上来划分可以讲漏洞分为两大类，通用漏洞(General)和上下文漏洞(contextual)。通用型漏洞是指在我们对应用的业务规律不是特别熟识的状况下能够找出的漏洞，例如一些RCE(远程代码执行)、SQLi(sql注入)、XSS(跨站)等。上下文漏洞是指需要在对应用的业务规律、认证方式等特别熟识的状况下才能找到的漏洞，例如权限绕过等。  在漏洞挖掘的过程中，我首先会依据经验优先考虑研究测试那些可能会对应用产生巨大威逼的部分。一些轻量级威逼检测模型(如STRIDE)可以辅助我们做出这样的决策。  下面我们首先看一下一个WEB应用程序的漏洞示例，后面将会介绍桌面程序：  首先我们假设目标web应用是一个单页面应用(singleapplicationSPA)，我们已经获得合法验证去访问这个应用，但是我们没有任何关于服务端的源代码或者二进制文件。在这种状况下，当我们枚举入口点时，可以通过探寻该应用的不同功能来进一步了解其业务规律及功能，可以通过抓包分析看HTTP恳求内容，也可以分析客户端的网页代码获取需要提交表单的列表，但是最终的限制还是我们无法详细知悉客户端和服务端调用的API之间的区分，不过通过以上方法，我们可以找到一些入口点，  接着就是操作这些入口点，以试图达到我们预期的担心全状态。由于漏洞的形态许多，我们通常需要构建一个适用于该测试应用程序的业务功能漏洞的测试集，以求达到最高效的查找漏洞。假如不那样做的话，我们就将会在一些无用的测试集上花费大量时间，并且看不到任何效果(举个例子，当后台的数据库为Postgresql时，我们用xp_cmdshell去测试，测试再多次都无济于事)。所以在构造测试集时，需对应用程序的规律有较深的理解。下图形象的展示了低效率测试集的效果：  对于桌面应用程序，漏洞挖掘的思路本质上与web程序是类似的，不过也有一些区分：最大的