Log4J – What you should know

Preface

The following is a collage of useful information re-shared by Catapult from several external sources including Log4Shell, Microsoft, and Catapult’s Spyglass team regarding the recent and critical security vulnerability affecting log5j. In order to rapidly help clients identify where their systems are vulnerable, our technical team has designed some purpose-built tools that query all Azure Subscriptions in a tenant to identify Virtual Machines with potential Log4j vulnerabilities. This is helping our clients quickly identify potentially at-risk machines and helping prioritize tactical remediation efforts.

If you are concerned that you may be exposed to this vulnerability, or simply don’t know if you are exposed – please contact me or our Spyglass team.

Security Alert and Advisory

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.

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).

Log4j versions prior to 2.15.0 are subject to a remote code execution vulnerability via the ldap JNDI parser. As per Apache’s Log4j security guide: Apache Log4j2 <=2.14.1 JNDI features used in configuration, log messages, and parameters do not protect against attacker-controlled LDAP and other JNDI related endpoints. An attacker who can control log messages or log message parameters can execute arbitrary code loaded from LDAP servers when message lookup substitution is enabled. From log4j 2.15.0, this behavior has been disabled by default.

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.

You’re probably already running Log4j. as it’s included in hundreds of other libraries as the standard logging tool. However, JDK versions greater than 6.211, 7.201, 8.191, 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.

Recommended Actions

Patch as soon as possible, after testing and following regular change management.

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.

-Dlog4j2.formatMsgNoLookups=true

Information from Microsoft

Here is a summary of what Microsoft had of information https://msrc-blog.microsoft.com/2021/12/11/microsofts-response-to-cve-2021-44228-apache-log4j2/

On December 9, researchers published a proof-of-concept (POC) exploit code for a critical vulnerability in Apache Log4j 2, a Java logging library used by a number of applications and services including but not limited to:

This vulnerability could be weaponized to execute malicious code and allow a complete takeover of vulnerable systems. It is also an appliance for other custom-built applications, even including Red Hat Openshift and also a number of VMware products which has now been confirmed as well. Here you can see that a PoC has been built for VMware vCenter https://twitter.com/tnpitsecurity/status/1469429810216771589?s=21

You can find an updated list of affected products here —> https://github.com/YfryTchsGD/Log4jAttackSurface

You can also read the info from VMware here. This just shows how large an impact this vulnerability has –> https://core.vmware.com/vmsa-2021-0028-questions-answers-faq#section1

Tracked as CVE-2021-44228 and by the monikers Log4Shell or LogJam, the issue concerns a case of unauthenticated, remote code execution (RCE) on any application that uses the open-source utility and affects versions Log4j 2.0-beta9 up to 2.14.1

There are already reports of attackers successfully exploiting this vulnerability (but as of now) for Bitcoin mining payloads.

Cloudflare noted that it blocked roughly 20,000 exploit requests per minute around 6:00 p.m. UTC on Friday, with most of the exploitation attempts originating from Canada, the U.S., the Netherlands, France, and the U.K.

Citrix is also doing an investigation of the impact on their products: https://support.citrix.com/article/CTX335705

What can we do to protect against vulnerability?

Patch! if you have built a custom application that uses that library.
If you have a 3. Party application/product such as VMware you need to just wait and ensure that you have control of the traffic.
If you are using Log4j v2.10 or above, and cannot upgrade, then set the property

log4j2.formatMsgNoLookups=true

If you have web services that are used to expose the service, you can use WAF custom rules to block the vulnerability, examples here:
Cloudflare WAF mitigation: https://blog.cloudflare.com/cve-2021-44228-log4j-rce-0-day-mitigation/
Citrix ADC WAF (If you have signature files automatically updated you have a new rule that can be used to block the known signatures)

There are many tools that you can use to monitor the traffic, if you want to know if you have this specific library installed within your environment there are different detection mechanisms.

Azure Monitor / Azure Sentinel

ConfigurationData
| where ConfigDataType == “Software”
| order by TimeGenerated desc
| where SoftwareName == “liblog4j2-java”
| summarize count() by CurrentVersion

Yara and other detection rules:
https://gist.github.com/Neo23x0/e4c8b03ff8cdf1fa63b7d15db6e3860b

GreyNoise

Is also monitoring which IP addresses they see who is scanning for vulnerable endpoints –> https://www.greynoise.io/viz/query/?gnql=tags%3A%22Apache%20Log4j%20RCE%20Attempt%22

Information and Testing Tool from Log4Shell

A tool has been setup by Log4Shell to help you test whether your applications are vulnerable to CVE-2021-44228.

You can access the tool here: https://log4shell.huntress.com/

The website will generate a unique identifier to test whether your application is vulnerable to Log4Shell (CVE-2021-44228). A negative test does not guarantee that your application is patched.

Here’s how to use it:

You copy and paste the generated JNDI syntax (the code block ${jndi[:]ldap[:]//…. presented on the site) into anything (application input boxes, frontend site form fields, logins such as username inputs, or if you are bit more technical, even User-Agent or X-Forwarded-For or other customizable HTTP headers)
- Please note that our blog platform disallows the complete syntax, so we have left off the closing curly brace 😅
Click the “View Connection” button after you have pasted in the syntax to see if it received any connection, and verify the detected IP address and timestamp to correlate with when you tested any service
If you see an entry, a connection was made, and the application you tested is vulnerable

The website works by generating a unique identifier for you that you can then use when testing input fields. If an input field or application is vulnerable, it will reach out to this website over LDAP. Our LDAP server will immediately terminate the connection and log it for a short time. This tool will not run any code on your systems.

Please note that this tool is intended for testing purposes only and should only be used on systems you are authorized to test. If you find any vulnerabilities, please read the Cybersecurity & Infrastructure Security Agency (CISA) Coordinated Vulnerability Disclosure (CVD) Guidance

For transparency’s sake, Log4Shell has provided access to the source code for this utility, which can be found here.

Again, If you have any concerns with respect to the log4j vulnerability or need assistance, please contact our team for assistance.

Until next time,