write in front
A blog post on Twitter last night attracted a lot of attention in the circle
Good luck! log4j 2.17.0 can RCE! !
Ran Goose:
lie……
Insiders booed...
Modify configuration file RCE? ? That's it? ? ?
So how did modifying the configuration file to use RCE become "popular"?
because
This matter also starts with the RCE of Log4j 2
There is a Pull in the log4j2 GitHub project:
https://github.com/apache/logging-log4j2/pull/608
A foreigner named "TopStreamsNet" mentioned:
If you look at how jndi works in 1.x, you'll see that there are two places where the lookup is done - namely JMSAppender.java:207 and JMSAppender.java:222 - which is what JNDI can handle if you set TopicBindingName or TopicConnectionFactoryBindingName - e.g. "ldap://host:port/a" JNDI will do exactly the same thing as 2.x - so 1.x is vulnerable, just the attack vector is "safer" because it depends on the configuration instead user input
Then the discussion about passing the configuration file RCE started.
In particular, the author of Log4j2 responded:
If an attacker can modify the configuration files on a certain system S, then it can be assumed that S has been penetrated to a large extent.
If an attacker can modify log4j.properties (log4j 1.x), she does not need to download malicious code, she can easily place malicious class files in the classpath and have them execute.
So, in a very strict sense, there is a vulnerability in log4j 1.x, but it has nothing to do with RCE caused by log parameters.
In fact, it can be seen that the author of Log4j2 did not agree with this foreigner’s point of view at first, but here comes the interesting part
Just when everyone thought this "vulnerability" was not a vulnerability, RadHat came out to act like a monster:
https://access.redhat.com/security/cve/CVE-2021-4104
They defined this RCE caused by the configuration file as a vulnerability and gave cvss v3 a medium risk score of 7.5!
Then someone replied under the log4j2 pull:
Passerby: Look, look, RedHat posted a CVE, and it still got a score of 7.5! (Actually, it was given 8.0 at the beginning)
Of course, some people also replied:
Passerby: TMD, ReaHat, you don’t understand the rules and don’t follow martial ethics. The official log4j hasn’t said anything yet. What are you doing here?
Later, under pressure, log4j recognized this CVE.
We decided to keep the CVE assigned by Red Hat to save creating another one and reject theirs.
log4j official: Okay, okay, I accept it. Isn’t it okay if I accept it?
At this point, the first CVE involving RCE caused by a configuration file discussed by log4j on pull was discovered by RedHat.
fruit
Before the CVE of log4j1 was released, I actually researched the views put forward by the foreigner "TopStreamsNet":
Discussion of useless RCE between log4j 1.x and logback:
https://www.cnpanda.net/sec/1131.html
And I found that in fact the configuration file RCE of log4j 1.x does not take effect immediately, because modifying the configuration file of log4j 1.x needs to be reloaded before it can take effect. In a production environment, who has nothing to do and actively restarts or reloads the configuration file? ?
But logback is different, because logback has a scan attribute that can automatically scan whether the configuration file has changed. If it has changed, the configuration file will be automatically updated. So while doing research, I wrote a SpringBoot demo and posted it on GitHub.
Coincidentally, I saw a question on the official issue of logback, to the effect of whether there is the vulnerability released by RedHat in logback. Then I replied to the address of the previous SpringBoot demo Demo. Later, the author of logback also assigned CVE-2021. -42550, and even sent me an email asking if I wanted credit.
Foreigners are still enthusiastic, but I think this loophole itself is very restrictive and useless, and the master @香伊香丝proposed this method of exploitation a year ago:
https://xz.aliyun.com/t/7351
So I declined the credit.
Later, I learned from Master @TiGer that this logback vulnerability has actually been exploited in actual examples:
You can refer to: https://www.cnblogs.com/zpchcbd/p/15542705.html
Summarize
Looking back at the configuration file RCE of log4j 2.17.0, it is indeed a bit outrageous, because after modifying the configuration file, it does not take effect in real time like logback, which is a tasteless thing.
In fact, @pwntester also said:
Most Java applications that use a database have a configuration file where you can specify the JNDI address to obtain the JDBC data source
A simple search found that some applications that can set configuration files through JNDI are as follows:
jetty
https://wiki.eclipse.org/Jetty/Feature/JNDI#Configuring_JMS_Queues.2C_Topics_and_ConnectionFactories
Apache ODE
https://ode.apache.org/using-a-jndi-datasource-under-servicemix-jbi.html
Apache Shrio
https://shiro.apache.org/static/1.3.2/apidocs/org/apache/shiro/jndi/JndiTemplate.html
https://www.programmerall.com/article/1371213168/
Tomcat
https://tomcat.apache.org/tomcat-8.0-doc/jndi-datasource-examples-howto.html
TomEE
https://tomee.apache.org/jndi-names.html
SpringBoot
https://blog.roncoo.com/article/133919
wait wait wait
There are too many. In fact, as @pwntester said, JNDI is similar to registering something in a center. When you want to use it in the future, you only need to search the registration center according to the name, and the registration center will return what you want. For example, in web applications, we can hand over some things (the most commonly used database-related configuration information) to the server software for configuration and management. In the program code or configuration file, we can get the things we registered by just searching by name. And if the registered things change, such as changing the database, we only need to modify the registration information and the name does not change, so the code does not need to be modified.
This is a standard Java naming system interface provided by SUN . It is a feature . Therefore, generally speaking, as long as JNDI exists, the ldap protocol can be used to implement RCE. Of course, it is not just the ldap protocol. In fact, There are also many protocols available:
In short, I think that the CVE of log4j 2.17.0 should be assigned, but what is too much is that this foreigner had the nerve to post on Twitter that log4j 2.17.0 has another RCE vulnerability (just exploit the hole, and even yelled) , the result is still this loophole, doesn’t it make others feel as uncomfortable as eating shit?)
In one sentence: Implementing RCE through configuration files can only be said to be a means of attack, but not a conventional vulnerability.