Third-Party Security Issue

[Aaron_Kiemele]

Update 12/28

On December 9, 2021, a Remote Code Execution (RCE) vulnerability (CVE-2021-44228) was identified in the log4j library (https://www.lunasec.io/docs/blog/log4j-zero-day/). The log4j project released version 2.15 to address this issue. New information has come to light identifying ways to exploit log4j 2.15 when the formatMsgNoLookups parameter was not set. CVE-2021-45046 was assigned to this and fixed on December 16, 2021 in log4j 2.16. 

We have continued to assess the impact and mitigate the vulnerability across our platform (tracked as PI-010403) as the security community has identified new issues in log4j. 

Due to the nature of these issues, these are considered critical vulnerabilities.

What Jamf products are impacted by the log4j vulnerability?

Jamf Pro (hosted on-premises): Patched

• Jamf Pro versions older than 10.31 do not use log4j 2.x (which these vulnerabilities pertain to). However, there are other known security issues that have previously been documented against these versions. We suggest strongly that you update to the latest release.
• The Jamf Pro 10.34.1 release mitigates the initial CVE-2021-44228. To mitigate the latest CVE, customers using 10.34.1 must set the “formatMsgNoLookups=true” parameter as described here. 
• We released Jamf Pro 10.34.2 to include log4j 2.16 and mitigate all currently known log4j vulnerabilities. No further configuration changes are necessary with this release.

We strongly encourage everyone running Jamf Pro on-premises to update to 10.34.2 or follow the manual instructions above as soon as possible.

Jamf Pro (Jamf Cloud and Jamf Cloud Premium): Mitigated and Patched

• Customers utilizing our cloud-based products have had the vulnerability mitigated through layered security controls, including disabling the vulnerable feature across all Java Virtual Machine instances using the formatMsgNoLookups=true parameter value and ensuring only secure message lookup patterns are in use. We are confident that our mitigations are effective against all currently known attacks.
• However, out of an abundance of caution, we are also upgrading all Jamf Cloud customers to 10.34.2 as quickly as possible. If you are a Jamf Premium Cloud customer, your environment has mitigations in place to protect you from these vulnerabilities. However, if you have a need to update to log4j 2.16, you can contact Customer Success and schedule your upgrade to 10.34.2 at your convenience. 

Jamf Connect: Not affected

Jamf Connect does not use the affected libraries.

Jamf Now: Not affected

Jamf Now does not use the affected libraries.

Jamf Protect: Not affected

Jamf Protect does not use the affected libraries.

Jamf School: Not affected

Jamf School does not use the affected libraries.

Jamf Threat Defense: Not affected

Jamf Threat Defense does not use the affected libraries.

Jamf Data Policy: Not affected

Jamf Data Policy does not use the affected libraries.

Jamf Private Access: Not affected

Jamf Private Access does not use the affected libraries.

Health Care Listener: Not vulnerable

While Health Care Listener does utilize the library that includes the vulnerability, it cannot be exploited by an attacker. Healthcare Listener 2.2.2 assets containing the updated version of Log4j 2.17 are available for download on Jamf Account.

Jamf Infrastructure Manager: Not vulnerable

While Jamf Infrastructure Manager does utilize the library that includes the vulnerability, it cannot be exploited by an attacker. Jamf Infrastructure Manager 2.2.2 assets containing the updated version of Log4j 2.17 are available for download on Jamf Account.

Next Steps

On December 17, 2021, we released Jamf Pro 10.34.2 to address the vulnerability. For more information on what’s included in this release, review the release announcement on Jamf Nation or read the release notes here. 

If you cannot upgrade to this latest release, you can choose to manually update the log4j instances of the affected systems as described in our technical documenta.... If you choose to implement the manual workaround as described, future updates (to versions after 10.34.2) will not be affected. For assistance with this workaround, reach out to support@jamf.com. 

UPDATE 12/18

We are aware of CVE-2021-45105 that was remediated in log4j 2.17.0. At this time, this new vulnerability does not seem to affect any Jamf products or services. The conditions required for the exploitation of the vulnerability are not met by Jamf's use of the log4j library. No further action is required at this time.

UPDATE 12/28

We are aware of CVE-2021-44832 that was remediated in log4j 2.17.1. Based on public disclosures to date, this vulnerability does not affect any Jamf products or services. The conditions required for the exploitation of the vulnerability are not met by Jamf’s use of the log4j library. No further action is required at this time. We will continue to monitor the situation and will report on new information as it becomes available.

If you have any questions, please reach out to Customer Success for assistance. 

[tlarkin]

Will we be notified on the fix for jamf cloud?  I have security folks asking for statuses on all our SaaS right now.

[Aaron_Kiemele]

We will update customers for all Jamf products, including Jamf Cloud, when we are able to share more information.

[CalleyO]

@tlarkin See Aaron's response above. I didn't want you to miss it. 😀

[TimArnold]

Can you get Aaron_Kiemele a badge like yours that states his position or employment status with Jamf. Right now it looks like some random person off the street. 

[seabash]

While awaiting official guidance from Jamf, Jamf (esp on-prem) admins might want to review this post RCE 0-day exploit found in log4j 

[mvanstone]

I applied that mitigation and rebooted my server. I'm running 10.34.

Scanning it now to see if anything was dropped on the server. Nothing yet.

Went through stuff like this with Exchange back in March! Not fun!

I also have a case opened (critical) and waiting to hear back from them.

[rhanooman]

So, there's a potential Security issue...and this is the medium for notice? Seems like there's something missing in this process....

[bentoms]

Any update?

[mattmcchesney]

I have our infosec team asking for an update as well. Anything? 

[R_C]

It has been 7 hours since this post was made and we've seen more info from JAMF customers regarding impact and remediation than from JAMF.

An update would be appreciated.

[_Bhupinder_]

Instead of whining at JAMF, why not just TURN YOUR SERVERS OFF for the weekend; at least?

I'm sure JAMF is doing all they can and I appreciate their efforts.

[R_C]

I'm certain that they are working diligently toward addressing this issue.
I've worked with them on addressing a number of issues and they have been incredibly helpful in resolving things.

Although some kind of follow up on the progress made while investigating and remediating the issue would help to alleviate some concern. We all appreciate their effort, you seem to be under the misconception that I don't.

[Aaron_Kiemele]

Updated 12/10 :  On December 9, 2021, a Remote Code Execution (RCE) vulnerability (CVE-2021-44228) was identified in the log4j library (https://www.lunasec.io/docs/blog/log4j-zero-day/) and multiple threat actors have been found to be scanning for vulnerable systems. We are actively working to assess the impact and mitigate the vulnerability across our platform(tracked as PI-010403). 

Due to the nature of the issue, this is considered a critical vulnerability.

What Jamf products are impacted by the vulnerability?

Jamf Pro (hosted on-premises): Affected

Jamf Pro 10.14 and later include Java 11 which partially mitigated the issue. We are actively working on a complete mitigation in a new Jamf Pro release. Until this version is available, a manual workaround to update the log4j library directly is documented below.

Jamf Pro (Jamf Cloud and Jamf Cloud Premium): Mitigated

Customers utilizing our cloud-based products have had the vulnerability mitigated through appropriate security controls. No further actions are necessary.

Jamf Connect: Not affected

Jamf Connect does not use the affected libraries.

Jamf Now: Not affected

Jamf Now does not use the affected libraries.

Jamf Protect: Not affected

Jamf Protect does not use the affected libraries.

Jamf School: Not affected

Jamf School does not use the affected libraries.

Jamf Threat Defense: Not affected

Jamf Threat Defense does not use the affected libraries.

Jamf Data Policy: Not affected

Jamf Data Policy does not use the affected libraries.

Jamf Private Access: Not affected

Jamf Private Access does not use the affected libraries.

Health Care Listener: Not vulnerable

While Health Care Listener does utilize the library that includes the vulnerability, it cannot be exploited by an attacker.

Jamf Infrastructure Manager: Not vulnerable

While Jamf Infrastructure Manager does utilize the library that includes the vulnerability, it cannot be exploited by an attacker.

Next Steps

We will be releasing updates for affected products as quickly as feasible. However, you can choose to work around the issue by manually updating the log4j instances of the affected systems as described in our technical document.... If you choose to implement the manual workaround as described, future updates (to versions newer than 10.34.1) will not be affected. For assistance with this workaround, please reach out to support@jamf.com. 

We are actively continuing to assess the impact and mitigate the vulnerability across our platform. Please note that some customers may experience brief Jamf Cloud interruptions over the weekend as a result of security updates and refinements. If you have any questions, please reach out to Customer Success. 

Due to the urgency, this communication is available in English only and will also be sending this via email to primary technical contacts at affected organizations.

Aaron Kiemele
Chief Information Security Officer, Jamf

[mvanstone]

Where can we download Jamf Pro 10.34.1?

[JenK]

To access the latest version of Jamf Pro, log into Jamf Account with your Jamf ID. The latest version is located in the Products section under “Jamf Pro.”

[Aaron_Kiemele]

Update - 12/14

On December 9, 2021, a Remote Code Execution (RCE) vulnerability (CVE-2021-44228) was identified in the log4j library (https://www.lunasec.io/docs/blog/log4j-zero-day/) and multiple threat actors have been found to be scanning for vulnerable systems. We have been actively working to assess the impact and mitigate the vulnerability across our platform(tracked as PI-010403). 

Due to the nature of the issue, this is considered a critical vulnerability.

What Jamf products are impacted by the vulnerability?

Jamf Pro (hosted on-premises): Patched

Jamf Pro versions older than 10.14 are vulnerable to this issue. Versions 10.14 through 10.34 include Java 11, which partially mitigates the issue. The Jamf Pro 10.34.1 release was made available to address the issue completely. Please update to this version as soon as possible.

Jamf Pro (Jamf Cloud and Jamf Cloud Premium - Mitigated

Customers utilizing our cloud-based products have had the vulnerability mitigated through appropriate security controls. No further actions are necessary.

Jamf Connect: Not affected

Jamf Connect does not use the affected libraries.

Jamf Now: Not affected

Jamf Now does not use the affected libraries.

Jamf Protect: Not affected

Jamf Protect does not use the affected libraries.

Jamf School: Not affected

Jamf School does not use the affected libraries.

Jamf Threat Defense: Not affected

Jamf Threat Defense does not use the affected libraries.

Jamf Data Policy: Not affected

Jamf Data Policy does not use the affected libraries.

Jamf Private Access: Not affected

Jamf Private Access does not use the affected libraries.

Health Care Listener: Not vulnerable

While Health Care Listener does utilize the library that includes the vulnerability, it cannot be exploited by an attacker.

Jamf Infrastructure Manager: Not vulnerable

While Jamf Infrastructure Manager does utilize the library that includes the vulnerability, it cannot be exploited by an attacker.

Next Steps

We released version 10.34.1 for Jamf Pro to address the vulnerability. For more information on what’s included in this release, check out the release announcement on Jamf Nation or read the release notes here. 

To access new versions of Jamf Pro, log into Jamf Account with your Jamf ID. The latest version is located in the Products section under Jamf Pro. 

If you cannot upgrade to this latest release, you can choose to work around the issue by manually updating the log4j instances of the affected systems as described in our technical document.... If you choose to implement the manual workaround as described, future updates (to versions newer than 10.34.1) will not be affected. For assistance with this workaround, please reach out to support@jamf.com. 

Please update to the latest release as soon as possible. If you have any questions, please reach out to Customer Success for assistance. 

Due to the urgency, this communication is available in English only and will also be sending this via email to primary technical contacts at affected organizations.

Aaron Kiemele
Chief Information Security Officer, Jamf

[landon_Starr]

Does this impact the Jamf ADCS tool in any way?

[Aaron_Kiemele]

@landon_Starr The ADCS Connector is not impacted by this issue. 

[TimArnold]

Do you have documentation from Jamf or some report stating it is not impacted?

Edit: Just googled you and realized you are the CISO. I'm leaving my question up because you really need a badge stating your position with Jamf. By just looking at your profile it looks like you are a random person off the street. Your job title should be under your name, not this "New Contributor III." 

[fgonzale]

For Jamf Infrastructure Manager is it not exploitable because Java is not actively running?

I notice these JAR files containing log4j 2.13.3 version components in JIM 2.2.0 at:

C:\Program Files\Jamf\Infrastructure Manager\jamf-im-enroll-2.2.0-2.2.0.jar
C:\Program Files\Jamf\Infrastructure Manager\jamf-im-launcher-2.2.0-2.2.0.jar

Are these needed or can they be deleted?

[Aaron_Kiemele]

@fgonzale JIM is not exploitable since no untrusted user data is ever logged. We purposely minimize what information is logged by JIM to mitigate any potential data handling issues.

Deleting the JAR files above would however cause JIM to no longer function correctly.

[jmbwell]

Thank you for looking into this. This is obviously a small, but vital and extremely sensitive component.

[fgonzale]

It looks like the Jamf Infrastructure Manager was just updated to version 2.2.1 which includes a newer 2.15 log4j library.

https://docs.jamf.com/infrastructure-manager/2.2.1/Jamf_Infrastructure_Manager_Release_History.html

Thank you!

[jrippy]

A new CVE affecting log4j 2.15.0.

log4j 2.16.0 has been released in response.

[Aaron_Kiemele]

Update 12/14 - We are aware of CVE-2021-45046 that was remediated in log4j 2.16.0. Based on what we know today, this new vulnerability does not affect Jamf products. The conditions required for the exploitation of the vulnerability are not met by Jamf's use of the log4j library. We will continue to investigate and monitor, but no further action is required to remediate this CVE with Jamf products.

Aaron Kiemele
Chief Information Security Officer, Jamf

[R_C]

Thanks for confirming that this CVE does not affect JAMF at this time. Would there be any issue if we go ahead and update log4j to v2.16.0 using prior manual remediation steps anyway for consistency? I can imagine that our IT Security would prefer that we err on the side of caution and update anyway for consistency.

[Aaron_Kiemele]

@R_C  As 2.16.0 does not resolve any issues we are aware of, I would not recommend straying off the recommended workflow. 

[Anonymous]

Can you elaborate on these conditions? I know our security group would want context. Can you help us out? Esp if further down you are NOT recommending the manual update here(but to 2.16):

https://docs.jamf.com/technical-articles/Mitigating_the_Apache_Log4j_2_Vulnerability.html

[Anonymous]

Adding this blog post:

https://www.praetorian.com/blog/log4j-2-15-0-stills-allows-for-exfiltration-of-sensitive-data/

[SmilieK]

This is what was changed in 2.16.0 and what Jamf is not using and why it won't effect Jamf Services.
https://logging.apache.org/log4j/2.x/changes-report.html#a2.16.0

[as_devops]

If Jamf Services are not affected by the changes in 2.16.0 then there is no reason not to include 2.16.0 instead of 2.15.0 in the release asap.

[thomas_janssen]

Hello,

I have a question regarding the cloud instances.

Jamf Pro (Jamf Cloud and Jamf Cloud Premium) Mitigated

Customers utilizing our cloud-based products have had the vulnerability mitigated through appropriate security controls. No further actions are necessary.

What are the appropriate security controls exactly? Our security team is not happy with the vague description

[bradtchapman]

It goes both ways.  Your security team would not be happy if Jamf asked it to disclose the "appropriate security controls" used to prevent access to your network, would they?

[AJPinto]

Sounds like this may not be the end of the story. Looks like as of Monday 2.15.0 was found to not fully patch the vulnerability in all configuration.

https://logging.apache.org/log4j/2.x/security.html

https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2021-45046 

[bentoms]

https://community.jamf.com/t5/jamf-pro/third-party-security-issue/m-p/254171/emcs_t/S2h8ZW1haWx8bWVz...

2.15.0 seems to be vuln to the new CVE, if a certain config is used too..
which Jamf are advising isn’t.
--
[image: Image]

[image: -]

[image: -] [image: -]
[image: -]
[image: -]
Ben Toms
Head of Innovation and Platform

[image: Image] www.datajar.co.uk

[image: Image] ben@datajar.co.uk

[image: Image] 01273 041886

[image: Image] 0800 368 9330

[image: Image] Orange Row, Brighton, BN1 1UQ



[image: -]

[image:
-]





Best Technical Support
MSP Innovation Awards
Europe 2021 [image: -]

Ranked no1 for support
G2 MDM Grid® for mobile device
management Fall 2021

--


This email and any files transmitted with it are confidential and
intended solely for the use of the individual or entity to whom they are
addressed. If you have received this email in error please notify the
system manager. Please note that any views or opinions presented in this
email are solely those of the author and do not necessarily represent those
of the company. Finally, the recipient should check this email and any
attachments for the presence of viruses. The company accepts no liability
for any damage caused by any virus transmitted by this email.
 
DATA JAR
LTD is a company registered in England and Wales. Registered number:
08750679. Registered office: 39 Sackville Road, Hove, East Sussex BN3 3WD

[Louie]

For customers that are Government Contractors CISA is REQUIRING companies be patched to 2.16 no later than 12/24 It would be great if jamf would patch the installers to accommodate for this, I realize this can be done manually but it will have to be done each time the JSS is upgraded.

https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance

Summary

Note: CISA will continue to update this webpage as well as our community-sourced GitHub repository as we have further guidance to impart and additional vendor information to provide.

CISA and its partners, through the Joint Cyber Defense Collaborative, are responding to active, widespread exploitation of a critical remote code execution (RCE) vulnerability (CVE-2021-44228) in Apache’s Log4j software library, versions 2.0-beta9 to 2.14.1, known as "Log4Shell." Log4j is very broadly used in a variety of consumer and enterprise services, websites, and applications—as well as in operational technology products—to log security and performance information. An unauthenticated remote actor could exploit this vulnerability to take control of an affected system.

• On December 10, 2021, Apache released Log4j version 2.15.0 in a security update to address the CVE-2021-44228 vulnerability.
• (Updated December 15, 2021) On December 13, 2021, Apache released Log4j version 2.16.0 in a security update to address the CVE-2021-45046 vulnerability. A remote attacker can exploit this second Log4j vulnerability to cause a denial-of-service (DOS) condition in certain non-default configurations.
  • Note: affected organizations that have already upgraded to Log4j 2.15.0 will need to upgrade to Log4j 2.16.0 to be protected against both CVE-2021-44228 and CVE-2021-45046.

In order for these vulnerabilities to be remediated in products and services that use affected versions of Log4j, the maintainers of those products and services must implement these security updates. Users of such products and services should refer to the vendors of these products/services for security updates. Given the severity of the vulnerabilities and the likelihood of an increase in exploitation by sophisticated cyber threat actors, CISA urges vendors and users to take the following actions. 

• Vendors
  • (Updated December 15, 2021) Immediately identify, mitigate, and update affected products using Log4j to version 2.16.0. Note: as stated above, affected organizations will need to upgrade to Log4j 2.16.0 to be protected against both CVE-2021-44228 and CVE-2021-45046.
  • Inform your end users of products that contain these vulnerabilities and strongly urge them to prioritize software updates.
• Affected Organizations
  • In addition to the immediate actions detailed in the box above, review CISA's GitHub repository for a list of affected vendor information and apply software updates as soon as they are available. See Actions for Organizations Running Products with Log4j below for additional guidance. Note: CISA has added CVE-2021-44228 to the Known Exploited Vulnerabilities Catalog, which was created according to Binding Operational Directive (BOD) 22-01: Reducing the Significant Risk of Known Exploited Vulnerab.... In accordance with BOD 22-01, federal civilian executive branch agencies must mitigate CVE-2021-44228 by December 24, 2021. 

[hansjoerg_watzl]

Question: How to check, if a Jamf Pro (Windows) server is already affected by active use of the Log4j vulnerability?

Would you see some suspicious entries in Jamf or Apache logs?

[CSNavigateurs]

Aaron_Kiemele Is it possible to put a DATE on your UPDATE as we can't see if it was posted BEFORE or AFTER the last reply in this thread

THX

[Aaron_Kiemele]

Great point, thank you. I will correct going forward.