【网络安全】漏洞挖掘入门教程（非常详细），小白是如何挖漏洞（技巧篇）从零基础入门到精通！

温馨提示：

初学者最好不要上手就去搞漏洞挖掘，因为漏洞挖掘需要很多的系统基础知识和一些理论知识做铺垫，而且难度较大……

较合理的途径应该从漏洞利用入手，不妨分析一些公开的CVE漏洞。很多漏洞都有比较好的资料，分析研究的多了，对漏洞的认识自然就不同了，然后再去搞挖掘就会易上手一点！

俗话说：“磨刀不误砍柴工”，就是这么个理儿。

对于有一些基础知识的初学者，应该怎样进行漏洞挖掘呢？

一、漏洞是怎样被发现的
在这里插入图片描述
从某个角度来讲，我们可以将漏洞挖掘工作比作玩迷宫游戏，不同的是，这个迷宫与我们平时所见的游戏中的迷宫略有不同：

（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应用是一个单页面应用程序（single-page-application SPA），我们已经获得合法验证去访问这个应用，但是我们没有任何关于服务端的源代码或者二进制文件。在这种情况下，当我们枚举入口点时，可以通过探寻该应用的不同功能来进一步了解其业务逻辑及功能，可以通过抓包分析看HTTP请求内容，也可以分析客户端的网页代码获取需要提交表单的列表，但是最终的限制还是我们无法具体知悉客户端和服务端调用的API之间的区别，不过通过以上方法，我们可以找到一些入口点。

接着就是操作这些入口点，以试图达到我们预期的不安全状态。由于漏洞的形态很多，我们通常需要构建一个适用于该测试应用程序的业务功能漏洞的测试集，以求达到最高效地寻找漏洞。如果不那样做的话，我们就将会在一些无用的测试集上花费大量时间，并且看不到任何效果（举个例子，当后台的数据库为Postgres时，我们用xp_cmdshell去测试，测试再多次都无济于事）。

所以在构造测试集时，需对应用程序的逻辑有较深的理解。下图形象地展示了低效率测试集的效果：

在这里插入图片描述

与黑盒测试相比，当有源代码时（白盒测试），在寻找代码入口和程序执行路径等漏洞挖掘点时所做的猜测性的工作会大大减少，在这种情况下，将数据载荷从入口点执行到不安全的程序位置的效率低于从不安全的程序位置回溯至入口点。不过在白盒测试中，你对代码的测试的覆盖面可能会由于你自己的知识局限性而受到影响。

二、漏洞挖掘需要具备的知识

从事漏洞挖掘工作需要具备的知识是极其广泛的，并且随着时间在不断改变，也取决于你所研究的对象（web程序、桌面程序、嵌入式等等）。不过，万变不离其宗，所需要掌握的知识领域却总可以认为是确定的，大致可以分为以下四个方面：

（1）程序正向开发技术。
这是一个开发者需要掌握的能力，包括编程语言、系统内部设计、设计模式、协议、框架等。拥有丰富编程经验与开发能力的人在漏洞挖掘过程中往往比那些只对安全相关领域有所了解的人员对目标应用能有更深入的理解，从而有更高的产出。

（2）攻防一体的理念。
这些知识涵盖了从基本的安全原则到不断变换的漏洞形态及漏洞缓解措施。攻击和防御结合的理念，能够有效帮助研究者既能够发现漏洞，同时也能够快速给出有效的漏洞缓解措施和规避方法。

（3）有效使用工具。
能够高效的使用工具能够快速将思路转化为实践，这需要通过花时间去学习如何配置和使用工具，将其应用于自己的任务并构建自己的工作流程来不断积累经验。更进一步，需要深入掌握所使用工具的原理，以及如何对其进行二次开发，以使得其能够更加高效的应用于当前的工作实际。事实上，面向过程的学习方法往往比面向工具的学习方法更加高效以及有价值，当自己发现一个在使用一个工具遇到瓶颈时，先不要退缩，尝试去改造它，或者通过自己动手实践去完成能够适应当前工作的工具，这往往能够帮助快速积累大量实践经验。帮助我们以后更加高效的去实践漏洞挖掘工作。

（4）对目标应用的理解。
最后，也是最重要的，作为一个漏洞挖掘人员，对自己研究的应用程序在安全性方面必须要比这个程序的开发者或维护者有更深的理解。这样你才能尽可能的发现这个程序中的漏洞并修复它。

零基础也不用担心，漏洞挖掘技术教程从0到已经整理好了，大家自取学习哦！

网络安全/黑客技术：CSDN大礼包：《黑客&网络安全入门&进阶学习资源包》免费分享

请添加图片描述

下面这张表格介绍了挖掘web应用程序和桌面应用程序的漏洞时所需要掌握的内容。每个类别中的条目仅用于说明目的，并非详尽无遗。

在这里插入图片描述

学习工具以及源代码：
请添加图片描述

三. 漏洞挖掘需要做什么

当分析一个应用程序时，你可以使用下图展示的四个“分析模型”，如果遇到障碍导致思路受阻时，你可以从其中一个模型切换到下一个模型，当然，这不是一个线性的切换，你也可以有自己的一套方法。

