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

Dec 10, 2021 by Jason McIntosh

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.

 

Share this post:

Recently Published Posts

How to Become a Site Reliability Engineer (SRE)

Jun 6, 2023

A site reliability engineer (SRE) bridges the gap between IT operations and software development. They understand coding and the overall task of keeping the system operating.  The SRE role originated to give software developers input into how teams deploy and maintain software and to improve it to increase reliability and performance. Before SREs, the software […]

Read more

Continuous Deployment KPIs

May 31, 2023

Key SDLC Performance Metrics for Engineering Leaders Engineering leaders must have an effective system in place to measure their team’s performance and ensure that they are meeting their goals. One way to do this is by monitoring Continuous Deployment Key Performance Indicators (KPIs).  CD and Automated Tests If you’re not aware, Continuous Deployment, or CD, […]

Read more

What Are the Pros and Cons of Rolling Deployments?

May 26, 2023

Rolling deployments use a software release strategy that delivers new versions of an application in phases to minimize downtime. Anyone who has lived through a failed update knows how painful it can be. If a comprehensive update fails, there are hours of downtime while it is rolled back. Even if the deployment happens after hours, […]

Read more