写点什么

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

发布于: 2021 年 07 月 23 日
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 获取 <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

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 自动升级服务价值极大,由于资料较少,没有触及原理实现,希望基础架构的同学可以写一篇文章介绍一下。

由于水平有限,文章多有纰漏不足,也恳请大家指正。


发布于: 2021 年 07 月 23 日阅读数: 502
用户头像

还未添加个人签名 2020.11.28 加入

还未添加个人简介

评论

发布
暂无评论
Jar 组件自动化风险监测和升级实践