Analysis:
Apache Log4j2 is an open source Java logging framework that is widely used in middleware, development frameworks and web applications to log information. Due to the recursive parsing of certain features of Apache Log4j2, an unauthenticated attacker can execute arbitrary code on the target server by sending specially constructed data request packets. Vulnerability PoC has been made public on the Internet, the default configuration can be exploited , the vulnerability has a wide range of impact , it is recommended that relevant users take measures as soon as possible to investigate and protect .
Based on the usage of Iog4j and the replication, the attack entry point depends on where Iog4j takes data from and puts it into the online business, so there is no fixed request path. In addition, the impact of this vulnerability may be magnified because any data from the online web service may be written to Iog4j, even in some pre-auth places, such as registration and login.to unauthorized command execution.
Detection:
manual testing
1, relevant users can be based on the Java jar decompression whether the existence of org/apache/logging/log4j related path structure, to determine whether the use of the components of the existence of vulnerabilities, if there is a relevant Java package, it is likely that the vulnerability exists.
2. If the program is packaged using Maven, check whether the relevant fields shown in the figure below exist in the project's files, and if the version number is less than 2.15.0, the vulnerability exists.
3, if the program is packaged using gradle, you can check the compilation configuration file, if there are .log4j related fields in the dependencies section, and the version number is less than 2.15.0, then there is this vulnerability.
4. Detect whether the Ivy dependency version is lower than 2.15.0.
5. Detect whether the SBT dependency version is lower than 2.15.0.
If you are not using the above tool, then you can globally search for thelog4jThe relevant jar packages of the
Affected Versions:
Apache Log4j <= 2.14.1
Known affected applications and components:
Apache Solr
Apache Flink
Apache Druid
srping-boot-strater-log4j2
More components can be found at the following links:
/artifact/.log4j/log4j-core/usages?p=1
Unaffected version:
Apache log4j-2.15.0-rc1
Protection:
1. Upgrade
Currently the official test version has been released to fix the vulnerability, affected users can first Apache Log4j2 all related applications to this version, download link: /apache/logging-log4j2/releases/tag/log4j-2.15.0-rc1
Note: Due to the fact that this version is not an official release and may be unstable, users are advised to backup their data before upgrading.
Known affected applications and components in the upgrade supply chain: Apache Solr, Apache Flink, Apache Druid, srping-boot-strater-log4j2
2、Traffic interception rulel $(jndi:ldap://rule2 $(jndi:rmi://))
The above traffic features may appear anywhere in the traffic and also include various types of requests (GET, POST, etc.), so feature matching needs to be done for the entire request traffic.
The above rules have no effect on normal jndi traffic in business (malicious traffic must contain ${jndi:rmi or ${jndi:ldap, normal business jndi traffic usually only contains rmi://, ldap://), but if your normal traffic also contains the above characteristics, please use with caution.
3. Temporary protection
From the official information and reproduction of the situation, the use of means of jndi injection is undoubtedly, jndi injection is nothing more than ldap, rmi, need to be externally connected to the request Idap-server/exp-server, prohibit the external connection to a certain extent to alleviate the situation, but can not defend against the attacker has been controlled by other internal servers. In addition, JDK11.0.1, 8u191, 7u201, 6u211 or later is unable to use JNDI injection by default, JDK6u141, 7u131, 8u121 or later can not be used to inject the RMI, the network of some bypas s method also relies on a specific local lib (the equivalent of the search for a new gadgets), so the Summary:
1, prohibit the use of Iog4j server external connection (logging server normal does not require external connection)
and at the border to detect dnslog-related domain access.
Some of the public dnslog platforms are listed below:
2, it is recommended to use a high version of the JDK
3, add jvm startup parameters :-=true
4. Add under the application classpathConfiguration file with =true
5. Set the system environment variable FORMAT_MESSAGES_PATTERN_DISABLE_LOOKUPS to true.
To this article on the Apache Log4j2 remote code execution vulnerability analysis + detection + protection of the article is introduced to this, more related to the Apache Log4j2 remote code execution vulnerability content, please search for my previous articles or continue to browse the following related articles I hope that you will support me more in the future!