在这里插入图片描述
在每一个模型之中都有主动活动（[active activities](https://www.zhihu.com/search?q=active activities&search_source=Entity&hybrid_search_source=Entity&hybrid_search_extra={“sourceType”%3A"answer"%2C"sourceId"%3A738120571})）与客观活动存在（passive activities），主动活动需要我们对程序的执行环境及上下文有一个比较全面的了解，而客观活动却不一定，比如它是客观存在与程序的一些技术文档之中。不过，这种划分也不一定严格，不过对于每一个活动，我们可以从以下几方面去考虑：

（1）理解有关漏洞的相关模型
（2）试图假设一个场景去破坏程序
（3）尝试去破坏程序

（一）程序用途分析（Use case analysis）
在这里插入图片描述
程序用途分析是指理解一个应用程序做了什么工作，会提供什么服务等。同时，阅读与该程序的相关文档将有助于进一步理解程序功能（如上图所示）。这样做有利于对程序有一个透彻的了解。

或许，比起直接构造测试样例进行测试，这项工作可能并不是那么有意思。不过，它的确可以节省一大笔时间。举一个例子， Oracle Opera（一个广泛使用的酒店管理软件）[CVE-2016-5563/4/5]的远程代码执行漏洞，可以通过阅读器用户手册快速找到可能存在危险的数据表，最后快速找出远程代码执行漏洞。

（二）执行条件分析（Implementation analysis）

在这里插入图片描述
执行条件分析是指理解应用程序运行时需要包括的环境因素，比如网络配置，端口使用等。可以通过端口扫描，漏洞扫描等方式进行操作。这些配置上的问题，很可能就会导致一个漏洞的出现。

举个例子，一个系统权限级别的程序，由于配置错误，可能会使的低权限的用户能够访问并修改，最终导致一个权限提升，引发一个提权漏洞。又比如，在一个网络程序中，可能程序本身并没有错误，但是由于这个服务器开了一个anonymous的FTP服务器，那么任何人都有可能访问这个机器，这就导致web应用的源代码或者其他敏感文件暴露在外面。这些问题，理论上并非程序自身的漏洞，但是由于其执行环境的因素，就使得其成为一个漏洞。

（三）通信分析（Communications analysis）

在这里插入图片描述
通信分析是指对一个目标程序与其他进程或系统之间交互信息的方式进行深入分析。在这样的前提下，可通过发送精心构造的请求（Request）等方法，触发不安全状态。许多web应用程序漏洞都是通过这种方式发现的。

在上述模式下，需要我们对数据通信协议有较为清晰的认识，如果并不能够清晰的了解协议格式呢？这种情况就要借助黑盒测试的技术进行解决，主要通过发送请求，并根据返回值进行判断是否存在异常。

下面举个例子来说明，这里假设存在一个金融网站，里面有一项功能允许用户使用不同的货币购买预付信用卡。这里假设实现这项业务的请求（Request）如下：

· fromAccount : 用于购买预付卡的账户

· fromAmount : 需要从fromAccount转入预付卡的金额（例如 $100）

· cardType : 需要购买的预付卡类型（例如美元、英镑）

· currencyPair : 付款账户fromAccount和预付信用卡cardType的货币配对 , 用于计算汇率（如 CADUSD、CADGBP）

四. 有关漏洞挖掘的其他想法

（一）漏洞的复杂性
漏洞的复杂性分布非常广。一方面，有很多漏洞非常简单与直观，并且利用代码一目了然，比如说经典的sql注入。另一方面，在系统中有的看似并不相关，并且就其自身而言并非不安全，但是当这些东西以一种特定的方式结合起来的时候，就有可能引发大的漏洞，比如说条件竞争，或者一些其他的复杂的逻辑漏洞。可以尝试将这些漏洞按照复杂级别分为“一级漏洞”和“二级漏洞”，不过也有其他分类方法。引用一局来自Project Zero的Ben Hawkes说过的一句话：

Themodern exploit is not a single shot vulnerability anymore. They tend to be achain of vulnerabilities that add up to a full-system compromise.

如今想要完成一个完整的利用，只靠单一的漏洞往往行不通。很多时候我们需要靠一连串的漏洞才能完成一起完整的利用，致使系统“妥协”。

（二）团队工作
在一个团队中工作能够有效帮助自己了解自己不知道的知识，以及提高自己已知的知识。不过在团队中要需要注意工作的方式方法，知之为知之，不知为不知，永远不要强行假装精通你不熟悉的东西，因为精通的人可以很轻易的指出你的症结。如果一个团队里面大家都不坦诚相待，那么这不是一个合格的团队，你可以尽早更换。在优秀的团队中，不要指望别人会把所有的知识交给你，要学会如何高效的学习，并在团队交流与合作中不断提高。

五. 最后

希望这篇文章在可以帮助你解开一些对于漏洞挖掘的谜团。在学习和研究漏洞挖掘的过程中遇到困难并感到不知所措是很正常的。不过学习的过程就是这样，只有不断的去尝试才会进步。

祝你在漏洞挖掘的路上走的越来越远！