High-Level Approaches for Finding Vulnerabilities

Fri 15 September 2017

This post is about the approaches I've learned for finding vulnerabilities in applications (i.e. software security bugs, not misconfigurations or patch management issues). I'm writing this because it's something I wish I had when I started. Although this is intended for beginners and isn't new knowledge, I think more experienced analysts might gain from comparing this approach to their own just like I have gained from others like Brian Chess and Jacob West, Gynvael Coldwind, Malware Unicorn, LiveOverflow, and many more.

Keep in mind that this is a work-in-progress. It's not supposed to be comprehensive or authoritative, and it's limited by the knowledge and experience I have in this area.

I've split it up into a few sections. I'll first go over what I think the discovery process is at a high level, and then discuss what I would need to know and perform when looking for security bugs. Finally, I'll discuss some other thoughts and non-technical lessons learned that don't fit as neatly in the earlier sections.

What is the vulnerability discovery process?

img

In some ways, the vulnerability discovery process can be likened to solving puzzles like mazes, jigsaws, or logic grids. One way to think about it abstractly is to see the process as a special kind of maze where:

1. You don't immediately have a birds-eye view of what it looks like.
2. A map of it is gradually formed over time through exploration.
3. You have multiple starting points and end points but aren't sure exactly where they are at first.
4. The final map will almost never be 100% clear, but sufficient to figure out how to get from point A to B.

从某个角度来讲，我们可以将漏洞挖掘工作比作玩迷宫游戏，不同的是，这个迷宫与我们平时所见的游戏中的迷宫略有不同：

（1）你无法立即看到它整体的外观 （2）随着漏洞挖掘工作的深入，这个迷宫的形状逐渐扩大 （3）你将会拥有多个起点及终点，但是无法确定这些点具体在哪里 （4）最终这个迷宫可能永远也无法100%的完整，但是却能够弄清楚A点至B点的一条完整路径

img

If we think about it less abstractly, the process boils down to three steps:

1. Enumerate entry points (i.e. ways of interacting with the app).
2. Think about insecure states (i.e. vulnerabilities) that an adversary would like to manifest.
3. Manipulate the app using the identified entry points to reach the insecure states.

具体一点地描述，我们可以将漏洞挖掘工作归结为三个步骤： （1） 枚举程序入口点（例如：与程序交互的接口） （2） 思考可能出现的不安全状态（即漏洞） （3） 设法使用识别的入口点到达不安全状态

In the context of this process, the maze is the application you're researching, the map is your mental understanding of it, the starting points are your entry points, and the end points are your insecure states.

即是说，在这个过程中，迷宫是我们研究的应用程序，地图是我们对程序的理解程度，起点是我们的入口点（交互接口），终点为程序的不安全状态。

Entry points can range from visibly modifiable parameters in the UI to interactions that are more obscure or transparent to the end-user (e.g. IPC). Some of the types of entry points that are more interesting to an adversary or security researcher are:

所谓入口点，既可以是UI界面上直观可见的交互接口，也可以是非常模糊与透明的交互接口（例如IPC），以下是部分安全研究员较为感兴趣的关注点：

• Areas of code that are older and haven't changed much over time (e.g. vestiges of transition from legacy).
• Intersections of development efforts by segmented teams or individuals (e.g. interoperability).
• Debugging or test code that is carried forward into production from the development branch.
• Gaps between APIs invoked by the client vs. those exposed by the server.
• Internal requests that are not intended to be influenced directly by end-users (e.g. IPC vs form fields).

（1） 应用程序中比较古老的代码段，并且这一部分随着时间的推移并没有太大的变化。 （2） 应用程序中用于连接由不同开发团队或者开发者开发的程序模块的接口部分 （3） 应用程序中那些调试和测试的部分代码，这部分代码本应在形成Release版本时去除，但由于某些原因不小心遗留在程序中。 （4） C-S模式（带客户端和服务端）的应用中客户端及服务端调用API的差异部分（例如网页表单中的hide属性字段） （5） 不受终端用户直接影响的内部请求（如IPC）

