Second Log4Shell vulnerability has been discovered so we recommend everyone to once again update the Log4j package to the latest Log4j 2.16 (at the time of writing).
(where attacker.com is an attacker-controlled server)
A couple of hours ago, a remote code execution vulnerability in Apache Log4j2 appeared on the Internet. An attacker can use this vulnerability to construct a special data request packet, which eventually triggers remote code execution. Due to the wide range of impact of this vulnerability, users are advised to investigate related vulnerabilities in a timely manner.
After analysis and confirmation by the White Hat Security Research Institute, there are currently many popular systems on the market that are affected. Almost very tech giants is the victim of this Log4j Remote Code Execution vulnerability.
Apache Log4j2 is a Java-based logging tool. This tool rewrites the Log4j framework and introduces a lot of rich features. The log framework is widely used in business system development to record log information.
In most cases, developers may write error messages caused by user input into the log. Attackers can use this feature to construct special data request packets through this vulnerability, and ultimately trigger remote code execution.
On November 24, 2021, the Alibaba Cloud security team officially reported the Apache Log4j2 remote code execution vulnerability to Apache. Because some functions of Apache Log4j2 have recursive analysis functions, attackers can directly construct malicious requests to trigger remote code execution vulnerabilities.
Vulnerability exploitation does not require special configuration. After verification by the Alibaba Cloud security team, Apache Struts2, Apache Solr, Apache Druid, Apache Flink, etc. are all affected.
Alibaba Cloud Emergency Response Center reminds Apache Log4j2 users to take security measures as soon as possible to prevent vulnerability attacks.
Level of the vulnerability: Serious (Critical)
2.0 <= Apache log4j2 <= 2.14.1
Impact judgment method: Users only need to check whether the Java application has introduced two jars, log4j-api and log4j-core. If there is application usage, it is likely to be affected.
Mitigation for Log4j Vulnerability
At present, Vulfocus has integrated the Log4j2 environment. You can start the environment test through the following link:
We highly recommend to use latest version of Log4j2, and also upgrade the applications and components that are known to be affected, such as srping-boot-strater-log4j2/Apache Solr/Apache Flink/Apache Druid.
What can be worse than this? Just some hours past and PoC for Log4j Vulnerability was released on the internet.
Check PoC here.