Log4j by Apache is one of the most common software in use today. The latest version of this software is Log4j 2.
On December 9th, 2021, the Alibaba cloud security team publicly disclosed a Log4j vulnerability to the rest of the world. As a result of this vulnerability, millions of computers that use it are at risk of cyberattacks.
Now the question is, what exactly can we do about this vulnerability? The Federal Trade Commission (FTC) recently issued guidelines on the extent of the vulnerability and how to best address it.
So please stick with us to find out everything you need to know about the Log4j vulnerability and how to keep your business and its applications safe from the potential exploit.
To fully understand the extent of the Log4j vulnerability, it helps first to know a little about Log4j. Log4j is an open-source Java logging framework by the Apache Software Foundation and a fundamental component of web application security. It helps record system events, such as potential errors or system changes, and keeps them logged.
As an example of Log4j in action, think of the HTTP 403: Forbidden error message. Users encounter this error when they try to access a forbidden resource, usually on a website. The web server hosting the site domain will display this message to the user and record the event in the system log with Log4j.
The site administrators can thus view the event of this error message later on and, if needed, use it to diagnose security issues.
Sounds good so far, but where’s the catch? Unfortunately, every piece of software on the planet is vulnerable to security exploits; Log4j is no exception.
The Log4j vulnerability, also known as Log4Shell, is a security vulnerability in Log4j that cyber-attackers can potentially exploit. The National Institute of Standards and Technology (NIST) has given Log4Shell the code CVE-2021-44228, available on the National Vulnerability Database.
Log4Shell also has additional variants, including CVE-2021-4104 and CVE-2021-45046. The variants differ from each other depending on the Log4j version and the attack vectors; CVE-2021-4104 is specifically for Log4j 1.2, and CVE-2021-45046 exploits the Log4j thread context map (MDC) input data as an attack vector.
In a nutshell, the Log4j vulnerability can allow any user to remotely execute third party code on a web server and gain unauthorized access to servers and all their data. The type of cyber-attack that this vulnerability can best utilize is a Remote Code Execution (RCE) attack.
Ever since Log4Shell was discovered, IT app cybersecurity experts and hackers alike have carefully studied how the exploit can work. Note that this section has a fair bit of technical jargon, so feel free to skip ahead if you want to learn how to protect your computer and information systems from the exploit.
At its heart, Log4Shell exploits what is known as the Java Naming and Directory Interface (JNDI), a Java Application Programming Interface (API) that enables Java object lookup at the program’s runtime, as long as it has a path to the data. The JNDI lets Java users efficiently look up and retrieve data.
Additionally, the JNDI can also utilize other directory interfaces not specific to Java, such as the Lightweight Directory Access Protocol (LDAP). LDAP is a general protocol that can retrieve object data as a web Uniform Resource Locator (URL). This object retrieval can occur either over a local server or over the internet as a whole.
The problem arises in how attackers can exploit default JNDI syntax using LDAP queries, which are system commands that request directory services for specific data. When logging a string, Log4j 2 will substitute strings on query expressions having the syntax: ${prefix: name}. One such possible substituted string expression is ${jndi:ldap://www.kiuwan.com}.
Since JNDI has pre-defined logic for detecting Java objects in a remote or local directory and loading them into memory, the LDAP object loader can thus retrieve malicious third-party code from a public URL and execute it after storage.
But what about code security protocols that disable the execution of remote data? Although such measures may prevent malicious third-party code execution, they do not protect the system from data retrieval. Attackers can still retrieve vulnerable data through LDAP URL exploitation and send them to their private servers.
LDAP isn’t the only protocol that attackers can exploit with Log4Shell. Other protocols such as Remote Method Invocation (RMI) and Domain Name System (DNS) are also vulnerable to the Log4Shell exploit.
Since the days following the public disclosure of vulnerability, Apache has addressed Log4Shell in multiple security patches. However, it is still ultimately up to an organization’s Information Technology security departments to update to the latest Log4j secure patches.
All Apache Log4j 2 versions from 2.0 to 2.12.1 and 2.13.0 to 2.15.0 are vulnerable to Log4j exploits. Apache Log4j 2 version 2.16.0 disabled the JNDI lookup functionality by preventing LDAP query manipulation. Version 2.17.0 also has a parameter called log4j2.enableJndiLookup, which needs to be set to true to enable JNDI lookup with LDAP or other protocols.
Although Log4Shell may not appear that dangerous at first glance, the truth is that it may be the single most dangerous security vulnerability of the past decade, if not of all time. In an interview, Jen Easterly, the current Cybersecurity and Infrastructure Security Agency (CISA) director, told CNBC that Log4Shell was the most serious security flaw she had seen in her decades-long career.
As millions of computers and systems worldwide use Log4j, the Log4j vulnerability has a far-reaching potential security impact. From tech giants such as Microsoft, Google, or Amazon to smaller cloud-service providers, no one is safe from the exploit.
Even Minecraft, a video game built with Java, isn’t safe from the Log4j vulnerability; players can remotely execute code on Minecraft servers by simply copy-pasting a single line of code.
Internet-capable smart devices such as television sets that use Java are also vulnerable. This enormous attack surface combined with how simply attackers can exploit Log4Shell makes the vulnerability especially dangerous.
Despite the catastrophic proportions of the exploit, not many organizations may be aware of Log4Shell or realize the extent of its damage. That’s because Log4Shell was initially a zero-day vulnerability, one which the software vendor is not aware of or has not yet patched. Although Apache has since patched the vulnerability, it is ultimately still up to the organizations using Log4j to update to the latest secure patch. Until then, the organization’s systems remain at risk.
By now, we’ve probably convinced you that Log4j is a highly dangerous vulnerability that organizations must immediately contain. But how exactly can one address this vulnerability?
The FTC has outlined several steps for mitigating the Log4Shell, which include:
It is important to note that the FTC is taking the Log4j risk very seriously. Organizations that are not taking steps to remediate the Log4j risk are liable to prosecution under the full extent of the law. It is the responsibility of such organizations that store sensitive user data to ensure that their users’ privacy and security is fully protected.
Since Log4j is an essential part of most software supply chains, not adequately addressing the Log4j vulnerability means your organization’s entire supply chain and development operations can also be at risk.
However, given the massive scale of Log4j, just updating to the latest security patches alone may not be enough. As the exploit continues to make waves throughout the media, more Log4j exploit variations will keep on emerging.
Fortunately, Kiuwan Security Solutions can protect your organization from exploits such as Log4j and its future variants. Kiuwan is an information technology security organization that focuses on building state-of-the-art cybersecurity products to protect organizations and their products from exploits and code vulnerabilities. Additionally, Kiuwan recently released a new API specifically for addressing the Log4j vulnerability.
Among the solutions Kiuwan offers are Static Application Security Testing (SAST) and SCA software insights. SAST can automatically scan your codebase for vulnerabilities and identify them, including the Log4j vulnerability Log4Shell. SCA insights is another application security testing tool that helps reduce risk from open source and third-party code components.
All Kiuwan code security solutions fully comply with the best IT security standards today, such as CERT, NIST, and OWASP. So rest assured, your system is guaranteed to be in safe hands with Kiuwan.
The Log4j risk vulnerability known as Log4Shell may be one of the most severe of all time. Not only that, but the FTC has publicly called for software organizations to immediately address the vulnerability to keep their customers and their data safe.
If you’re looking for an additional layer of security against Log4Shell, why not give Kiuwan Security Solutions a try to ensure your organization’s and customers’ safety?
