Jar 组件自动化风险监测和升级实践
点击蓝字|关注我们
Qunar技术沙龙
曾兆祜
2018年5月加入去哪儿网,现负责基础安全攻防平台的开发建设以及日常的安全运营工作
背景
以 Xstream、Jackson、Fasjson 等为代表的 Jar 组件高危漏洞层出不穷,安全组每年 N 次推动业务线进行第三方 Jar 组件升级,每次升级动辄涉及成百上千个应用服务,给双方都带来了沉重的负担。为了降低安全组在 Jar 组件升级期间的工作量,同时尽量给业务线减负,Qunar 安全组在 Jar 组件自动化风险监测和升级上进行了大量实践,并总结形成了一套相对完善的解决方案。本主主要聊一下 Qunar 安全组在 Jar 组件自动化风险监测和升级方面的探索和实践。
流程介绍
Jar 组件风险监测和升级本质是由风险情报驱动的一个工作流,主要包括外部安全通告监控、Jar 组件资产收集、受影响资产分析、通知业务线升级等流程。在之前一段时期,Jar 组件漏洞升级依靠安全运营人员人工的方式来串联每个流程,这样效率低下,甚至容易出错。随着 SOAR(安全编排自动化与响应)近年来的备受关注,Qunar 安全组也在 SOAR 项目上进行了建设,依托 SOAR 对事件的整合和安全服务串联能力,我们针对 Jar 组件风险监测和升级场景进行了合理编排,达到了自动化的效果,极大提升了安全运营效率。除此之外基础架构的同事,提供了 TCDEV 自动升级服务,为业务线升级操作提供了极大便利。事件流程如下图所示:技术实现
本部分主要介绍 SOAR 串联的每部分安全工具、服务的技术实现。1. 安全通告监控
安全运营人员第一时间获取漏洞通告,对漏洞的评估研判、迅速响应和有序推动至关重要。早在19年,安全组借助应届生项目,实现了“安全漏洞智能感知系统”。系统主要功能为:CVE、CNVD 以及知名厂商漏洞风险告警抓取
漏洞信息去重整合
对存在 POC 的漏洞抓取 POC
漏洞信息模糊匹配关联 Jar 组件资产库(SecDB),IM 预警安全运营人员
该系统关键点在于会通过模糊匹配的方式关联 Jar 组件资产库,关联到资产后 IM 发送预警信息给安全运营人员,进行进一步的风险评估以及后续的 Jar 组件升级流程。系统流程图如下:
漏洞感知平台,以 Xstream 为例抓取效果图:
2. Jar 资产收集
安全资产收集是安全运营的必备基础能力之一,Qunar 安全组历来都把资产收集做到了业内最好的水准。当前我们采用以 HIDS 为主要平台,通过在 Agent 端调度资产收集插件的方式,高效的对主机的资产进行定时、实时的采集。Agent 调度示意图:查找 cataline.base 列表
items=$(ps aux | grep catalina.base | grep -v grep)
获取 catalina.home、catalina.base 等路径信息
catalina_home=$(echo "$item" | tr ' ' '\n' | grep catalina.home | cut -d= -f2 | sort | uniq)
catalina_base=$(echo "$item" | tr ' ' '\n' | grep catalina.base | cut -d= -f2 | sort | uniq)
根据 server.xml 获取 <Host> 以及 <Context> 信息
根据 appBase 或者 docBase 定位 WEB-INF/lib 路径
枚举 WEB-INF/lib 路径下 Jar 包,提取每个 Jar 包的 pom.properties 信息,这样就可以进行资产收集了,例如:
jar_version=$(echo "$pom_properties" | grep -m 1 -E '^version=' | awk -F'=' '{print $NF}' | tr -d '\n\r')
jar_groupid=$(echo "$pom_properties" | grep -m 1 -E '^groupId=' | awk -F'=' '{print $NF}' | tr -d '\n\r')
jar_artifactid=$(echo "$pom_properties" | grep -m 1 -E '^artifactId=' | awk -F'=' '{print $NF}' | tr -d '\n\r')
通过以上手段的就可以获取主机上存活 Java 项目依赖的 Jar 包信息,一旦爆发漏洞根据以上信息,关联应用以及 Owner 快速响应。以 Xstream 为例,收集的资产信息如下:3. SOAR
① 安全通告监控服务发出预警信息后,需要人工干预。安全运营人员会研判是否启动升级流程,如果是,则填写配置漏洞信息,启动升级流程;否则,忽略该告警信息② 启动升级流程后,首先需要关联信息生成受影响资产清单
a) 资产列表生成:根据配置的版本信息进行逻辑过滤,生成受影响资产的列表,同时标记内外网,以执行不同的优先级策略
b) 关联 Appcode:通过 Portal API 获取受影响主机对应的 Appcode
c) 关联 Owner:通过 Portal API 获取受影响主机对应的 Owner
d) 关联技术 TL:通过 ISAPI 员工信息关联 Owner 的技术 TL(技术 TL 充当安全对接人的角色,执行自上而下的漏洞升级推动工作)③ 接下来会将资产清单提供给 tcdev,tcdev 会接管可自动化升级的应用,剩余部分继续由安全负责通知业务线技术 TL 升级
Xstream 漏洞升级示例,配置漏洞信息,启动自动关联信息升级通知流程:
Xstream 安全通知示例,通过内部 IM 通知技术 TL 执行升级任务:
4. TCDEV 自动升级服务
一般的公司,将风险事件通知负责人后整个事件流程就结束了,然后执行周期性的通知升级。但是在 Qunar 内部,基于 TCDEV 开发的自动升级服务,可以极大解放业务线的风险组件升级压力。TCDEV 自动升级服务可以帮助业务线自动进行 Jar 组件升级,当前 50% 的应用可以自动化升级, 30% 的应用可以通过 TCDEV 提供的一键升级服务进行一键升级(需业务线开发评估风险),另外 20% 应用执行安全组传统的升级策略。TCDEV 自动升级详情如下:
应用已经升级 tcdev 4.x,且已接入灭霸自动化测试的应用,tcdev 接管升级,届时会联系业务确认(应用占比 50%)
应用已升级 tcdev 4.x,但自动化测试未覆盖的应用,可在 portal 上点击 “tcbom升级” 快速完成(应用占比30%)
尚未升级 tcdev 4.x 的应用,建议手动升级 tcdev 至 4.0.x (应用占比20%)
总结