一种POC生成方法、装置、电子设备和存储介质

技术领域

本申请涉及网络安全检测技术领域，特别涉及一种POC生成方法、装置、电子设备和计算机可读存储介质。

背景技术

安全产品诸如waf（Web Application Firewall，Web应用防护系统）、IDS、漏洞扫描器需要支持检测漏洞，而检测漏洞需要漏洞相关的POC（Proof of Concept，验证性测试，用于检测是否存在漏洞）。目前漏洞的POC的获取途径通常是搭建环境来获取数据包，通过人工分析提取特征，然后依靠安全研究人员手动进行脚本编写POC，效率较低，并且当有一定规模数量的漏洞时无法快速且及时的完成POC的编写，延长了安全产品漏洞覆盖的时间。

发明内容

本申请的目的是提供一种POC生成方法、装置、电子设备和计算机可读存储介质，实现了生成POC的另一途径，可自动化生成POC，有效降低人力成本，同时提升了安全产品漏洞覆盖率的效率。其具体方案如下：

第一方面，本申请公开了一种POC生成方法，包括：

当接收到POC生成请求时，读取规则文件，根据特征字段提取所述规则文件中的规则内容；其中，所述规则文件属于开源IDS系统内文件；

根据所述规则文件的规则语法，解析所述规则内容中的关键字，生成特征数据集合；

将所述特征数据集合POC格式化，生成POC。

可选的，所述根据特征字段提取所述规则文件中的规则内容，包括：

当所述规则文件属于Snort开源系统或Suricata开源系统内文件时，读取所述规则文件中的行内容，选取以alert开头，且所述行内容带有classtype和sid字段的目标内容，并将所述alert、所述classtype和所述sid作为特征字段；

将所述目标内容作为所述规则内容。

可选的，所述根据所述规则文件的规则语法，解析所述规则内容中的关键字，生成特征数据集合，包括：

根据所述规则文件的规则语法对应的规则协议字段，从所述规则内容中确定目标漏洞类型的规则内容；

根据所述目标漏洞类型的规则内容，确定所述目标漏洞类型的漏洞所在的端口；

根据所述端口和所述规则协议字段中的协议类型，利用正则匹配提取所述目标漏洞类型的规则内容中的关键字，生成所述特征数据集合。

可选的，所述根据所述端口和所述规则协议字段中的协议类型，利用正则匹配提取所述目标漏洞类型的规则内容中的关键字，生成所述特征数据集合，包括：

当所述目标漏洞类型为web漏洞时，根据所述web漏洞所在的端口和所述规则协议字段中的协议类型，利用所述正则匹配提取所述目标漏洞类型的规则内容中的漏洞名称、请求方式、请求路径和请求参数，得到所述特征数据集合。

可选的，在所述生成特征数据集合之后，还包括：

将所述特征数据集合转换为json格式，生成特征json文件；

相应的，所述将所述特征数据集合POC格式化，生成POC，包括：

将所述特征json文件POC格式化，生成所述POC。

可选的，所述将所述数据集合POC格式化，生成POC，包括：

获取预先创建的POC模板，将所述特征数据集合中的特征数据填充至所述POC模板，生成所述POC。

第二方面，本申请公开了一种POC生成装置，包括：

读取模块，用于当接收到POC生成请求时，读取规则文件，根据特征字段提取所述规则文件中的规则内容；其中，所述规则文件属于开源IDS系统内文件；

解析模块，用于根据所述规则文件的规则语法，解析所述规则内容中的关键字，生成特征数据集合；

生成模块，用于将所述特征数据集合POC格式化，生成POC。

可选的，所述读取模块，包括：

当所述规则文件属于Snort开源系统或Suricata开源系统内文件时，读取所述规则文件中的行内容，选取以alert开头，且所述行内容带有classtype和sid字段的目标内容，并将所述alert、所述classtype和所述sid作为特征字段；

将所述目标内容作为所述规则内容。