The types of vulnerabilities I think about surfacing can be split into two categories: generic and contextual. Generic vulnerabilities (e.g. RCE, SQLi, XSS, etc.) can be sought across many applications often without knowing much of their business logic, whereas contextual vulnerabilities (e.g. unauthorized asset exposure/tampering) require more knowledge of business logic, trust levels, and trust boundaries.

从攻击面上来划分，可以将漏洞分为两大类，通用漏洞（General）和上下文漏洞（Contextual）。通用型漏洞是指在我们对应用的业务逻辑不是非常熟悉的情况下能够找出的漏洞，例如一些RCE（远程代码执行）、SQLi（sql注入）、XSS（跨站）等。上下文漏洞是指需要在对应用的业务逻辑、认证方式等非常熟悉的情况下才能找到的漏洞，例如权限绕过等。

The rule of thumb I use when prioritizing what to look for is to first focus on what would yield the most impact (i.e. highest reward to an adversary and the most damage to the application's stakeholders). Lightweight threat models like STRIDE can also be helpful in figuring out what can go wrong.

在漏洞挖掘的过程中，首先根据经验优先考虑研究测试那些可能会对应用产生巨大威胁的部分。一些轻量级威胁检测模型（如STRIDE）可以辅助我们做出这样的决策。

Let's take a look at an example web application and then an example desktop application.

下面我们来看一个WEB应用程序的漏洞示例，后面将会介绍桌面程序：

Let's say this web application is a single-page application (SPA) for a financial portal and we have authenticated access to it, but no server-side source code or binaries. When we are enumerating entry points, we can explore the different features of the site to understand their purpose, see what requests are made in our HTTP proxy, and bring some clarity to our mental map. We can also look at the client-side JavaScript to get a list of the RESTful APIs called by the SPA. A limitation of not having server-side code is that we can't see the gaps between the APIs called by the SPA and those that are exposed by the server.

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

The identified entry points can then be manipulated in an attempt to reach the insecure states we're looking for. When we're thinking of what vulnerabilities to surface, we should be building a list of test-cases that are appropriate to the application's technology stack and business logic. If not, we waste time trying test cases that will never work (e.g. trying xp_cmdshell when the back-end uses Postgres) at the expense of not trying test cases that require a deeper understanding of the app (e.g. finding validation gaps in currency parameters of Forex requests).

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

With desktop applications, the same fundamental process of surfacing vulnerabilities through identified entry points still apply but there are a few differences. Arguably the biggest difference with web applications is that it requires a different set of subject-matter knowledge and methodology for execution. The OWASP Top 10 won't help as much and hooking up the app to an HTTP proxy to inspect network traffic may not yield the same level of productivity. This is because the entry points are more diverse with the inclusion of local vectors.

对于桌面应用程序，漏洞挖掘的思路本质上与web程序是类似的，不过也有一些区别：最大的区别在于，桌面应用的执行方式与流程与web程序不一样，下图展示的是桌面应用漏洞挖掘的一些内容：

img

Compared to black-box testing, there is less guesswork involved when you have access to source code. There is less guesswork in finding entry points and less guesswork in figuring out vulnerable code paths and exploitation payloads. Instead of sending payloads through an entry point that may or may not lead to a hypothesized insecure state, you can start from a vulnerable sink and work backwards until an entry point is reached. In a white-box scenario, you become constrained more by the limitations of what you know over the limitations of what you have.

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

What knowledge is required?

So why are we successful? We put the time in to know that network. We put the time in to know it better than the people who designed it and the people who are securing it. And that's the bottom line. — Rob Joyce, TAO Chief

The knowledge required for vulnerability research is extensive, changes over time, and can vary depending on the type of application. The domains of knowledge, however, tend to remain the same and can be divided into four:

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

1. Application Technologies. This embodies the technologies a developer should know to build the target application, including programming languages, system internals, design paradigms/patterns, protocols, frameworks/libraries, and so on. A researcher who has experience programming with the technologies appropriate to their target will usually be more productive and innovative than someone who has a shallow understanding of just the security concerns associated with them. （1） 程序正向开发技术。这是一个开发者需要掌握的能力，包括编程语言、系统内部设计、设计模式、协议、框架等。拥有丰富编程经验与开发能力的人在漏洞挖掘过程中往往比那些只对安全相关领域有所了解的人员对目标应用能有更深入的理解，从而有更高的产出。
2. Offensive and Defensive Concepts. These range from foundational security principles to constantly evolving vulnerability classes and mitigations. The combination of offensive and defensive concepts guide researchers toward surfacing vulnerabilities while being able to circumvent exploit mitigations. A solid understanding of application technologies and defensive concepts is what leads to remediation recommendations that are non-generic and actionable. （2）攻防一体的理念。这些知识涵盖了从基本的安全原则到不断变换的漏洞形态及漏洞缓解措施。攻击和防御结合的理念，能够有效帮助研究者既能够发现漏洞，同时也能够快速给出有效的漏洞缓解措施和规避方法。
3. Tools and Methodologies. This is about effectively and efficiently putting concepts into practice. It comes through experience from spending time learning how to use tools and configuring them, optimizing repetitive tasks, and establishing your own workflow. Learning how relevant tools work, how to develop them, and re-purpose them for different use cases is just as important as knowing how to use them. A process-oriented methodology is more valuable than a tool-oriented methodology. A researcher shouldn't stop pursuing a lead when a limitation of a tool they're using has been reached. The bulk of my methodology development has come from reading books and write-ups, hands-on practice, and learning from many mistakes. Courses are usually a good way to get an introduction to topics from experts who know the subject-matter well, but usually aren't a replacement for the experience gained from hands-on efforts. 有效使用工具。能够高效的使用工具能够快速将思路转化为实践，这需要通过花时间去学习如何配置和使用工具，将其应用于自己的任务并构建自己的工作流程来不断积累经验。更进一步，需要深入掌握所使用工具的原理，以及如何对其进行二次开发，以使得其能够更加高效的应用于当前的工作实际。事实上，面向过程的学习方法往往比面向工具的学习方法更加高效以及有价值，当自己发现一个在使用一个工具遇到瓶颈时，先不要退缩，尝试去改造它，或者通过自己动手实践去完成能够适应当前工作的工具，这往往能够帮助快速积累大量实践经验。帮助我们以后更加高效的去实践漏洞挖掘工作。
4. Target Application. Lastly, it's important to be able to understand the security-oriented aspects of an application better than its developers and maintainers. This is about more than looking at what security-oriented features the application has. This involves getting context about its use cases, enumerating all entry points, and being able to hypothesize vulnerabilities that are appropriate to its business logic and technology stack. The next section details the activities I perform to build knowledge in this area. 对目标应用的理解。最后，也是最重要的，作为一个漏洞挖掘人员，对自己研究的应用程序在安全性方面必须要比这个程序的开发者或维护者有更深的理解。这样你才能尽可能的发现这个程序中的漏洞并修复它。

The table below illustrates an example of what the required knowledge may look like for researching vulnerabilities in web applications and Windows desktop applications. Keep in mind that the entries in each category are just for illustration purposes and aren't intended to be exhaustive.

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

img

Thousands of hours, hundreds of mistakes, and countless sleepless nights go into building these domains of knowledge. It's the active combination and growth of these domains that helps increase the likelihood of finding vulnerabilities. If this section is characterized by what should be known, then the next section is characterized by what should be done.

数千小时，数百个错误，无数不眠之夜进入建立这些知识领域。这些知识领域将会帮助你提高挖掘漏洞的能力。如果说上面一节是讲诉挖掘漏洞所需要的知识，那么下面的这一节将讲诉挖漏洞如何做。

What activities are performed?

When analyzing an application, I use the four "modes of analysis" below and constantly switch from one mode to another whenever I hit a mental block. It's not quite a linear or cyclical process. I'm not sure if this model is exhaustive, but it does help me stay on track with coverage.

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

Within each mode are active and passive activities. Active activities require some level of interaction with the application or its environment whereas passive activities do not. That said, the delineation is not always clear. The objective for each activity is to:

在每一个模型之中都有主动活动（active activities）与客观活动存在（passive activities），主动活动需要我们对程序的执行环境及上下文有一个比较全面的了解，而客观活动却不一定，比如它是客观存在与程序的一些技术文档之中。不过，这种划分也不一定严格，不过对于每一个活动，我们可以从以下几方面去考虑：

1. Understand assumptions made about security.
2. Hypothesize how to undermine them.
3. Attempt to undermine them.

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

Use case analysis is about understanding what the application does and what purpose it serves. It's usually the first thing I do when tasked with a new application. Interacting with a working version of the application along with reading some high-level documentation helps solidify my understanding of its features and expected boundaries. This helps me come up with test cases faster. If I have the opportunity to request internal documentation (threat models, developer documentation, etc.), I always try to do so in order to get a more thorough understanding.

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

This might not be as fun as doing a deep-dive and trying test cases, but it's saved me a lot of time overall. An example I can talk about is with Oracle Opera where, by reading the user-manual, I was able to quickly find out which database tables stored valuable encrypted data (versus going through them one-by-one).

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

Implementation analysis is about understanding the environment within which the application resides. This may involve reviewing network and host configurations at a passive level, and performing port or vulnerability scans at an active level.

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

An example of this could be a system service that is installed where the executable has an ACL that allows low-privileged users to modify it (thereby leading to local privilege escalation). Another example could be a web application that has an exposed anonymous FTP server on the same host which could lead to exposure of source code and other sensitive files. These issues are not inherent to the applications themselves, but how they have been implemented in their environments.

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

Communications analysis is about understanding what and how the target exchanges information with other processes and systems. Vulnerabilities can be found by monitoring or actively sending crafted requests through different entry points and checking if the responses yield insecure states. Many web application vulnerabilities are found this way. Network and data flow diagrams, if available, are very helpful in seeing the bigger picture.

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

While an understanding of application-specific communication protocols is required for this mode, an understanding of the application's internal workings are not. How user-influenced data is being passed and transformed within a system is more or less seen as a black-box in this analysis mode, with the focus on monitoring and sending requests and analyzing the responses that come out.

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

If we go back to our hypothetical financial portal from earlier, we may want to look at the feature that allows clients to purchase prepaid credit cards in different currencies as a contrived example. Let's assume that a purchase request accepts the following parameters:

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

• fromAccount: The account from which money is being withdrawn to purchase the prepaid card.
• fromAmount: The amount of money to place into the card in the currency of fromAccount (e.g. 100).
• cardType: The type of card to purchase (e.g. USD, GBP).
• currencyPair: The currency pair for fromAccount and cardType (e.g. CADUSD, CADGBP).

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

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

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

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

The first thing we might want to do is send a standard request so that we know what a normal response should look like as a baseline. A request and response to purchase an $82 USD card from a CAD account might look like this:

当我们要去测试这样一个应用程序时，首先我们可能会想到发送一个正常的数据请求，以帮助我们了解该应用程序的标准响应的格式。例如下图，用CAD去购买82美刀的预付卡的请求和响应是下面这个样子：

{             "status": "ok",             "cardPan": 4444333322221111,             "cardType": "USD"             "toAmount": 82.20,           }

We may not know exactly what happened behind the scenes, but it came out ok as indicated by the status attribute. Now if we tweak the fromAmount to something negative, or the fromAccount to someone else's account, those may return erroneous responses indicating that validation is being performed. If we change the value of currencyPair from CADUSD to CADJPY, we'll see that the toAmount changes from 82.20 to 8863.68 while the cardType is still USD. We're able to get more bang for our buck by using a more favourable exchange rate while the desired card type stays the same.

或许我们并不知道程序在后台到底对我们的数据做了何种处理，但是我们通过观察status字段的属性知道我们的请求是ok的，下面如果我们将fromAmount参数调整为一个负数，或者将fromAccount调整为其他某个人的账户，那么这个web应用就可能会返回错误响应，比如验证不通过。另外如果我们将currencyPair从CADUSD（加元对美元）改为CADJPY（加元对日元）而cardType不变，那么我们会看到返回值中toAmount字段从82.20变为8863.68。如果程序缺乏足够的验证的话，我们有可能通过这种方式获取到更多的钱而付出的钱不变。

If we have access to back-end code, it would make it easier to know what's happening to that user input and come up with more thorough test cases that could lead to insecure states with greater precision. Perhaps an additional request parameter that's not exposed on the client-side could have altered the expected behaviour in a potentially malicious way.

另一方面，如果我们能够获取到后台代码或程序，那事情就变得更加有意思，我们可以轻松了解到后台的运作流程，如后台是如何处理请求，有哪些错误响应，这将有助于我们构造出更加具有针对性的数据对应用进行测试。

Code and binary analysis is about understanding how user-influenced input is passed and transformed within a target application. To borrow an analogy from Practical Malware Analysis, if the last three analysis modes can be compared to looking at the outside of a body during an autopsy, then this mode is where the dissection begins.

There are a variety of activities that can be performed for static and dynamic analysis. Here are a few:

代码及二进制分析是指理解一个目标程序是如何处理用户输入的数据，以及该程序的执行流程。目前有很多方法可以对程序实现动态和静态分析，下面介绍其中一部分：

• Data flow analysis. This is useful for scouting entry points and understanding how data can flow toward potential insecure states. When I'm stuck trying to get a payload to work in the context of communications analysis, I tweak it in different ways to try get toward that hypothesized insecure state. In comparison with this mode, I can first look into checking whether that insecure state actually exists, and if so, figure out how to craft my payload to get there with greater precision. As mentioned earlier, one of the benefits of this mode is being able to find insecure states and being able to work backwards to craft payloads for corresponding entry points.
• 数据流分析。数据流分析对于寻找入口点以及数据是如何走向潜在的不安全状态是非常有用的。在通信分析（Communications analysis）遇到困难时，很难构造出合适的Request，这时可以调整思路采取其他的方式寻找不安全状态，在数据流分析中，可以首先判断是否存在不安全状态，如果存在，则进一步跟踪数据是如何流向该状态。这个方法的好处是，一旦发现不安全状态，入口点也随之确定，这将会为发掘漏洞提供巨大帮助。
• Static and dynamic analysis go hand-in-hand here. If you're looking to go from point A to B, then static analysis is like reading a map, and dynamic analysis is like getting a live overview of traffic and weather conditions. The wide and abstract understanding of an application you get from static analysis is complemented by the more narrow and concrete understanding you get from dynamic analysis
• 在这个过程中，动态分析和静态分析需要紧密配合起来。举个例子，当你在寻找如何从A点走到B点时，静态分析就好比是在阅读一张地图，而动态分析就好比直接在这地图上走，需要实时关注路上的天气及交通状况，IDA和windbg的配合就是如此。静态分析可以对程序有一个全貌但不细致的理解，动态分析则可以对程序有一个狭隘但却细致的理解，二者是相互补充的。
• Imports analysis. Analyzing imported APIs can give insight into how the application functions and how it interacts with the OS, especially in the absence of greater context. For example, the use of cryptographic functions can indicate that some asset is being protected. You can trace calls to figure out what it's protecting and whether it's protected properly. If a process is being created, you can look into determining whether user-input can influence that. Understanding how the software interacts with the OS can give insight on entry points you can use to interact with it (e.g. network listeners, writable files, IOCTL requests).
• 外部引用分析。在分析程序的过程中，程序上下文环境中可能非常有限，这个时候分析程序的导入API可以帮助我们进一步了解程序的功能以及它与操作系统的交互方式。比如说，程序引用加密库对数据进行加密，那么你可以跟踪这个加密库并分析其功能，进而分析自己的输入是否能够影响其功能。另外，理解程序是如何与操作系统的交互也可以帮助我们进一步找到与程序进行交互的入口点。
• Strings analysis. As with analyzing imports, strings can give some insights into the program's capabilities. I tend to look for things like debug statements, keys/tokens, and anything that looks suspicious in the sense that it doesn't fit with how I would expect the program to function. Interesting strings can be traced for their usages and to see if there are code paths reachable from entry points. It's important to differentiate between strings that are part of the core program and those that are included as part of statically-imported libraries.
• 字符串分析，与外部引用分析一样，分析程序中的字符串将帮助我们进一步理解程序中的功能，特别是那些调试信息，关键字或者令牌什么的，或者是那些看起来特别奇特的东西，对这些关键的字符串的分析及跟踪也将有利于我们寻找到更多的程序入口，进而更加全面的找出程序中的缺陷。
• Security scan triage. Automated source code scanning tools may be helpful in finding generic low-hanging fruit, but virtually useless at finding contextual or design-based vulnerabilities. I don't typically find this to be the most productive use of my time because of the sheer number of false positives, but if it yields many confirmed vulnerabilities then it could indicate a bigger picture of poor secure coding practices.
• 安全扫描分析。使用自动化的扫描工具（如PHP源代码扫描AWS）可能帮助我们快速找到一些常见的漏洞。但是对于寻找基于上下文和基于设计的漏洞并没有太大帮助。这种方法可以用来做一些辅助性的功能，如果单纯靠扫描就能找出一堆漏洞，你研究的目标安全做的就太差了，这在目前并不常见，或者说研究这类目标对于提高你自己并无太大的帮助。
• Dependency analysis. This involves triaging dependencies (e.g. open-source components) for known vulnerabilities that are exploitable, or finding publicly unknown vulnerabilities that could be leveraged within the context of the target application. A modern large application is often built on many external dependencies. A subset of them can have vulnerabilities, and a subset of those vulnerabilities can "bubble-up" to the main application and become exploitable through an entry point. Common examples include Heartbleed, Shellshock, and various Java deserialization vulnerabilities.
• 依赖性分析。一个应用程序往往会依赖其他外来的组件，比如一些开源模块，它所依赖的开源模块自身存在的漏洞可能会被引入造成自身的未公开漏洞。值得一提的是，现今一个程序往往都是引用了众多第三方扩展模块，这些第三方的漏洞极易造成主程序的漏洞。举个例子，大多数浏览器都会使用sqlite做数据缓存，如果sqlite存在漏洞，那么这些浏览器都有可能存在问题，无论是谷歌还是火狐。
• Repository analysis. If you have access to a code repository, it may help identify areas that would typically be interesting to researchers. Aside from the benefits of having more context than with a binary alone, it becomes easier to find older areas of code that haven't changed in a long time and areas of code that bridge the development efforts of segmented groups.
• 版本分析。如果你有机会访问程序的代码仓库，那么你就可以通过分析历史版本的方式对程序进行分析，这种方式不是基于上下文的，比如说，寻找那些长时间没有做改动的部分，这些部分极易寻在漏洞。

Code and binary analysis typically takes longer than the other modes and is arguably more difficult because researchers often need to understand the application and its technologies to nearly the same degree as its developers. In practice, this knowledge can often be distributed among segmented groups of developers while researchers need to understand it holistically to be effective.

代码分析通常需要花费比其他方式更多的时间，同时也更难，因为研究者对这个程序的功能和使用的技术的掌握程度要不亚于其开发者，另外，一个程序的开发可能是由一个团队进行维护，那么对于研究者，全面掌握这些东西显得比较困难。但是只要肯专研，其实什么也都是能够克服的，请参考名言：只要工夫深，铁杵磨成针。

I cannot overstate how important it is to have competency in programming for this. A researcher who can program with the technologies of their target application is almost always better equipped to provide more value. On the offensive side, finding vulnerabilities becomes more intuitive and it becomes easier to adapt exploits to multiple environments. On the defensive side, non-generic remediation recommendations can be provided that target the root cause of the vulnerability at the code level.

另外，不得不再次强调一下编程能力的重要性，如果一个研究人员对他当前研究的程序所采用的语言和技术有深入扎实的功底，那么他必将创造出很多有价值的东西。从攻击的角度来说，他可以发现更加简单及直观的漏洞，编写利用程序也将得心应手。从防御的角度来说，他可以提供出代码级别的、具有高度针对性的修复建议而非那种通用的方法。

Similar to the domains of knowledge, actively combining this analysis mode with the others helps makes things click and increases the likelihood of finding vulnerabilities.

Other Thoughts and Lessons Learned

This section goes over some other thoughts worth mentioning that didn't easily fit in previous sections.

Vulnerability Complexity

Vulnerabilities vary in a spectrum of complexity. On one end, there are trivial vulnerabilities which have intuitive exploit code used in areas that are highly prone to scrutiny (e.g. the classic SQLi authentication bypass). On the other end are the results of unanticipated interactions between system elements that by themselves are neither insecure nor badly engineered, but lead to a vulnerability when chained together (e.g. Chris Domas' "Memory Sinkhole"). I tend to distinguish between these ends of the spectrum with the respective categories of "first-order vulnerabilities" and "second-order vulnerabilities", but there could be different ways to describe them.

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

The modern exploit is not a single shot vulnerability anymore. They tend to be a chain of vulnerabilities that add up to a full-system compromise. — Ben Hawkes, Project Zero 如今想要完成一个完整的利用，只靠单一的漏洞往往行不通。很多时候我们需要靠一连串的漏洞才能完成一起完整的利用，致使系统“妥协”。

Working in Teams

It is usually helpful to be upfront to your team about what you know and don't know so that you can (ideally) be delegated tasks in your areas of expertise while being given opportunities to grow in areas of weakness. Pretending and being vague is counterproductive because people who know better will sniff it out easily. If being honest can become political, then maybe it's not an ideal team to work with. On the other hand, you shouldn't expect to be spoon-fed everything you need to know. Learning how to learn on your own can help you become self-reliant and help your team's productivity. If you and your team operate on billable time, the time one takes to teach you might be time they won't get back to focus on their task.

The composition of a team in a timed project can be a determining factor to the quantity and quality of vulnerabilities found. Depending on the scale and duration of the project, having more analysts could lead to faster results or lead to extra overhead and be counterproductive. A defining characteristic of some of the best project teams I've been on is that in addition to having good rapport and communication, we had diverse skill sets that played off each other which enhanced our individual capabilities.

We also delegated parallelizable tasks that had converging outcomes. Here are some examples:

1. Bob scouts for entry points and their parameters while Alice looks for vulnerable sinks.
2. Alice fleshes out the payload to a vulnerable sink while Bob makes sense of the protocol to the sink's corresponding entry point.
3. Bob reverses structs by analyzing client requests dynamically while Alice contributes by analyzing how they are received statically.
4. Bob looks for accessible file shares on a network while Alice sifts through them for valuable information.

Overall, working in teams can increase productivity but it takes some effort and foresight to make that a reality. It's also important to know when adding members won't be productive so as to avoid overhead.

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

作者：「已注销」 链接：https://www.zhihu.com/question/23217846/answer/738120571 来源：知乎 著作权归作者所有。商业转载请联系作者获得授权，非商业转载请注明出处。

Final Notes

Thanks for taking the time to read this if you made it this far. I hope this has taken some of the mystery out of what's involved when finding vulnerabilities. It's normal to feel overwhelmed and a sense of impostor syndrome when researching (I don't think that ever goes away). This is a constant learning process that extends beyond a day job or what any single resource can teach you. I encourage you to try things on your own and learn how others approach this so you can aggregate, combine, and incorporate elements from each into your own approach.

I'd like to thank @spookchop and other unnamed reviewers for their time and contributions. I am always open to more (critical) feedback so please contact me if you have any suggestions.

The following tools were used for graphics: GIMP, WordItOut, draw.io, and FreeMind.

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