DAST 黑盒漏洞扫描器 第三篇:无害化

0X01 前言

甲方扫描器其中一个很重要的功能重点,就是无害化,目的是尽量降低业务影响到可接受程度。
做过甲方扫描器,基本上对于反馈都有所熟悉。
“我们的服务有大量报错,请问和你们有关么”
“我们的接口昨晚请求量飙升,这是扫描器造成的么”
扫描,应该尽量无感知。
无害化,是扫描器不同于SAST/IAST的一个难点(当然IAST有部署上的性能问题,偶尔的OOM、过高的资源占用也是大问题),是生存下去的必须考虑的一个点。扫描要有产出、要有效率,而业务侧更注重安全、有无业务影响,尤为重要,毕竟谁也不想业务一出问题先来问问是不是安全部门的扫描器。
业务影响的大体场景分类,个人还是分成针对web接口扫描和主机端口扫描造成的业务影响。

0X02 web接口扫描无害化

2.1 QPS

2.1.1 为什么要控制qps

QPS(Queries-per-second),指扫描器每秒针对业务发出的请求量。

QPS不控制好,很容易随时导致业务反馈,业务经过一番辛苦排查,发现是扫描器,自然会带着情绪进行反馈;更严重者甚至会导致占用过多服务资源,导致影响正常业务(可能升级到事务报告,虽然没收到过)

常见的反馈场景分为几种:
a. 在nginx层的公司级监控中,扫描器发送的请求超过了某个接口设置的QPS阈值
b. 在web框架的监控中,请求QPS超过阈值
c. 业务自行设置的监控中,请求超过阈值
d. 业务接口本身没有超过阈值,但是后端的二次调用或多次调用(RPC或其他http服务)超过了阈值

怎么解决?

2.1.2 聚合方式控制qps的关键点

QPS控制需要确定两个点:
1 聚合方式:通过什么方式把不同的URL聚合到一个key中
为什么需要聚合?我们要控制的是对业务的接口的请求量,而不是我们看到的URL的访问量。

a 同一个path,但是参数不同,大多数情况下还是同一个接口同一个函数在处理;

b 而现在动态参数已经很普遍了,比如百度贴吧的帖子
https://tieba.baidu.com/p/1000000001
最后的十位数字不位于参数,而是位于路径中,后端读取这段路径的值来作为变量,不管数字怎么变都是同一个接口处理。

c 甚至于子域名也可能对应同一个接口
https://bj.meituan.com/meishi/
https://sh.meituan.com/meishi/
长这样多数情况下,不同的城市 北京bj、上海sh、广州gz等,都是对应到同一个美食列表页服务

如果不聚合,针对每个长得一模一样的url设置最低的1的qps,当同时对帖子进行扫描时,即使每个url每秒只发送一个请求,在同一段时间内url数量多时,对这个处理的接口发起的访问量也会变得极大。特别是在业务高峰期(早8点到晚10点业务请求量较大),接口压力本来就挺大,基于流量镜像模式的,接收到的url也很多,再做一次扫描,容易把业务打的叫苦不迭。
所以聚合理论上是将表面不一的url收束在属于它们自己的范围内,当然越接近接口越精准。

2 QPS值:对应的key能使用多少QPS、每秒能发送多少请求
QPS值,取决于这个接口的承接能力、设置报警的阈值。
值设置的高了,容易打爆业务接口;值设置的低了,扫描速率会较慢,流量大时可能消费不完。
最适合的值上限,是业务正常情况下的请求量均值或上限。
有的业务会按照一分钟请求总量来设置告警,一分钟 100-1000,也就对应着 1-17的QPS。平时访问量较低的接口,QPS为1就足以打报警。

2.1.3 不同的实现方式

a 域名聚合
同一个域名或子域名的请求不超过N(5-10)。
一刀切方式,优点是成本低、效果也挺好。
缺点是绝对平等,不管流量大小都使用同一个QPS,流量大时可能扫描不完。
和任务绑定起来适用于扫描任务多但每个任务流量不多的情况,比如多用户多任务的情况。

b 集群聚合
每一个url,根据nginx解析结果,获取url最终归属的业务集群。
结合内部监控数据,获取每个集群实时访问量,计算出每个集群的访问峰值;
使用峰值减去实时访问量(前n分钟),得到空余的可用访问量
缺点:
1 依赖于内部基建的资源
2 同一个集群下的接口,可用的访问量是基于整个集群的。比如A可用300、B可用300、C可用300,集群整体可用900,但A本身承受量只有500。这样就会出现QPS倾斜,访问都打到A,会把A打爆。