第三方面，本申请公开了一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行所述计算机程序时实现如上述POC生成方法的步骤。

第四方面，本申请公开了一种计算机可读存储介质，所述计算机可读存储介质上存储有计算机程序，所述计算机程序被处理器执行时实现如上述POC生成方法的步骤。

本申请提供一种POC生成方法，包括：当接收到POC生成请求时，读取规则文件，根据特征字段提取所述规则文件中的规则内容；其中，所述规则文件属于开源IDS系统内文件；根据所述规则文件的规则语法，解析所述规则内容中的关键字，生成特征数据集合；将所述特征数据集合POC格式化，生成POC。

可见，本申请通过提取规则文件中的规则内容，并解析规则内容中的关键字，进行POC格式化，从而生成POC，与相关技术中人工提取特征编写POC不同，本申请利用已有的规则文件中的规则，直接将该规则转化为POC，从而进行漏洞检测，其中，规则文件属于开源IDS系统内文件，且定期更新，实现了生成POC的另一途径，提高了POC的形成效率，无需人工分析提取特征，并依靠安全研究人员手动进行脚本编写POC，只需提取规则文件，解析规则内容并进行POC格式化，即可生成POC，避免了相关技术中需要人工分析提取特征，依靠安全研究人员手动进行脚本编写POC，效率较低，导致延长安全产品漏洞覆盖率时间的缺陷，本申请能够实现自动化生成POC，有效降低人力成本，同时提升了安全产品漏洞覆盖率的效率。本申请同时还提供了一种POC生成装置、一种电子设备和计算机可读存储介质，具有上述有益效果，在此不再赘述。

附图说明

为了更清楚地说明本申请实施例或现有技术中的技术方案，下面将对实施例或现有技术描述中所需要使用的附图作简单地介绍，显而易见地，下面描述中的附图仅仅是本申请的实施例，对于本领域普通技术人员来讲，在不付出创造性劳动的前提下，还可以根据提供的附图获得其他的附图。

图1为本申请实施例所提供的一种POC生成方法的流程图；

图2为本申请实施例所提供的一种具体实施例的系统架构图；

图3为本申请实施例所提供的一种具体实施例的工作流程示意图；

图4为本申请实施例所提供的一种POC生成装置的结构示意图。

具体实施方式

为使本申请实施例的目的、技术方案和优点更加清楚，下面将结合本申请实施例中的附图，对本申请实施例中的技术方案进行清楚、完整地描述，显然，所描述的实施例是本申请一部分实施例，而不是全部的实施例。基于本申请中的实施例，本领域普通技术人员在没有做出创造性劳动前提下所获得的所有其他实施例，都属于本申请保护的范围。

目前，获取相关漏洞的POC时，局限于漏洞信息获取、分析效率等原因，往往需要人工分析提取特征，然后依靠安全研究人员手动进行脚本编写POC，效率较低。

基于上述技术问题，本实施例提供一种POC生成方法，能够实现自动化生成POC，有效降低人力成本，同时提升了安全产品漏洞覆盖率的效率，具体请参考图1，图1为本申请实施例所提供的一种POC生成方法的流程图，具体包括：

S101、当接收到POC生成请求时，读取规则文件，根据特征字段提取规则文件中的规则内容；其中，规则文件属于开源IDS系统内文件。

本实施例并不限定产生POC生成请求的触发动作，例如可以是用户输入IDS规则存放路径以及输入规则文件后缀名（各安全厂商的规则文件后缀名都不同，诸如.rules、rule），还可以是其他。本实施例中的规则文件是开源IDS系统内的文件，本实施例并不限定开源IDS系统的具体系统，可以是Snort开源系统或是Suricata开源系统，还可以是其他开源系统。可以理解的是，IDS（intrusion detection system，入侵检测系统）是一种对网络传输进行即时监视，在发现可疑传输时发出警报或者采取主动反应措施的网络安全设备。Snort和Suricata都是开源IDS系统，Snort下有很多社区进行支持，形成了自己的规则集，定期更新并且允许用户下载。其规则语法也很简单，能使使用者更方便的入门。Suricata可以使用与Snort相同的规则，其规则语法大体上是一致的，只有少部分字段的使用不同，同时也有自己的规则集。Snort、Suricata规则覆盖了owasp（开放式Web应用程序安全项目）10项最严重的相关漏洞检测，并且每周都会更新新的规则文件，包括最新爆发的漏洞。

