Update on 15/12/2021: A new vulnerability has been found for Log4j, affecting even the 2.15.0 version. Developers should update to 2.16.0 to completely disable the JNDI module, or remove the JndiLookup class from previous versions.
A new zero-day vulnerability was recently dropped for Apache Log4j, a commonly used logging library in Java. The vulnerability is rated as critical, and was given a CVSS rating of 10. This exploit affects a huge number of apps, with reports of it working in Minecraft, Twitter, iCloud, SMS shortcode services and many more. A lot of the services has since been patched, but exploit may still affect unpatched systems.
On December 9, 2021, a Github repository popped up with a proof of concept for a new exploit. Now known as CVE-2021-44228, Log4Shell allows for remote code execution (RCE) by running arbitrary codes through the JNDI system. Basically, it means an attacker can send a string of command to an active Log4j session to exploit the vulnerability. An example is shown below:
Log4Shell is particularly serious. Logging is an essential part of software. Since a lot of system uses Java and Apache, a lot of websites are vulnerable to this attack. There has been reports of hackers actively domain scanning to exploit this vulnerability. Users cannot do much to protect themselves, other than to wait for the server to be patched.
So far, numerous agencies has issued alert about the vulnerability. The United States Cybersecurity and Infrastructure Security Agency, Austria’s CERT and New Zealand’s CERT all released an advisory on the exploit. Apache has also acknowleged and patched the vulnerability in an update.
Log4Shell Mitigations
Since the announcement of the attack, the community has released new patches and mitigation method. Affected system can be patched using Log4j 2.15.0. Log4j 2.16.0 will disable JNDI completely, therefore nullifying that vector of attack.
Failing that, Cyberason has released Logout4Shell as a “vaccine patch”. It uses the vulnerability to patch the system, making it immune from further exploitation. In the worst case scenario, appending -Dlog4j2.formatMsgNoLookups=true will neutralise the threat.
While certain Java versions, like 8u191 has partial mitigation of the exploit, they are not completely immune. The recommendation to update Log4j to the latest version still stands.
The Log4Shell vulnerability only highlights the danger of a homogenous codebase. A certain XKCD comic comes to mind:
Interested in articles like this? Check out our reporting on Gigabyte ransomeware attack, or the data breach at Acer.
Read more about Log4Shell:
Remote code injection in Log4j · CVE-2021-44228 · GitHub Advisory Database
Log4Shell: RCE 0-day exploit found in log4j 2, a popular Java logging package | LunaSec
Log4Shell explained – how it works, why you need to know, and how to fix it – Naked Security (sophos.com)
