许多简略的绕开前边咱们是依照payload为${jndi:rmi://127.0.0.1:1088/sine}做深入分析和解决的。但在源代码中，有很多方面都论述了这儿是存有递归法解决的，换句话说我们可以假如嵌入${}语法的方法来解决这儿的返回。例如咱们选择lower协议做返回，拼凑进到源代码中上半部分会被做为varname，后半段分会被返回更换本来的结论进到下一次拼凑，如此一来又可以构建新的payload。乃至官方网站之中还加了容错机制源代码，假如遇上不符合条件的标识符，还会继续被可以直接删除。因为许多特殊的要求，这儿我不会公布有关的绕开payload，假如能看懂这一部分源代码的朋友肯定可以很轻松愉快的构建。

实际上这一漏洞几日前就被公布了升级补丁，以前也留意到了，只不过想不到运用的逻辑这般简略。在全部漏洞刮起全安全圈的飓风时，愈来愈多的朋友将眼光聚集到这儿。rc1的修复也迎来了绕开，这儿的绕开实际上还挺有趣的，大家一起来看一下补丁。修复补丁和检测样例又十分有趣,简略而言，本来的修复逻辑解决处，想办法使他解决出错，那样以前的throw并不会做解决，反而是可以直接走入lookup修复方案

1、现阶段Apache官方网站只公布了2.15.0rc2并打包了2.15.0的release，无法确保并不会被二次绕开，并且听说这一版本兼容度没有很高。

https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2

2、如今常见的修复方案关键聚集在配置改动上

在项目的log4j2.component.properties配置文件中加上配置：

log4j2.formatMsgNoLookups=true

要留意的是，这一配置只起效于2.10.0以上。

还可以在java的启动项中加上该配置

-Dlog4j2.formatMsgNoLookups=true

3、此外很有可能就需要依靠各种WAF了

实际上这一漏洞在12月6号就升级补丁了，并且在twiter传的很广，最初见到第一反应是不太可能有那么严重的问题，肯定是限定重重。结论运用压根就非常简单，突然之间风靡了全部java届的全部项目。

而做为1个基础组件，这一组件被大部分的java框架/java运用引入，许多的问题突然之间被曝料出去。就在下班了将近1个钟头，payload就早已广为流传开了，若不是jndi到rce的运用不算是简略，可能许多服务一晚上早已沦陷了。

因为厂家还没来得及公布修复后的release，造成这一漏洞前期只有利用waf防御，假如安全运营构建较为差的厂家，可能只有等死，这类感受不历经这样的大洞很有可能难以感受到吧。