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

Continuous Deployments meet Continuous Communication

Sep 7, 2023

Automation and the SDLC Automating the software development life cycle has been one of the highest priorities for teams since development became a profession. We know that automation can cut down on burnout and increase efficiency, giving back time to ourselves and our teams to dig in and bust out innovative ideas. If it’s not […]

Read more

Happy 7th Birthday, Armory!

Aug 21, 2023

Happy 7th birthday, Armory! Today we’re celebrating Armory’s 7th birthday. The parenting/startups analogy is somewhat overused but timely as many families (at least in the US) are sending their kids back to school this week. They say that parenting doesn’t get easier with age – the challenges simply change as children grow, undoubtedly true for […]

Read more

Visit the New Armory Developer Portal

Aug 11, 2023

Easier Access to Tutorials, Release Notes, Documentation, and More! Developer Experience (DX) is one of Armory’s top focuses for 2023. In addition to improving developer experience through Continuous Deployment, we’re also working hard to improve DX for all of our solutions.  According to ThoughtWorks, poor information management and dissemination accounts for a large percentage of […]

Read more