Written by akendo on 
4 minutes reading posted in Security
with tags: java 100daystooffload

Log4Shell

Okay, at this point you already have heard of the new hot shit in the infosec: Log4shell or CVE-2021-44228. In case you don’t, here is the news: Log4Shell is a Zero-day vulnerability within the default logging facility of Java. This was the 10th of December. At this stage everyone has rushed to shodan and to find for services, application or anything that run with Java that takes any input and logs it.

Background about log4j

Log4j is more than just a framework for logging. It exists also in different implementation for PHP. There are some unofficial ports as well. It is out since around 1996. To make use of log4j, your code has to Initialize an instance of it. I’m using here the example code from the of LunaSec:

static Logger log = LogManager.getLogger(YOUCLASSNAME.class.getName());

Now you can use logging in your code to created different types of message:

log.debug("Request User Agent:{}", userAgent);

That’s it. Nothing special about. So, what’s going wrong here? So in the report of the LunaSec, they created simple HTTP Server that will print out the user agent of a client. To exploit this flaw, we need to provided the malicious payload:

curl 127.0.0.1:8080 -H 'User-Agent: ${jndi:ldap://127.0.0.1/a}'

Now, your Java codes start to fetch the resource a from localhost and tries to execute it. Why? That’s what the JDNI in the string does. There were some more change Oracle disabled. But the LDAP feature remain working until now. The exploit might require a bit more effort to have a workaround in place. However, it is just some more effort.

Background about JDNI

For this, we need to take a look at the JDNI keyword. There is a lot of resource about that subject, in its core it is a basic vulnerability. The default logging facility provides the ability to utilizes the JDNI standard. The ‘Java Naming and Directory Interface’ or JDNI is an API for the utilization of a directory or name service like LDAP.

It should allow looking up for external resources. This is useful when you do not quite not know where your databases will be and defining this RMI type to. Effectively is this an RPC type of services, but as always, a java like fashion. They support:

Older versions of log4j seems to be not affected. Different feature has been disabled. For instance, the RMI feature was disabled with the release of Java 8u121.

RMI has been disabled in later version of Java that minimizes the attack vector. However, there might be quite some workarounds for this. To exploit this vulnerability, you can utilize something called marshalsec. This is general deserialization problem of the Java RPC not able to ensure that not something bad is happening and leading to RCE in this case. So, this might apply to the vulnerability as well.

We knew about the capability of JDNI at least since 2016. On the BlackHat, this was documented in a white paper!

Impact

This vulnerability was introduced in 2013. Meaning that we’re having a zero-day for around 8 years by now. Good Luck, check if it has been exploited before.

It is a dead simple vulnerability, it out-weight hearthbleed, and does not require much knowledge to exploit. Hearthbleed on the other side did only return random memory samples at had at least a a bit of effort that need to be put to make sure that this was useful. Creating this string is childlike easy, and running a server that can provide the necessary Java Class is effortless at this time.

More wire is that we can see that almost all vendors are affected. Even renaming your iPhone causes the something within the iPhone to execute it. It is so wildly deployed that it might be on Mars! Now that’s a fix to roll. Good thing, that there is no Internet on Mars.

Responses

When you have an application with Java in it, you most likely have log4j running. Hence, I advise you to disable it. This is a 10/10 in the CVE score. It does not become worse. The log4j have nuked the feature just now. We see attacks that aims to exploit this, worms that should be in development and ransomware that starts to exploit it.

Even with a up-to-date Java, you aren’t safe. Some people have done great responses to mitigate it. The best fix so far is from Cyberreason. But in the end, the best is to install the latest version of log4j and be done with it.

best regards,
akendo