关于服务器软件漏洞测试程序的设计与实现

发布时间：2014-07-29 21:02

网络安全是当前的热门话题，互联网安全性差的重要表现是服务器软件大多存在漏洞，黑客的入侵行为大多是利用服务器漏洞实现的。现在，笔耕论文新浪博客，每天都有新的服务器软件出现，但这些软件基本上都存在着漏洞，按照传统的测试方法，依靠测试人员去分析代码来完成测试，显然是满足不了需求的。网络服务器软件的漏洞测试是一个十分重要的问题，设计一个较为自动化、通用的漏洞测试工具是十分必要的。
一般漏洞研究方法是先熟悉软件功能，分析服务协议，检查程序代码，然后再推测什么情况下会出现漏洞。这是一个工作量很大的过程，而且开发出来的测试程序也是针对特定软件，不能通用。我们的测试软件要做到通用，就要找出网络服务器软件的共同特性，采用易于配置，易于扩展的结构。

1.网络服务的共性及漏洞产生原因
网络服务基本上都是基于客户机-服务器模型。
                              
 请求数据包

 响应数据报

  图1 
                  
客户机发出请求数据包，服务器返回响应数据包，即Request-Response方式。服务的共性就在于客户机与服务器通过数据包进行通信。每个服务都有自己的应用层协议。服务器软件的应用层协议决定了服务器对请求数据包里的内容怎么解释，所以协议也就体现在数据包中。服务器软件的漏洞一般是因为服务器对异常的请求数据包不能正确响应。对于异常的请求数据包，像数据包里有太长的文件名或文件目录路径包含特殊字符等，如果服务器软件不能正确处理，就可能导致缓冲区溢出、泄露服务器重要信息、拒绝服务等问题，使得入侵者有机可乘。如IIS服务器的UNICODE编码漏洞，对于未打补丁的IIS服务器，如果入侵者输入类似的请求,IIS服务器会将文件路径中的%255c解释为“/”，绕过系统安全策略，在服务器上执行dir 命令，并将结果返回给客户端。利用这种方法，可在服务器上执行任何系统命令，能轻而易举的控制整个服务器。我们的测试程序就是要能自动生成各种可能导致服务器不正常工作的请求数据包，并分析返回的响应信息，找出漏洞所在。

2.测试程序的设计方案
为了通用，测试程序不能过多涉及到具体协议，而测试数据包的格式又要符合具体协议，这是一个矛盾。我们采用样本包和动态链接库的方法来解决这个矛盾。样本包，即有代表性的数据包，依www服务为例，请求数据包“GET /pub/index.htm HTTP/1.1”可以很好的代表一类请求，就可以作为一个样本包。如果只对这个样本包中的某个数据域进行变换，则生成数据包的格式一般也是满足www服务通信协议的。对于一个具体服务，它的协议体现在通信所用的数据包中，我们可以收集一个足以体现该服务协议的样本包集，采用一个脚本来描述这些样本包，要测试不同的服务软件，只须编写与之对应的脚本即可。测试程序只对脚本进行处理，不必与具体协议相关，也就实现了通用性。整个测试程序的系统框图如图2所示，测试数据包生成模块处理脚本，生成测试数据包，发送给服务器；响应信息分析模块分析返回信息，并将分析结果保存在记录文件中。

脚本

记录文件
                                图2
2.1脚本
脚本是对样本包集的描述，服务器软件的协议体现在脚本中。测试数据包就是对样本包的某个域进行变换后得到的数据包。
为了便于程序处理，定义了几个关键字：
SAMPS , 样本包开始；ITEM , 数据项;  SAMPE ，样本包结束； RESULT ,返回结果特征串；
“ ; ”，注释，如果一行以 “;” 打头，则这一行是注释行。
脚本中依次列出各个样本包，每个样本包分成几个数据域，每个数据域用一个数据项来表示。
GET /pub/index.htm HTTP/1.1的脚本描述为：

SAMPS
ITEM COMM GET
    ITEM  PATH  /pub/
    ITEM  FILE  index.htm
ITEM  VER  HTTP/1.1
RESULT …
  SAMPE

每个数据项由三部分组成，以第一个数据项ITEMS COMMI GET 为例： ITEMS，关键字，标识数据项开始（每个数据项占一行，因此无须关键字标识数据项结束）；COMM：数据项类型名，数据项类型名决定了它的变换处理函数；GET： 数据项的内容。

2.2测试数据包生成模块
 测试数据包生成模块是整个测试工具的关键所在，只有生成最可能导致服务器出问题的请求数据包，才能发现服务器软件的漏洞所在。但又不能产生过多的数据包，使得测试效率太低。从统计测试的角度来说,就是要生成最可能导致服务器出错的数据包的样本集。
测试数据包生成模块对脚本的处理过程为：从脚本中读出一个样本包，脚本处理函数构造描述样本包的链表，链表的结构为:
typedef struct RULELIST
{
     rulenode* rulelisthead;
     rulenode* rulelistend;
}RULELIST;
样本包中的每一项为链表中的一个节点rulenode；
结点rulenode的定义为
   typedef struct _rulenod
{  
  char  type[8];        //数据项类型名
char item[128];       //数据项内容
  _rulenode *nextnode;  //指向下一个结点的指针
}rulenode;

构造好链表后，对该样本包里一个数据项的内容进行变换，而保持其它数据项不变，生成测试数据包，发送给服务器，分析返回信息，将测试结果写入记录文件，处理完该样本包的所有数据项后，释放链表，读出下一样本包，重复上面的处理过程，直至脚本结束。
模块中对数据项内容进行变换的处理函数做成DLL动态链接库，调用时根据数据项类型名进行调用。这样使得该测试程序易于扩展，如果被测试软件的数据包中有原测试程序未定义的数据项类型，只需在脚本中加入新的数据项类型， 同时将对应的处理函数做成DLL动态链接库的形式，拷贝至测试程序目录下即可，而原有的程序一点也不必改动。

2.3响应信息分析模块
   响应信息分析模块主要对返回信息进行特征串搜索,记录下服务器软件出现异常时的情况。特征串定义在脚本中,特征串搜索采用Boyer-Moore字符串匹配算法.如果返回信息中有匹配的字符串,就意味着服务器可能出错.例如，IIS 返回 “The remote procedure call failed ” ,就是RPC 服务出现错误。由于很多情况下返回信息很难预料，即便采用人工智能的方法也难判断服务器到底出了什么问题。所以响应信息分析模块只是检测异常，将异常记录下来，进一步的分析判断还需要人工介入。    
 

 

本文编号：6512