本实施例通过读取开源IDS系统内的规则文件，根据特征字段提取规则文件中的规则内容。本实施例并不限定特征字段的具体内容，根据具体使用哪个开源IDS系统内的规则文件而定，即不同的开源IDS系统内的规则文件的特征字段是不同的。举例说明，在Snort开源系统和Suricata开源系统中，规则内容通常以alert（脚本语言）开头，并带有classtype和sid字段，其中classtype用于表明该规则的漏洞类型，sid用于表明规则编号。在这一种具体的实施例中，根据特征字段提取规则文件中的规则内容，可以包括：

当规则文件属于Snort开源系统或Suricata开源系统内文件时，读取规则文件中的行内容，选取以alert开头，且行内容带有classtype和sid字段的目标内容，并将alert、classtype和sid作为特征字段；

将目标内容作为规则内容。

即本实施例中当规则文件属于Snort开源系统或Suricata开源系统内文件时，特征字段是alert、classtype和sid，具体的，选取以alert开头，且行内容带有classtype和sid字段的目标内容，即可确定为规则内容。

S102、根据规则文件的规则语法，解析规则内容中的关键字，生成特征数据集合。

可以理解的是，不同的开源IDS系统具有不同的规则语法，因此，需要根据开源IDS系统内规则文件对应的规则语法来解析规则内容中的关键字。还可以理解的是，针对不同类型的漏洞所针对的规则的关键信息即关键字是不同的，例如，web漏洞，分为http协议和tcp协议，其中，对于http协议，会有关键字http，关键字http_uri（请求路径）、关键字http_request_body（请求参数）等。解析得到的所有关键字形成特征数据集合，即特征数据集合中包含解析规则内容得到的关键字。

本实施例并不限定解析规则内容中的关键字，生成特征数据集合的具体过程。在一种具体的实施例中，根据规则文件的规则语法，解析规则内容中的关键字，生成特征数据集合，可以包括：

根据规则文件的规则语法对应的规则协议字段，从规则内容中确定目标漏洞类型的规则内容；

根据目标漏洞类型的规则内容，确定目标漏洞类型的漏洞所在的端口；

根据端口和规则协议字段中的协议类型，利用正则匹配提取目标漏洞类型的规则内容中的关键字，生成特征数据集合。

可以理解的是，规则文件中可能包含不止有一种规则协议，例如，针对web漏洞的规则文件中包含有http规则协议和tcp规则协议（传输控制协议），因此，需要确定想要检测生成的漏洞类型即目标漏洞类型的规则内容，在解析过程中就可以调过非目标漏洞类型的规则内容，有效提高解析效率。例如，想要解析的目标漏洞类型为http规则协议的web漏洞，通常content字段之后，会带有规则协议字段http，如http_uri、http_request_body等。而一般二进制漏洞或者其他涉及到非常规端口的漏洞，其规则协议字段一般为tcp或udp（传输控制协议），并且content字段之后不存在http关键字，那么在解析过程中就可以跳过该规则内容。

在确定目标漏洞类型的规则内容后，进一步解析确定目标漏洞类型的漏洞所在的端口。可以理解的是，本实施例中解析确定漏洞所在端口的过程即根据具体的规则内容和对应的规则语法来确定，举例说明，以web漏洞的一条规则内容为例，alert http any any-> any any，代表捕获http规则协议任意源地址源端口到任意目的地址目的端口，其第四个any指代任意源端口，一般来说any的默认值为80或者8080（可以在配置文件中设置），那么按照这个位置就可以获取漏洞所发生的端口。

