Do you need the software equivalent of a journal to keep track of what’s going wrong in online services or applications? log4j is one such tool that allows developers to track the bugs among the activities of a system and/or application. Tracking the activity of software and hardware processes is called “logging” and is a useful way to keep a close eye on any problems that may arise. Log4j is an open source logging library used in applications and services on the Internet. You may also know this name from recent news coverage. In this article, we’ll go over what Log4j is, use cases for the developer tool, and the reasons why it might pose a security threat in a software development environment.
What is Log4J?
One of the things to consider when a developer writes software that communicates over the Internet (whether it’s intended to receive, process, or send data) is how to track that data through a process called logging. Logging itself is an important task because it involves tracing the code’s behavior and operations, as well as how that code processed the data.
Logging helps developers better understand their software and see where data may have been mishandled (causing incorrect results) or if a hacker has attempted to take control of the code or data, or even through malicious input could do.
Programmers can create logs in many different ways, such as displaying the system’s behavior on a screen or writing it to a text file. However, log files often become complicated and difficult to manage as the complexity of the systems themselves increases and the volume of traffic and storage increases. This is where log management software like Log4j 2 comes in.
Apache Log4j is a Java-based logging framework that is part of the Apache Software Foundation’s Apache Logging Services project. On August 5, 2015, the project committee announced the end of life of log4j 1 and since then log4j 2 has been used. This successor has been rewritten from the ground up and delivered with more mainstream features. Some of the features the successor has over its predecessor include support for XML, JSONand YAML, support for property lookup and extensibility via a custom plugin system. These are just some of the new features in Log4j 2, but what makes the successor a popular logging solution for many organizations, platforms and individuals is that it is an open source platform.
Read: Microservices logging: solutions and challenges
What is Log4j used for?
Log4j 2 is most commonly used in web apps, cloud services and email platforms. Google, Microsoft, Apple, Amazon and big players use it for their cloud platforms and other products. It logs messages from software and searches for bugs with a wide spectrum for its search profile – from basic website and browser information to the smallest technical details of the system on which Log4j is loaded. Not only does it create simple logs, but Log4j 2 can also generate advanced log information by executing commands. This allows us to say that it can communicate with other data sources, including internal directory services.
As mentioned earlier, using a logging API is a crucial part of the software development process – especially for online applications. It’s not enough to just rely on debugging your software yourself; In fact, it doesn’t work without the right kind of feedback. In a production environment in particular, you can’t just rely on debugging tools for regular maintenance. Logging contributes to the development process by adequately recording errors in a complicated environment with minimal human intervention in files or databases. This leads to higher productivity that cannot be achieved by manually finding errors to fix. Within this need, Apache’s Log4j is proving to be the frontrunner in logging for Java applications.
Log4j is the logging framework most widely adopted on the web, with organizations from every corner of the industry integrating the library into myriad applications. Nvidia, Hewlett Packard Enterprise, Cloudflare, Microsoft, iCloud, IBM, Red Hat, Salesforce and Siemens are just some of the major platforms and organizations using Log4j as a logging solution. Even video game applications, like various versions of Minecraft, use Log4j to detect errors. All applications and systems that use Java are most likely using some version of Log4j. Due to the open-source nature, it’s important to understand which version of the logging library you’re using.
Read: Best Java IDEs for 2022
Log4j vulnerability concerns
There have now been reports of a zero-day vulnerability in Log4j 2, publicly announced in December 2021, that involved remote code execution. The vulnerability has since been patched in several consecutive updates, but may still be present in a number of online environments. There are ways to find this vulnerability if you think it’s in your own environment. The Cybersecurity and Infrastructure Security Agency – and several contributors – have released a public use scanner to find versions of Log4j that could be affected by this vulnerability. You can find this scanner on their GitHub. After finding the vulnerable versions, update Log4j of these environments to the latest version.
Many companies have now recognized this vulnerability and have made statements on how they intend to protect their data – and that of their users. If you use applications, services and/or devices that you suspect are connected to Log4j 2, you are encouraged to search for these statements and research if there is a fix for this vulnerability. Otherwise individual users should disable these devices/services. As in most cases for consumers, the answer to failures in such technologies is to disable or update those technologies.
Sometimes, popular open source software that has been around for a while adds new functionality to existing code without carefully examining what is already there. Sometimes these new additions, made by individuals attempting to adapt widely used software to their own needs, open up an earlier set of code in the stack to potential attacks. This was the case with Log4j 2.
Read: Best bug tracking software and tools
Among the myriad of features this library offers, Log4j 2 allows a developer to replace the strings you would tell them with variables. This would define other useful information besides the usual data that Log4j 2 can retrieve and display as strings. This function behaves recursively. So when something is logged, the process iterates through the data, and when it sees something resembling “${VARIABLE}”, Log4j replaces that with a string extension of the appropriate data.
If this string also contains “${X}”, this logging process is repeated. The problem here is that it will do the same with any untrusted data it receives; for example if it is configured to log something like a web browser’s user gene. A smart person could modify this data to include the symbols “${}” so that at the time Log4j logged this data, it would include this extended data called from outside the system. At the very least, this would mean that you couldn’t trust your logs since they are partially controlled by external users.
Making this even worse is another added feature that allows users to use JNDI (Java Naming and Directory Interface) to look up data in other services – like LDAP and DNS. Someone found that if they did the right kind of string input to Log4j 2 to expand and accept commands, it could lead to data exfiltration and even more malicious actions. This makes it all the more important not only to test such software on the receiving end of open source, but also to work with those who maintain the software when you decide to work with and modify their work.
Open source really is a double-edged sword. On the one hand, the benefit of open source is that the source code is available and people can look at it and fix any bugs or add what they need, along with a community that forms around that software. On the other hand, people could stack code on top of more code and, instead of not letting buggy old code die, invariably propagate bugs to new features.
Open source is not inherently secure and this won’t be the last time a security breach like this happens; We probably haven’t seen how bad it can get. But with a proper community mentality around these libraries, we can fix bugs quickly before bad actors exploit them and ruin the internet for all of us.
