核弹级漏洞炸翻安全圈，想安心过年就靠它了

“最近Log4J中爆出的一个风险较大的安全漏洞，很多客户给予了前所未有的重视。车库创新(Client Engineering) GCG团队，急客户之所急，从产品的全生命周期出发，提出的一套防漏补缺的组合拳，可消除风险于无形。车库创新团队立足于市场最前沿，和客户肩并肩，梳理痛点，共创方案，迅速验证，并以此为契机，全面赋能客户创新实践与数字化转型。”

— 鱼栋

即使你并非身处安全圈，最近也可能频繁看到Log4Shell这个词。很多媒体将其描述为“让互联网着火”“危机数百万Java应用”“过去十年最严重的漏洞”。

什么是Log4Shell

2021 注定是不平凡的一年，有机遇也有挑战，我们在挑战中蜕变，在蜕变中前行。时至岁末，IT界爆出了一个“核弹级”的漏洞: Log4Shell，至今已有一个多月，其影响依然在持续发酵，相关联的新漏洞也接连出现，很多企业给予前所未有的重视，给 IT 界带来了巨大的冲击。

何为Log4Shell? 简而言之，Log4Shell是Java日志框架log4j支持的Lookup JNDI(JAVA命名和目录接口)造成的漏洞。此JNDI支持LDAP数据源，可以通过LDAP, 根据用户指定的Key来获取相应的内容（数据或者对象），如果获取的内容是从第三方的服务器下载的Java对象（此对象可能具有破坏性），那么在加载这个Java对象并执行代码时，可能对应用程序造成不可估量的破坏。因为log4j应用广泛，涉及面广，一时之间，激起了千层浪。

Log4Shell全周期防补一体化

IBM作为安全领域的领军者，一直以来，视用户应用和数据安全为生命。作为一线团队IBM Client Engineering，从产品的全生命周期出发，提出了防漏补缺的一套组合拳，可使此漏洞风险消除于无形。

如下图所示，下文分别从产品研发到上线应用全生命周期：开发、部署、使用和维护三个阶段进行了探讨，从漏洞的预防、探测、管理和响应四个方面着手，对用户的应用程序全方位保驾护航。

组合拳之一：Instana和QRadar双剑合璧

Instana是现代化的应用性能管理工具，在亚秒级的链路追踪和非采样不丢失任何链路请求方面有着绝对的领导地位，而Log4Shell正是由发起API请求配合log4j的JNDI:LDAP 漏洞达到攻击的目的，这也是Instana可以发现该漏洞攻击的天然优势。

同时，QRadar能够提供快速而精准的态势感知，检测企业内部和云环境中的威胁并评估其安全风险，并提供快速展开调查所需的实时分析与管理。所以Instana和QRadar的结合可以对用户安全起到更加全面的评估和响应。

Log4Shell漏洞攻击剖析

为了清晰化Instana发现Log4Shell漏洞攻击的原理及方法，我们进行了Log4Shell漏洞模拟攻击实验，得出了如下两条结论：

• Instana可以实时发现服务被Log4Shell漏洞发起的任何攻击。
• Instana可以发现含有Log4Shell漏洞的应用/服务。

这个结论是如何得出来的呢？首先，让我们通过下图来回顾如何通过Log4Shell的漏洞发起攻击的。

从上面的流程，我们可以看出，应用需要同时满足以下几个条件，才可能被攻击，否则该漏洞将对系统不构成威胁：

• Java 应用
• 使用了log4j (版本<2.15)，且lookup 功能为打开状态
• Logger打印变量包含外部请求变量
• Instana和QRadar对漏洞攻击的监控和响应

如下图，如果该漏洞被利用而受到攻击，我们可以轻易从Instana界面或者Trace Data 获取到相关攻击数据和信息。

另外，我们开发出了一个脚本，它可以通过Instana API 拿到Trace Data, 实时分析并且告警当前系统有无受到攻击，也可以告知用户当前系统是否有Log4Shell 漏洞， 运行结果展示如下：

QRadar 可以监控接入服务的网络流量和日志。也可以通过接入第三方的漏洞扫描结果从而更具体的发现相关漏洞。所以QRadar也同样可以通过Instana API拿到相应的Trace Data， 指定相应的规则实时监控是否有人正在利用漏洞对我们的系统进行攻击，指定相关脚本，对漏洞或者攻击做出相应举措。同时可以Qradar SOAR安全编排自动化响应，来对漏洞做出自动而及时的补救措施。

组合拳之二：PAAS保驾护航之RHACS

RHACS（Red Hat Advanced Cluster Security）是企业级的 Kubernetes 原生容器安全防护解决方案，可帮助用户更安全地构建、部署和运行云原生应用，能让用户及时洞察基于OpenShift 环境的关键漏洞和威胁。RHACS 默认配备了多种部署时和运行时策略，能有效防止有风险的工作负载部署或运行。同时，RHACS 可以监控、收集和评估系统级事件，如作业执行、网络连接和网络流，以及 Kubernetes 环境中每个容器内的权限提升等，并及时洞察问题，并根据既定规则判断出危险的级别。

RHACS漏洞管理功能非常全面，可以在整个软件开发生命周期中，识别并修复容器镜像和 Kubernetes 的漏洞。如下图中，RHACS在应用镜像中识别出了Log4Shell漏洞，并标记为Critical级别。

