As we head into the holiday season and organizations begin to wind down for end-of-the-year festivities, admins the world over have been handed a lump of coal, while bad actors looking to exploit systems have essentially received an early gift in the form of the Log4j vulnerability. One that affects a widely used component of many software applications and services. This is not unique to any one company, with potentially hundreds or thousands of products affected. Ranging from networking equipment to server management software and consumer & enterprise applications (to name a few), vendors will need to scramble to update vulnerable software to patch against the vulnerabilities that have been uncovered.
In this blog, Jamf aims to provide insight for users who are not familiar with this (and any subsequent) critical vulnerability and provide those with working knowledge of the issue some guidance based on security best practices to mitigate these vulnerabilities.
- What is Log4j and why is it such a problem?
- What Jamf products are affected by the vulnerability and how is Jamf mitigating it?
- How can Jamf products help your organization mitigate these threats?
Canto I: What is Log4j?
Pronounced “Log Forge”, the critical vulnerability is a flaw that exists within the popular Log4j, Java-based logging library that it is susceptible to a Remote Code Execution (RCE) exploit. Initially assigned CVE-ID, CVE-2021-44228, the vulnerability refers to the flaw in Apache software, Log4J, which is a library used by various applications to log information during the execution of Java applications. It is one of, if not the most, common library developers use for both open source and commercial software.
Canto II: Why is it such a big deal?
Due to its widespread use and implementation across various devices and vendors, the true impact of this severe threat cannot be quantified. What is known is that RCE-type vulnerabilities rate it at a critical severity level since exploiting the flaw allows threat actors to effectively execute code remotely on the affected systems without necessarily being authorized to do so. These types of attacks essentially permit attackers to exploit devices and potentially the data they contain. The initial vulnerability effectively allowed an attacker to ask the log4j library to download arbitrary code from a server the attacker controlled and run it as if it was part of the application itself. Effectively an attacker could take over any application that utilized log4j even if the attacker never had to authenticate to the service using the library.
Furthermore, the word “vulnerabilities” mentioned prior was not a typo. But rather, the plurality refers to a second vulnerability (CVE-2021-45046) that has been discovered as a result of the fix for the initially detected vulnerability being incomplete due to certain non-default configurations. On the plus side, the additional vulnerability seems to be more of a Denial of Service (DoS) attack rather than a take-over-your-service attack.
What does this mean for resolving Log4j you may be asking? Well, it’s still bad, but it’s getting better. In cases such as these, it is not uncommon for multiple levels of updates to be required to fully patch against the threat. As for it getting better, this second identified vulnerability no longer permits RCE exploits but does still allow attackers to maliciously craft input data resulting in a DoS attack.
Canto III: How is Jamf affected by it?
Like many other vendors, including Apple, Google and Microsoft, unfortunately, some Jamf products were affected by the Log4j vulnerability. Due to the nature of the CVE-2021-44228 and CVE-2021-45046 vulnerabilities, their critical severity rating and their potential to impact services, Jamf acted quickly. Aaron Kiemele, Jamf’s CISO created a dedicated Jamf Nation post providing Jamf users with the latest information on how Log4j impacts Jamf services as well as information on the strategies currently being implemented by Jamf to mitigate this threat on its services.
- Jamf Pro (on-premises): Patched release available
- Jamf Pro (cloud-based): Mitigated and Patched
- Jamf Connect: Not Affected
- Jamf Now: Not Affected
- Jamf Protect: Not Affected
- Jamf School: Not Affected
- Jamf Threat Defense: Not Affected
- Jamf Data Policy: Not Affected
- Jamf Private Access: Not Affected
- Health Care Listener: Not Vulnerable
- Jamf Infrastructure Manager: Not Vulnerable
According to Matthias Wollnik, a Product Marketing Manager at Jamf with a focus on Security, "Jamf Infrastructure Manager (JIM) only logs internal operational data and does not log any untrusted, or client-supplied information. As a result, an attacker has no avenue to supply a message to Log4j that would allow them to exploit the recent vulnerabilities".
…and what mitigation strategies does Jamf have in place?
For Jamf Pro instances that are on-premises, or self-hosted by your organization, the issue is addressed completely as of version 10.34.2 which includes log4j 2.16. A previous version (10.34.1) was released containing log4j 2.15. The latest information indicates that log4j 2.15 requires additional configuration to be secure against CVE-2021-45046. Jamf advises on-prem admins to update to the 10.34.2 version as soon as possible.
If organizations cannot upgrade to this latest release at this time, you can choose to alternatively implement a workaround by manually updating the Log4j instance on affected systems and setting the corresponding configuration, as described in Jamf’s technical document. Performing the workaround will not affect future updates negatively.
Cloud-hosted Jamf Pro instances have been mitigated through appropriate security controls and are not vulnerable at this time. However, out of an abundance of caution, Jamf Pro 10.34.2 is being rolled out to these customers as well.
Canto IV: What can we do to protect ourselves?
The Log4j vulnerability has such far-reaching implications worldwide, that in the U.S., the Cybersecurity & Infrastructure Security Agency (CISA) created a website and GitHub repository aimed at tracking and responding to the widespread exploitation affecting the Apache Log4j library. Additionally, CISA provided vulnerability guidance in the form of a live document that provides admins and security teams with up-to-date information on how to protect against affected systems, with ongoing sources for detections rules to aid in detecting exploitations, Log4Shell hashes, mitigation guides for various software developers and vendors, and additional resources for global agencies, such those found in North America, Europe and Asia.
“Patch fast and patch often” – Jamf
Apart from patching the necessary Log4j vulnerability with the patch(es) obtained from your software developer’s website, or at the very least, a workaround that provides a means to update the vulnerable Log4j libraries that may be embedded into components that make up the affected app or service that relies on it.
By leveraging Jamf Pro, IT admins can make short work of not only identifying which systems have older versions of affected applications but also creating Smart Groups to gather them dynamically, using the software deployment feature to update impacted apps directly and/or remotely deploy patches, as needed.
Beyond that, there are some foundational security procedures that admins can (and should) follow to limit the organization's exposure to security threats or potentially mitigate risks stemming from Log4j vulnerabilities.
How do you know what’s vulnerable unless you know what you have? That’s the first step: assessing what devices, apps and services comprise your organization's infrastructure. Keeping an updated inventory allows you to know exactly what resources your organization owns, how they’re utilized and what exactly they’re used for. Armed with this knowledge, admins can easily determine what’s at risk and move forward in determining to what degree before deploying mitigation strategies.
Software Bill of Materials
Abbreviated as SBOM, these act as software component inventories that provide organizations and developers alike with accurate and easy-to-understand descriptions of the fundamental building blocks of the components that go into software applications and services. The benefit to this from an enterprise viewpoint is that it allows security teams a simple way to ascertain which components may be exposed to specific vulnerabilities within first and third-party apps in use.
Defense in depth
This security best practice has been proven to protect resources by layering multiple security protections, applying them in such a way to build one upon the next solution to strengthen the overall security of systems, apps and services. While defense-in-depth strategies won’t resolve the underlying vulnerability, they can offer a means of protection against the effects of the vulnerability by limiting the attack surface of an affected app and/or by containing the exposure.
One such example is utilizing Jamf Protect to identify any attackers leveraging the vulnerability. As of yesterday, customers have a new detection in their UI titled SuspiciousJavaActivity. This is detection that looks for either curl or bash -i running under Java. This is a behavior that many different attackers are abusing when it comes to the Log4j vulnerability. A detection on this might be a sign that a Log4j exploit has occurred. However, some legitimate Java applications may also perform these actions (rarely, we hope). It's up to the security analyst to determine what is and isn't normal for the application in question.
One important thing to remember: personal macOS systems are unlikely to have many if any, active applications using Log4j that an attacker may interact with remotely. Analysts can take this into consideration when trying to make determinations of whether an alert is worth pursuing.
The principle of least privilege is widely regarded as a baseline component that admins bake into their security processes to keep user access limited to only what’s necessary for them to be productive – no more, no less. The principle applies to the host, application and network levels, all of which may be hardened to prevent systems that are victims of the RCE exploit in Log4j from initiating connections as a form of egress control. This type of security helps admins lockdown and contain compromised systems until the vulnerability is patched.
Web Application Firewall
WAFs have shown to be a great piece of protective software that effectively blocks attempts to communicate with services and apps that are affected by the Log4j vulnerability. In short, un-obfuscated strings, as well as those with simple evasion techniques employed should be easily stopped by a capable WAF. However, as researchers have noted, threat actors are increasingly adapting their usage of the Log4j language to include key strings that have been encoded to evade detection using more complex lookups to disguise critical strings. Security teams should take great care to evolve their WAF rules to identify and block these obfuscated strings, preventing attempts to exploit vital systems.
Monitoring & reporting
Active scanning for Log4j vulnerable systems has been reported by several security agencies to be at an all-time high. Making matters worse is guidance that indicates nation-states are backing threat actors, as attacks continue to evolve. Monitoring your infrastructure actively to not only identify vulnerable systems and apps but also to assess device health is crucial to protecting your organization’s security posture. Additionally, reviewing reports for key indicators of compromise, including hashes associated with the “Log4Shell” exploit feed admins the threat intelligence details needed to adjust protections, such as WAFs, to mitigate ongoing risks.