这个问题在某些漏洞之中可能非常常见。有的时候通过漏洞返回的页面信息非常丰富,我们能够从中选取非常多的信息填写到我们的条件表达式中;但是有时候有的漏洞返回的内容却寥寥无几,可能还是不相关的其他信息。这些情况无论是在漏洞审核还是漏洞编写中都是棘手的存在
对于反连平台的匹配内容这里不做说明,只要明确了漏洞只能通过反连平台进行检测,且能够写出相关的利用方式,那么我们直接使用反连平台进行匹配即可,基本不会出现漏报和误报的现象
同时关于常见的概念,这里暂且定义为一般在网站中会经常出现的内容。这些内容在系统的开发过程中被广泛使用
这个问题在现在的审核方式中,一般会按照以下的内容进行判断
常见
的匹配内容,例如user,passwd等常见字符串。但是如果这些内容是漏洞的一部分,可以保留,但是一定要增加匹配站点中其他的信息随机化的问题在poc的编写过程中一直存在,有的时候我们能随心所欲地给各种我们想验证的内容给出随机的内容,但有的时候因为系统的各种限制,导致我们不是很方便地写出随机化的内容
一般来说,我们设置随机化的内容是为了达成以下的目的:
所以这里需要明确的就是,在能够找到随机化的利用方法时,一定一定
要按照规范去编写poc的内容,这样我们才能够认为这是一个较高质量的poc,反之可以直接pass
同时对于那些写不出来随机化内容的poc,现在大概有两种处理方法
综上,随机化也许并不是必须的,但是一定是需要我们在不同系统中寻求匹配方法时时刻注意的
首先比较下两者的优缺点
方法 | 优点 | 缺点 |
---|---|---|
使用网页特征匹配 | 简单便捷,发包量低,基本只要发一个包就能确定是不是漏洞版本 | 可能会因为实际的网络环境,难以对漏洞进行利用,或者在一些特征变更不明显的系统中,发生误报的问题 |
使用实际利用方法 | 准确,只要验证成功且匹配规则无问题,就能够说明目标系统绝大多数情况下都是存在漏洞的 | 相比特征匹配来说,可能需要寻求更加严谨的利用方式,且返回的结果可能会受安全设备的影响 |
两种各有千秋,并不好直接说某一种就是我们的最优解,这是需要我们依据漏洞的类型与利用的难易程度进行衡量,选择对于当前漏洞的最优解,达到尽可能地减少发包量,同时尽可能地减少误报程度
的目的。当然这些内容并不是强求的
但是依据以往情况下审核过后的结果,我们大致可以分为这么几种情况
此种情况最为简单,即然能够验证漏洞,且漏洞无危害,那么直接使用漏洞原理显然是最为稳妥的方式。只要expression编写恰当,就能形成一个相对节省资源且稳定的poc
和上边一种情况类似,我们也可以选择使用原理去进行检查。但是这种情况下,如果能够确认我们所寻找出的是唯一的,是能够取缔掉后边的原理检查的,那么我们也可以使用这些内容去直接匹配
这种情况和上一种情况相似,参考上一种情况的要求写出特征内容的匹配即可
这种情况下首先推荐保留现有的内容,直接挂起,等待xray2.0发布完整的go插件系统后,再用完整的语言内容去进行实现
那么这种情况下,直接使用原理去验证貌似并不是我们的最优解。这种情况下,我们就需要尝试去寻找网页特征(版本或者其他信息)以及指纹去侧方位地去验证目标系统是可能存在漏洞的
但是这里我们就要求寻找的特征一定是漏洞发生时才能够存在的,例如
例如这个poc的内容就符合上述内容中情况3,也就是有有利用方式,但是能够使用非常明显的特征去进行匹配。而且后边所匹配的cntForm等内容覆盖了现有框架内能出现的所有情况,同时这些内容也是只有漏洞版本所会出现的
那么通过上边的判断,我们可以认为这个poc的内容是可以取代实际的原理去验证漏洞的存在的
首先对于这个问题,这里的回答是不能。对于这个问题大概有以下的解答
虽然说我们并不收取拥有固定用户认证凭证的内容,但是以下几种情况仍然在我们的收录范围之内
从现在poc的提交情况来看处于内网,不能访问外部环境的poc基本没有,但是我们仍然需要考虑这种情况的存在,毕竟在扫描的过程中这种情况也是非常常见的
那么按照现在的经验,这里大概可以分为三个步骤去进行排查
目标不出网,但是漏洞是有回显的,能展示各种漏洞下的执行结果 那这个情况属于是最为简单的情况,我们只需要正常写出poc内容匹配漏洞产生的结果即可
目标不出网,同时漏洞无回显,但是我们能够通过发生漏洞时的某一种特征去进行匹配 那虽然要多加注意,但是这里也是非常鼓励将无回显的漏洞转换为有特征输出的漏洞去进行匹配,在一定程度上平衡漏洞检出和漏洞误报之间的关系
目标不出网,且发生漏洞时目标站点返回的信息极为简单,基本没有有效信息的时候 那么如果到了这个阶段,我们才能够考虑使用相关的版本特征等去进行匹配,尽可能地锁紧条件,减少误报的几率