再根据端口和协议类型，利用正则匹配提取规则内容中的关键字，生成特征数据集合。例如，利用正则匹配，匹配协议类型、漏洞名称msg、http_uri、http_client_body等，例如，

在这一种具体的实施例中，根据端口和规则协议字段中的协议类型，利用正则匹配提取目标漏洞类型的规则内容中的关键字，生成特征数据集合，可以包括：

当目标漏洞类型为web漏洞时，根据web漏洞所在的端口和规则协议字段中的协议类型，利用正则匹配提取目标漏洞类型的规则内容中的漏洞名称、请求方式、请求路径和请求参数，得到特征数据集合。

即本实施例以web漏洞类型为例，根据web漏洞所在的端口（默认为80或8080）和协议类型即http或tcp，由于web漏洞重要的信息在于漏洞名称、请求方式、请求路径和请求参数，因此本实施例利用正则匹配提取规则内容中的漏洞名称、请求方式、请求路径和请求参数，得到特征数据集合。

在一种具体的实施例中，为了使各个特征数据呈现比较清晰直观，便于开发人员开发维护，本实施例中在生成特征数据集合之后，还可以包括：

将特征数据集合转换为json格式，生成特征json文件

可以理解的是，json格式的文件呈现比较清晰直观，便于开发人员开发维护。因此，本实施例中将生成的特征数据集合转化为json格式，得到json文件。

相应的，将特征数据集合POC格式化，生成POC，可以包括：

将特征json文件POC格式化，生成POC。

将特征数据集合转换为json（JavaScript Object Notation，JS对象简谱）格式的json文件后，通过对特征json文件POC格式化，生成POC。

S103、将特征数据集合POC格式化，生成POC。

本实施例并不限定将特征数据集合POC格式化，生成POC的具体方式。在这一种具体的实施例中，将特征数据集合POC格式化，生成POC，可以包括：

获取预先创建的POC模板，将特征数据集合中的特征数据填充至POC模板，生成POC。

本实施例中通过获取预先创建的POC模板，格式化将特征数据集合中的特征数据套用在POC模板中，即可生成POC。举例说明，以python脚本为例，根据其http_method为post，那么POC的请求方式就采取requests.post，请求路径为目标地址加上http_uri中的值，post参数page=login，解析pcre正则表达式，得到其匹配的内容为key参数中包含竖线、分号以及反引号，并且漏洞是有关于命令注入漏洞，一般测试漏洞是否存在都会使用dnslog平台，那么产生的key=;ping dnslog平台或者key=;`ping dnslog`，最后形成类似request.post(目标地址+http_uri,data={‘page’=’login’,’key’=’\;`ping dnslog`’})格式的脚本，用于测试漏洞是否存在。

基于上述技术方案，本实施例通过提取规则文件中的规则内容，并解析规则内容中的关键字，进行POC格式化，从而生成POC，与相关技术中人工提取特征编写POC不同，本申请利用已有的规则文件中的规则，直接将该规则转化为POC，从而进行漏洞检测，能够实现自动化生成POC，有效降低人力成本，同时提升了安全产品漏洞覆盖率的效率。

以下提供一种生成POC系统的具体实施例。相关技术中，一般是根据已有的漏洞信息转换为IDS规则，那么反过来将IDS规则转换为漏洞信息，可用于弥补自身安全产品覆盖不足的问题。本系统包括IDS规则提取模块，漏洞特征提取模块，POC生成模块，共3个模块，图2为本实施例提供的一种具体实施例的系统架构图，各个模块的功能分布如下：

1、IDS规则提取模块，用于从Snort、Suricata等IDS规则文件中识别规则，去除注释等不必要因素，并提取存放到数据库或者统一路径下。

