一、背景简介
2022年7月30日起，各大威胁情报社区及安全圈内开始盛传log4j存在0day漏洞，由于log4j在去年12月爆出严重的jndi注入漏洞，可通过在特定点插入恶意的jndi payload达到执行任意代码进而控制主机的目的。
log4j2（一般简称log4j）是Apache基金会开发维护的开源java日志组件，在以Java开发的系统中大量被直接或间接使用，一旦再出现类似去年12月的漏洞，几乎所有业务系统都将收到影响，影响范围将极其大。因此各方都十分关注此消息的准确性。
二、情况分析
首先，针对log4j组件本身进行分析
- log4j是日志组件，在项目中也主要用于日志的记录，在实际的开发中，多以类似logger.trace()、logger.error()的代码存在，针对用户侧，其主要以字符串作为外部数据输入源，无其他外部数据输入源。
- log4j主要用于记录日志，其输出基本上为日志文件,同时这些日志文件有固定的文件类型后缀。因此不太可能存在写入恶意jsp文件的情况
-
log4j支持各种类型的lookup，其中尤以jndi lookup最危险，去年的log4j漏洞皆因jndi lookup而起，但在此之后，log4j已经默认关闭了jndi lookup，使用jndi lookup需要手动开启。
结合以上的3点，结合log4j本身的组件特性以及应用场景，其最可能出现的漏洞点仍然是注入。综上所述，并根据最新的威胁情报分析，此次谣传的log4j 0day更可能是一种新的绕过方式：
- 绕过安全设备的检测,但需要存在log4j历史漏洞
-
绕过log4j本身对于lookup查询类型尤其是jndi lookup类型的判断。
前者的可能性较大，后者的可能性较小但不完全排除。 主要原因如下：
1．针对于安全设备的绕过主要针对的是安全设备对于jndi注入利用payload的检测测，其中典型的的payload形如如: ${jndi：dns://dnslog/} ，其payload中包含了jndi，${等关键特征，由于log4j本身支持多种lookup，使用"${::-.}"作为绕过的方式，如果是之前未升级版本，只是针对jndi，dns之类的进行拦截的话，有可能会被绕过。如果升级了版本就不受影响
2．针对log4j本身对jndi lookup类型的判断可能性较小，即使绕过后能够传递恶意的jndi lookup字符串，但由于log4j已经默认关闭了jndi lookup，因此恶意的jndi lookup字符串也不能生效，要想生效还必须利用手段启用jndi lookup，这从技术上较难实现。
综上所述，并根据最新的威胁情报分析，此次谣传的log4j 0day应该是payload变形或针对于安全设备监测一种新的绕过方式。
三、排查及处置方式
1）针对log4j本身:
遵从已公开最新的log4j漏洞CVE-2021-44832的排查方式，请确保log4j已经升级到
Java8及以上 : Log4j 2.17
Java7 : Log4j 2.12.4
Java6 : Log4j 2.3.2
并持续关注log4j2官方公告：
https://logging.apache.org/log4j/2.x/security.html
2）针对安全设备的绕过: 升级安全设备规则库，保持监测
3）针对jndi lookup漏洞：
由于jndi lookup需要外联，请保持对外联情况的监测，发现可疑的外联情况及时排查，即使log4j存在新的jndi lookup漏洞也能快速发现快速处置。
发布者：小站，转转请注明出处：http://blog.gzcity.top/4752.html
微信扫一扫 
支付宝扫一扫 