授权公司平台发布
https://mp.weixin.qq.com/s?__biz=MzIzODAwMTYxNQ==&mid=2652140540&idx=1&sn=3d872e0b97a854f5bcb31eaf7540963e&chksm=f320df5cc457564a5760d7807be2048f7420868b6394c149620de900af77caf88d1307806d99&scene=21#wechat_redirect
对于防守方而言，为保护防守方的系统安全，除了收集防守的资产范围及明细内容（域名、IP地址段、端口、服务等）外，如何能先攻击者一步找到资产上的漏洞并进行修复尤为重要，且在寻找过程中不能影响业务实际运行。
而对于攻击方而言，目标资产及其属性是什么不重要，大多的攻击方式仍旧相对简单，即拿着一堆漏洞POC全部发送请求，中了哪个再进行后续的分拣验证提交SRC。
攻防双方的目标差距导致了双方做法的差异，这也就是为了避免对资产上运行的业务造成比较大的压力，各大SRC在规则中基本都明确禁止使用大规模扫描器对目标资产进行扫描。那对于防守方而言，如何定制一个既能扫描漏洞，又不会造成较大压力的漏扫是技术能力建设过程中的一个话题。
注1：漏洞扫描在安全行业内已经是非常成熟的一个产品了，在商业产品领域还是在开源领域都有着非常多优秀的产品，相关的介绍文章、技术白皮书也非常完善，故本篇文章不对这些做更多的介绍，更多的讲解漏扫的原理及如何定制化研发的部分。
注2：对于本篇文章所指的漏洞，主要定位为通用组件，存在高危可被远程利用，且POC至少处于半公开状态，对于非通用系统，及因合规需求（基线、版本号）的漏洞扫描不在包含范围内。
考虑到前言中防守方的需求，我在今年针对此部分做了一些实践，作为其中的POC框架部分，这里由笔者简单给大家做一些分享和介绍，供大家参考。
一、自研or二次开发？
市面上可供选择的商业或开源漏扫非常多，考虑到实际的业务需求，我们最终选择了kunpeng作为二次开发的框架，框架的优点如下：
- 使用go作为开发语言，后期编译制品时，可跨平台跨操作系统通用（适配各操作系统/x86/arm64）
- 除go插件外，支持json插件，对于简单poc可缩小工作量
- 扫描时支持指定资产类型和资产目标，缩小因无用扫描给被测资产带来的压力
项目地址：https://github.com/opensec-cn/kunpeng
注：本篇文章已征得kunpeng框架作者授权
二、使用方法介绍
0x01：使用Python调用
配置部分参考原项目中存在部分，核心调用代码如下：
请注意上图中选中的target部分，可自定义指定target进行扫描是我们选择该poc作为定制化开发框架的一个重要部分，指定target可极大的缩小无用poc对目标资产的扫描，降低被测服务器的压力，根据项目描述，target可以为poc中指定部分，也可以为kunpeng的漏洞ID。
0x02：使用HTTP API调用
示例代码，运行完成后可通过http://127.0.0.1:38080访问（需要被他人访问可监听0.0.0.0，但需要注意该端口默认没有认证！）：
启动HTTP服务器后，有如下3个API可供使用：/api/pluginList -> 获取插件列表（GET）/api/check -> 发起漏洞检测（POST，同步请求）/api/config -> 更新配置（POST）
详细的逻辑可以在web/api.go中查询，参数内容与使用Python调用大同小异，有需要增加认证或其他功能的也可在此文件中定制：
三、定制化部分
Kunpeng项目是非常优秀的一个poc框架，基本使用已不成问题，但考虑到落地中的实际场景和需求，原先的功能与我们的需求存在一定的差异性，我们选择对原框架进行一定的修改。
0x01: 对辅助验证接口进行定制修改
辅助接口通常针对无法回显的POC漏洞进行验证，例如常见的有fastjson、cas 反序列化漏洞等。
原项目中，Kunpeng的辅助接口使用的是http协议，具体配置可在项目的使用方法中找到，为aider配置字段，将相关代码进行格式化及base64 decode后可得正文内容如下：
使用辅助接口的POC操作方式如下（plugin/go/weblogicWLSRCE.go）：
使用此种方式进行辅助验证存在一个前提条件：被验证的机器及POC框架均须可使用HTTP方式访问部署辅助接口的服务器，操作的流程图如下：
而在现实生产网环境中，大多的被测服务器是被禁止访问外网的，导致使用此架构存在如下的困难：
1. 如果被测环境在不同的网络域（生产/测试），那么需要在不同的网络域部署aider，poc也随之需要跟着变动
2. 如果被测环境禁止访问外部服务器，那么此方式会导致漏检
为了解决此问题，我们对原项目进行了修改，新增支持了dnslog.cn和ceye.io的支持：
我们在config/config.go的结构体内新定义了两个变量，用于支持配置dnslog类型和token：
考虑新增的部分尽量不影响原POC，基于上面定义的aider_type对于 aider的生成和判断，默认使用项目原模式。
注：ceye.io原生自带api及token，但需要用户注册和登录，dnslog.cn无需登录，通过session区分用户，在编写相关代码时需要注意区分及保持前后一致。
同时，对于dnslog而言，无法使用add和check的方式在URL后端拼接提供给漏扫检查，我们需要对原POC进行适当的修改，将randstr拼接在URL的前面，形成子域名的模式进行检查：
此时无回显漏洞的验证方式变成了如下的方式：
相比于原模式，此方式适配性更广，服务器无法访问外部HTTP服务器的情况可绕道使用dns方式进行验证，但仍存在有如下两种情况导致误报：
1. 被测资产未配置dns，无法请求域名
2. 网络波动或抖动引起的漏报
故在实际操作过程中，建议大家根据实际情况合理选择反连平台及操作方式和模式。
0x02：对json插件的逻辑进行定制修改
项目中原json插件的逻辑仅支持一次交互逻辑，即发起一次请求获得结果，并进行验证，其余逻辑均需要编写go插件。考虑到多次交互的漏洞验证场景趋多，我们对此部分逻辑进行修改，扩充支持组漏洞验证模式。
在plugin/json.go中，对json plugin的结构体进行扩充，支持添加组漏洞条件（and/or）：
默认情况下的json插件均不需要修改，需要用到的漏洞poc可写成如下模式（条件为or，groups中任意一组成立则poc验证为真）：
0x03：对http请求返回进行修改
原项目中封装net/http包对目标地址发起http请求，但未考虑http中重定向设置部分，默认情况下会跟随http的response返回自动跟踪重定向，这样会导致部分漏洞需要从重定向报文中取数据或检测重定向漏洞时判断失败：
但因为go不支持默认参数传参，我们重新设计函数并对原函数内容提取了重新包裹，确认在不影响原功能情况下新增自定义重定向功能：
此时原POC均不需要进行修改，对于需要定义重定向功能的POC而言，选择新的函数即可：
本篇文章基于我们定制化漏扫的POC框架做了一部分分享，关于资产扫描及漏扫中其他功能的定制化（例如与SOAR联动抑制误报、系统上线或日常运营逻辑建设等）受限于篇幅暂未分享，挖个坑后续更新。
发表回复