[JavaWeb]Log4j的前因后果
Log4j的前因后果
简介
Log4J的三大组件：
Logger：日志记录器，负责收集处理日志记录 （如何处理日志）
Appender：日志输出目的地，负责日志的输出 （输出到什么地方）
Layout：日志格式化，负责对输出的日志格式化（以什么形式展现）
还是一如既往的先对其的应用有个大概的了解，有利于对 漏洞的全局把控
漏洞相关知识前置
由于Log4j漏洞是利用了Log4j.lookup的解析+jndi的相关漏洞，最终触发了所谓的“核弹级”漏洞。
Log4j的应用架构
JNDI的应用结构
漏洞分析
先用网上的exp随便测了测，发现error和fetal会触发，而info和debug不会触发
所以接下来，首先要来分析为什么error和fetal会触发？又为什么info和debug不会触发
流程分析
-
进入日志记录后，首先判断了日志是否需要记录。确认记录，继续跟进
-
先匹配到了${}中包裹的字符串
-
再对获取到的字符串不断进行递归检测${}，看是否还能进行替换
-
继续进行识别，进行变量替换
-
经过无数遍的字符串扫描识别后，看到了解析器组会依次对变量进行解析，而且同时看到了可以解析jndi的相关变量
-
一直跟到jndiManager#lookup()，发现没有任何过滤。
分析了下，主要是因为我这里测试的方式不是webAPP，所以不执行WebLookup的插件。也就无法进行jndi的利用了
- 到此，分析完了log4j的漏洞细节
分析下来就是log4j支持${}的表达式，会对其进行递归解析。官方开启此种方式是为了能够快速获取其他信息。但对jndi的支持，却导致了此次的漏洞。
log4j中项目lookup的作用：** Lookups provide a way to add values to the Log4j configuration at arbitrary places. They are a particular type of Plugin that implements the StrLookup interface. **”
以上内容复制于log4j2的官方文档lookup - Office Site。其清晰地说明了lookup的主要功能就是提供另外一种方式以添加某些特殊的值到日志中，以最大化松散耦合地提供可配置属性供使用者以约定的格式进行调用。
漏洞利用
直接就是套用jndi的exp。
漏洞修复
官方先是给出了内网白名单的修复--》被解析漏洞绕过--》然后又被发现逻辑漏洞
泛域名解析:就是多个子域名解析到同一个ip上
流程分析小结：跟的时候总是跟的目标不对，而且似乎对jndi的底层实现不熟。对关键类中的敏感方法不够感冒。。。