2、漏洞特征提取模块，根据提取的规则，按照Suricata、Snort规则语法，提取出诸如漏洞名称、请求方式、请求路径、请求参数等重要特征，并形成特征数据集合。

3、POC生成模块，根据整合过后的数据集合，格式化套用到POC生成模板中。

图3为本实施例提供的一种具体实施例的工作流程示意图，主要工作流程如下：

1、开始运行；

2、接收用户输入的IDS规则存放路径以及用户输入的规则文件后缀名（各安全厂商的规则文件后缀名都不同，诸如.rules、.rule）；

3、根据后缀名读取规则文件，逐行读取内容并去除两边的空白字符，当行内容是以alert字符开头，并且包含classtype:、sid:时，判断为规则并存放；

4、读取步骤3得到的规则，按照Suricata、Snort规则语法，提取规则协议、规则名称、flow字段、content字段以及修饰content字段的各类关键字，如果规则协议为HTTP，并且flow字段的值包含to_server，那么重新将规则名称、content字段以及修饰content字段的各类关键字重新整合数据为集合。本实施例中针对于Snort和Suricata规则，因为两者规则语法相近，且语法较为简单。在规则文件中，一般除了规则还会有部分注释以及说明，所以需要先将这些干扰项去除。而在Snort和Suricata中，规则一般以alert开头，并且通常带有classtype和sid，用于表明该规则的漏洞类型和规则编号。可以通过读取行内容并且去除两边的空白字符，并判断是否以alert开头，行内容中是否带有classtype和sid字段。

5、根据步骤4得到的特征数据集合，套用POC模版，格式化生成POC。

以OpenRepeater 2.2未授权远程代码执行(CVE-2019-25024)为例子。其规则如下：

模板的漏洞名称即为规则中的msg信息，请求方式为http_method对应的POST方式，漏洞路径为http_uri关键字对应的/functions/ajax_system.php，post请求参数为http_client_body关键字对应的post_service，而针对于rce远程代码执行漏洞常规的POC方法都是dnslog探测，所以这里使用的payload就是ping生成的dnslog地址。

获取到的信息集合为{"漏洞名称":"OpenRepeater 2.2未授权远程代码执行","请求方式":"POST","漏洞路径":"/functions/ajax_system.php","请求参数":"post_service"}，可以直接使用正则替换的方式生成模板，比如re.sub("漏洞名称",数据集合["漏洞名称"],POC模板)，或者是使用格式化字符，POC模板.format(数据集合["漏洞名称"])，得到最终POC。

基于上述技术方案，本实施例提供了一种新的获取漏洞信息的方式，使得安全产品能够更好的覆盖部分漏洞，并且自动化形成POC，能够有效地降低人力成本，安全工作人员也可以根据这些POC，在这些基础上进一步完善提炼，避免了前期形成POC花费大量时间。

下面对本申请实施例提供的一种POC生成装置进行介绍，下文描述的POC生成装置与上文描述的POC生成方法可相互对应参照，相关模块均设置于中，参考图4，图4为本申请实施例所提供的一种POC生成装置的结构示意图，包括：

在一些具体的实施例中，具体包括：

读取模块401，用于当接收到POC生成请求时，读取规则文件，根据特征字段提取规则文件中的规则内容；其中，规则文件属于开源IDS系统内文件；

解析模块402，用于根据规则文件的规则语法，解析规则内容中的关键字，生成特征数据集合；

生成模块403，用于将特征数据集合POC格式化，生成POC。

在一些具体的实施例中，读取模块401，包括：

读取单元，用于当规则文件属于Snort开源系统或Suricata开源系统内文件时，读取规则文件中的行内容，选取以alert开头，且行内容带有classtype和sid字段的目标内容，并将alert、classtype和sid作为特征字段；

规则内容单元，用于将目标内容作为规则内容。

在一些具体的实施例中，解析模块402，包括：

第一确定单元，用于根据规则文件的规则语法对应的规则协议字段，从规则内容中确定目标漏洞类型的规则内容；

