最近几天对于很多开发者而言，只能用争分夺秒与胆战心惊来形容。而造成这一切的源头，来自于被公布的 Apache Log4j2 远程代码执行漏洞（CNVD-2021-95914）。当前几乎所有技术巨头都在使用该开源组件，其危害将带来一连串连锁反应。据行业机构不完全统计，该漏洞影响 6w+ 流行开源软件，影响 70% 以上的企业线上业务系统！漏洞波及面、危害程度均堪比 2017 年的让数百万台主机面临被勒索病毒攻击的风险的“永恒之蓝”漏洞。
漏洞解析
Apache Log4j RCE 漏洞造成如此大影响的原因，不仅在于其易于利用，更在于其巨大的潜在危害性。此次危机由 Lookup 功能引发，Log4j2 在默认情况下会开启 Lookup 功能，提供给客户另一种添加特殊值到日志中的方式。此功能中也包含了对于 JNDI 的 Lookup，但由于 Lookup 对于加载的 JNDI 内容未做任何限制，使得攻击者可以通过 JNDI 注入实现远程加载恶意类到应用中，从而造成 RCE。
据悉，Apache Log4j 2.x <= 2.14.1 版本均回会受到影响。可能的受影响应用包括但不限于：Spring-Boot-strater-log4j2、Apache Struts2、Apache Solr、Apache Flink、Apache Druid、Elasticsearch、Flume、Dubbo、Redis、Logstash、Kafka 等。直接应用了 Log4j-core 的依赖中，就包含了 SpringBoot、JBoss、Solr 等流行框架。漏洞几乎影响所有使用 Log4j2 2.15.0 的用户，包含 2.15.0-rc1 也已经有绕过手法流出。
仅需四步，借助阿里云 ARMS 应用安全，全面拦截 Log4j2 漏洞攻击
此次 Log4j2 漏洞，作为一款日志框架，相比起记录日志等类型的正常行为，进行命令注入、执行，本身就是明显异常行为。
RASP 在默认规则下，会拦截掉所有因反序列、JNDI 注入导致的命令执行、任意文件读取、恶意文件上传等危险行为。不同于传统基于流量特征的防御方式，RASP（Runtime Application Self-Protection）基于行为和应用运行时上下文，不会陷入特征穷举并更加关注「正常基线」。即应用的正常使用行为有哪些，如果这个行为（如命令执行）不属于该功能的正常操作，则会进行拦截。
此次漏洞，系 Log4j2 的 JNDI 功能造成的命令执行漏洞，处在 RASP 覆盖场景之中，无需新增规则也能默认防御。因此，ARMS 应用安全基于阿里云 RASP 技术针对上述漏洞进行攻击防护。
1、登录阿里云 ARMS 控制台
说明：阿里云 ARMS 探针版本容器服务应用 / EDAS 应用等自动升级场景 >=2.7.1.2，其他场景(手动升级)>=2.7.1.3。应用首次开启接入ARMS应用安全，需要重启应用实例。
2、在左侧导航栏，选择应用 > 攻击统计页面
当受到 Log4j2 远程代码执行漏洞攻击时，ARMS 应用安全会识别上报攻击行为事件。还可通过配置告警规则，通过短信、钉钉、邮件等渠道接收攻击告警通知。默认防护模式为监控模式，建议观察一段时间后调整防护设置为监控并阻断，一旦发生攻击行为可以直接阻断，保障应用安全运行。
3、在左侧导航栏，选择应用安全 > 危险组件检测，针对三方组件以来自动分析关联 CVE 漏洞库并提供修复建议
4、危险组件全量自查，通过搜索查看所有接入应用是否包含 Log4j 组件，并确定组件版本
修复升级与建议
（1）排查应用是否引入了 Apache Log4j-core Jar 包，若存在依赖引入，且在受影响版本范围内，则可能存在漏洞影响。请尽快升级 Apache Log4j2 所有相关应用到最新的 Log4j-2.15.0-rc2 版本。
（2）升级已知受影响的应用及组件，如 spring-boot-starter-Log4j2/Apache Struts2/Apache Solr/Apache Druid/Apache Flink。
（3）可升级 jdk 版本至 6u211 / 7u201 / 8u191 / 11.0.1 以上，可以在一定程度上限制 JNDI 等漏洞利用方式。
（4）尽可能杜绝对外开放端口，加强应用的证书验证管控，最大可能减少外网攻击面。
（5）在外网开启 Web 应用防火墙 +RASP 组合，采取行为和应用运行时上下文防御策略。
（6）安全配置评估中，严格控制开源软件安全，并自建内部安全版本库，及时更新。
（7）建立多层检测防御体系，采用内网多层隔离，并全面提升威胁检测能力。
点击此处，查看更多应用安全相关信息！
