Hackers can take control of millions of servers, shut them down or force them to spew malware due to common error code. Here’s how it happened and what you can do to protect yourself.
The Log4j exploit, referred to by some as Log4Shell or CVE-2021-44228 , has been in the news for the past few weeks. It’s bad! It is everywhere! But what is it? How did it end up on millions of servers? And how can you protect yourself from the effects of this vulnerability?
That’s not data – that’s code!
The crux of the problem with Log4j is a confusion between simple data and executable commands. Malicious coders have almost always exploited this kind of confusion.
In the days of DOS-based computer viruses, programs on disk were simply copied and started directly into memory. Early viruses added in the form of a data block at the end of the host program. By adjusting a byte or two at the beginning of the program, they made DOS execute the virus code before starting the program. And the virus added to more programs during its short run.
Windows programs, called portable executable (PE) programs, are much more advanced. Different blocks of information are loaded into the appropriate memory area and those blocks are marked as code or data. Still, adversaries succeeded in attacks that forced the execution of what was supposed to be data. Modern Windows versions use Data Execution Prevention (DEP) and Address Space Layout Randomization (ASLR) to thwart such attacks.
Java and Open Source
Log4j is written in Java, which means it doesn’t have intrinsic protections like DEP and ASLR. On the other hand, it is an open-source package. That means anyone (well, anyone with coding skills) can read the source code, spot any bugs, and help improve the package.
The theory is that open-source code is more secure because it’s been scrutinized and there’s no possibility of a backdoor or other unwanted feature hiding in the code. When the library involved is very sensitive, perhaps with regard to coding, it is really seriously examined. But apparently this simple log-writing module didn’t get enough attention.
Why is it everywhere?
When there is a vulnerability in an operating system or a popular browser, it usually only affects the users of that operating system or browser. The publisher is working on a new version that closes the gap, releases an update and all is well.
Log4j is different. It is not an operating system, or a browser, or even a program. Rather, it is what coders call a library, or a package, or a code module. It serves one purpose: to keep a log of what happens on a server.
People who write code want to focus on what makes their program unique. They don’t want to reinvent the wheel. So they rely on endless libraries of existing code, such as Log4j. The Log4j module comes from Apache, the most widely used web server software. And that’s why it can be found on millions of servers.
Who is the victim here?
Here is an important point. Attacks using the vulnerability in Log4j are not aimed at you. A hacker forcing 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 major companies have been affected.
You may have seen (or skimmed) a YouTube video where a security researcher demonstrated that you took over a Minecraft server with nothing more than in-game chat. That doesn’t mean it affected the players involved in the chat. It means that the researcher forced the server to run arbitrary code.
But don’t relax yet. A hacker who can run arbitrary code on the affected server has unlimited options. Of course, a ransomware attack on the server owner can be quite lucrative, as can co-opting the server to do bitcoin mining. But it is also possible that the hacker undermines the server, thereby inflicting malware on visitors to websites hosted on that server.
What can I do?
The Log4j exploit is just one of many vulnerabilities exploited by bad actors. The CISA’s catalog of exploited vulnerabilities lists 20 found in December alone. If you look closely, you can see that some have already been fixed, but others have a fix that only needs to be implemented for six months or more. Few, of course, will have the impact of the Log4j exploit.
As for the protection against Log4j on the server side, it’s laughably simple. There is a setting that determines whether the logging system can interpret data as code. Turning off that switch does the job. Of course 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 is turned off by default.
As noted, Log4j is code designed for servers and the exploit attack affects servers. However, you could be indirectly affected if a hacker uses it to disable a server that is important to you, or tries to use the server for drive-by downloads or other malware attacks.
There’s nothing you can do to prevent the impact of a server takedown, but you can protect yourself against those secondary attacks by installing a strong antivirus program and keeping it up to date. Do your part by staying alert for phishing fraud, using a password manager, and directing your internet traffic through a Virtual Private Network or VPN. If you keep your own data, devices and connections secure, you are unlikely to be affected by the effects of a Log4j exploit attack.