精华内容
下载资源
问答
  • afl-fuzz技术初探

    2020-02-23 14:25:29
    afl-fuzz技术初探 - M4x - 博客园 afl-fuzz技术初探 afl-fuzz技术初探 转载请注明出处:http://www.cnblogs.com/WangAoBo/p/8280352.html 参考了:...
    
    
        
        
        
        
        
        
        
        afl-fuzz技术初探 - M4x - 博客园
    
    
    

    afl-fuzz技术初探

    afl-fuzz技术初探

    转载自:http://www.cnblogs.com/WangAoBo/p/8280352.html

    参考了:

    http://pwn4.fun/2017/09/21/AFL%E6%8A%80%E6%9C%AF%E4%BB%8B%E7%BB%8D/

    http://blog.csdn.net/youkawa/article/details/45696317

    https://stfpeak.github.io/2017/06/12/AFL-Cautions/

    http://blog.csdn.net/abcdyzhang/article/details/53487683

    在计算机领域,Fuzz Testing(模糊测试)是一种很有效的测试方法,主要原理为构造一系列“坏”数据传入应用程序,通过判断程序是否发生异常发现和检测潜在的bug.而在安全领域引入fuzz技术,无疑可以使安全研究员效率倍增,更有效的挖掘和防护漏洞。

    AFL(American Fuzzy Lop)是目前最高级的Fuzzing测试工具之一,由lcamtu开发.当需要测试的程序有源码时,AFL通过对源码重新编译时插桩(插入分析代码)的方法来探测程序内部的执行路径.相对于其他fuzzer,AFL-Fuzz具有更低的性能消耗,更有效的fuzzing策略和tricks最小化技巧,只需简单的配置即可处理复杂的程序.当然,对于没有源码的可执行程序,AFL也可进行处理,但需要QEUM模拟器的支持.

    本次实验将介绍AFL的安装和使用方法,以有源码的upx为例进行展示,也会简要介绍AFL处理无源码程序的情况.

    安装afl

    听学长介绍,afl会烧ssd,不建议在本地安装

    • 下载最新源码

    • 解压并安装:

      $make
      $sudo make all

      如果不报错,则afl-fuzz就安装成功了

    有源码的afl-fuzz

    这里以fuzz upx为例进行测试

    编译upx

    • upx项目地址([https://github.com/upx/upx)
    • 因为afl会对有源码的程序进行重新编译,因此需要修改upx的Makefile
    $git clone https://github.com/upx/upx.git
    $cd upx
    $vim Makefile
    CC = /usr/local/bin/afl-gcc #添加此句

    $cd src
    $vim Makefile
    CXX    ?= /usr/local/bin/afl-g++ #将CXX改成afl-g++

    通过upx的文档,还需要安装三个库:

    安装lzma-sdk

    $git submodule update --init --recursive

    安装ucl

    • 下载ucl
      bash wget http://www.oberhumer.com/opensource/ucl/download/ucl-1.03.tar.gz

    • 编译:

      $cd ucl-1.03
      $./configure
      $make 
      $sudo make install

      $export UPX_UCCLDIR="~/ucl-1.03"

    安装zlib

      $wget http://pkgs.fedoraproject.org/repo/pkgs/zlib/zlib-1.2.11.tar.xz/sha512/b7f50ada138c7f93eb7eb1631efccd1d9f03a5e77b6c13c8b757017b2d462e19d2d3e01c50fad60a4ae1bc86d431f6f94c72c11ff410c25121e571953017cb67/zlib-1.2.11.tar.xz

      $cd zlib-1.2.11/
      $./configure
      $sudo make install

    编译upx

    $cd ~/upx
    $make all

    若没有报错,则编译成功

    此时可在/src目录下找到upx.out文件

    对upx进行fuzz测试

    $cd ~
    $mkdir afl_in afl_out
    afl_in存放测试用例,afl_out存放fuzz结果
    $cp /usr/bin/file afl_in
    $afl-fuzz -i afl_in -o afl_out ~/upx/src/upx.out @@
    @@会代替测试样本,即相当于执行了upx.out file

    AFL运行界面:

    运行结果与分析

    可以看出,在短短的十几分钟内,已经跑出了6个crash,安全从业者可以通过分析afl_out中的文件得到更多信息,可以看出使用afl-fuzz比起人工审查效率有了极大地提高

    对于从stdin获取输入的程序,可以使用

    # afl-fuzz -i afl_in -o afl_out ./file

    无源码的afl-fuzz

    对无源码的程序进行fuzz一般有两种方法:

    1. 对二进制文件进行插桩
    2. 使用-n选项进行传统的fuzz测试

    这里主要介绍第一种,该方法是通过afl-qemu实现的.

    编译afl版的qemu

    $ cd qemu_mode 
    $ ./build_qemu_support.sh

    在编译时,可能会遇到以下的报错:

    报错信息都比较明显,安装相应的库即可

    若遇到glib2丢失,可以

    $sudo apt-get install libglib2*

    对readelf进行fuzz

    以readelf为例

    $mkdir afl_in afl_out
    $cp test afl_in
    test为自己准备的测试elf
    $sudo cp /usr/bin/readelf .
    $afl_fuzz -i afl_in -o afl_out -Q readelf -a @@

    如下图,已经开始fuzz了:

    展开全文
  • AFL-fuzz技术

    2019-08-23 13:51:34
    阅读目录 编译upx 对upx进行fuzz测试 AFL运行界面: ...afl-fuzz技术初探 参考了: http://pwn4.fun/2017/09/21/AFL%E6%8A%80%E6%9C%AF%E4%BB%8B%E7%BB%8D/ http://blog.csdn.net/youkawa/article...

    阅读目录

    afl-fuzz技术初探

    参考了:

    http://pwn4.fun/2017/09/21/AFL%E6%8A%80%E6%9C%AF%E4%BB%8B%E7%BB%8D/

    http://blog.csdn.net/youkawa/article/details/45696317

    https://stfpeak.github.io/2017/06/12/AFL-Cautions/

    http://blog.csdn.net/abcdyzhang/article/details/53487683

    在计算机领域,Fuzz Testing(模糊测试)是一种很有效的测试方法,主要原理为构造一系列“坏”数据传入应用程序,通过判断程序是否发生异常发现和检测潜在的bug.而在安全领域引入fuzz技术,无疑可以使安全研究员效率倍增,更有效的挖掘和防护漏洞。

    AFL(American Fuzzy Lop)是目前最高级的Fuzzing测试工具之一,由lcamtu开发.当需要测试的程序有源码时,AFL通过对源码重新编译时插桩(插入分析代码)的方法来探测程序内部的执行路径.相对于其他fuzzer,AFL-Fuzz具有更低的性能消耗,更有效的fuzzing策略和tricks最小化技巧,只需简单的配置即可处理复杂的程序.当然,对于没有源码的可执行程序,AFL也可进行处理,但需要QEUM模拟器的支持.

    本次实验将介绍AFL的安装和使用方法,以有源码的upx为例进行展示,也会简要介绍AFL处理无源码程序的情况.

    安装afl

    听学长介绍,afl会烧ssd,不建议在本地安装

    • 解压并安装:

      $make
      $sudo make all

       

    • 如果不报错,则afl-fuzz就安装成功了

    有源码的afl-fuzz

    这里以fuzz upx为例进行测试

     

    编译upx

    • upx项目地址([https://github.com/upx/upx)
    • 因为afl会对有源码的程序进行重新编译,因此需要修改upx的Makefile
    $git clone https://github.com/upx/upx.git
    $cd upx
    $vim Makefile
    CC = /usr/local/bin/afl-gcc #添加此句

     

     

    $cd src
    $vim Makefile
    CXX    ?= /usr/local/bin/afl-g++ #将CXX改成afl-g++

    通过upx的文档,还需要安装三个库:

    安装lzma-sdk

    $git submodule update --init --recursive

     

    安装ucl

    • 下载ucl
      bash wget http://www.oberhumer.com/opensource/ucl/download/ucl-1.03.tar.gz

    • 编译:

      $cd ucl-1.03
      $./configure
      $make 
      $sudo make install

       

       

    $export UPX_UCCLDIR="~/ucl-1.03"

    安装zlib

      $wget http://pkgs.fedoraproject.org/repo/pkgs/zlib/zlib-1.2.11.tar.xz/sha512/b7f50ada138c7f93eb7eb1631efccd1d9f03a5e77b6c13c8b757017b2d462e19d2d3e01c50fad60a4ae1bc86d431f6f94c72c11ff410c25121e571953017cb67/zlib-1.2.11.tar.xz

     

     

      $cd zlib-1.2.11/
      $./configure
      $sudo make install

    编译upx

    $cd ~/upx
    $make all

    若没有报错,则编译成功

     

    此时可在/src目录下找到upx.out文件

     

    对upx进行fuzz测试

    $cd ~
    $mkdir afl_in afl_out
    afl_in存放测试用例,afl_out存放fuzz结果
    $cp /usr/bin/file afl_in
    $afl-fuzz -i afl_in -o afl_out ~/upx/src/upx.out @@
    @@会代替测试样本,即相当于执行了upx.out file

     

     

    AFL运行界面:

     

     

    运行结果与分析

     

    可以看出,在短短的十几分钟内,已经跑出了6个crash,安全从业者可以通过分析afl_out中的文件得到更多信息,可以看出使用afl-fuzz比起人工审查效率有了极大地提高

    对于从stdin获取输入的程序,可以使用

    # afl-fuzz -i afl_in -o afl_out ./file

    无源码的afl-fuzz

    对无源码的程序进行fuzz一般有两种方法:

    1. 对二进制文件进行插桩
    2. 使用-n选项进行传统的fuzz测试

    这里主要介绍第一种,该方法是通过afl-qemu实现的.

     

    编译afl版的qemu

    $ cd qemu_mode 
    $ ./build_qemu_support.sh

    在编译时,可能会遇到以下的报错:

     

     

    报错信息都比较明显,安装相应的库即可

    若遇到glib2丢失,可以

    $sudo apt-get install libglib2*

     

    对readelf进行fuzz

    以readelf为例

    $mkdir afl_in afl_out
    $cp test afl_in
    test为自己准备的测试elf
    $sudo cp /usr/bin/readelf .
    $afl_fuzz -i afl_in -o afl_out -Q readelf -a @@

     

    如下图,已经开始fuzz了:

     

    展开全文
  • fuzz技术.png

    2021-02-16 11:53:49
    软件模糊测试思维导图
  • 基于漏洞特征和Fuzz技术的Windows漏洞挖掘模型研究
  • Fuzz技术介绍

    2019-09-26 16:39:20
    模糊测试的定义 模糊测试定义为“通过向应用提供非预期的输入并监控输出中的异常来发现软件中的故障(faults)的方法”。 典型而言,模...

    模糊测试的定义

    模糊测试定义为“通过向应用提供非预期的输入并监控输出中的异常来发现软件中的故障(faults)的方法”。
    典型而言,模糊测试利用自动化或是半自动化的方法重复地向应用提供输入。显然,上述定义相当宽泛,但这个定义阐明了模糊测试的基本概念。

    用于模糊测试的模糊测试器(fuzzer)分为两类:

    一类

    是基于变异(mutation-based)的模糊测试器,这一类测试器通过对已有的数据样本进行变异来创建
    测试用例;

    而另一类

    是基于生成(generation-based)的模糊测试器,该类测试器为被测系统使用的协议或是文件格式建模,基于模型生成输入并据此创建测试用例。这两种模糊测试器各有其优缺点。

    如果你是模糊测试的新手,可以将模糊测试类比成如何闯进一所房子。假设你不幸丢了工作,不得不以犯罪为生,现在你想要破门进入一所房子。
    如果采用纯白盒测试的方法,你需要在破门前得到房子的所有相关信息,包括房子的蓝图(blueprints),房子的锁的生产厂家、房子的建筑材料等。显然,白盒测试放在这种情况下有独特的好处,但也并非万无一失。应用白盒测试方法,你需要对房子进行静态分析而不是进行运行时(实际进入房子时)检查。例如,通过静态分析你发现这所房子起居室的侧面窗户有一个漏洞,可以把窗户打碎进入房子。但你肯定没办法预见到你进入后的事情,也许当你进入以后,发现愤怒的房主正在屋里拿着枪等你。
    另外,你可以采用黑盒测试方法来进入这所房子。采用黑盒测试方法,你可以在黑暗的掩护下接近房子,悄悄测试所有的门和窗户,向房子内窥视以决定最好的突破口。但是,如果你最终选择使用模糊测试方法进入这所房子,你可以既不用研究房子的蓝图、也不用手工尝试所有那些锁,只需要选择一种武器并让进入房子的过程完全自动化——这就是强制安全漏洞发现方法的威力!

    模糊测试各阶段

    采用何种模糊测试方法取决于众多因素。没有所谓的一定正确的模糊测试方法,决
    定采用何种模糊测试方法完全依赖于被测应用、测试者拥有的技能、以及被进行模糊测
    试的数据的格式。但是,不论对什么应用进行模糊测试,不论采用何种模糊测试方法,
    模糊测试执行过程都包含相同的几个基本阶段。

    1.确定测试目标

    只有有了明确的测试目标后,我们才能决定使用的模糊测试工具或方法。如果要在安全审计中对一个完全由内部开发的应用进行模糊测试,测试目标的选择必须小心谨慎。但如果是要在第三方应用中找到安全漏洞,测试目标的选择就更加灵活。要决定第三方应用模糊测试的测试目标,首先需要参考该第三方应用的供应商历史上曾出现过的安全漏洞。在一些典型的安全漏洞聚合网站如 SecurityFocus 18 和 Secunia 19 上可以查找到主要软件供应商历史上曾出现过的安全漏洞。如果某个供应商的历史记录很差,很可能意味着这个供应商的代码实践 (code practice)能力很差,他们的产品有仍有很大可能存在未被发现的安全漏洞。除应用程序外,应用包含的特定文件或库也可以是测试目标。
    如果需要选择应用包含的特定文件或者库作为测试目标,你可以把注意力放在多个应用程序之间共享的那些二进制代码上。因为如果这些共享的二进制代码中存在安全漏洞,将会有非常多的用户受到影响,因而风险也更大。

    2.确定输入向量

    几乎所有可被利用的安全漏洞都是因为应用没有对用户的输入进行校验或是进行必要的非法输入处理。是否能找到所有的输入向量(input vector)是模糊测试能否成功的关键。如果不能准确地找到输入向量,或是不能找到预期的输入值,模糊测试的作用就会受到很大的局限。有些输入向量是显而易见的,有些则不然。寻找输入向量的原则是:从客户端向目标应用发送的任何东西,包括头(headers)、文件名(file name)、环
    境变量(environment variables),注册表键(registry keys),以及其他信息,都应该被看做是输入向量。所有这些输入向量都可能是潜在的模糊测试变量。

    3.生成模糊测试数据

    一旦识别出输入向量,就可以依据输入向量产生模糊测试数据了。究竟是使用预先确定的值、使用基于存在的数据通过变异生成的值、还是使用动态生成的值依赖于被测应用及其使用的数据格式。但是,无论选择哪种方式,都应该使用自动化过程来生成数据。

    4.执行模糊测试数据

    该步骤紧接上一个步骤,正是在这个步骤,“模糊测试”变成了动词。在该步骤中,一般会向被测目标发送数据包、打开文件、或是执行被测应用。同上一个步骤一样,这个步骤必须是自动化的。否则,我们就不算是真正在开展模糊测试。

    5.监视异常

    一个重要但经常容易被忽略的步骤是对异常和错误进行监控。设想我们在进行一次模糊测试,在测试中,我们向被测的 Web 服务器发送了 10000 个数据包,最终导致了服务器崩溃。但服务器崩溃后,我们却怎么也找不到导致服务器崩溃的数据包了。如果这种事真的发生了,我们只能说这个测试毫无价值。模糊测试需要根据被测应用和所决定采用的模糊测试类型来设置各种形式的监视。

    6.判定发现的漏洞是否可能被利用

    如果在模糊测试中发现了一个错误,依据审计的目的,可能需要判定这个被发现的错误是否是一个可被利用的安全漏洞。这种判定过程是典型的手工过程,需要操作者具有特定的安全知识。这个步骤不一定要由模糊测试的执行者来进行,也可以交给其他人来进行。

    这里写图片描述

                                    </div>
    
    展开全文
  • Android系统服务在为用户提供便利的同时,也存在着一些风险。在使用系统服务的过程中,异常的外部数据,有可能会导致系统服务崩溃,甚至是远程代码执行,内存破坏等严重后果。Android系统服务的安全问题需要重视。...
  • Fuzz技术与软件安全性测试 PPT 著名软件安全专家 王清
  • afl-fuzz技术白皮书

    万次阅读 2016-03-10 15:37:53
    afl-fuzz的设计宗旨 ================ 速度、可靠、易用 覆盖率计算 ======== 通过在编译期间instrument一些指令来捕获branch (edge) coverage和运行时分支执行计数 在分支点插入的指令大概如下: cur_location = ;...
    1. afl-fuzz的设计宗旨
      ================
      速度、可靠、易用

    2. 覆盖率计算
      ========
      通过在编译期间instrument一些指令来捕获branch (edge) coverage和运行时分支执行计数
      在分支点插入的指令大概如下:

      cur_location = <COMPILE_TIME_RANDOM>;
      shared_mem[cur_location ^ prev_location]++; 
      prev_location = cur_location >> 1;
    
    1. 为了简化连接复杂对象的过程和保持XOR输出平均分布,当前位置是随机产生的。

    2. share_mem[]数组是一个调用者传给被instrument程序的64KB的共享内存区域,数组的元素是Byte。数组中的每个元素,都被编码成一个(branch_src, branch_dst),相当于存储路径的bitmap。这个数组的大小要应该能存2K到10K个分支节点,这样即可以减少冲突,也可以实现毫秒级别的分析。
      这种形式的覆盖率,相对于简单的基本块覆盖率来说,对程序运行路径提供了一个更好的描述。以下面两个路径产生的tupes为例:
      A -> B -> C -> D -> E (tuples: AB, BC, CD, DE)
      A -> B -> D -> C -> E (tuples: AB, BD, DC, CE)
      这更有助于发现代码的漏洞,因为大多数安全漏洞经常是一些没有预料到的状态转移,而不是因为没有覆盖那一块代码。

    3. 最后一行右移操作是用来保持tuples的定向性。如果没有右移操作,A ^ B和B ^ A就没办法区别了,同样A ^ A和B ^ B也是一样的。Intel CPU缺少算数指令,左移可能会会导致级数重置为0,但是这种可能性很小,用左移纯粹是为了效率。

    4. 发现新的执行路径
      =========

    AFL-fuzzer用一个全局的map用来存储之前执行时看到的tupes。这些数据可以被用来对不同的trace进行快速对比,从而可以计算出是否新执行了一个dword指令/一个qword-wide指令/一个简单的循环。
    当一个变异的输入产生了一个包含新路径(tuple)的执行trace时,对应的输入文件就被保存,然后被用在新的fuzzing过程中。对于那些没有产生新路径的输入,就算他们的instrumentation输出模式是不同的,也会被抛弃掉。
    这种算法考虑了一个非常细粒度的、长期的对程序状态的探索,同时它还不必执行复杂的计算,不必对整个复杂的执行流进行对比,也避免了路径爆炸的影响。为了说明这个算法是怎么工作的,考虑下面的两个trace,第二个trace出现了新的tuples(CA, AE)

      #1: A -> B -> C -> D -> E
      #2: A -> B -> C -> A -> E
    

    同时,由于执行了第2个trace,下面的pattern就不被认为是不同的了,尽管它看起来是一个不同的执行路径。

      #3: A -> B -> C -> A -> B -> C -> A -> B -> C -> D -> E
    

    为了发现新的tuples,AFL-fuzzer也会粗糙地计算已经有的tuple的数目。它们被分成几个bucket:

      1, 2, 3, 4-7, 8-15, 16-31, 32-127, 128+
    

    从某种程度上讲,这些数字有一些fuzzer架构的意义:
    它是一个8-bit counter和一个8-position bitmap的映射。其中8-bit counter是通过instrument产生的;而8-bit position bitmap则依赖于fuzzer跟踪的,已经执行的tuple数目。
    只更改了单个bucket的改变会被忽略掉。在程序控制流中,从一个bucket到另一个bucket的转变,会被标记为感兴趣的改变,接下来会被使用。
    hit count算法可以分辨出控制流是否发生改变,比如说一个基本块被执行了两次,但其实它只被hit了一次。hit count算法对循环了多少次是不敏感的。
    另外,算法通过设置执行超时,来避免效率过低的fuzz。从而进一步发现效率比较高的fuzz方式。

    1. 输入队列的进化
      ==========

    经变异的测试用例,会使程序产生新的状态转移。这些测试用例稍后被添加到input队列中,用作下一个fuzz循环。它们补充但不替换现有的发现。
    这种算法允许工具可以持续探索不同的代码路径,其实底层的数据格式可能是完全不同的。如下图:
    [外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-xYrgiiBY-1586859319387)(http://lcamtuf.coredump.cx/afl/afl_gzip.png)]

    下面的链接是对这个算法的一些实际应用,可以参考下:
    http://lcamtuf.blogspot.com/2014/11/pulling-jpegs-out-of-thin-air.html
    http://lcamtuf.blogspot.com/2014/11/afl-fuzz-nobody-expects-cdata-sections.html

    这种过程下产生的语料库基本上是这些输入文件的集合:它们都能触发一些新的执行路径。产生的语料库,可以被用来作为其他测试的种子。
    使用这种方法,大多数目标程序的队列会增加到大概1k到10k个entry。大约有10-30%归功于对新tupe的发现,剩下的和hit counts改变有关。

    下面这这表比较了几个不同的guided fuzzing方法,发现文件语法和探索程序执行路径的能力:

        Fuzzer guidance | Blocks  | Edges   | Edge hit | Highest-coverage
          strategy used | reached | reached | cnt var  | test case generated
      ------------------+---------+---------+----------+---------------------------
         (Initial file) | 156     | 163     | 1.00     | (none)
                        |         |         |          |
        Blind fuzzing S | 182     | 205     | 2.23     | First 2 B of RCS diff
        Blind fuzzing L | 228     | 265     | 2.23     | First 4 B of -c mode diff
         Block coverage | 855     | 1,130   | 1.57     | Almost-valid RCS diff
          Edge coverage | 1,452   | 2,070   | 2.18     | One-chunk -c mode diff
              AFL model | 1,765   | 2,597   | 4.99     | Four-chunk -c mode diff
    

    第一行的blind fuzzing (“S”)代表仅仅执行了一个回合的测试。
    第二行的Blind fuzzing L表示执行了几个回合的测试,但是没有进行改进。

    另一个独立的实验基本上也获得了相似的数据:

        Queue extension | Blocks  | Edges   | Edge hit | Number of unique
          strategy used | reached | reached | cnt var  | crashes found
      ------------------+---------+---------+----------+------------------
         (Initial file) | 624     | 717     | 1.00     | -
                        |         |         |          |
          Blind fuzzing | 1,101   | 1,409   | 1.60     | 0
         Block coverage | 1,255   | 1,649   | 1.48     | 0
          Edge coverage | 1,259   | 1,734   | 1.72     | 0
              AFL model | 1,452   | 2,040   | 3.16     | 1
    
    1. 语料的选择
      ========

    上述探索程序路径的方法意味着:一些后来出现的test cases产生的edge coverage,可能会是之前的test cases产生的edge coverage的超集。
    为了优化fuzzing的结果,AFL会用一个快速算法周期性的重新计算队列,这个算法选择一个小的能够覆盖目前所有tuple的test cases子集。
    算法是这么工作的:给队列的每一个entry赋一个值(这个值是它的执行时延和文件大小的比例),然后为每个tuple选择值最小的一个。
    这些tuples之后会按照下述流程进行处理:

      1) Find next tuple not yet in the temporary working set,
    
      2) Locate the winning queue entry for this tuple,
    
      3) Register *all* tuples present in that entry's trace in the working set,
    
      4) Go to #1 if there are any missing tuples in the set.
    

    这样产生的语料,会比初始的数据集小5到10倍。没有被选择的也没有被扔掉,而是在遇到下列对队列时,以一定概率略过:

      - If there are new, yet-to-be-fuzzed favorites present in the queue, 
        99% of non-favored entries will be skipped to get to the favored ones.
    
      - If there are no new favorites:
    
      - If the current non-favored entry was fuzzed before, it will be skipped 95% of the time.
    
      - If it hasn't gone through any fuzzing rounds yet, the odds of skipping drop down to 75%.
    

    基于以往的测试经验,这提供了一个队列循环速度和test case多样性的平衡。
    我们也可以用afl-cmin去专门处理数据,这个工具会永久丢弃冗余的entries,然后产生一个供afl-fuzz或其他工具使用的语料。

    1. 整理输入文件
      =========

    文件大小对fuzzing的性能有很大的影响,一是因为大文件会让目标程序变慢,二是因为大文件减少了一个mutation触发重要格式控制结构的,而不是总在触发冗余的数据块。因为一些mutations可以使得产生文件的大小迭代性增加,所以也要考虑(一个不好的起始语料)这个因素。
    幸运的是,instrumentation的反馈提供了一个用来自动精简(trim down)输入文件的简单的方法,这种方法同时还保证了对文件的改变不会对执行路径产生影响。afl-fuzz内置的trimmer试图用计算变量长度和step over的方法,循序地减少数据块。
    这个trimmer试图在精确和产生的进程数之间做一个平衡。而afl-min这个工具则是用了一个更详尽的迭代算法去精简文件,当然耗时更多。

    1. Fuzzing策略
      ============

    instrumentation产生的反馈,让我们更容易去理解不同fuzzing策略的价值,进而去优化它们的参数使得它们更有效。
    afl-fuzz所使用的策略是一种与格式无关的策略,详见:http://lcamtuf.blogspot.com/2014/08/binary-fuzzing-strategies-what-works.html
    afl-fuzz一开始所做的工作都是确定性的,之后才会有一些随机性的更改和test case的拼接,这些确定性策略包括:

      - Sequential bit flips with varying lengths and stepovers,
    
      - Sequential addition and subtraction of small integers,
    
      - Sequential insertion of known interesting integers (0, 1, INT_MAX, etc),
    

    非确定性步骤包括:stacked bit flips, insertions, deletions, arithmetics, and splicing of different test cases.

    为了性能、简洁性、可靠性,AFL不试图去推断某个mutation和program state的关系。
    这意味着,这条规则有一个例外:
    当一个新的队列条目,经过初始的确定性fuzzing步骤集合时,并且文件的部分区域被观测到对执行路径的校验和没有影响,这些队列条目在接下来的确定性fuzzing阶段可能会被排除。
    尤其是对那些冗长的数据格式,这可以在保持覆盖率不变的情况下,减少10-40%的执行次数。在一些极端情况下,比如一些block-aligned的tar文件,这个数字可以达到90%。

    1. 字典
      =====

    instrumentation产生的反馈让我们可以自动的辨认出一些输入文件的语法符号,从而可以进一步发现,某些预定义的或者自动检测的字典条目可以组成一个正确的被测程序语法。
    详见:http://lcamtuf.blogspot.com/2015/01/afl-fuzz-making-up-grammar-with.html

    大体上,一开始一些基本的语法token被随机组合在一块时。instrumentation和队列进化设计一起提供了一个反馈机制,可以用来区分哪些可以触发新行为和那些无意义的语法。进一步可以基于这种反馈机制,构建更复杂的语法。
    这种词典已经被证明可以让fuzzer快速地构建一些很复杂的语法,比如JavaScript, SQL, XML。

    1. crashes的重复
      =============
      crashes的重复数据删除,对于每一个完整的fuzzing工具来说是一个必不可少的问题,然而很多工具都用了错误的解决方案.
      比如,只看出错的内存地址,如果错误发生在一个库函数中,就会导致一些完全无关的问题被聚合在一块。
      同一个错误,有可能是通过不同的路径触发的,所以call stack校验和这种方案也不可靠。
      afl-fuzz采用的方案是:如果下列条件之一符合,就认为crash是唯一的:
      - The crash trace includes a tuple not seen in any of the previous crashes,
      - The crash trace is missing a tuple that was always present in earlier faults.
    
    1. 调查crashes
      ============

    对不同类型的crash进行探索是有歧义的,afl-fuzz提供了一个crash探索模式。
    在这种模式下,导致crash的test case以一种和普通fuzz类似的方式去测试,但是抛弃了所有没有导致crash的mutations,详见:http://lcamtuf.blogspot.com/2014/11/afl-fuzz-crash-exploration-mode.html。
    这种方法利用instrumentation的反馈,探索crash程序的状态,从而进一步通过歧义性的失败条件,找到了最新发现的input。
    对于crashes来说,值得注意的是和正常的队列条目对比,导致crash的input没有被去掉,为了和它们的父条目(队列中没有导致crash的条目)对比,它们被保存下来,
    这就是说afl-tmin可以被用来随意缩减它们。

    1. The fork server
      ===================

    为了提升性能,afl-fuzz使用了一个“fork server”,fuzz进程只进行一次execve(),linking和libc initialization,之后的fuzz进程通过写时拷贝技术从已经停止的fuzz进程镜像直接拷贝。详见:http://lcamtuf.blogspot.com/2014/10/fuzzing-binaries-without-execve.html
    fork server被集成在了instrumentation的程序下,在第一个instrument函数执行时,fork server就停止并等待afl-fuzz的命令。
    对于需要快速发包的测试,fork server可以提升1.5到2倍的性能。

    1. 并行机制
      ========

    实现并行的机制是,定期检查不同cpu core或不同机器产生的队列,然后有选择性的把队列中的条目放到test cases中。
    详见: parallel_fuzzing.txt.

    1. 二进制instrumentation
      ======================
      AFL-Fuzz对二进制黑盒目标程序的instrumentation是通过QEMU的“user emulation”模式实现的。
      这样我们就可以允许跨架构的运行,比如ARM binaries运行在X86的架构上。QEMU使用basic blocks作为翻译单元,利用QEMU做instrumentation,再使用一个和编译期instrumentation类似的guided fuzz的模型。
      像QEMU, DynamoRIO, and PIN这样的二进制翻译器,启动是很慢的QEMU mode同样使用了一个fork server,和编译期一样,通过把一个已经初始化好的进程镜像,直接拷贝到新的进程中。
      当然第一次翻译一个新的basic block还是有必要的延迟,为了解决这个问题AFL fork server在emulator和父进程之间提供了一个频道。这个频道用来通知父进程新添加的blocks的地址,之后吧这些blocks放到一个缓存中,以便直接复制到将来的子进程中。这样优化之后,QEMU模式对目标程序造成2-5倍的减速,相比之下,PIN造成100倍以上的减速。
    展开全文
  • 参考文献 https://blog.csdn.net/weixin_39448417/article/details/99703723
  • 模糊测试的定义 模糊测试定义为“通过向应用提供非预期的输入并监控输出中的异常来发现软件中的故障(faults)的方法”。 典型而言,模糊测试利用自动化或是半自动化的方法重复地向应用提供输入。显然,上述定义相当宽泛...
  • app发布后经常容易出现各种诡异的crash, 这些crash固然可以通过各种崩溃分析服务去定位. 但是的确很影响用户体验. 在crash分类中有一类是后端接口引发的.... 接口自身变更, 接口失效或者超时, 比如用户进地铁接口...
  • 一些软件安全工程师经常用加密技术,但是用错或者是设计上有一些东西出现错误。    Security Testing一般的方法就是以下这几种: White BOX:我们一般会用静态的源码扫描工具。通过对源代码的扫描,我们...
  • 一些软件安全工程师经常用加密技术,但是用错或者是设计上有一些东西出现错 误。 Security Testing一般的方法就是以下这几种: White BOX:我们一般会用静态的源码扫描工具。通过对源代码的扫描,我们...
  • Fuzz安全测试技术

    2013-05-08 21:51:28
    Fuzz安全测试技术
  • Fuzz进行到底

    2017-11-10 15:05:00
    Fuzz Testing(模糊测试)是一种简单有效的黑盒测试技术,本文... 希望本文可以使你重新看待Fuzz技术,并在实际测试项目中找到Fuzz的乐趣 。 传统Fuzz简介 简而言之,Fuzz就是: 用随机坏数据攻击一个程序,然后...
  • 作 者: failwest时 间: 2008-10-21,00:14链 接: http://bbs.pediy.com/showthread.php?t=75032待到秋来九月八,我花开后百花杀最近应一个会议的邀请,需要准备一些关于security testing的东西,fuzz技术作为工业界...
  • 漫谈软件测试中的Fuzz测试技术

    千次阅读 2011-03-30 16:02:00
    一些软件安全工程师经常用加密技术,但是用错或者是设计上有一些东西出现错误。  Security Testing一般的方法就是以下这几种:  (1)White BOX:我们一般会用静态的源码扫描工具。通过对源代码的扫描,我们...
  • 一些软件安全工程师经常用加密技术,但是用错或者是设计上有一些东西出现错误。  Security Testing一般的方法就是以下这几种:  (1)White BOX:我们一般会用静态的源码扫描工具。通过对源代码的扫描,我们可以把源...
  • 通过与和,OSS-Fuzz旨在通过将现代的模糊技术与可扩展的分布式执行相结合,使通用的开源软件更加安全和稳定。 我们将 , 和模糊测试引擎与以及 (分布式模糊测试执行环境和报告工具)结合使用来支持。 当前,OSS-...
  • 各类Fuzz软件

    千次阅读 2019-01-06 18:54:00
    基于模糊测试技术开发的测试工具有很多,其中最长被使用而且改进也是最多的一个工具就是AFL(American Fuzz Lop). 本篇文章不会赘述如何安装afl,以及如何使用afl进行简单的fuzz。由于很多被测程序都有自己的一个...
  • Fuzzing技术总结(Brief Surveys on Fuzz Testing)- wcventure

    万次阅读 多人点赞 2018-08-26 22:05:20
    Fuzzing survey Static analysis Dynamic analysis Symbolic execution Fuzzing White box fuzzing Grey box fuzzing Black box fuzzing ...Generation-based Fuzzing ...Fuzzing技术的对比 F...
  • afl-fuzz资源汇总

    2020-11-28 00:04:16
    AFL漏洞挖掘技术漫谈(二):Fuzz结果分析和代码覆盖率 AFL++实战(一)-黑盒测试FFmpeg 使用AFL进行fuzz 如何Fuzz ELF文件中的任意函数 如何使用AFL进行一次完整的fuzz过程 使用Afl-fuzz (American Fuzzy Lop) 进行...
  • fuzz工具SPIKE学习

    千次阅读 2019-05-26 13:16:40
    1.什么是FUZZfuzz测试是将故意格式错误的数据发送到程序以便在应用程序中生成故障或错误的过程。...从技术上讲,SPIKE实际上是一个模糊器创建工具包,它提供了API,允许用户使用C语言基于网络的协...
  • 简单的漏洞越来越少,需要改进目前的方法 : 通过符号执行,得出执行路径,然后在进行fuzzy是较为有效的方法之一 1)为待测单元自动地...符号执行(symbolic execution)是一种代码执行空间遍历技术。枚举了程...
  • 介绍模糊测试(Fuzz Testing,Fuzzing)

    万次阅读 2019-09-24 23:49:20
    模糊测试是一种自动或半自动的测试技术,常被用来发现软件/操作系统/网络的代码中的错误和安全性问题,其中用于输入随机的数据和不合法的数据被称为“FUZZ”。之后,系统将被监视各种异常,如系统崩溃或内置代码失败...

空空如也

空空如也

1 2 3 4 5 ... 8
收藏数 142
精华内容 56
关键字:

fuzz技术