第二确定单元，用于根据目标漏洞类型的规则内容，确定目标漏洞类型的漏洞所在的端口；

提取单元，用于根据端口和规则协议字段中的协议类型，利用正则匹配提取目标漏洞类型的规则内容中的关键字，生成特征数据集合。

在一些具体的实施例中，提取单元，包括：

提取子单元，用于当目标漏洞类型为web漏洞时，根据web漏洞所在的端口和规则协议字段中的协议类型，利用正则匹配提取目标漏洞类型的规则内容中的漏洞名称、请求方式、请求路径和请求参数，得到特征数据集合。

在一些具体的实施例中，还包括：

转化模块，用于将特征数据集合转换为json格式，生成特征json文件；

相应的，生成模块403，包括：

生成单元，用于将特征json文件POC格式化，生成POC。

在一些具体的实施例中，生成模块403，包括：

获取单元，用于获取预先创建的POC模板，将特征数据集合中的特征数据填充至POC模板，生成POC。

由于POC生成装置部分的实施例与POC生成方法部分的实施例相互对应，因此POC生成装置部分的实施例请参见POC生成方法部分的实施例的描述，这里暂不赘述。

下面对本申请实施例提供的一种电子设备进行介绍，下文描述的电子设备与上文描述的POC生成方法可相互对应参照。

本申请还公开一种电子设备，包括：

存储器，用于存储计算机程序；

处理器，用于执行计算机程序时实现如上述POC生成方法的步骤。

由于电子设备部分的实施例与POC生成方法部分的实施例相互对应，因此电子设备部分的实施例请参见POC生成方法部分的实施例的描述，这里暂不赘述。

下面对本申请实施例提供的一种计算机可读存储介质进行介绍，下文描述的计算机可读存储介质与上文描述的POC生成方法可相互对应参照。

本申请还公开一种计算机可读存储介质，计算机可读存储介质上存储有计算机程序，计算机程序被处理器执行时实现如上述POC生成方法的步骤。

由于计算机可读存储介质部分的实施例与POC生成方法部分的实施例相互对应，因此计算机可读存储介质部分的实施例请参见POC生成方法部分的实施例的描述，这里暂不赘述。

说明书中各个实施例采用递进的方式描述，每个实施例重点说明的都是与其他实施例的不同之处，各个实施例之间相同相似部分互相参见即可。对于实施例公开的装置而言，由于其与实施例公开的方法相对应，所以描述的比较简单，相关之处参见方法部分说明即可。

专业人员还可以进一步意识到，结合本文中所公开的实施例描述的各示例的单元及算法步骤，能够以电子硬件、计算机软件或者二者的结合来实现，为了清楚地说明硬件和软件的可互换性，在上述说明中已经按照功能一般性地描述了各示例的组成及步骤。这些功能究竟以硬件还是软件方式来执行，取决于技术方案的特定应用和设计约束条件。专业技术人员可以对每个特定的应用来使用不同方法来实现所描述的功能，但是这种实现不应认为超出本申请的范围。

结合本文中所公开的实施例描述的方法或算法的步骤可以直接用硬件、处理器执行的软件模块，或者二者的结合来实施。软件模块可以置于随机存储器（RAM）、内存、只读存储器（ROM）、电可编程ROM、电可擦除可编程ROM、寄存器、硬盘、可移动磁盘、CD-ROM、或技术领域内所公知的任意其它形式的存储介质中。

以上对本申请所提供的一种POC生成方法、装置、电子设备及计算机可读存储介质进行了详细介绍。本文中应用了具体个例对本申请的原理及实施方式进行了阐述，以上实施例的说明只是用于帮助理解本申请的方法及其核心思想。应当指出，对于本技术领域的普通技术人员来说，在不脱离本申请原理的前提下，还可以对本申请进行若干改进和修饰，这些改进和修饰也落入本申请权利要求的保护范围内。