在“没有人的安全部”构筑护网防御工事(4)——漏洞修补

第四部分 漏洞修补

1 概述(what)

1.1 含义

任何系统都存在各种各样的漏洞,广义的漏洞是指任何可以引起系统的功能、数据、配置、设计等被破坏的交互点,这里可以包括一些不安全的配置、业务逻辑等,而这一章节的漏洞,是指应用、组件、基础软件自身的代码漏洞,这些漏洞可以通过修改代码、安装补丁等方式进行修复。

近些年来随着三方应用、开源组件越来越丰富和广泛被使用,一些重大的代码安全漏洞也通过这些组件被引入到组织的信息系统当中。而漏洞利用,仍然是攻击者入侵的最核心得分手段。

1.2 原理

漏洞修补的过程相对简单,主要步骤分为四步:1.发现漏洞 2.修复漏洞 3.验证效果 4.风险规避。

发现漏洞是指,通过已知信息推理系统可能存在的漏洞或通过具有特定特征的交互请求获得目标的响应,以判定系统是否存在漏洞。翻译成人话,一种是白盒,就是通过已知的软件名称、三方库、版本信息等数据,通过在公开漏洞库中检索,已获得系统可能存在的漏洞信息;另一种是黑盒,就是通过扫描器等漏洞发现工具,在假设系统是黑盒的情况使用枚举的手段探测和推测系统可能存在的漏洞。

修复漏洞是指,通过修改漏洞形成的机制或逻辑,使破坏系统的交互行为无法进行。通常修复漏洞需要修改代码,如果使用三方产品则需要升级版本或安装补丁包。

验证效果是指,模拟漏洞利用的手段,对漏洞利用的过程进行尝试复现,如果没有出现漏洞被成功利用,或者返回具有漏洞存在的特征的响应结果,那么代表漏洞修复成功。漏洞验证具有一定的技术能力要求,对于技术储备不足的组织来说,可以根据能力所及的水平,选择性的进行。

风险规避是指,在漏洞修复过程中,往往会存在一些客观原因,某些漏洞无法被修复(例如稳定性风险的考虑),此时需要通过其他方式让漏洞无法被利用,简而言之最简单的做法就是网络隔离或者将系统下线。

1.3 原则

  1. 有效原则。通过各种手段发发现的系统漏洞数量之多往往超过管理员的预期,而且大量漏洞甚至看不懂什么意思。此时需要对漏洞进行分拣,有必要修复的漏洞务必要修复,没有必要修复的漏洞直接忽略即可。

  2. 暴露面优先原则。从整体架构的角度,如果能够缩小风险暴露面,优先选择缩小暴露面,而后再考虑通过修复的方式处理漏洞。

  3. 完全原则。很多漏洞修复的时候只处理某种验证或利用方式造成的后果,而没有从根本上解决问题,另一些时候,一些三方组件提供的补丁包存在被绕过的情况,面对这种问题需要充分考虑漏洞形成的机制和原理,从根源上将漏洞封堵,而不只是防止某一种利用方式。如果是三方组件,则需要安装到最新版本,并注意是否有补丁被绕过的情况。

  4. 稳定原则。不是所有的漏洞都能已简单的方案修复,漏洞修复往往伴随着系统的变更,而系统的变更又可能产生风险。尤其是在操作系统层面,安装漏洞修复补丁可能引起补丁功能与其他组件甚至操作系统自身的不兼容,因此漏洞修复要秉承稳定性优先的原则,通过充分测试、充分灰度验证的方案降低稳定性风险。

2 目的(why)

漏洞是攻击者为获得系统权限而选择的核心攻击对象之一,攻击者通过利用漏洞,可以达到获得系统权限的目的,从而获得分数,或者进一步向内渗透。漏洞修补不仅是一个技术问题,也是一个治理问题,因此漏洞修补不一定在单点上追求极致的修复效果,但在整体上要尽可能做到充分的覆盖,以尽可能减少漏洞被利用成功的宏观概率。另一方面,对于系统的关键组件的关键功能(例如身份认证、权限管理),要确保漏洞修复的效果,避免单点脆弱性造成重大风险。

3 方案(how)

1.暴露面分析

漏洞修补需求确定漏洞产生的范围,因为全局的漏洞100%完成修复是一项极其艰难和工程浩大的工作,短期之内无法完成,同时亦无必要。因此,在制定漏洞修补计划时要对系统的暴露面有所了解,并且在完成第一章节提到的网络隔离后,将系统的风险暴露面进一步缩小,在此基础上对必须暴露的风险点、线、面收集漏洞信息,并完成修复。

2.漏洞扫描

漏洞扫描是发现漏洞的主要手段,对于缺少安全技术运营能力的团队,也可以使用漏洞扫描工具进行扫描。漏洞扫描器的检出率和准确率是其主要的性能评价指标。检出率是指在测试条件下,漏洞的检出数量与已知的全部漏洞数量的百分比;准确率是指对于扫描出的结果,有效的漏洞占全部检出漏洞的百分比。选择一个检测性能良好的扫描工具,对于提升漏洞修补工作的质量非常关键,但是在扫描技术没有代际差异的同一时期的产品面前,扫描器的检出率和准确率往往反向相关,也就是说除非扫描器技术有了进步,否则漏洞的检出率相对高的时候,准确率会降低,反之亦然。当然这是理论上的相对效果,近些年各厂商在扫描器上的持续提升使得这个产品的检测结果已经非常友好,而不像十年前的漏扫工具,扫描的结果几乎无法直接使用。

