Defensics健壮性测试工具测试方案

保证原创精品已受版权保护Defensics健壮性测试工具测试方案前言本文档就CodenomiconDefensics的工控安全测试方案提供说明，就测试原理，测试组网，支持的协议以及测试流程提供帮助，指导测试的进行。测试日程安排N/A产品功能介绍CodenomiconDefensics是基于协议级别的专门进行fuzzing测试的健壮性测试工具，专门用于发掘产品当中的未知漏洞。当前随着APTs高级持续攻击的日益猖獗，网络及工控安全面临前所未有的挑战，大部分的攻击利用的都是设备或系统当中的零日漏洞，这类漏洞由于缺少相应的防护措施以及补丁，往往成为黑客攻击的首选。而黑客在寻找零日漏洞时往往采用的就是fuzzing技术，Defensics能够先敌而动，在黑客攻击之前发现产品当中隐含的零日漏洞，帮助客户弥补潜在的安全隐患。CodenomiconDefensics通过构造有序的异常用例集合，来查看系统是否会出现中断或服务失败等现象。通过采用基于协议建模的构建方法，可以保证对协议所有状态机和字段的覆盖。而通过智能高效的用例生成策略，可以使测试人员从无限的数据源中摘取出容易诱发系统服务失败的数据。作为黑盒测试，Fuzzing测试不需要访问源代码，因此可在第三方软件上使用。通过自动化的用例生成、管理和执行，最大限度地提升测试效率，保证产品的安全质量。测试原理模糊测试（Fuzzing），是一种通过向目标系统提供非预期的输入并监视异常结果来发现软件漏洞的方法。目前国际上公认找寻未知漏洞的最佳途径就是通过Fuzzing。Codenomicon公司主推的Defensics产品就是一款基于黑盒的专门针对网络协议进行Fuzzing的安全性/健壮性测试平台。我们会选取出一系列的有组织的异常数据（畸形报文）发送给被测设备，并通过正常报文的探测来观察被测设备是否还处于正常工作状态。这里所谓的“有组织的异常数据”是通过一下两个方向来形成的：缓冲区溢出/溢进，边界值，等等（后续会有具体分类）；根据某种特定网络协议的规约（比如RFC）来对该协议的每一个具体字段，以及整个状态机的所有报文顺序进行遍历，确保代码的高覆盖率。以下是Defensics进行Fuzzing的原理，如图所示，一个完整的测试场景一般可以分为三个步骤：互通性测试，互通性测试的目的是检测工具和被测物之间的配置一致性和连通性是否正常。工具会发送一组正常的协议报文用例到被测物，每个用例都是一个完成的报文交互过程，通过这样一组正常用例，可以覆盖协议所有的状态机和字段，在发送异常用例之前确保被测物状态正常，同时检查其支持的协议状态机。发送异常报文，工具会基于正常的互通性用例生成异常用例，每一个用例同样是一个完整的协议交互，工具会修改其中的某个报文的某个字段或某几个字段，或者重新构造整个报文，用例的数量从几万到几百万不等，工具会自动化的执行测试。发送探测报文，每发送一个异常测试用例之后，工具会发送一个正常的探测报文，去检查被测物是否能正常响应探测报文，其目的一是检查一下被测物在接收到异常报文后是否能够正常提供服务，二是在进行下一条用例前确保被测物的状态正常。如果被测物能够正常响应检测报文，工具会自动跳转到下一条用例。如果不能正常响应，工具会一直检测下去直到被测物响应为止。检查配置/一致性检查配置/一致性失败互通性测试通过通过下一个测试例下一个测试例发送异常报文发送异常报文轮数+1轮数+1发送探测报文 发送探测报文通过失败通过失败根据上图我们可以看到判定探测报文通过与否是我们检验某一条测试用例是否对SUT造成影响的唯一标准；而判定标准是由Timeout值决定的，该值由测试人员根据SUT的正常响应时间决定。所以，所有我们判定探测失败的测试用例，都是因为超过了Timeout值还没有得到正常的相应，通过这种机制，我们可以100%的确保没有误判，因为所有失败的用例都使得SUT在正常响应时间内无法提供服务。这里我们以IPv6协议为例，结合Defensics的界面进行具体说明。在Interoperability中套件已经根据规约定义好正常的协议交互测试用例，这些用例覆盖了该协议所有可能的状态机。点击test即开始执行互通性测试，通过互通性测试可以检查测试仪和被测设备之间的配置一致性是否正常，有些被测设备可能并不支持协议的全部实现，会显示为部分pass，部分fail（绿色表示pass，红色表示fail）。2.在进行完Interoperability（互通性测试）之后，工具会基于刚才跑通的正常用例生成变异的测试用例，由于之前进行了互通性检测，可以保证被测设备对这部分功能是支持的。在5）testcases中可以选择异常用例的范围。3.在选择完测试用例后，在4）Instrumentation中选择探测报文类型，这些探测报文都是正常的协议报文，默认情况下该功能是打开的。通过配置探测报文，测试工具会在每条测试用例中先发送异常报文，然后发送探测报文检查被测设备状态，如果被测设备正常响应，就跳转到下一条用例，如果不能，就重发该检测报文，直到被测设备响应为止。4.在完成4）instrumentation和5）testcases之后，即可进入到6）testrun部分开始执行测试用例。功能特点基于协议建模，全状态机全字段覆盖Defensics是基于协议级别的fuzzing测试工具，每个协议有相应独立的套件，套件采用协议建模的方式进行构建，因此可以保证对协议状态机和字段100%的覆盖。在测试过程中，每一个用例都是一个完整的报文交互，因此不仅仅是可以对第一步交互进行fuzzing，而且可以对所有的协议交互流程进行深度的覆盖。用例自动生成，基于黑盒测试原理Defensics是基于黑盒测试的fuzzing工具，使用时无需访问源代码。测试脚本按照协议规约的定义已经内嵌其中，从用例的生成、管理、执行，到结果的导出，生成报告，完全实现自动化的运行。用例公开，便于问题定位和复现Defensics的用例库涵盖了协议的所有字段，数量从几万到几百万不等，并且可以根据需要手动调节用例库的规模。Defensics的每一个用例都是对用户公开的，用户可以查看用例报文的交互流程，报文的具体内容以及如何生成的异常用例。广泛的协议覆盖，支持大多数主流通讯和工控协议Defensics能够支持超过260种协议，涵盖了二层到七层的通讯协议、工控协议、文件格式、私有协议、空口协议等，目前大部分的通讯协议和主流的工控协议均可测试。支持私有协议测试，提供二次开发JavaSDK针对私有协议特别是工控领域中大量用到的私有协议，可以使用Defensics专门针对私有协议的套件TrafficCaptureFuzzer进行测试。TrafficCaptureFuzzer采用抓包变异的原理，将正常的交互报文导入测试套，基于正常的报文进行fuzzing变异。并且用户可以根据需要修改、定制相关的测试脚本。针对一些复杂的协议交互，例如checksum校验、协议字段交互等，Codenomicon还提供一套JavaSDK用于高级二次开发。支持服务器端和客户端，提供双向测试Defensics基于某个具体协议，可以提供针对服务器端和客户端的双向测试，从而确保对协议报文的完整覆盖。测试协议覆盖目前Defensics可以针对260多种协议进行fuzzing测试，覆盖了从2层到7层的大部分通讯协议，工业控制协议以及私有协议。并且对一个特定协议可以支持服务器端和客户端两个方向。支持的工控协议：ModbusTCPPLC/Master，DNP3Client/Server，ProfinetDCPserver，ProfinetPTCPClient/Server，IEC61850MMSClient/Server，GOOSE/SV，IEC60870-5-104Client/Server，CIP/EtherNet与工控相关的通讯协议：Ethernet，IPv4，TCPv4，UDPv4，ICMPv4，IGMP，XMLSOAPClient/Server，XMLSOAPClient/Server，1588PTPClient/Server，BootP/DHCPClient/Server，NTPClient/Server，FTPClient/Server，HTTP/HTTPSClient/Server，SNMPv1/v2，SNMPv3，Telnet，SSLTLS1.1/1.2Client/Server，IPv6，SSHv1/v2，SMTP私有协议和文件：TrafficCaptureFuzzer(抓包变异)，UniversalFuzzer(文件格式)测试场景测试采用直连的方式连接Defensics测试仪和被测设备，二者通过网线直连，需要为DUT和Defensics配置相应的IP地址，一般配置在同一网段。由测试工具发送有组织的异常数据，观察被测设备在异常报文作用下的健壮性。为了能直观的观察被测DUT的异常，最好在DUT下再连接一次设备。一个典型的测试场景包含了三部分，首先测试工具会向DUT发送一组正常的一致性检测报文，用以检测双方的一致性是否正常。在一致性报文通过后再发送有组织的异常报文测试用例。第三步再发送正常的检测性报文，用以检测刚才的异常报文是否造成影响。测试过程这里以一个典型的Modbus测试流程为例，阐述了如何使用Defensics测试工具进行fuzzing测试。Basicconfiguration加载套件后首先会进入到Basicconfiguration，在Basicconfiguration中需要对一些基本的被测设备变量进行设置，例如在Modbus套件中需要输入被测设备的IP地址，端口号等变量。这些变量是测试的必要配置，对于一些在应用层实现上可能各个厂家有所区别的协议，还需要提供一下交互报文。InteroperabilityInteroperability主要进行一致性检测，测试栏中包含的是该协议典型的测试流程，每一个测试流程都是一组或几组报文的交互，可以点击用例从右边说明栏查看。测试时点击test，工具会自动运行每一个用例，绿色表示通过，红色表示异常，对于红色的用例，可能是被测设备不支持协议的某些部分，也可能是双方的配置有问题，需要结合具体问题具体分析。对于绿色的用例，工具会基于这些用例自动生成相应的异常用例库。Testcases第三步在Testcases中选择想要测试的用例，正常条件下一个套件的用例从几万到几十万不等，某些较大的套件会有几百万的用例，但是由于工具采用了自动化的运行方式，运行速度是很快的，通常几个小时就可以将整个用例运行一遍。此外，每个用例的具体内容是对用户公开的，可以点击具体的用例从右边说明栏查看具体的报文内容。并且为了配合不同的测试需求，Testcases提供了几种不同数量规模的用例库，default模式，full模式，unlimited模式等，每种模式都对应了不同数量级别的用例，对协议的覆盖度也相应的逐级提高。Testrun在Testrun中点击Test按钮就可以开始测试，工具会实时显示当前运行的用例编号，测试状态，运行速度，测试进度等信息。当测试中出现bug，工具会提示红色的SUTfail，点击旁边的Showlogs按钮可以查看具体的日志。Results在每次测试开始时，工具会自动在Results里生成一个以时间戳为名称的测试结果文件夹，里面包含了测试的结果列表，测试用例的交互日志，每一条用例报文的内容等信息。用户还可以通过Results中的Re-run功能重跑那些失败的用例。以上给出的是一个测试的基本流程，用户在使用中结合具体环境可能还需要修改一些配置变量，具体可以参考defensics-instructions.pdf。测试常见结果及处置预案（1）测试常见结果对于Fuzzing测试，它本身是没有预设立场的，所有的测试可能出现的问题都是等价对待的，可以进行区分的只有发送的异常数据包的种类，而不是测试结果的分类。从外部表现上来看，常见的现象有以下几种：系统级挂死或异常协议模块挂死或异常系统级别重启协议模块重启DoS攻击从导致漏洞的生成原因来看，常见的漏洞类型可以分为以下几种：BufferOverflow(缓冲区溢出)：一个缓冲区溢出漏洞可能会出现一个固定大小的缓冲区数据保留在栈或堆。如果输入数据的大小未经过验证，与缓冲区的大小无法适配则缓冲器溢出。一个缓冲区溢出漏洞，可能导致各种问题，包括崩溃，超负荷和其他古怪的行为。在许多情况下，可能被黑客利用缓冲区溢出在易受攻击的系统才能运行外部代码。这是通过精心构造的数据片，导致溢出。在这种情况下，通过网络彻底攻陷一台主机是非常有可能的。内存溢出条件本身可以产生其他严重的故障，因为临界状态变量或其他变量可能会被攻击者控制。Formatstringvulnerability（格式字符串漏洞）:在格式字符串漏洞中，通常会通过类似C/C++语言的printf（）等功能来输入一小串格式字符串；一个黑客能够在指定的输入数据（格式字符串）中添加类似（%s%s%s）的内容来利用这个漏洞。这种漏洞能带来的影响跟缓冲区溢出比较相似，通常能够造成拒绝服务攻击。Memoryallocationbomb（内存分配炸弹）：内存分配炸弹利用内存分配例程中的弱点。根据入侵者伪造的长度字段，可用于对存在漏洞的主机上请求分配所有可用的内存资源。一个程序分配大量的内存是基于一个小项内输入数据的基础上；如果反复多次重复该项，内存分配就很容易受到攻击。如果分配例程失败，就会出现空指针的情况。调用函数并没有认识到这一点，简单地假设分配是成功的。内存分配炸弹导致拒绝服务的情况。保护程序的内存分配炸弹可能是有问题的，因为它是难以指定一个单一的外部请求应该被允许接收多少内存资源。Resourceallocationproblems（资源分配问题）：一些异常的输入可能会导致被测系统分配类如文件描述符的资源。然而，这些资源可能会被视为异常而无法释放，并最终到这服务降级或者拒绝服务的现象。Missingvaliditychecks（合法性未验证）：对于协议字段内的输入字符通常会有一个范围的限制，而且并不是所有合法的输入都合理。如果输入字符的合法性没有被检查就导致了一系列的问题。一个典型的情况就是C/C++软件中对于singedintegers和unsignedintegers的处理；如果一个程序默认处理unsigned，他可能无法正常处理singed的数据。另一个例子就是不正确的数据取值，比如对月份取13。异常的输入元素可能会导致被测软件出现空指针现象，不合法指针行为，不合法的索引以及引用。Busyloops