CVE-2021-44228 – log4j (Log4Shell) – an analysis

Today marked a 0-day disclosure of a rather nasty vulnerability in one of the most commonly used frameworks for logging – log4j.  This one is nasty on multiple levels.  Note that Armory Enterprise is NOT affected by this vulnerability.  The impact on this vulnerability is likely huge and is already being exploited.  Additionally it can impact both servers and client applications.  Let’s dive into the details.

What is the Log4Shell vulnerability?  Simple put, it’s a way to inject any random code into a system using log4j.  To quote SANS:  “we should stress out that *absolutely any input field* that is controlled by an attacker, and passed to the log4j library can lead to remote code execution.”  It’s distinctly probable this is in most major websites or vendor solutions.  Here’s a simple example of a rest server with the vulnerability:

@RequestMapping(value = "/some/endpoint/${something}", method = RequestMethod.GET)
public String myEndpoint(String something, HttpRequest request, HttpResponse response) {
   log4.warn("Received request from a browser" + request.getHeader("User-Agent"))
}

This is a simple http endpoint in spring boot logging the user agent.  You don’t even need to reference the header – ANY log4j call that logs ANY field without sanitizing it is vulnerable.  It could be as simple as log4j.warn(“User typed in a last name of X”) which could trigger this vulnerability.  All an attacker has to do is include a simple payload.  This attack payload will trigger log4j to connect to a remote LDAP/RMI server and inject custom code from that RMI server into the server running the above.  The attacker just has to run an RMI/LDAP server, define some attack code and is in business.  This is so simple to trigger that it’s scary… and can be done by those with relatively little expertise.  There’s readily available tools to do exactly this (not sharing attack code here!).

What’s worse on this vulnerability is the impact is not JUST to servers. Imagine your Google Pixel phone.  It’s distinctly possible that you might have an app on your phone that uses log4j, and if you go to a bad website or an app has an open hole… well, you just had your phone hacked as well, since it runs Java.  The downside here is that many end users (aka your parents who have a nifty Google Phone) CAN’T implement basics like blocking RMI/LDAP calls from their home network easily like corporate offices can.

No official score has been released on the vulnerability yet but I’d rank this as CVS3.1 score of 10.  It’s simple to implement, you can attack someone from your home computer (don’t do this), it’s trivial to implement the attack, it bypasses any normal authentication privileges (aka it can trigger even when there’s authentication blocks in place), it doesn’t require any user interaction, and did we mention it’s easy to trigger?  As a result of it being an RCE, there’s almost unlimited potential for damage.  It could expose passwords, credentials, sensitive data, and a whole lot more without much effort.

Bottom line for any devs using log4j:  UPDATE YOUR LIBRARY today.  Read the mitigation techniques (NOTE: The LDAP attack vector on recent JVMs is already protected but RMI is not!) and implement these fixes.  Bump fast & release fast as you can.  Block egress on RMI/LDAP from your networks (Note that the port can be included IN the URL so port blocking isn’t a guaranteed fix). It’s also a good reminder to  read and be aware of the OWASP top 10.  This particular vulnerability falls into CWE-502: Deserialization of Untrusted Data.  It’s not the first such vulnerability out there, but this one is scary on several levels.