c 去重聚合
镜像模式下基本都会有一套去重程序、流量清洗服务,在去重的时候记录下每个key的实时访问量。
用去重的key作为聚合的值,QPS计算的方式和之前一样,计算每个key的峰值,再减去前n分钟(在可控范围内尽可能少)的qps,得到这个key在这一分钟的可用量。
结合路径相似度与页面相似度的去重,去重key接近于接口,效果比较理想。

2.1.4 QPS超限后的限制方式

如果插件最小任务单位已经拆分到请求级别,那么可以将请求任务丢到队列里,根据可用量来读取请求任务运行。
但插件有很多情况需要上下文关联,比如需要第一个请求获取登录凭证token、第二个请求使用该token进行后端RCE等。
这时当扫描规则发送请求时,该请求已经没有可用QPS了,怎么做限制

方法1
直接sleep,等待可用了再发送,但会导致任务hang住、占用节点。资源多无所谓。

方法2
超限后扔回重试队列中
但是下次扫描并不从头开始,而是从中断处开始继续扫描

不进行断点重扫,会有部分插件一定扫描不完,比如有的规则扫描时没有限制,1秒10个请求,无法成功;而QPS控制业务边缘归属于引擎,不应该影响规则本身的检测效果

记录每个扫描任务的每个请求hash (url + header + postBody),给插件分类(有无上下文关键);
对于没有上下文的规则,下次任务已经请求过的hash直接跳过;对于有上下文关联的规则,存储每个hash的返回,重试时已经请求过的hash,直接读取上一次的返回。

2.2 业务错误码报错

业务线会监控服务稳定性可用性,最简单的就是404/504等错误码的每分钟占比。
可用性有的会直接影响到业务的KPI与指标。
这里应该收集每一次的反馈,和内部监控平台沟通谈需求,识别到内部扫描时把这部分请求摘掉;如果是单个业务自身做的报错收集,只能靠他们自己去解决这些问题了。
这里注意扫描时要让业务溯源简单,自定义的header / ua / 出口IP等,否则溯源老半天才发现是内部扫描,业务会更生气。

2.3 脏数据

脏数据是一个无法避开不谈的问题。

镜像模式下,只过滤掉header与post,只扫描get,仍然可能会存在脏数据问题。
get理论上应该是做查询,select操作,但是业务想用来做增删改操作也无可厚非。

get中可能存在用户凭证,业务不把token放在cookie中了,而是放在get参数中、平时保存在localstorage中。这种情况带着get参数值去扫描,等于拿着用户的身份去扫描,有个信息增删改操作,就会导致用户脏数据。
再比如,业务写接口,登录界面获取手机验证码,getCode?phone=xxx&type=1,拿到这条流量进行扫描,在对type进行扫描的时候,重复发送给用户验证码,用户还以为账号是被黑了。
又或者,没有增删改等,只是单纯的查询,但因为带着用户信息,频繁访问,被反扒处置了,用户被封禁了。

方法1 清洗与打标

在2.1中,说过接口;在我们有了所有接口数据后,借用其他安全产品的能力(SAST/IAST),给接口打上标签,判断是增删改或者是查;增删改操作就小心跳过,可避免掉大部分脏数据业务影响情况。再设置参数名黑名单,过滤掉形如phone/token/tele等明显带有用户特性的参数名的值。
这种做法相对安全,覆盖率取决于SAST/IAST的能力,但也会导致这些接口的漏报

方法2 爬虫

通过爬虫,第一篇1.2.4,采用自身测试账号抓取的流量,通常脏数据问题会比较少,因为这些请求都是正常用户可以访问到发出的,也是外部扫描器会收集到的。
用户能访问到的接口,造成脏数据,说明外部的用户也可以造成,特别是外部的白帽子/黑客也会进行扫描。并不是不扫描问题就不存在,只是没暴露。

方法3 影子环境

直接将现有的DB环境、服务环境复制一份,通过nginx层转发扫描请求/压测请求到影子环境,风险极低,但成本极大(成本*2)。
或者单纯的复制DB环境,在数据库连接函数中作hook,把扫描请求的数据库链接改为影子库。但是操作起来很麻烦,开发维护成本较大,多层调用最后再到DB,和最初的请求关联起来判断是不是扫描的就很难。
而且除了常规DB mysql/mongo/redis/MQ/kafka等,还有其他的数据库甚至是本地log等,转了一部分但另一些操作没转,业务数据层方面就不一致了,只能通过反馈不断维护,比较麻烦,不太推荐。

方法4 测试环境

第一篇 1.2.6中,测试环境进行扫描。
把扫描作为一个能力开放给业务线,在业务可控的情况下,可以带cookie扫描、也不需要过滤各种参数,QA在明白风险的情况下进行扫描。
甚至可以进行流量打标,让业务自行选择是否对涉及增删改的接口进行扫描。