漏洞扫描工具的检测结果报告往往包含着对漏洞的修复建议,使用者需要通过分析自身情况决定使用何种修复方案。

3.版本管理

三方组件的版本管理是主动发现漏洞的途径之一,相比漏洞扫描,三方组件的版本管理能够更直接有效的定位到漏洞极其影响范围。系统管理员应该对系统环境(尤其是生产环境)建立三方组件引入、使用、记录的流程,这些组件应该包括任何非自研的开源或商业化的软件或组件,包括但不限于操作系统、数据库、中间件、开源应用框架、开源工具软件、开源代码编码语言、运行环境和三方库等。系统管理员可以建立内部的软件仓库或者linux软件、代码三方库源提供下载,下载的日志整经过解析后存储在数据库中,作为内部的资产库。

如果由于缺少早期的基础设施导致无法跟踪和记录上述信息,那么可以登录到主机采集相关的软件信息。如果软件都是通过仓库安装的,那么收集到这些信息并不困难,但是如果通过源码编译的软件则很难收集完整。因此在系统环境中应该严格禁止通过源码编译的方式安装程序。

完成软件信息收集后,则可以根据厂商发布的漏洞补丁信息升级到最新的版本。对于使用量比较小的软件则可以使用爬虫软件从CVE等标准漏洞库检索组件相关的漏洞信息。

4.自研的应用漏洞

信息系统的自研应用漏洞的发现对于缺少专业安全团队的组织来说是比较困难的。而形成漏洞的原因五花八门,因此修复的手段也是不尽相同。这里我们总结在护网中容易造成丢分的代码层面漏洞的几种问题的防范措施。

(1)不信任一切用户输入

常见的应用层漏洞如SQL注入、XSS、命令注入等漏洞都是由于过分信任用户输入而形成的。这类漏洞的一个特点是用户输入可以被当做代码执行,而功能的开发人员没有意识到用户可能构造特殊的输入信息将文本组合、拼装、转换成可执行代码,从而按照攻击者的意图控制服务端的逻辑。

对这类漏洞的防范方案是对一切用户输入进行过滤,杜绝或降低用户输入构造成代码的可能性,例如对><\/;’,等特殊字符进行转换(如果对这类基础知识不够了解,可以自行搜索)。如果某个输入点的内容类型是特定的,则可以以白名单的方式限制用户输入,例如只允许输入数字、字母、下划线或者横杠等。

(2)确认用户的身份和权限

对于业务逻辑层面而言,权限漏洞是较为常见的一类漏洞,例如水平越权、垂直越权。这类漏洞的特点是功能与用户数据关联,而用户的身份由由来自用户输入的参数决定,而这个参数容易预测,例如根据用户uid更改用户昵称。假如传入参数的uid被修改为他人uid,那么他人的昵称则会在非本人操作的情况下呗篡改。另一种情况是用户执行某个本身不具备权限的操作,但是由于没有对用户身份和权限进行严格验证,则出现了可以被成功访问的结果。上述第一种情况称作水平越权,第二种情况称为垂直越权。

对这类漏洞的处理办法是每次操作前验证当下的用户身份,身份标签具有不易被猜测的特点(例如用sessionID关联用户ID),同时在每次操作先验证用户是否具有响应的权限。

(3)禁止无限提交

对于攻击者,利用身份劫持获得系统权限也是一种常见的突破方式。利用弱口令暴力破解、密码重置漏洞可以有一定概率劫持普通用户或管理员的身份。此类漏洞有一些存在验证码过短、有效期过长(有时甚至不会设置过期时间)等问题。攻击者可以通过暴力破解的方式获得正确的登录密码或验证码。

对于这类漏洞,最好的解决方法是限制同一个账号、IP等主体的提交次数,一旦超过限制的上限,便锁定会话或中止流程。此外,如果有参数过短的问题,请加固参数,如果有参数可预测的问题,请随机化参数,如果有时间窗口过长的问题,请缩短有效期。

5.临时下线应用

对于不能修复的漏洞或系统重要性较低,可以临时下线应用系统,避免被攻击队攻击。从暴露面优先原则来看,临时下线应用也是一种高效的修复方案。

6.接入WAF

WAF对于大多数扫描器行为也有很好的防护效果,由于攻击者发现漏洞也会依赖扫描器,因此使用WAF相当于一种对漏洞的通用修复手段。尽管WAF有一定概率被绕过,但仍不失为一种有效的漏洞修补的替代手段。尤其是接入云WAF,云端的安全工程师可以在护网时期实时观测攻击队行为并及时响应,防护效率大大提高。

4 需要注意的一些问题

漏洞修补的周期较长,从制定计划、发现问题、实施变更到最终验证,整个过程会遇到方方面面的细节问题,导致计划进度受阻。当变更遇到预期较大差异时,还可能引发故障,从而不得不执行回滚计划,项目的推进信心也会大大受阻。因此要及早启动漏洞修复计划,通常三个月时间是至少的。

漏洞修复也会带来来自业务方的阻力,尤其是当漏洞的危害风险不能被准确描述或验证的时候,业务部门为了稳定性或者其他原因或习惯性的倾向于采取保守的工作策略。因此漏洞修补一方面需要做好沟通,统一认识,另一方面也需要拉高管下台背书,大树底下好乘凉。


Author | Mushen

THE QUIETER YOU BECOME, THE MORE YOU ARE ABLE TO HEAR. 安全运营搞了十多年,现在在阿里云做安全架构和SDL。