Last December 2021, one of the technology industry’s most serious zero-day vulnerabilities was discovered: Log4j. What exactly is a zero-day vulnerability? A zero-day is defined as a vulnerability that’s been disclosed but has no corresponding security fix or patch. This puts all systems and applications where the vulnerability is present at risk due to the lack of remediation for the weakness. We can compare it to a scenario where your car’s door-locking mechanism stops working, but the car dealer doesn’t have a way to resolve the issue. This puts your car at risk of being stolen since you have no ability to lock the doors.
Log4j was discovered on December 9, 2021, leaving many cybersecurity professionals working 40-plus hour weeks through the end of the year to assess their environments and coordinate remediation efforts across their organizations. It’s also one that left many other people asking, “What’s the big deal? New zero-days are published every week, so why is this one so bad?”
Although this vulnerability seemed similar to many zero-days due to the ease of exploitability and the lack of authentication required to perform the exploit, it was so concerning because of the number of systems and software impacted. Jen Easterly, director of CISA (Cybersecurity and Infrastructure Security Agency), says this “is what makes it ‘the most serious flaw’ she has seen in her decades-long career.”
What Is Log4j?
Log4j is an open-source logging framework maintained by Apache, a software foundation. It’s a Java-based utility, making it a popular service used on Java-based systems and applications. When the Log4j zero-day was disclosed, organizations were scrambling to understand how it might impact them.
Within a few days, cybersecurity experts collaborated to begin compiling a list of software that the Log4j vulnerability affected as well as those that it didn’t. Although this list helped companies better assess their environments for impacted systems and applications, security teams were sitting ducks for a few days, at the mercy of the technology vendors, waiting for them to produce security patches that would remediate the flaw. As a result, organizations were being urged to take down any internet-facing, non-business-critical systems to prevent them from being exploited while security teams waited for those system updates to be released.
It shouldn’t come as a surprise that after its discovery, security researchers saw millions of attempted exploits, many of which turned into successful denial-of-service (DoS) attacks. It didn’t take long for a new variant of ransomware that leveraged the exploit to be developed either. This is the primary reason why security teams rushed to take many of their systems impacted by this zero-day offline. Leaving any system or application found to be vulnerable exposed was like playing a game of roulette.
Due to the obvious severity and publicity around this particular zero-day, vendors were quick to publish security fixes and the patching began. Unfortunately for many IT and security teams, this massive project occurred right around the holidays in the last few weeks of December.
How Does the Log4j Exploit Work?
As mentioned previously, cybersecurity experts considered the Log4j exploit critical due to the ease of exploitation and the fact that no authentication was required to perform it. Add the prevalence of the vulnerability of public-facing systems to this and you have yourself a major cause for concern.
Log4j is used to log messages within software and has the ability to communicate with other services on a system. This communication functionality is where the vulnerability exists, providing an opening for an attacker to inject malicious code into the logs so it can be executed on the system.
The vulnerability was first discovered in a version of the game Minecraft. Malicious individuals learned that the game’s chat was being logged using Log4j and, if they entered malicious code into the chat, it led to remote code execution (RCE). Remote code execution is a type of cyberattack that allows an individual to execute code on a backend system, remotely.
Upon this discovery, a world of opportunities opened up as hackers and security researchers alike began to test how far they could take this potential flaw. And so began the mass network scanning activity required to find potentially vulnerable systems and then perform POCs (proof of concepts) of the exploit.
It didn’t take long for official POC code to surface on GitHub, an open-source coding community where members can share and collaborate on coding projects. The software community uses it to develop programs. For cybersecurity experts, however, it’s used to share scripts and programs related to securing or exploiting various systems or vulnerabilities. This includes POC code, or exploit code, typically with instructions, that publicizes how to exploit a specific vulnerability.
In the case of Log4j, a GitHub user published a Log4j POC for LDAP (Lightweight Directory Access Protocol) remote code execution. If you recall, RCE attacks result in malicious code being executed on a remote system, and the exploit is leveraging the LDAP service, which is a protocol used for cross-platform directory services authentication. In simpler terms, it’s what enables a remote directory (typically Microsoft Active Directory) to be searched and used for authentication purposes to an internal service.
To perform the exploit using the popular POC code on GitHub, all an attacker has to do is run the provided script on their system to deploy an HTTP server and fake LDAP server, then inject the crafted malicious payload into a text field on a vulnerable platform. This can be within a chat, like in the Minecraft exploit, or as simple as pasting the command into the username field of a login form with a random password.
You might be wondering, “What’s so special about the crafted payload?” The payload is ultimately what exploits the Log4j vulnerability. It does so by using JNDI, Java Naming and Directory Interface, a feature that enables a user to fetch and load Java objects from a server. Although this is a secure functionality, the Log4j flaw allows an attacker to input their own JNDI lookups, where they then direct the server to their fake LDAP server. From here, the attacker now has control of the remote system and can execute malware, exfiltrate sensitive information like passwords, and more.
Can the Log4j Exploit Be Fixed?
The Log4j zero-day vulnerability took the cybersecurity world by storm. Many industry experts, in addition to CISA’s director Jen Easterly, claimed they had never seen anything like it throughout their careers. If you ask any security professional who worked for a large enterprise when the Log4j vulnerability was first disclosed, they’ll likely recount the hours spent working with various IT teams to assess and respond to the news in order to protect their organization’s network.
Many security teams spent days running vulnerability assessments, then identifying which systems should be cut off from the world wide web. Since this type of activity directly impacts business operations, the decisions required involvement from various senior leaders across the IT department and impacted business functions, while security leaders did their best to relay the seriousness of the situation in order to avoid a cyberattack.
Since December, most vendors have published security updates that resolve the Log4j flaw within their applications, and Apache themselves have released fixes and updated versions that remediate the vulnerability. With that being said, thousands of systems are still vulnerable today. As of April 2022, the cybersecurity firm Rezilion claimed there were still over 68,000 publicly accessible systems at risk. At this point, it leaves many of us wondering whether the organizations that own those systems even know they exist. One thing is for certain though: They’ll know once one of them is exploited.