Jar 组件自动化风险监测和升级实践

曾兆祜

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 调度示意图： Jar 组件资产收集插件的主要实现思路如下：

查找 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 获取以及信息
根据 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

SOAR 全称 Security Orchestration, Automation and Response，即安全编排自动化与响应，该技术主要聚焦于安全运营领域。Qunar 安全组基于 StackStorm 工作流引擎二次开发打造了 SOAR 项目，安全组件和剧本通过 python 和 yaml 实现。在 Jar 组件自动化风险监测和升级场景中流程如下图所示：从工作流流程图，我们可以看出：

① 安全通告监控服务发出预警信息后，需要人工干预。安全运营人员会研判是否启动升级流程，如果是，则填写配置漏洞信息，启动升级流程；否则，忽略该告警信息

② 启动升级流程后，首先需要关联信息生成受影响资产清单 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%）

总结

以上就是 Jar 组件自动化风险监测和升级实践中涉及的方方面面。整体流程还有优化提升的空间，比如在漏洞评估和 TCDEV 自动升级服务还需要人工介入等。另外，TCDEV 自动升级服务价值极大，由于资料较少，没有触及原理实现，希望基础架构的同学可以写一篇文章介绍一下。由于水平有限，文章多有纰漏不足，也恳请大家指正。