Log4j: Critical vulnerability that attackers make thousands of attempts to exploit
A major vulnerability in the popular Java Log4j logging package, called Log4Shell, discover on December 9, 2021. CVE-2021-44228 is a remote code execution vulnerability with a severity of 10 (the highest possible risk level) that allows an attacker to take total control of any compromised machine.
What is log4j?
The Apache Foundation has created Log4j, an open source Java logging library. Many applications and services use it widely. Including in-house developed custom applications, as well as various cloud services, online applications, and email services. This implies that efforts to exploit the vulnerability might put a wide variety of programs at risk.
Apache Struts2, Apache Solr, Apache Druid, Apache Flink, and Apache Swift all include the Log4j library, which many enterprises Java systems use it; Netty, MyBatis, and Spring Framework are just a few of the important projects that use the library.
Because of its popularity, the Log4j library is utilized by numerous software firms and online services, including Amazon, Splunk, Cisco, Cloudflare, ElasticSearch, Red Hat, Zabbix, and many more.
What is CVE-2021-44228? and why is so dangerous?
CVE-2021-44228 is a Remote Code Execution (RCE) vulnerability, commonly known as Log4Shell or LogJam.If an attacker is able to exploit it on one of the servers, they will be able to run arbitrary code and perhaps gain entire control of the system. CVE-2021-44228 is extremely hazardous because to the ease with which it may be abused; even a rookie hacker can readily exploit this vulnerability.
Log4Shell takes use of Log4j’s ability to use JNDI (Java Naming and Directory Interface), which stands for Java Naming and Directory Interface. This functionality was introduced in 2013. An attacker can compel the susceptible application to connect to an attacker-controlled LDAP server and release a malicious payload by utilizing a specially crafted text that leverages JNDI lookups.
The Swiss Government Computer Emergency Response Team (GovCERT) has created a schematic of the attack chain.
First step: an attacker who sends a malicious payload through a use-supplied input starts the exploit. This might be an HTTP header or whatever the program is logging with Log4j.
Second step: The program records the user’s input.
Third step: the Log4j library interpretes The malicious payload, which then connects to a malicious LDAP server.
The fourth step: A response from the malicious LDAP server instructs the application to load an external class file.
Fifth step: the program executes and downloads the remote Java class file.
Which Log4j library versions are vulnerable?the program executes and downloads the remote Java class file
From 2.0-beta9 through 2.14.1, almost all versions of Log4j are susceptible. Installing the most recent version of the library, 2.15.0, is the easiest and most effective protection strategy.
Furthermore, we recommend that you deploy security solutions on your servers, as this will often allow you to identify the launch of dangerous code and stop the assault from progressing.
Because of this vulnerability, many Java applications and services are susceptible. Certain packages that use the vulnerable version of Log4j (CVE-2021-44228):
The Log4Shell vulnerability is a high-impact flaw that attackers may easily exploit and has far-reaching implications for the whole industry. Since some application aren’t impacted by these flaws, such as zabbix, which employs Java in its single product, Zabbix Java Gateway, which doesn’t use the log4j library and hence isn’t affected by this flaw. We also find Grafana “Grafana OSS and Grafana Cloud” unaffected.