A zero-day vulnerability was recently detected in the popular logging library, Apache Log4j. Such an attack on your organization would enable the perpetrators to remotely carry out a complete code execution. While you must have already invested in anti-phishing services and other solutions, you need to consult professional IT teams to keep your digital assets secure from such new forms of cyber threats, too.
Apache Log4j is a commonly deployed logging library for cloud services and enterprise apps. Besides, an increasing number of enterprise developers have been supporting private apps. Since the attacks started, Apache has developed an update on security and recommended specific configurations for the older versions. This step can considerably mitigate the impact of the vulnerability. Below is more information on the new threat and how you can draw a strong line of defense against it.
Background of the New Attack
As an open-source Apache framework, Apache Log4j 2 happens to be a common element to manage logging requests. On December 9, 2021, the vulnerability came to notice. It could get a system running on version 2.15 of Apache Log4j or below compromised. Thus, malicious actors would execute codes arbitrarily on vulnerable servers. The next day, NIST published a critical CVE in the National Vulnerability Database and named the new method of attack deployed by the attackers as CVE-2021-44228.
The severity level of the threat is ten as per the CVSS base. Therefore, admins using Log4j to manage their respective environments need to update to versions higher than v2.15.0. The severity of the attack makes it necessary for organizations to take adequate mitigation measures to be on the safer side. Besides, the CISA (Cybersecurity and Infrastructure Security Agency) has come up with specific recommendations to help entrepreneurs deal with the vulnerability.
How To Detect Log4j Vulnerability In Your Applications
Using open-source tools such as Grype and Syft can help you detect Log4j vulnerability in your applications. While Grype is a reliable vulnerability scanner, Syft can produce an SBOM (software bill of materials). These tools would help you investigate through several layers of JAR (Java archive) files to detect the vulnerability. Their specific actions are as follows.
- Syft can detect the exact version of Log4j that your Java application contains. The Log4j JAR might be direct or concealed in any included dependency in the project.
- Grype can specifically tell you the vulnerabilities that the software contains. You can take necessary action accordingly to mitigate the adversaries.
Why Addressing Log4j is a Major Challenge
Addressing Log4j is not as easy as other mitigation measures like phishing protection provided by email hosting providers. As a popular library, users extensively deploy Log4j across various Java applications. It is a Java library that is one of the most widely used today. Most of these libraries log data, and Log4j makes the process extremely easy. However, the challenge with the Log4j threat lies in identifying it due to the unique pattern of Java’s packing the works. The chances are high that the Log4j would remain concealed somewhere in your application without your knowledge.
The dependencies in the Java ecosystem remain distributed as JAR files. They serve as a package that one might deploy as a Java library. Besides, tools such as Gradle and Maven can add the JAR files automatically at the time of development of the Java application. A JAR might also have another JAR that might work well for a dependency. Therefore, it is possible for the vulnerability to remain concealed up to several levels inside your application. In some conditions, a single dependency might pull in several other dependencies. This fact would make it challenging to identify the Log4j.
One JAR can remain nested in another in Java, and the chain continues. There might be several layers, and you need to investigate all of them. Therefore, merely looking at the JARs in a specific project might prove to be inadequate, as the Log4j might remain concealed in another JAR file.
Mitigating Risks Associated With Log4j Vulnerability
Here are specific measures that organization heads should adopt to mitigate the risk caused by Log4j.
Make Your Apps Invisible And Lower The Attack Surface
Currently, there are several zero-trust architecture models available, such as the ZPA and Zscaler Zero Trust Exchange. Such an architecture ensures that all the internal apps stay invisible in cyberspace, thus operating in the dark. Once you deploy a zero-trust platform to hide the apps, it would become challenging for the attackers to detect and exploit them. Thus, entrepreneurs can secure the vulnerable parts of Apache.
Implement Authorized Access to Apps
With a layered defense on integrated platforms, cybersecurity turns out to be the most effective. Therefore, you need to implement authorized and restricted access to your apps, applying principles like ‘need-to-know basis’ and ‘least privilege.’ You need to formulate a policy that would recognize vendors’ identities when they access the apps. Since the attackers will not be a known vendor, the setup will prevent them from accessing the apps.
Restrict Lateral Movement Within The Network
An attacker infiltrating an organization’s information network may perform lateral attacks. It can result in the installation of ransomware or exfiltration of data. Therefore, it is necessary to implement solutions that decouple apps from the leading network. Then the users can access them without accessing the core network. They can prevent lateral movement and provide micro-segmentation from one app to another. Also, installing ransomware protection is essential in case lateral access occurs despite all precautions.
Inspect Traffic: Both Inbound And Outbound
With the proper security mechanism, you can benefit from constant monitoring and visibility of your inbound and outbound traffic. Sophisticated tools are required to inspect encrypted and unencrypted traffic and block the initial compromises. The reason is that malicious actors often try to access your organizational environment through cyberspace.
Moreover, ensure that there are no post-exploitation activities like exfiltration of data and interaction with command-and-control servers. At this stage, you need to inspect server-to-internet and internet-to-server traffic. You will block possible threats or detect and mitigate the same in the process.
Final Words
Given that Log4j is extensively used, a wide range of services and software might come under the impact of the adversary. Malicious actors have already made thousands of attempts to find vulnerable devices. Nevertheless, you can mitigate such specialized threats by using dedicated protection methods, besides standard email security measures and other traditional safeguards.