Looks like they were planning for a long one per the (separate!!!???) maintenance email:
Eighteen hours??? 😱 Oh no...
I find it a little hard to believe on 12/10 we got this email with regards to Jamf and the identified vulnerability and stated that Jamf Pro Cloud and Jamf Cloud Premium were mitigated through appropriate security controls. No further actions are necessary! Here we are locked out of Cloud solution to mitigate something that was already stated being done on 12/10/2021. Major disruption to my Health System.
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 Health Care Listener 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 documentation. If you choose to implement the manual workaround as described, future version updates 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.
18 hours? You can't be serious....
18 hours? You can't be serious....
This is not acceptable.
I agree with the others. Being down for hours in the middle of the week is no bueno.
We understand and do not take lightly the impact of performing this maintenance without more notice. The information in the original post has been updated with estimated timing of the completion of this maintenance. Please monitor status.jamf.com for updates. We will share more information as we’re able.
Thank you for your patience as we continue to work to ensure the security of your Jamf environment.
This is completely unacceptable. Zero communication of a "scheduled" maintenance in the middle of the work day? If any of us did this, we'd be shown the door. There had better be a good explanation for this.
Communication was sent via email, prior to the change being implemented.
No communication regarding a mid afternoon maintenance window on a weekday? Ouch.
Email communication was sent prior to start
tough time to take out the cloud when people are also trying to remediate log4j with Jamf. Hope this includes a way for Jamf to detect 3rd party log4j issues.
@swapple wrote:
tough time to take out the cloud when people are also trying to remediate log4j with Jamf. Hope this includes a way for Jamf to detect 3rd party log4j issues.
they added this to Jamf Protect this week - "SuspiciousJavaActivity
This analytic will show when the curl command or an interactive bash shell is executed under Java. To date these are the most common actions being taken by successful log4j exploits. These actions might also be performed by legitimate Java applications in your environment. It is up to the analyst to determine if the detected application should be performing these actions."
We understand and do not take lightly the impact of performing this maintenance without more notice. The information in the original post has been updated with estimated timing of the completion of this maintenance. Please monitor status.jamf.com for updates. We will share more information as we’re able.
Thank you for your patience as we continue to work to ensure the security of your Jamf environment.
Welp…
@kaylee_carlson Looks NIST released CVE-2021-45105 with 8.1 (of 10) rating requiring log4j to be patched to 2.17.
https://nvd.nist.gov/vuln/detail/CVE-2021-45105
@swapple wrote:
tough time to take out the cloud when people are also trying to remediate log4j with Jamf. Hope this includes a way for Jamf to detect 3rd party log4j issues.
they added this to Jamf Protect this week - "SuspiciousJavaActivity
This analytic will show when the curl command or an interactive bash shell is executed under Java. To date these are the most common actions being taken by successful log4j exploits. These actions might also be performed by legitimate Java applications in your environment. It is up to the analyst to determine if the detected application should be performing these actions."
But did the figure this out 2 seconds before they did the update so there was no choice but to kick everyone working in Jamf out?? No time to schedule it? No notifications???
We understand the need to do it. The method has destroyed a lot of confidence in Jamf that it was done with very little notice.
But did the figure this out 2 seconds before they did the update so there was no choice but to kick everyone working in Jamf out?? No time to schedule it? No notifications???
We understand the need to do it. The method has destroyed a lot of confidence in Jamf that it was done with very little notice.
I don't know what you're complaining about. They sent out a mail during my lunch break, 20 mins before they kicked it off, outlining an undefined start time of "soon", and with no expected completion time. lol.
Log4j 2.17.0
https://community.jamf.com/t5/jamf-pro/third-party-security-issue/td-p/253740
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.
Communication was sent via email, prior to the change being implemented.
Thats a terrible reply and look at the situation. Giving a heads up 20 minutes before taking the instance out is not acceptable by any means unless they actively noticed an attack ongoing. Most of us were hit in the middle of the day with no warning, I don't check my email every minute, as my workflow does not allow for this. Taking down an instance with close to no warning is unacceptable in every sense of the word. While you are technically correct, the issue is not whether or not an email or communication went out. But the shoddy and terrible timing and effects it had for those of us caught with little to no warning. Don't be so glib with your response, just because you may not have been effected, doesn't mean the rest of us weren't.
Thats a terrible reply and look at the situation. Giving a heads up 20 minutes before taking the instance out is not acceptable by any means unless they actively noticed an attack ongoing. Most of us were hit in the middle of the day with no warning, I don't check my email every minute, as my workflow does not allow for this. Taking down an instance with close to no warning is unacceptable in every sense of the word. While you are technically correct, the issue is not whether or not an email or communication went out. But the shoddy and terrible timing and effects it had for those of us caught with little to no warning. Don't be so glib with your response, just because you may not have been effected, doesn't mean the rest of us weren't.
Never claimed I wasn't affected and never claimed anyone else was. I merely stated communication was sent out. Also, you bring up a good point, that to my knowledge has not been determined or at least publicly communicated: that is that none of us know whether an attack was active or not. Don't be so quick to rush to conclusions is merely all i was trying to infer with my factual response.
Never claimed I wasn't affected and never claimed anyone else was. I merely stated communication was sent out. Also, you bring up a good point, that to my knowledge has not been determined or at least publicly communicated: that is that none of us know whether an attack was active or not. Don't be so quick to rush to conclusions is merely all i was trying to infer with my factual response.
I agree with your last part, and understand where you are coming from as your answer was technically correct, but as you can see from the myriad of responses here, the timing and execution was terrible. Even taking that into account, the communication was also incredibly poor. The response you are posting on this thread (in a few locations) just comes off as a little tone deaf considering the impact it had on a lot of us. I meant no attack or disrespect by any means, so I apologize if it comes off that way, but there were a lot of issues introduced to our environment due to computers being knocked offline (server connections) during usage that we are still trying to get resolved
I agree with your last part, and understand where you are coming from as your answer was technically correct, but as you can see from the myriad of responses here, the timing and execution was terrible. Even taking that into account, the communication was also incredibly poor. The response you are posting on this thread (in a few locations) just comes off as a little tone deaf considering the impact it had on a lot of us. I meant no attack or disrespect by any means, so I apologize if it comes off that way, but there were a lot of issues introduced to our environment due to computers being knocked offline (server connections) during usage that we are still trying to get resolved
I certainly understand, we were in the middle of testing some detection scripts for log4j and poof, gone. I thought it would be around an hour tops, but nope, quite an extended outage. I understand the pain, but also want to cut JAMF some slack in the sense that I've not seen anything else like this in the 5 or so years I've been a customer and due to the severity of the vulnerability/the unknown of whether there was an actual attack in place.
I certainly understand, we were in the middle of testing some detection scripts for log4j and poof, gone. I thought it would be around an hour tops, but nope, quite an extended outage. I understand the pain, but also want to cut JAMF some slack in the sense that I've not seen anything else like this in the 5 or so years I've been a customer and due to the severity of the vulnerability/the unknown of whether there was an actual attack in place.
You do bring up a good point, Jamf has been fairly solid overall, and frankly their patch policy has been on the better end of companies I use. I think this is one of those "I'm frustrated at the situation" kind of things. Especially given the impact and timing, not just in the day/week, but just right before the holidays, with some folks having smaller crews, etc. My thoughts are they had an active attack or proof of one that happened since the last patch (if I remember correctly there were 2 in a short window) but either way. Sorry for the post venting, and hope you have a happy holiday season!
You do bring up a good point, Jamf has been fairly solid overall, and frankly their patch policy has been on the better end of companies I use. I think this is one of those "I'm frustrated at the situation" kind of things. Especially given the impact and timing, not just in the day/week, but just right before the holidays, with some folks having smaller crews, etc. My thoughts are they had an active attack or proof of one that happened since the last patch (if I remember correctly there were 2 in a short window) but either way. Sorry for the post venting, and hope you have a happy holiday season!
All valid points for venting 🙂 Merry Christmas Friend and a Happy New Year!
Email communication was sent prior to start
sorry but 20 min before taking it down when a previous email stated nothing needed to be done is just crazy and would be viewed as completely not okay in any corp environment.
sorry but 20 min before taking it down when a previous email stated nothing needed to be done is just crazy and would be viewed as completely not okay in any corp environment.
an emergency change control for an active exploited attack like this is acceptable to me as a customer especially considering the repercussions if said attack would have been successful.
How is JAMF addressing the vulnerability issues introduced in Log4j 2.16 CVE-2021-45105 that is fixed by Log4j version 2.17? Has it been determined that JAMF Pro version 10.34.2 is vulnerable or not impacted?
