Log4j vulnerability is one of the biggest topics recently. A zero-day vulnerability affecting widely used software component that is being actively exposed in the wild. What could be worse? Almost every small, medium, and big company having different external and internal systems is affected. Before it is not too late and the vulnerability is not exploited by an external actor, it is crucial to perform Log4j scanning and find out if the software that you use is vulnerable.
For those of you that are not working with Java, this component might be unheard of. But you probably know Apache – one of the most famous web servers. And the Log4j is an Apache logging library that is used in many products.
Many different widely used products are using the log4j library. So, it is scary to realize that there are dozens of widely adopted products that are vulnerable. Even though official patches were released for many of them, not everyone had updated their systems.
The vulnerability has a CVE number assigned – CVE-2021-44228.
How serious is this vulnerability?
The vulnerability has a CVSS 10.0 rating (out of 10), so it is pretty dangerous and is a critical vulnerability. All Log4j2 versions prior to 2.15.0 are vulnerable to remote code execution.
How does the Log4j exploit work?
Before diving into the Log4j exploit specifics, we must understand how does the component work. It is a logging component that logs requests that a client sends to the server. And the problem occurs when the client modifies his requests and adds a specific payload, that is being executed on the server.
And the main problem is that Log4j JNDI features do not protect against attacker-controlled LDAP and other JNDI-related endpoints.
This can be exploited in the following way:
- Attacker modifies the request and adds the JNDI lookup in a header, sending the request to the server.
- Server logs the request with a malicious payload
- Log4j interpolates the payload and queries the malicious LDAP server
- LDAP server passes the information where the malicious Java class is
- Server downloads the malicious code and executes it
From the application perspective, you can prevent this from happening during different stages of the attack (refer to the image above).
Ongoing List of Impacted Products and Devices
Please find below a list of publicly available information and vendor-supplied advisories regarding the Log4j vulnerability.
My System is Vulnerable to Log4j Vulnerability! Now What?
In case you detected that your system is vulnerable to Log4J vulnerability, which is also known ass Log4shell, or Logjam, there are a few things you should do:
- You should upgrade the software that uses this logging library immediately.
- If you can’t upgrade it, or the vendor does not release the fix yet, you should restrict access to the system. Of course, this might not be the way to go if business operations require it to be public. But if it is possible, it is advised to restrict access from the external network until the software will be upgraded
- Another countermeasure if updating is not possible, is to configure WAF to block the attack. However, keep in mind that some of the PoCs that can be found around the internet, have WAF bypass functionality. So, this might not be the perfect solution
- Set the log4j2.formatMsgNoLookups property, or LOG4J_FORMAT_MSG_NO_LOOKUPS env variable to True, to disable the lookup functionality
Want to Learn More?
Contact us today for your free consultation and find out if your organization has been compromised by the log4j vulnerability and how you can prevent exploitation.