A critical remote code execution (RCE) zero-day exploit has been discovered in the popular Java logging library log4j. This vulnerability affects a wide range of internet-facing applications that use log4j, including many popular websites. The exploit is based on a previously unknown vulnerability in the Java Runtime Environment (JRE). If exploited, the vulnerability could allow an attacker to execute arbitrary code on a vulnerable system. This RCE exploit is being actively exploited by cybercriminals in attacks against websites and other online services. As such, organizations that rely on log4j for their infrastructure are at risk of being attacked. If you are using log4j in your organization, please review the security advisory and update your software as soon as possible. ..
A critical remote code execution vulnerability has been found in log4j, a very popular logging tool used by most of the industry. It’s extremely severe, affecting nearly every server running Java, and is very simple to exploit, so you will want to update and mitigate the issue ASAP.
How Does This Work?
The bug, tracked by CVE-2021-44228, likely affects almost any Java application using log4j, which is quite a few considering how ubiquitous it is. If your application ever logs a string sent in by a user, it’s probably vulnerable. As far as exploits go, it’s one of the worst ones this year, as it can target basically any server running Java in some fashion (though the primary attack vector may be harder on modern JDK versions, more on that below).
Essentially, the exploit allows an attacker to send your server any string like the following, and if it logs it somewhere in your app, your server will execute code hosted at that address.
This works because, when parsing this uniquely formatted string, log4j will make a request through the Java Naming and Directory Interface, which ends up sending a download request to an arbitrary endpoint. It downloads and deserializes the .class file in an insecure manner. Because Java classes can have static initializers that run whenever the class is compiled and referenced, this results in remote arbitrary code execution from a simple, short string. For example, a client could set their user-agent to this string, or otherwise include it in a request, and when your server logs it, it will trigger the exploit.
That’s pretty horrible, scoring a perfect 10 on the CVSS scale.
RELATED: How Are Security Vulnerabilities Ranked? (CVSS)
It’s going to affect a lot of applications. For example, Minecraft was one of the first to spread the news and patch the exploit, as it was possible to execute code both on servers and on all players connected to a server through the in-game chat messages. A hotfix update for the game was released to patch the bug.
Popular services like Steam and iCloud have already been found to be vulnerable, and security research firm GreyNoise has already detected multiple IPs running scans for vulnerable servers.
— remy🐀 (@_mattata) December 10, 2021
You’re probably already running log4j, as it’s included in hundreds of other libaries as the standard logging tool. However, JDK versions greater than 6u211, 7u201, 8u191, and 11.0.1 are not affected by the primary attack vector (using LDAP) that’s being exploited right now. That isn’t to say you shouldn’t update, since the bug in log4j + JNDI is still severe, and can easily be used with other attack vectors as well.
How Do I Fix It?
Luckily, there is already a fix that patches it entirely, so you should update your servers ASAP. This affects client applications as well though, which also need to update for this critical patch. After all, 3 billion devices run Java, so it’s going to be a while before it’s fully fixed.
The exploit has already been patched in log4j‘s latest release, 2.15.0-rc2, so you should update that if you can. The patch has also been backported to earlier versions, given the severity for users who may be stuck on legacy releases.
If you’re using another library that uses log4j, you should still be able to manually update in most cases, but if you can’t, you can use this JVM flag to mitigate the issue, which simply tells log4j to never do any lookups when formatting messages.