同时，RHACS具有强悍的检测和响应能力，可以使用规则、允许列表和基线来识别可疑活动，并采取行动阻止攻击，强化用户的 Kubernetes 环境和工作负载，确保应用更安全和更稳定。如下图，我们定义了一个系统规则来识别Log4Shell漏洞。

当此规则被激活之后，用户创建的应用容器如果有Log4Shell的漏洞，就会被拦截。从如下错误提示信息中，可以看出，由于容器镜像包含了Log4Shell的漏洞，同时在RHACS的Violations界面，我们可以看到阻止应用创建的事件。

组合拳之三：DevSecOps防漏于未然

DevSecOps是开发、安全性和运维的缩写，从初始设计到集成、测试、部署和软件交付，在软件开发生命周期的每个阶段自动化的集成安全检查功能。DevSecOps通过主动改进安全措施，加速安全漏洞修补，快速、高效的软件交付，可以防漏洞于未然。

在以下实践中，DevSecOps在现有CI/CD Pipeline中为开发人员提供自动化安全防护，提供持续的镜像扫描和保障。镜像构建之后，需要对镜像进行扫描来检查漏洞，如果有Critical的漏洞，在部署之前，需要先对漏洞进行修复。

如下图中的镜像扫描日志中，我们可以看出由于检测到了Log4Shell的漏洞，所以导致此步骤检测失败。

同时，在CD阶段，我们基于开源的Starboard，开发了一个扫描用户运行容器漏洞的工具：Starboard Report。当容器创建或者升级的时候，Starboard Report就会自动的探测器漏洞，并实时的展示给用户，如下。

点击其中的一个运行容器的报告，就可以看到漏洞扫描的详细信息，如下所示。

组合拳之四：Hot Mitigation（热舒缓）补漏趁天晴

Log4Shell 漏洞爆发以后，开源社区给予了极大的关注，在短时间内就有大量的开源项目不断的涌现出来，有讲如何探测该漏洞的，有讲如何Hot Mitigation(热舒缓)的，有描述漏洞原理的等等，不一而足，完美的体现出开源社区的强大力量和快速响应。下图是在Github上以star数排名关于log4shell的Repositories， 相当惊人。

本节会介绍一种在开源社区中较为有代表性的Hot Mitigation的方式。该方式有两个优点：

•因为官方正式补丁包发布是需要时间和验证的，在这段时间内漏洞是毫无防护的，除非关停服务，该Hot Mitigation可以有效解决这一点。

•其他Mitigation方式，如修改JVM参数，都需要重启JVM，造成了停机时间，但本文介绍的这种方式不需要重启JVM，就避免了停机时间。

在开始之前，让我们回顾一下Log4Shell漏洞的原理：

“org/apache/logging/log4j/core/lookup/JndiLookup” 这个Java类的“lookup”方法会在非法的服务器上下载恶意代码，这样一次攻击就达成了。一个显而易见的想法是，如果把原本的“lookup”方法篡改掉，比如让“lookup”固定的返回字符串：“Patched JndiLookup::lookup()”不就避免了漏洞吗？这恰恰就是这种Mitigation的原理，更难能可贵的是这一切都是在无需重启JVM的情况下做到的，并且无论是本地程序还是Kubernetes下的Container都能搞定。

我们的工作是， 首先使用了开源社区所贡献的，用于Hot Mitigation的Java Jars，然后辅以Kubernetes的DaemonSet，ClusterRole等，和相应的脚本，让它能够很完美的在Kubernetes环境中工作。

简单描述工作原理，安装以后（DaemonSet），在每个Kubernetes Node上会启动一个进程去探测该Node上所有的Java进程（JVM），一旦发现，会尝试注入一个Java Agent到该JVM，并且尝试去篡改所有JndiLookup。实例的Lookup方法，让该方法只是返回一个固定的字符串Patched JndiLookup::lookup()， 如下图所示：

为了验证改方案的结果，我们准备了三个实验对象：本地Java应用程序，不包含有漏洞版本的Log4J库，Hot Mitigation后Log呈现如下：

因为该Java程序中并未包含log4j库，所以被告知并未发现相应的漏洞。

本地Java应用程序， 包含有漏洞的log4j版本：

发现了漏洞，并patch，符合我们的预期。运行在Kubernetes Pod中的Java 程序，并未包含相应的log4j库， 所得与第一个对象相同。

最终，在DeamonSet相关的Pod日志中，我们能看一下信息：

这样，就实现了在升级官方发布的补丁包之前并且避免的停机时间的Hot Mitigation。

结语：未雨绸缪早当先，居安思危谋长远

在 IT 行业，应用程序的功能和性能固然重要，但安全运行是基础，尤其在这种Critical级别的安全漏洞面前，人人当存有戒心。及时的检测到漏洞，并采取相应的措施，才能保证应用程序不被攻击和利用，企业的效益才能得到保障。

在此调研过程中，我们开发了一些工具，比如如何探测应用中是否有此漏洞，以及是否已经受到攻击等。如果您感兴趣，请联系IBM Client Engineering团队（热线电话：4006682350），我们可以为您演示以上功能，也可以辅助您提升系统和应用的安全。

最后，笔者想提醒大家，Hot Mitigation或许在短时间内可以防止攻击，我们注意到，Apache基金会已逐步推出官方补丁，长远来看，建议用户给应用程序打上安全有效的补丁，方能防患于未然。

​​了解更多IBM相关：http://server./act/ibm/2022q1#box1​​