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

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

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

修复方法1，升级

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

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

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

修复方法3，javaagent

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

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

参考长亭 https://github.com/chaitin/log4j2-vaccine

修复方法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");

以上几种方法仅供参考

本文作者：宽字节安全

本文为安全脉搏专栏作者发布，转载请注明：https://www.secpulse.com/archives/171498.html