PS:
有的收购业务一扫系统就出问题,没有统一测试环境,没有统一上线流程可以获取代码进行接口打标,脆弱至到处都是未授权,这种情况无能为力。

2.4 扫描时间段

有的业务允许扫描,但希望扫描的时间段放在半夜,因为半夜业务访问量较低,出了脏数据或者QPS等问题,影响会比白天高峰期时小,到业务 "开门" 也有一定的缓冲时间。

2.5 限制带宽

虽然都是过滤就可以的,但是和静态文件影响扫描性能不同,这个会造成成本问题。

扫描时可能会遇到下载文件的接口,请求一次后,接口会把几十上百兆的文件内容返回给客户端。这QPS一上来,带宽蹭蹭蹭就起飞了。私有云场景可能是和云服务买带宽套餐,可能是阶梯式收费,也可能是按使用量收费。一旦超量,可能就要多花费个几百万,足以发个严重事故了。

所以流量过滤时,也要过滤掉content-length过长的、content-type属于下载类型的。

0X03 主机端口扫描无害化

3.1 内网HTTP服务报错

内网中有很多HTTP服务,对内网进行框架漏洞扫描时,可能会引起报错,影响与处理方法同2.2

3.2 指纹匹配过滤不符合端口的数据

内网有很多端口服务,端口服务有自己的报错姿势。
有业务自己写的socket服务,但是没有做数据校验,当接收到不符合格式的数据时,抛异常导致进程中断。
这样的业务,其实也算存在DOS漏洞,可以提交安全工单敦促业务修复。

也存在部分常规业务,打个比方,redis协议扫描mysql导致mysql处理时间过长hang住(可能不是这两个服务,时间长忘记了)。
这种可以通过端口指纹方式避免掉,通过给每个端口打上所属服务/框架的标签,规则设置一级指纹(URL/HOST等数据类型)、二级指纹(URL数据的框架、HOST端口的服务/框架),在任务处过滤掉不匹配不对应的,可避免数据不匹配导致的服务报错或者挂掉

3.3 业务方给定指纹

内网可能有RPC框架,接收到不符合端口的数据会报错,但是框架层面无法作数据校验、来直接过滤掉不符合的数据,因为使用方需要这些报错来判断服务是否有异常。也无法在框架层面直接判断来源IP和集群过滤掉扫描请求,这不符合框架的设计。

可以由框架提供探测指纹,端口连接后返回特定数据,标识本身服务。

3.4 限制服务同一时间的链接数

内网扫描出现的比较多的情况,是一个IP端口的服务被链接过多,导致服务异常。

一个要做的是限制同一个 IP+端口 单位的链接数,同一时间只能链接N个。
另一个,可能存在规则socket.connect后,没有close,即使任务关闭,但远程连接方没有收到关闭请求,还在等待接收数据。即使本身已经限制了链接数,还是会打爆。所以规则检测,需要判断connect后是否有close。

PS:
当然还可能会有层出不穷的报错,比如扫描弱口令 比如ssh/mysql/mssql/redis时,引起的大量报错信息与不停告警。遇到过业务方写个了mssql代理,扫描时导致DBA mssql各种报错,但是DBA不知道是哪个机器发送的请求,业务方也不知道自己的代理启动在哪里,只知道有扫描器弱口令规则的paylaod,也无法加白名单。最后把IP写进username里才定位出来。

也可能有内部业务与其他公司有服务对接,在自家内网开了个代理服务器,可映射到其他内网。扫描时检测到各种端口,其实是其他公司的内网各IP与端口。这种情况十分危险,有反馈最好先加白过滤。代理服务器可能链接到其他传统的、脆弱老旧内网,一扫过去可能就挂了,事故报告就来了。

0X04 规则无害化

4.1 场景

规则无害化由上述方式并不能很好控制。
有的友商扫描SMB (MS17-010)等漏洞的时候,没有把控好规则的危害程度...直接上了把业务打蓝屏的规则;
log4J常规payload,链接到dns,会导致log4J等待、hang住,qps过高可能会打挂服务。

4.2 靶场验证

规则扫描线上服务之前,需要设置靶场链接,经过验证后才能上线,不仅是验证规则是否有效,也是验证规则是否会对环境造成影响

4.3 插件审核机制

自动化检测一些常规规范,比如调用socket.connect后是否有close()等

对个人而言,代码得或多或少符合PEP8规范吧,杂乱无章的缩进、不明所以的换行、奇怪的dict有换行没换行交替,实在是看了有些尴尬

再是人工审核,审核时需要审核员(可以是固定资深人员、也可以是自选另外一个同事),迭代更新的规则展示更新的部分。审核主要是依靠经验判断有无不可控的风险。

posted @ 2022-06-14 23:33  huim  阅读(82)  评论(0编辑  收藏  举报