The quick log4j vulnerability explainer

A devastating zero-day vulnerability was disclosed rather unwittingly via a tweet and a post on Github that showed sample code being executed remotely via the log4j. This exceptional post from lunasec.io is where some people from the infosec community would have encountered the information first on Friday, December 10, 2021.

• This zero-day, notified as CVE 2021 - 44228, is a command injection vulnerability in Apache log4j (more formally known as Remote Code Execution, or RCE)
• This is a widespread issue that affects a lot of applications, that use Java and the logging library, log4j

A story in three parts 😶 #log4j pic.twitter.com/XMl02BcaJY

— Cas van Cooten (@chvancooten) December 10, 2021

This log4j (CVE-2021-44228) vulnerability is extremely bad. Millions of applications use Log4j for logging, and all the attacker needs to do is get the app to log a special string. So far iCloud, Steam, and Minecraft have all been confirmed vulnerable.

— Marcus Hutchins (@MalwareTechBlog) December 10, 2021

Any application, either a stand-alone, or a web application generates logs when input is supplied, or when other actions are performed

• Programming languages have libraries to handle and take care of logging for you like Apache's log4j
• log4j unfortunately has a system where you can have jndi commands passed as a log entry, that will get interpreted as code!
• Normally, a logging capability should handle this as text! NOT AS CODE.
• This means, an attacker can run code via this zero-day on any box using log4j.
• Sometimes, this logging library may be running on sensitive servers, or cloud instances, making most of these vulnerable to remote code execution!
• Huntress researcher John Hammond recreated a proof-of-concept attack based on this vulnerability. Notice the text in yellow - that is the command used to inject code

• These sort of vulnerabilities are generally mitigated by 'input sanitization' however,
• This cannot just be mitigated by removing or sanitizing the JNDI command. Attackers can obfuscate those commands, and it will be difficult to find
• Turns out that you can pass a LDAP query and the logging library will execute it as a code
• JNDI = java naming and directory interface
• LDAP (lightweight directory access protocol) functionality, a network communications technology, is actively being exploited in this zero-day

Black Hills Information Security did a fantastic recap on the history of major vulnerabilities, and the industry's reaction to devastating zero-days like Heartbleed and Shell Shock. They have some great thoughts on the nature of this zero-day and how it will be a major concern for years to come

• There are excellent write-ups on what is affected, and the security community is working tirelessly to patch vulnerable systems. These are the following mitigations recommended:
• Upgrade to Apache Log4j 2.15.0
• Set the system property formatMsgNoLookups to TRUE
• set the JVM parameter Dlog4j2.formatMsgNoLookups=true
• Remove the jndiLookup class from the classpath
• Block if you can LDAP lookups from OUTSIDE your environment

Excellent further reading by SwitHak that put together a compilation of all the vendor updates and mitigations that are currently taking place, or recommended

Further thoughts and the way forward

This vulnerability demonstrates a category of attacks that the "offensive community" (as John Strand likes to call them) will keep attempting to exploit. It is obvious at this point that other logging libraries, or other such open source applications will be probed for such vulnerabilities.

There is no user input required, no one is required to be phished or tricked into clicking a link with this vulnerability. That is what makes it most dangerous. Additionally, logging is a normally benign technology that resides on even sensitive servers or probably even on Industrial control systems, or other such risky environments.

Vulnerabilities that offer remote code execution on a broad range of systems are the most sought after by the most sophisticated players and cyber-criminals in the offensive space. A big thanks to John Strand and the team at Black Hills for such a fantastic recap. Spare a thought for the members of the infosec community working tirelessly over the weekend to mitigate and patch systems.