精华内容
下载资源
问答
  • 基于docker / qemu / kvm / trinity的linux内核模糊测试工具链。 不要使用它。 它会破裂。 要求 码头工人 qemu / kvm 用法 设置debian sid docker build box zined@foo:~/src/kfuzz$ make docker #---------------...
  • 模糊测试工具Peach Fuzzer官方文档翻译
  • RESTler是第一个有状态的REST API模糊测试工具,用于通过其REST API自动测试云服务并查找这些服务中的安全性和可靠性错误。 对于具有OpenAPI / Swagger规范的给定云服务,RESTler会分析其整个规范,然后生成并执行...
  • webfuzz模糊测试工具

    热门讨论 2012-03-19 19:58:31
    web应用程序的模糊测试工具,可用于自动发包,测试web应用程序的安全漏洞,可用于发现sql注入,xss漏洞等威胁。
  • 现有的模糊测试工具都存在耦合严重的问题,这对模糊测试工具的实验性开发和拓展带来很大的挑战。我们设计和实现了一种模块化的、可拓展策略的模糊测试工具。我们将整个模糊测试的过程模块化,并将模块分为不可被拓展...
  • PwnFuzzer 是一个 java 工具,它发送 http 请求并尝试猜测用户列表的密码。 它易于使用和配置。 享受 ;)
  • 这是用于测试Django应用程序的自动模糊测试工具。 它根据您在开发服务器上的活动生成url和params映射,然后使用它来模糊测试您的应用程序。 如何使用 添加到已安装的应用程序 INSTALLED_APPS + =('django_fuzzytest...
  • dizzy是一个模糊测试框架,用python编写,并且能够通过很多输出选项进行全状态和无状态模糊测试。 用法 $dizzy_cmd version 2.0 running on Linux usage: dizzy_cmd [-h] [-s START_AT] [-d SEC] [-l] [-o OPTIONS] ...
  • 板球赛是一个充当分布式模糊测试工具的项目,可管理整个网络中的模糊测试工具。 当前支持AFL( )。 AFL包含在Fuzzer特性中,因此实现该特性的任何其他Fuzzer都将兼容,从而允许不同类型的Fuzzer进行交互并共享其...
  • 用于进行模糊测试的开源工具,此压缩包内整合了64位绿色版本,及windbg 32位
  • 程序模糊器 介绍 非常WIP / PoC代码。 谨慎行事。 非常感谢lcamt​​uf,AFL员工,John Regehr和C-Reduce员工以及GCC员工。 用法 将AFL下载到当前目录。 建立它。 使用afl-gcc构建编译器。 如有必要, $AFL_PATH...
  • 我知道这个工具不是蛮力工具,但我很喜欢这个名字。 该工具比其他方法更快,因为它发送异步请求。 您还可以在CLI上查看%状态。 这样,您可以猜测还剩下多少个单词。 最后,您可以在csv文件中查看所有请求和响应...
  • DirBuster是一款路径及网页暴力破解的工具,可以破解出一直没有访问过或者管理员后台的界面路径
  • afl.pdf模糊测试工具

    2021-08-20 20:03:20
    主要介绍AFL源码;比较详细
  • wfuzz 是一款Python开发的Web安全模糊测试工具
  • 本文发表于 TesterHome 社区,作者为资深测试开发工程师恒捷,原文标题为《谷歌开源模糊测试工具 ClusterFuzz 尝鲜记录 (进行中)》,原文链接:https://testerhome.com/topics/18171 背景 模糊测试,是指用随机...

    本文发表于 TesterHome 社区,作者为资深测试开发工程师恒捷,原文标题为《谷歌开源模糊测试工具 ClusterFuzz 尝鲜记录 (进行中)》,原文链接:https://testerhome.com/topics/18171

    背景

    模糊测试,是指用随机坏数据(也称做 fuzz)攻击一个程序,然后等着观察哪里遭到了破坏。(出自 模糊测试)。一直以来都有不少的模糊测试工具,但大多只集中在数据生成,执行和异常检测依赖人工,未有比较完整的方案。

    早在八年前,google 内部就在建设和使用模糊测试的工具来测试其内部的应用,而在两年前, google 推出了 OSS-Fuzz 服务,用于给开源项目的进行免费的模糊测试服务,可自动在新版本代码提交后自动完成 测试->异常检测->issue登记->老版本issue回归及自动关闭 的功能。背后使用的就是 ClusterFuzz 技术。流程图如下:

    而在过年前,google 开源了 ClusterFuzz ,并解决了原有 ClusterFuzz 必须依赖 Google Cloud 提供的服务这个问题,提供了本地运行的解决方案。根据官方介绍,它具备如下功能:

    • 高度可扩展,谷歌的内部实例运行在超过 25000 台机器上

    • 准确的去副本化(Accurate deduplication)

    • 问题跟踪器的全自动错误归档和关闭

    • 最小化测试用例

    • 通过二分法回归查找

    • 提供分析 fuzzer 性能和崩溃率的统计信息(不支持本地部署)

    • 易于使用的 Web 界面,用于管理和查看崩溃

    • 支持引导模糊(例如 libFuzzer 和 AFL)和黑盒模糊测试

    其大致执行流程如下:

    当然,方案并不完美,如模糊数据统计、崩溃数据统计等功能由于依赖 google cloud 强大的数据处理能力,本地运行时是用不了的。

    官方说的总是美好的,现实是否这么完美呢?曾有人说,实践是检验真理的唯一标准,为了更好地了解这个工具,当然就要本地跑个 demo 玩下啦。

    本地搭建及运行

    要获得 ClusterFuzz 的完整功能,需要连接 Google Cloud Platform。但结合国情,我们更期望了解它纯本地运行能做到什么,因此这次尝鲜主要尝试纯本地运行。

    注意:虽然运行可以脱离 Google Cloud Platform ,但部分安装时用到的工具需要到 Google 站点下载,所以,你懂得。

    以下步骤均是在 macOS 10.14 上进行。

    环境搭建

    1、下载源码

    git clone https://github.com/google/clusterfuzz
    
    cd clusterfuzz

     

    2、安装 google cloud sdk

    进入 https://cloud.google.com/sdk/ ,按照引导安装 sdk 并配置好环境变量(mac 下可以直接用解压后的 install.sh 脚本一键安装),确认命令行可调用 gcloud 命令

    $ gcloud -v
    
    Google Cloud SDK 226.0.0
    
    bq 2.0.38
    
    core 2018.11.16
    
    gsutil 4.34

    3、安装 python 和 go 运行环境。

    特别注意:如果你使用的是 macOS 或者 Ubuntu、Debain,直接执行第4步即可,脚本里会自动安装 Python 和 go

    python 要求 2.7.10 以上,但不能是 python 3。在 mac 上可以直接运行 brew install python@2 安装。

    go 未要求版本,在 mac 上可以直接运行 brew install go 安装。我用的是 go1.11.5 darwin/amd64

    4、安装其他依赖

    针对

    • Ubuntu (14.04, 16.04, 17.10, 18.04, 18.10)

    • Debian 8 (jessie) or later

    • Recent versions of macOS with homebrew (experimental)

    几个系统,官方已经内置了安装依赖的脚本,直接运行即可:

    local/install_deps.bash

    执行完毕,会出现

    Installation succeeded!
    
    Please load virtualenv environment by running 'source ENV/bin/activate'.

    的提示。

    坑一,官方的脚本里第一行用了 -ex 参数,会导致运行脚本时如果有命令执行出错(如 brew install 时有些应用本地已经安装过,但非最新版本),直接退出程序。

    可以通过 sed-i'''s/bash -ex/bash -x/'local/install_deps* 命令直接去掉 -e 参数。已经给官方提了 issue 。

    坑二,官方脚本里使用 python butler.py bootstrap 初始化环境时,会自动去 google 站点下载 chromedriver 相关的文件。

    全局搜索了下源代码,只有跑单测的时候有用到 chromedriver ,所以可以直接注释掉这个函数:

    diff --git a/src/local/butler/common.py b/src/local/butler/common.py
    
    index 94b17b3..3e9de99 100644
    
    --- a/src/local/butler/common.py
    
    +++ b/src/local/butler/common.py
    
    @@ -275,7 +275,7 @@ def install_dependencies(platform_name=None):
    
    _remove_invalid_files()
    
    execute('bower install --allow-root')
    
    
    
    - _install_chromedriver()
    
    + #_install_chromedriver()
    
    
    
    def symlink(src, target):

    坑三,运行时会报错 

    Analysisof target'//local:create_gopath'failed;build aborted:nosuchpackage'@org_golang_google_api//iterator':failed to fetch org_golang_google_api:2019/02/1901:15:41unrecognizedimportpath"google.golang.org/api"

    这是在运行 bazel 构建 go 环境的时候报错了,原因是 @org_golang_x_tools、@com_google_cloud_go、@org_golang_google_api 这几个第三方依赖网络原因获取不到。

    尝试一:使用代理

    因为 go 获取依赖有可能用 http ,也有可能用 git ,所以保险起见全部都配好代理:

    export HTTP_PROXY=http://112.126.81.122:6$(date +%m%d)
    
    export HTTPS_PROXY=${HTTP_PROXY}
    
    git config --global https.proxy ${HTTP_PROXY}
    
    git config --global http.proxy ${HTTP_PROXY}

    可惜的是,配置完了还是不行,bazel 构建时提示 

    fatal:unable to access'https://code.googlesource.com/google-api-go-client/':LibreSSLSSL_connect:SSL_ERROR_SYSCALLinconnection to code.googlesource.com:443,此路不通。

    尝试二:修改运行环境,改为在网络本身就没问题的地方运行

    嗯,哪里有这样的环境呢?一个是自己买云主机,另一个就是考虑用 docker hub 提供的构建环境了。看了下后面的使用步骤,也没有需要在源码目录做操作的部分,就选择 docker 吧。

    动手 fork 了官方仓库,开始了漫长的尝试:https://github.com/chenhengjie123/clusterfuzz

    2.23 更新:docker 镜像已成功打包,基于 ubuntu 16.04 系统。镜像中已运行完毕本文中的第1-4步(除了坑2中的注释 chromedriver ),装好了所有依赖。镜像地址:https://hub.docker.com/r/chenhengjie123/clusterfuzz_local

    可通过  docker run-it--name clusterfuzz-p9000:9000-p41089:41089-p9001:9001-p9002:9002chenhengjie123/clusterfuzz_local 进入镜像运行环境,进入后续的步骤。clusterfuzz 的源代码存放在镜像的 /clusterfuzz 目录。

    5、切换到 python 的 virtualenv

    $ source ENV/bin/activate

    校验是否一切就绪

    $ python butler.py --help
    
    python butler.py --help
    
    DEPRECATION: Python 2.7 will reach the end of its life on January 1st, 2020. Please upgrade your Python as Python 2.7 won't be maintained after that date. A future version of pip will drop support for Python 2.7.
    
    usage: butler.py [-h]
    
    {bootstrap,py_unittest,go_unittest,js_unittest,format,lint,package,deploy,run_server,run,run_bot,remote,clean_indexes,generate_datastore_models,create_config}
    
    ...
    
    

    运行本地实例

    本地实例包含2个部分,一个是管理各个执行机器人的服务端,另一个是执行机器人。

    启动本地服务

    首次运行,添加 --bootstrap 进行各个数据的初始化。同时个人推荐加上 --skip-install-deps 跳过依赖安装(前面步骤已经装过了,不需要重复安装)

    $ python butler.py run_server --bootstrap --skip-install-deps

    非首次运行,务必去掉 --bootstrap 参数。

    坑四:启动时会到 https://www.googleapis.com/discovery/v1/apis/pubsub/v1/rest 获取一些信息,如果此时网络连不通,会报错

    报错信息:

    Created symlink: source: /clusterfuzz/local/storage/local_gcs, target /clusterfuzz/src/appengine/local_gcs.
    
    Traceback (most recent call last):
    
    File "butler.py", line 282, in <module>
    
    main()
    
    File "butler.py", line 256, in main
    
    command.execute(args)
    
    File "src/local/butler/run_server.py", line 162, in execute
    
    test_utils.setup_pubsub(constants.TEST_APP_ID)
    
    File "/clusterfuzz/src/python/tests/test_libs/test_utils.py", line 308, in setup_pubsub
    
    _create_pubsub_topic(client, project, queue['name'])
    
    File "/clusterfuzz/src/python/tests/test_libs/test_utils.py", line 284, in _create_pubsub_topic
    
    if client.get_topic(full_name):
    
    File "/clusterfuzz/src/python/google_cloud_utils/pubsub.py", line 192, in get_topic
    
    request = self._api_client().projects().topics().get(topic=name)
    
    File "/clusterfuzz/src/python/base/retry.py", line 88, in _wrapper
    
    result = func(*args, **kwargs)
    
    File "/clusterfuzz/src/python/google_cloud_utils/pubsub.py", line 89, in _api_client
    
    discovery.DISCOVERY_URI.format(api='pubsub', apiVersion='v1'))
    
    File "/clusterfuzz/src/third_party/httplib2/__init__.py", line 1694, in request
    
    (response, content) = self._request(conn, authority, uri, request_uri, method, body, headers, redirections, cachekey)
    
    File "/clusterfuzz/src/third_party/httplib2/__init__.py", line 1434, in _request
    
    (response, content) = self._conn_request(conn, request_uri, method, body, headers)
    
    File "/clusterfuzz/src/third_party/httplib2/__init__.py", line 1390, in _conn_request
    
    response = conn.getresponse()
    
    File "/usr/lib/python2.7/httplib.py", line 1123, in getresponse
    
    raise ResponseNotReady()
    
    httplib.ResponseNotReady

    解决猜想:看了下这个页面,实际上是获取 api 文档。理论上只要把这个 api 文档事先下载好并放到资源文件中,然后把这个从网络获取文档的步骤改为读取资源文件即可。晚些尝试下。

    由于时间关系,暂时先想办法让网络能访问 google 先绕过。

    启动到末尾,会出现如下日志:

    | INFO 2019-02-23 06:25:34,648 api_server.py:265] Starting gRPC API server at: http://localhost:39957
    
    | INFO 2019-02-23 06:25:34,877 dispatcher.py:256] Starting module "default" running at: http://localhost:9000
    
    | INFO 2019-02-23 06:25:35,021 dispatcher.py:256] Starting module "cron-service" running at: http://localhost:9001
    
    | INFO 2019-02-23 06:25:35,023 admin_server.py:150] Starting admin server at: http://localhost:9002

    表明已经启动完毕。可以通过打开 http://localhost:9002/ 打开管理员界面。

    坑五:内部监听地址都是 localhost ,意味着在 docker 容器内部时,即使用 -p 暴露了端口也访问不了

    解决猜想:把源码中 localhost 都替换为 0.0.0.0 ,即监听所有地址,应该可以解决。目前还在修改中。

    后续部分翻译自官方文档,还没亲测,大家可以先看看了解。 

    ====== 官方文档翻译分割线 ======

    启动执行机器人

    官方命令:

    python butler.py run_bot --name my-bot /path/to/my-bot

    其中 my-bot 可以替换为自己喜欢的名称。我改成了 fuzzing-bot

    $ python butler.py run_bot --name fuzzing-bot `cwd`/fuzzing-bot

    执行成功后,可在前一步的管理员界面看到机器人状态。

    可通过

    tail -f `cwd`/fuzzing-bot/bot.log

    查看机器人实时日志输出。

    开始测试

    官方给了一个例子,寻找 OpenSSL 的心脏滴血内存溢出漏洞。下面按照给出的步骤执行。

    编译一个包含这个漏洞和已经带有 fuzz 插桩的 OpenSSL

    # 下载并解压包含这个漏洞的 OpenSSL :
    
    curl -O https://www.openssl.org/source/openssl-1.0.1f.tar.gz
    
    tar xf openssl-1.0.1f.tar.gz
    
    
    
    # 使用 AScan 和 fuzzer 插桩编译 OpenSSL:
    
    cd openssl-1.0.1f/
    
    ./config
    
    
    
    # 注意:$CC 必须指向 clang 二进制文件。简单地说,按照这个命令来写就对了
    
    make CC="$CC -g -fsanitize=address,fuzzer-no-link"
    
    cd ..
    
    
    
    # 下载 fuzz target 和它的数据依赖:
    
    curl -O https://raw.githubusercontent.com/google/clusterfuzz/master/docs/setting-up-fuzzing/heartbleed/handshake-fuzzer.cc
    
    curl -O https://raw.githubusercontent.com/google/clusterfuzz/master/docs/setting-up-fuzzing/heartbleed/server.key
    
    curl -O https://raw.githubusercontent.com/google/clusterfuzz/master/docs/setting-up-fuzzing/heartbleed/server.pem
    
    
    
    # 编译可用于 ClusterFuzz 的 OpenSSL fuzz target ($CXX 需要指向一个 clang++ 二进制文件):
    
    $CXX -g handshake-fuzzer.cc -fsanitize=address,fuzzer openssl-1.0.1f/libssl.a \
    
    openssl-1.0.1f/libcrypto.a -std=c++17 -Iopenssl-1.0.1f/include/ -lstdc++fs \
    
    -ldl -lstdc++ -o handshake-fuzzer
    
    
    
    zip openssl-fuzzer-build.zip handshake-fuzzer server.key server.pem

    上传 fuzzer 到 ClusterFuzz

    1、进入 Jobs 页面,点击 【ADD NEW JOB】按钮 2、job 的各个输入框填写以下内容:

    输入框名称内容
    Namelibfuzzerasanlinux_openssl
    PlatformLINUX
    Templateslibfuzzer engine_asan
    Environment StringCORPUS_PRUNE = True

    3、把上一步打包的 openssl-fuzzer-build.zip 文件上传到 "Custom Build" 字段 4、点击 【ADD】 按钮,完成添加 5、点击【Select/modify jobs】,勾选 "libfuzzerasanlinux_openssl" ,然后点击【SUBMIT】 按钮

    执行及查看结果

    通过查看本地的机器人执行日志,可以发现 fuzz libFuzzer libfuzzer_asan_linux_openssl 这个字符串,代表目前 fuzz 测试已经在进行中了。

    稍等一会,会在日志中发现一个堆栈信息和 AddressSanitizer:heap-buffer-overflow 出现在日志中。

    再稍等一会,可以在 <> 页面看到一个标题为 "Heap-buffer-overflow READ{*}" 的测试用例,这个就是 ClusterFuzz 发现的心脏滴血漏洞了。

    扩展性

    从官方文档上看,上面的例子只是用到了引导式 fuzz ,ClusterFuzz 还支持可任意扩展的黑盒 fuzz ,可支持使用 Python 编写 fuzz 生成器。此次由于时间关系未能尝试,有兴趣的同学可以尝试一下。

    同时官方的 local 文件夹中有看到 docker 运行相关的脚本,相信未来会支持通过 docker 运行,降低环境配置成本。

    局限性

    从官方文档中可以看到,被测试的软件需要在编译时插入一些桩用于检测异常,而这个方案目前仅支持 C/C++ ,且主要用于内存地址检测。而对于我们平时接触到的 Java/python/go 应用,没有提供对应的方案,需要另行扩展。

    小结及展望

    ClusterFuzz 正如其名,一个集群运行的 Fuzz 工具。它提供了执行机器人管理以及一个非常简便的管理界面,也做到了和研发流程无缝的接入,甚至更进一步地做到了 bug 自动创建及修复检测。

    从小的地方看,它让模糊测试通过集群获得了更高的执行效率和问题发现效率。

    从大的地方看,它提供的整体流程,包含了自动报 bug 和检测 bug 修复情况,让大家只在需要的时候感知到它的存在,正是目前大部分 CI 实践中欠缺的最后一公里路,缺陷的自动上报与修复检测,值得我们思考补全我们的 CI 流程。

    虽然目前并未提供除 C/C++ 之外的完整解决方案,但相信按照其扩展性,扩展到支持更多的语言并不是难题。期望未来有更多的同学参与扩展这个工具,形成开箱即用的解决方案。(end)

    谷歌 ClusterFuzz 尝鲜意犹未尽?

    想掌握更多测试前沿技术神兵利器?

    推荐关注 MTSC2019 互联网测试开发大会

    聚焦测试前沿技术趋势与创新发展

    分享质量管理案例与最佳实战经验

     

    MTSC 中国移动互联网测试开发大会(Mobile Testing Summit China)是由 TesterHome 社区主办的软件测试行业年度技术盛会。自 2015 年创办以来,MTSC 已成功举办 4 届。MTSC2019 第五届大会将于 2019 年 6 月 28~29 日在北京国际会议中心举行。大会官网:https://testerhome.com/mtsc/2019

    推荐演讲嘉宾特别福利

    目前,MTSC2019 面向软件测试行业全球公开征集议题,期待各位资深测试技术专家和质量管理经理贡献 Topic 或者推荐演讲嘉宾。推荐成功者,免费赠送一张 MTSC2019 大会门票。:)

    议题信息可发送邮件至: topic@testerhome.com

    往届 MTSC 大会风采

     

     

    展开全文
  • 模糊测试工具defensics

    万次阅读 2014-09-03 21:37:13
    defensics是一个模糊测试工具,百度百科对模糊测试(Fuzzing)的定义是,是一种通过向目标系统提供非预期的输入并监视异常结果来发现软件漏洞的方法。它是通过异常输入的方式触发原来未知的漏洞。 模糊测试的测试...
    defensics是一个模糊测试工具,百度百科对模糊测试(Fuzzing)的定义是,是一种通过向目标系统提供非预期的输入并监视异常结果来发现软件漏洞的方法。它是通过异常输入的方式触发原来未知的漏洞。
    
    模糊测试的测试用例生成方式有两种:基于生成和基于变异的。基于变异的模糊测试,使用实际的输入,通过随机修改样本或基于样本结构的方式生成测试用例。而基于生成的模糊测试中,需要对被测协议或文件格式有较好的理解,对被测协议或文件格式建立起模型,然后模糊测试工具根据模型生成测试用例,对协议功能有一个完美的覆盖。
    defensics公司的一个文档中曾经在测试用例,执行时间和发现漏洞等方面对基于生成和基于变异的模糊测试进行了对比,基于生成的测试执行时间要短很多,测试用例数量要少很多,但是发现的漏洞数却要多很多。
    公司利用defencisc主要是做基于TCP/IP协议模糊测试。现阶段主要是利用Condenomicon提供的测试suite来进行的,还未针对公司内部的协议做模糊测试。
    defensics是由Codenomicon 科诺斯公司提供的,它也提供了常见协议的test suite,可以到公司网站下载最新的test suite,目前用得比较多的是ARP Server/Client Test Suite,IPv4 test suite,TCP for IPv4 Server/Client Test Suite,ICMPV4 Test Suite等test suite。最多的一个test suite可能有上百万个测试用例,最少的也得上万个。
    defensics主要是针对协议,输入一些变异的,异常的,不合法的协议数据,从而检验系统对这些异常数据的处理能力。比如将TCP协议的端口字段增加一个字节,TCP协议的窗口长度为0等,每个test suite是针对一个协议的各个方面的异常数据的总和。
    如TCP for TPV4 server test suite的组织结构为:
       TCP for TPV4 server test suite:
           active-close   --named group
           wait-close
           SYNACK-Reset
           Established-Reset
           Sockstress
           known-Attacks
           
    已经出现过的漏洞的地方往往还存在脆弱点。
    如果不确定当前被测试系统是否能支持test suite或者group,可以自动扫描是否支持。
    如果不用官网提供的test suite,自己很难写出比较全面的系统的模糊测试用例。
    defensics也是一个较好的自动化测试工具,所有的测试用例从运行到结果的显示到report都是自动化的,一个suite的测试用例多达百万个,如果不能全自动的运行,也是一件特别伤脑筋的事情。
    defensics可以记录不用level的log。如valid case and failed case,valid case and anomally messages,debug trace(full logging),no trace等,一般选择valid case and failed case,如果全部log都保存下来也需要不少空间啊,关键是分析也费劲。


    测试用例运行完成之后,在result里面可以看到,如果测试用例全部通过,则文件夹标记为绿色,如果有测试用例没有通过,这文件夹标记为红色。

    result文件夹里主要有三个文件,main.log, notes.xml和statistics.csv。main.log记录的是被测系统和测试系统之间的数据包,点开可以看到每个数据包的具体数据。statistics.csv里面会显示pass和fail的测试用例,点开fail的测试用例,也可以看到数据包并了解数据包是在哪里发生了变异。

    一下是defensics 11 工具官方给出的main log主要包括哪些内容

     Defensics 11 Main log
     
    Main - Result view - Main log
    Main log
    Main log contains detailed test run results, including details of sent and received messages. Main log file is opened to main log viewer that can show details of the file in the viewer component on the right.
    Please note that the main log may be a large file in long test runs, depending on the logging settings.
    A main log can have the following log entries:
    Test case info
    The beginning and the end of each test case is logged. Click the test case index line to go to test case documentation. Each test case is given a verdict, usually with some remarks explaining the cause of the verdict.
    Messages
    Green message line indicates an outgoing message and blue line an incoming message. Message contents may be available by clicking the message line. Use the  'Save to file...'  link to save the message content. For test cases with long overflow anomalies, the content is abbreviated for performance reasons.
    Other entries
    Test suite specific log entries may be present.


    note.xml是一个xml格式的report,里面主要是记录了测试系统以及测试suite等信息。对分析具体的漏洞我觉得并没有多大用处。

     Defensics 11 Notes file
     
    Main - Result view - Notes file
    Notes file
    Notes can be used to store user-supplied information about a test run. Carefully filled notes may improve test run identification and search remarkably. Notes are stored as an XML file notes.xml. Contrast to other files, which are generated by the test driver during the test run, notes file can be edited by user during and also after the test execution.
    Information in notes file is organized into key-value pairs. There are some built-in keys, which are used in report generation. However, user can provide any new keys for own use. The built-in keys are described here.

    Special directory for results
    A directory where to test runs result files are placed. Directory structure of result directories with a defined testplan.directory is: result directory/<testplan directory>/suitename/timestamp/<result files>. Key used in xml file: Testplan.Directory.

    System under test
    Name of the System Under Test (SUT). Added to report document. Key used in xml file: SUT.Name

    Version of the system under test
    Version of the System Under Test (SUT). Added to report document. Key used in xml file: SUT.Version

    Tester name
    Name of the tester. Key used in xml file: Tester.Name

    Tester contact information
    Contact information of the tester, such as e-mail address. Key used in xml file: Tester.Contact

    Name of the test run
    Name of the test run is shown in result browser. This will replace the default test run name consisting of date and time. Key used in xml file: Testrun.Name

    Report name
    Name of an generated report document. Key used in xml file: Report.Name

    Report information
    Longer description added to the Executive summary page of a report document. Key used in xml file: Report.Info

    Used sequence files
    Sequence used in the test run. Visible in result browser. Key used in xml file: Testrun.Used.Sequence

    Continuation of defined testrun
    Denotes this test run is resumed from a previous test run defined by the value. Key used in xml file: Testrun.Continuation-of

    Continues in defined test run
    This test continues in test run defined by the value. Key used in xml file: Testrun.Continued-in

    Auxiliary test run in
    Test run has an auxiliary test run in. Key used in xml file: Testrun.Auxiliary-in

    Type of the test run
    Type of test is marked here, possible values are   normal, auxiliary and valid  . Key used in xml file: Testrun.Type

    Test case selection mode
    Test case selection mode is marked here. Possible values are   all, random, %value, first and last  . Key used in xml file: Testrun.Selection.Mode
    Notes file is lazily created by GUI when required. The file does not exit, if there has been no need for it! 
    Templates and Editing
    You can edit notes using result browser by clicking the file notes.xml. You can edit values for built-in keys. You can add new keys as well. Changes to the notes are automatically saved.
    You can import notes from templates as well. There is a list of saved templates on top of the view. Mouse over a template will show the saved template content. Select a template and click   "Import from template"  . It will overwrite all the editable values. New templates can be defined in   'All' -> 'Notes'   tab of the GUI.
    Notes are saved as xml and are editable in external editors too. See more details about the notes xml format

    还有一个文件是statistics.csv,这个文件就是以表格的形式记录了测试用例通过与否等信息。官方文档有点长我就不贴了。


    运行完成之后,还可以利用工具生成失败测试用例的一个summary的report。以下是一个示例。

     Test run summary   

    20140901-0317-03 : TCP for IPv4 Server Test Suite

      Overall verdict   
      Overall verdict      FAIL
    [   Test case count   ]   1
      Failures    
    Verdicts from valid case or external instrumentation
      Analysis tools   
     
      System under test   
      Name   

      Version   

      Instrumentation methods   
      Valid case instrumentation       ENABLED   
      External instrumentation           DISABLED   
      SNMP instrumentation              DISABLED   
      Instrumentation fail limit           1
      Instrumentation frequency        1

      Verdict from valid case instrumentation / connection instrumentation   
      Overall verdict           fail
      Test cases in total    1
      Failed                          1
    Passed                        0
      Test execution time   
      Test run started        20140901 03:17:03
      Test run ended         20140901 03:17:13
      Running time           00:00:10
      Average cases per second   

      Test setup   
      Name of the tester   


      Contact information   

      Operating system    Linux i386 3.7-trunk-686-pae
      Java                          1.7.0_25 23.25-b01 mixed mode
       Test suite   
      Name                      TCP for IPv4 Server Test Suite
      Version                  4.2.1 
      License                 Licensed to***
      Suite hash            ***
      Options   
      Sequence                                 TCP with HTTP GET payload (in file user/http.seq)
      Test case selection mode      all
      Test run type                             normal
      Options in detail    
    ...

      Test run analysis   
      Click the links below to perform some advanced analysis of the selected test runs:   
      Denial of Service Analysis    
      Analyze the Denial Of Service (DOS) situations during the failed test cases. The analysis provides an estimate of the vulnerability of SUT for DOS attacks.   
      Response Analysis    
      Find our all different Status responses from the SUT and list them with representative test cases. The analysis provides an overview for SUT behavior and error modes.   
      Slow Test Case Analysis    
      Find the non-failed test cases which running times compared to amount of sent traffic are the longest.   

    点开  Denial of Service Analysis 链接之后,里面有更详细的在这个测试用例时是否遭受了DoS攻击的信息。
             Response Analysis   列出了被测系统SUT在失败的测试用例执行时返回的不同状态。


    看似测试已经完成,报告也有了,其实工作也许做了1/3不到。

    1.对所有失败的测试用例得重新执行一遍。

    2.检查每个测试用例失败时,被测系统的状态并检查这种状态对于系统来说是否是可以接受的以及这种状态带来的潜在的风险是什么。

    3.会导致DoS的测试用例,可以再利用DoS工具再测试一下。


    对所有失败的测试用例进行分析统计,就可以了解协议在哪些方面的畸形数据处理方面容易出错从而造成严重的安全问题。最后提交测试报告,提交bug,跟踪bug状态,开发修复之后还得验证bug等等。

    展开全文
  • 0x10 物联网设备模糊测试 对于物联网设备,比如家用路由器模块,UPNP、HTTP server、Telnet都是用户经常接触的模块,通常也能够与外界交互,从而提供了入口。如果这些模块或者使用的协议存在漏洞,往往能够直接利用...

    0x10 物联网设备模糊测试

    对于物联网设备,比如家用路由器模块,UPNP、HTTP server、Telnet都是用户经常接触的模块,通常也能够与外界交互,从而提供了入口。如果这些模块或者使用的协议存在漏洞,往往能够直接利用,达到远程攻击的效果。

    IoT 固件分析往往涉及到二进制代码审计、静态扫描以及动态调试等,其中模糊测试作为一种重要的方法,能够给安全测试添砖加瓦。针对IoT设备的模糊测试主要有两类

    • 固件的二进制Fuzz测试,如AFL
    • 物联网协议Fuzz测试,如Peach、Sulley
      在这里插入图片描述

    本次重点介绍Sulley的衍生项目——boofuzz的使用。对物联网设备的协议fuzz测试,不可丢失的一环是监控器,能够发现bug是监控器的作用所在。一般来说,大多数针对协议的fuzz测试,在每次发送变异报文后,通过ping或者其他协议监测对方是否在线从而判断设备是否出现异常。这种方法较为简单,但是粗粒度的监视器带来的后果是较高的误报率;另一种方式是ssh或者telnet登录目标设备,实时观察当前设备的状态,这种方式优点是随时捕捉异常信号,缺点是,针对不同设备可能要开发不同的监控API。所以当前诸多的协议Fuzz工具,大部分使用第一种,即通过目标设备是否可达来判断崩溃情况。


    0x20 boofuzz 框架介绍

    0x21 从Sulley说起

    项目地址:https://github.com/Bit9/sulley。该项目基于Python2.7,也就是说,如果你要安装此工具,需要该Python环境的支持。

    sulley 是一款模糊测试框架,可以使用 sulley 进行协议Fuzzing。Sulley(以作者的观点来看)所具有的能力超过了以前所发布的大多数模糊测试技术,包括商业工具和那些在公开领域中可用的工具。该框架的目标是不仅要简化数据的表示,而且还要简化数据的传输以及对目标的监视。Sulley从Monsters,Inc创建之后就被亲切的命名 ,因为它是模糊化的工具。现在sulley 已经停止更新,不再维护。1

    大多数情况下,现代模糊器只专注于数据生成。Sulley不仅具有令人印象深刻的数据生成能力,而且还朝着更进一步的方向迈进了一步,其中还包括现代模糊器应提供的许多其他重要方面。Sulley监视网络并有条不紊地维护记录。Sulley可以检测和监视目标的运行状况,并可以使用多种方法将其恢复到已知的良好状态。Sulley对检测到的故障进行检测,跟踪和分类。Sulley可以并行进行测试,从而显着提高测试速度。Sulley可以自动确定哪些独特的测试用例序列会触发故障。Sulley可以自动完成所有这些工作。
    Sulley框架
    图 Sulley框架 2

    上图是Sulley的整体框架图,来源于BlackHat。Sulley主要包括四大组件

    1. Data Generation 数据生成
    2. Session 会话管理
    3. Agents 代理
    4. Utilities 独立单元工具

    其中,数据生成和会话管理是比较重要的两个模块。Sulley数据生成方式是基于generation-based的方式,需要对协议或者文件进行建模。数据生成的特点3

    • 一个数据报文由基元(Primitives)、块(Blocks组成)
    • 多个基元可以组成块,块可以相互嵌套
    • 在基元的基础上我们可以创建自定义的特殊的复杂基元(Legos,数据积木,暂且这么翻译吧),例如Email的地址,IP地址等。
    • 最后还有一些有用的工具,例如算length长度、校验和、加密模块等

    会话模块,根据已经构建好的Request,利用 Pgraph 绘制, Pgraph 可以创建、修改和渲染图
    在这里插入图片描述
    图 Session2

    在上图中,节点ehlo、helo、mail from、rcpt to、data表示5个请求,路径’ehlo’->‘mail form’->‘rcpt to’->‘data’和’helo’->‘mail from’->‘rcpt to’->data’体现了请求之间的先后顺序关系。callback_one()和callback_two()表示回调函数,当从节点echo移动到节点mail from时会触发该回调函数,利用这一机制,节点mail from可以获取节点ehlo中的一些信息。而pre_send()和post_send()则负责测试前的一些预处理工作和测试后的一些清理工作。每个节点连接起来,组成状态图,可以对图中的每个节点进行操作,也可以自定义callback回调函数。

    由于该项目不再更新,为此,本次将使用另外一个版本boofuzz,该工具基于Sulley,并且作者积极更新。Boofuzz是古老的Sulley模糊测试框架的分支和后续版本。除了大量的错误修复之外,boofuzz还致力于扩展性。

    0x22 boofuzz API

    Session对象是Fuzz测试的核心,当你创建Session的时候,你会传递一个Target对象,该对象本身接收一个Connection对象

    session = Session(
        target=Target(
            connection=SocketConnection("127.0.0.1", 8021, proto='tcp')))
    

    连接对象实现ITargetConnection。可用的选项包括 SocketConnection和SerialConnection。

    准备好会话对象后,接下来需要在协议中定义消息。细节请参照 静态协议定义功能定义协议 。每一条消息均以一个s_initialize
    函数开头,比如这是fuzz FTP协议中的几个消息定义:

    s_initialize("user")
    s_string("USER")
    s_delim(" ")
    s_string("anonymous")
    s_static("\r\n")
    
    s_initialize("pass")
    s_string("PASS")
    s_delim(" ")
    s_string("james")
    s_static("\r\n")
    
    s_initialize("stor")
    s_string("STOR")
    s_delim(" ")
    s_string("AAAA")
    s_static("\r\n")
    
    s_initialize("retr")
    s_string("RETR")
    s_delim(" ")
    s_string("AAAA")
    s_static("\r\n")
    

    定义消息后,将使用刚刚创建的Session对象将它们连接到图中:

    session.connect(s_get("user"))
    session.connect(s_get("user"), s_get("pass"))
    session.connect(s_get("pass"), s_get("stor"))
    session.connect(s_get("pass"), s_get("retr"))
    

    之后,就可以进行fuzz测试了

    session.fuzz()
    

    每次运行的日志数据将保存到当前工作目录下boofuzz-results目录中的SQLite数据库中。可以随时通过以下任一方式在任何这些数据库上重新打开Web界面

    boo open <run-*.db>
    

    该段译自:https://boofuzz.readthedocs.io/en/stable/user/quickstart.html# API接口的详细说明,参照手册4即可。


    0x30 Fuzz HTTP协议

    0x31 boofuzz安装

    Boofuzz需要Python。建议的安装要求pip。

    Ubuntu: sudo apt-get install python-pip
    

    请注意,源码是用python2写成的,高版本ubuntu自带python3,需要自己安装python2,所以应该用pip2

    Ubuntu: pip2 install boofuzz
    

    其他系统安装,请参考手册。官方手册中,提供了两个开源的示例 5

    0x32 fuzz 某一路由器

    在理解了 boofuzz (Sulley) 的架构之后,现在我们用boofuzz实战操作一波吧。

    Created with Raphaël 2.2.0 开始 构造请求 设置会话信息 添加监控 开始fuzz 结束

    Step1 根据API接口的数据包构造请求

    比如,我们要对路由器的登录接口进行fuzz测试,首先需要使用Burpsuite设置代理,进行抓包。以下为某路由器的登录界面
    在这里插入图片描述
    Burpsuite抓包结果
    在这里插入图片描述
    现在需要根据报文,利用boofuzz框架提供的原语对http请求进行定义

    s_initialize(name="Request")
        with s_block("Request-Line"):
            # LINE 1
            s_static("POST", name="Method")
            s_delim(" ", name='space-1')
            s_string("/fromLogin", name='Request-URI')  # 需要变异
            s_delim(" ", name='space-2')
            s_static('HTTP/1.1', name='HTTP-Version')   
            s_static("\r\n")
    
            # LINE 2
            s_static("Host", name="Host")
            s_static(": ")
            s_static("192.168.10.1", name="ip")
            s_static("\r\n")
    
            # LINE 3  对应 Content-Length: 400
            s_static('Content-Length')
            s_static(': ')
            s_size('data', output_format='ascii', fuzzable=True)    # size的值根据data部分的长度自动进行计算,同时对该字段进行fuzz
            s_static('\r\n')
    
            # ...
        	s_static('\r\n')
    
        # 对应http请求数据
        with s_block('data'):
            s_static('login_name=&curTime=1581845487827&setLang=&setNoAutoLang=&login_n=admin&login_pass=')
            s_string('123456', max_len=1024)	# 需要变异,且最大长度为1024
            s_static('&languageSel=1')
    

    Step2 设置会话信息

    以下是最简单的一个会话的设置,包括设备的IP地址以及端口

    session = Session(
            target=Target(
                connection=SocketConnection("192.168.10.1", 80, proto='tcp')
                netmon=Remote_NetworkMonitor(host, port, proto='tcp'))  # 服务可用性监控 非必须代码
            ),
        )
    

    如果需要fuzz多个请求,比如说,还要继续fuzz登录后的一些接口,还需要将之前定义的请求按照一定的先后顺序连接,比如说

    session.connect(s_get('login'))		# 默认前置节点为root
    session.connect(s_get('login'), s_get('setsysemailsettings'), callback=add_auth_callback)
    session.connect(s_get('login'),s_get('setsyslogsettings'), callback=add_auth_callback)
    session.connect(s_get('login'),s_get('setschedulesettings'), callback=add_auth_callback)
    

    上面的代码中等同于下面的图例
    在这里插入图片描述
    由于setsysemailsettingssetsyslogsettingssetschedulesettings等请求需要在登录之后才可以正常使用,所以需要在login请求之后发生。而setsysemailsettingssetsyslogsettingssetschedulesettings这几个请求之间则没有明确的先后关系。add_auth_callback为自定义的回调函数,主要用于从login请求中获取用于登录认证的信息如cookie,然后将其设置于setsysemailsettingssetsyslogsettingssetschedulesettings等请求中。


    Step3 添加监视器

    正如我们在0x10节所说,通过当前设备是否在线,就是判断目标设备是否崩溃的方法之一。结合Step 2中,我们已经引用的函数Remote_NetworkMonitor(),其核心代码如下,此函数并非官方API,也可不添加

    # 通过TCP全连接来判断目标端口是否在监听
    if self.proto == "tcp" or self.proto == "ssl":
        try:
            self._sock.connect((self.host, self.port))
            self.alive_flag = 1
        except socket.error as e:
       		self.alive_flag = 0
    

    Step4 开始fuzz

    最后只需要调用session.fuzz() 即可。运行我们编写好的脚本,正如0x22最后所述,每次运行的日志数据将保存到当前工作目录下boofuzz-results目录中的SQLite数据库中,运行boo open <run-*.db>,会在26000端口开启一个Web服务器,控制和查看测试进度(某些版本,运行fuzz脚本,会自动打开26000端口,所以只需要打开如下页面即可)。
    在这里插入图片描述
    上图表明,第238个用例测试结果出现了异常。tips:在打开数据库监控状态的时候,如果提示26000端口已经占用,可以使用netstat -anp | grep 26000找到进程,并杀死即可

    0x33 结果分析

    具体的原因,就要靠我们自己进行后续的分析了。可以使用数据库查看软件,Kali自带 DB Browser for SQLite,打开 boofuzz-results 目录下的相关文件可看到fuzz的日志
    在这里插入图片描述
    从数据库中可以看到,的确是按照我们的代码,对相关字段进行变异,从而达到fuzz的效果。进一步观察238个用例的前一个用例,找到发送的内容,重新发送,观察设备状态,看问题是否能够复现,最终确定漏洞是否存在。


    0x40 总结

    IoT 设备在移动互联网时代,是一个兴起并且正在壮大的群体,其安全性不容忽视。对 IoT 设备的协议进行模糊测试,是一种有效的漏洞挖掘手段。boofuzz就是这样一个优秀的针对协议fuzz的工具,笔者深入浅出,从原理出发,介绍其架构组成,并最终进行实战演练,更多的细节说明,请参考相关用户手册,这个工具更多的功能等你发现!

    附:fuzz脚本

    #!/usr/bin/env python
    # Designed for use with boofuzz v0.0.9
    # coding=utf-8
    from boofuzz import *
    
    
    def main():
        session = Session(
            target=Target(
                connection=SocketConnection("192.168.10.1", 80, proto='tcp')
            ),
        )
    
        s_initialize(name="Request")
        with s_block("Request-Line"):
            # LINE 1
            s_static("POST", name="Method")
            s_delim(" ", name='space-1')
            s_string("/fromLogin", name='Request-URI')  # variation
            s_delim(" ", name='space-2')
            s_static('HTTP/1.1', name='HTTP-Version')   
            s_static("\r\n")
    
            # LINE 2
            s_static("Host", name="Host")
            s_static(": ")
            s_static("192.168.10.1", name="ip")
            s_static("\r\n")
    
            # LINE 3  对应 Content-Length: 400
            s_static('Content-Length')
            s_static(': ')
            s_size('data', output_format='ascii', fuzzable=True)    # size的值根据data部分的长度自动进行计算,同时对该字段进行fuzz
            s_static('\r\n')
    
            # ...
            s_static('\r\n')
    
        # 对应http请求数据
        with s_block('data'):
            s_static('login_name=&curTime=1581845487827&setLang=&setNoAutoLang=&login_n=admin&login_pass=')
            s_string('123456', max_len=1024)
            s_static('&languageSel=1')
    
    
        session.connect(s_get("Request"))
    
        session.fuzz()
    
    
    if __name__ == "__main__":
        main()
    

    1. https://www.jianshu.com/p/5993d5f003d3 ↩︎

    2. Fuzzing Sucks! Introducing the sulley fuzzing framework. Pedram Amini & Aaron Portnoy. Black Hat US 2007 ↩︎ ↩︎

    3. https://blog.csdn.net/u012397189/article/details/79758931 ↩︎

    4. https://boofuzz.readthedocs.io/en/stable/user/quickstart.html# ↩︎

    5. https://boofuzz.readthedocs.io/en/stable/index.html ↩︎

    展开全文
  • 头文件 令人眼花f乱的模糊测试工具包使用的模糊测试脚本。
  • 模糊测试工具Simple Fuzzer

    千次阅读 2017-04-21 10:51:49
    模糊测试工具Simple Fuzzer
    模糊测试工具Simple Fuzzer

    模糊测试是一种不同于渗透测试的漏洞检测方式。它向目标系统发送各种非预期的输入,然后通过监视异常结果来发现漏洞。Kali Linux虽然作为渗透测试系统平台,但也提供了一些模糊测试工具,如Simple Fuzzer。

    Simple Fuzzer工具具备全面的模糊测试功能,但使用非常简单。该工具提供一种非常简洁的脚本语言。该语言提供文本模糊字符串和序列模糊字符串两种形式。同时,该语言支持脚本包含等功能,来构建复杂的测试用例。通过该语言,用户来构建测试所用的配置文件。然后,通过Simple Fuzzer加载该文件,就可以对目标实施各种模糊测试。

    展开全文
  • Valgrind的全自动模糊测试工具。 要求 bzip2 自动配置 制作 海湾合作委员会 Python 安装 $ ./install.sh 配置 配置文件: fuzz/settings.cfg 执行 CLI: $ ./fuzz/fuzz.py 图形用户界面: $ ./fuzz/gui.py 例子 ...
  • 模糊单元 该项目提供了一种创建大量 JUnit 测试的机制,理论上,这些测试将覆盖测试用例的问题空间。 它旨在具有以下功能: ...模糊测试将(在某些情况下)使用遗传算法完成,以了解应将哪些模式用作测试用例参数。
  • XMPP模糊器 XMPP-FUZZER 是 XMPP 的模糊测试工具。 它建立在 Smack 库之上。 可惜目前只支持中文。 它最初发布在 code.google.com/p/xmpp-fuzzer 上。 共同开发者:姜峰和( ) 2009年开发。
  • 在最近项目的测试中,我们引入了模糊测试(Fuzztesting)。在这个过程中,接触到了Sulley,一款用Python实现的用于网络协议fuzztesting的开源测试框架。跟其他的开源工具比起来,使用上比较灵活,而且也很方便。  在...
  • 模糊测试工具-peachFuzzer

    千次阅读 2015-12-03 21:57:12
    3中方式获得Debugging tools:WKD的一部分、Windows SDK一部分、单独工具包 ) 若要下载 SDK 并将其安装在其他计算机上,请单击下载链接并运行安装程序。然后,在 指定位置 对话框中,单击 下载可安装在单独计算机...
  • ConFuzz将QuickCheck样式的基于属性的测试与覆盖率指导的模糊测试相结合,用于在事件驱动程序中查找并发错误。 ConFuzz基于基于属性的测试库并使用AFL查找并发错误。 有关更多技术详细信息,请参阅在 2021上发布的...
  • crashbin_explorer:查看引起错误的每一个测试用例,展示每个错误发生的地址,错误的堆栈追踪并把它画在一个图上 其余的模块暂时不会讲,等用到的时候再讲吧 4.本章总结  Sulley最主要的就是4大模块,协议...
  • Web模糊测试工具Powerfuzzer

    千次阅读 2017-04-20 10:32:46
    Web模糊测试工具Powerfuzzer
  • 帕夫模糊器 Paff the Fuzzer 是一个 PoC 二进制模糊器,用户可以通过动态库链接来检测目标文件。 用法 $制作; ./bash runUnitTests.sh 例子 guifre@debian:~/Paff-The-Fuzzer$ bash runUnitTests.sh Fuzzing ...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 73,533
精华内容 29,413
关键字:

模糊测试工具