最近一天被log4j2刷屏了，多说一句，这个漏洞其实非常考验安全人员的应急能力，代码能力和社交能力。漏洞都三天了，竟然还有人在要exp，现在做安全的人都这么水了吗？

我们向开发者给出安全建议的时候，一定要结合业务方具体需求，不要给出不切合实际的修复方案。即不能宕机，又要保证安全性。

还有很多写规则的乙方waf同学，漏洞自己都没研究明白，就要写规则，结果误报一大堆。

修复方法1，升级

这种方案是最简单的，但是需要关闭应用，重新打包，提测。但是这种修复方案是最彻底的。当然，如果因为某些原因不方便关闭应用，那么下面几种方法可能最适合业务方。

修复方法2，修改配置文件

这个修复方法也需要暂时关闭应用，配置方法 log4j2.formatMsgNoLookups=True。当然，既然选择这种修复方案，那还不如选择第一种修复方案比较彻底。

修复方法3，javaagent

这个方法，需要给JDK注入一个jar，在jar中将存在漏洞的class代码直接修改。缺点？有可能业务方不愿意用你的rasp。毕竟拖拖拉拉，万一影响业务性能巴拉巴拉怎么整？

但是优点不需要关闭站点，不会影响线上业务。

修复方法4，反射修改属性

这种方法同样也不需要重启应用，只需要可以在对方的JVM中执行代码，就可以修复。无任何风险。当然前提一定是可以执行代码，方式包括jsp文件等。

这东西其实就是内存马的核心思想，包括DFS搜索对象等等～

既然我们已经知道了，最终根据前缀来找到最终的处理程序，也就是lookup。那么我们通过反射，直接修改strLookUPMap不就可以。

在log4j2中，配置文件是用单例模式，所以非常容易修改。。

通过反射修改这个对象，首先我们要拿到这个对象的引用。

使用我这段通过DFS搜索对象的工具。

选择一个我们喜欢的对象查找路径，然后将其变成反射代码就可以了。代码大概如图

把这段代码包装成jsp文件，直接上传到web站点运行就行。当然如果是springboot的话，想办法执行代码也是可以的。

最终成功的没有触发jndi请求。

代码

   Object obj = LogManager.getLogger();

   Field contextF = obj.getClass().getDeclaredField("context");

   contextF.setAccessible(true);

   Object context = contextF.get(obj);

   Field configurationF = context.getClass().getDeclaredField("configuration");

   configurationF.setAccessible(true);

   Object configuration = configurationF.get(context);

   Field substF = configuration.getClass().getSuperclass().getDeclaredField("subst");

   substF.setAccessible(true);

   Object subst = substF.get(configuration);

   Field variableResolverF = subst.getClass().getDeclaredField("variableResolver");

   variableResolverF.setAccessible(true);

   Object variableResolver = variableResolverF.get(subst);

   Field strLookupMapF = variableResolver.getClass().getDeclaredField("strLookupMap");

   strLookupMapF.setAccessible(true);

   HashMap strLookupMap = (HashMap) strLookupMapF.get(variableResolver);

   strLookupMap.remove("jndi");

以上几种方法仅供参考