The Log4j exploit, called Log4Shell or CVE-2021-44228 by some, has been in the news this past few weeks. It’s bad! It’s everywhere! But just what is it, really? How did it make its way onto millions of servers? And how can you protect yourself from the consequences of this security hole?
That’s Not Data—That’s Code!
At the heart of the problem with Log4j is a confusion between simple data and executable commands. Malicious coders have been exploiting this kind of confusion practically forever.
In the days of DOS-based computer viruses, programs on disk were simply copied straight into memory and launched. Early viruses appended themselves in the form of a data block at the end of the host program. By tweaking a byte or two at the start of the program, they caused DOS to execute the virus code before launching the program. And the virus appended itself to more programs during its brief run.
Windows programs, called Portable Executable (PE) programs, are vastly more sophisticated. Various blocks of information load into the appropriate memory area, and those blocks are marked as code or data. Even so, malefactors managed attacks that forced execution of what was supposed to be data. Modern Windows versions use Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) to foil such attacks.
Java and Open-Source
Log4j is written in Java, which means it doesn’t intrinsically have protections like DEP and ASLR. On the other hand, it’s an open-source package. That means anybody (well, anybody with coding skills) can read the source code, spot any bugs, and contribute to improving the package.
The theory is that open-source code is safer because it’s been examined by many sets of eyes, and because there’s no possibility of a backdoor or some other unwanted feature hiding in the code. When the library involved is highly sensitive, perhaps involving encryption, it really does get serious scrutiny. But apparently this simple log-writing module didn’t receive sufficient attention.
Why Is It Everywhere?
When there’s a security hole in an operating system or a popular browser, it typically affects just the users of that operating system or that browser. The publisher works up a new version that patches the hole, pushes out an update, and all’s well.
Log4j is different. It’s not an operating system, or a browser, or even a program. Rather, it’s what coders call a library, or a package, or a code module. It serves one purpose—keeping a log of what happens on a server.
People writing code want to focus on what makes their program unique. They don’t want to re-invent the wheel. So, they rely on endless libraries of existing code, such as Log4j. The Log4j module comes from Apache, which is the most widely used web server software. And that’s why it’s found on millions of servers.
Who Is the Victim Here?
Here’s an important point. Attacks using the vulnerability in Log4j are not aimed at you. A hacker who forces it to log a line of text that becomes a command is aiming to install malware on the server. Microsoft reports that state-sponsored hackers are using it, likely to push ransomware. Apple, Cloudflare, Twitter, Valve, and other large companies have been affected.
You may have seen (or skimmed) a YouTube video in which a security researcher demonstrated taking over a Minecraft server using nothing more than in-game chat. That doesn’t mean it affected the players involved in the chat. It means the researcher forced the server to run arbitrary code.
But don’t relax just yet. A hacker who can run arbitrary code on the affected server has unlimited options. Sure, a ransomware attack on the server’s owner could be quite lucrative, as could co-opting the server to do bitcoin mining. But it’s also possible that the hacker could subvert the server, causing it to inflict malware on visitors to websites hosted on that server.
What Can I Do?
The Log4j exploit is just one of many security holes being exploited by bad actors. The CISA’s exploited vulnerabilities catalog lists 20 found in December alone. Looking closely, you’ll see that some are fixed already, but others have a fix that’s not due for six months or more. Few will have the impact of the Log4j exploit, of course.
As for protecting against Log4j on the server side, it’s laughably simple. There’s a setting that controls whether the logging system can interpret data as code. Turning that switch off does the job. Naturally Apache has released an update to the code module, but some researchers report that the only significant change in the update is that this switch defaults to off.
As noted, Log4j is code designed for servers, and the exploit attack affects servers. Still, you may be affected indirectly if a hacker uses it to take down a server that’s important to you, or tries to use the server for drive-by downloads or other malware attacks.
There’s nothing you can do to avoid the impact of a server takedown, but you can protect against those secondary attacks by installing a powerful antivirus utility and keeping it updated. Do your part by staying alert for phishing frauds, using a password manager, and running your internet traffic through a Virtual Private Network, or VPN. Keeping your own data, devices, and connections secured means you’re unlikely to be affected by the fallout from a Log4j exploit attack.
