Posted on 12-10-2021 03:30 AM
A zero day exploit has been found which affects the latest version of jamf.
This exploit affects the java logger log4j, which is used by Jamf. If you are hosting an onpremise version, take a look at the JSSAccess.log to check for anomalies.
Posted on 12-10-2021 03:53 AM
Posted on 12-10-2021 03:57 AM
Start your server with log4j2.formatMsgNoLookups set to true, or update to log4j-2.15.0-rc1 or later.
Posted on 12-10-2021 05:05 AM
Here is the cve for completeness:
Posted on 12-10-2021 05:32 AM
Thanks for sharing.
Does it help to restrict the access to computer only and to disable the login on the JSS page?
Posted on 12-10-2021 05:35 AM
No. Currently only workaround is to start your server with log4j2.formatMsgNoLookups set to true, or update to log4j-2.15.0-rc1 or later. If you want to be updated you can check this blog post for possible mitigations:
Posted on 12-10-2021 06:32 AM
Specific for Jamf Pro:
Edit this file:
restart your jamf instance.
Posted on 12-10-2021 07:19 AM
Thank you Elies. Every place I was looking was just saying set formatMsgNoLookup to true. Not very helpful if you do not knot the filename or proper format. This saved a lot of time.
Posted on 12-10-2021 11:39 AM
Not seeing the log4j2.component.properties file on either of our nodes. We only have log4j2-default.xml and log4j2.xml. Performed a find for *.properties files in ROOT and didn't find it.
Posted on 12-10-2021 06:40 AM
So you can either set that in log4j2.component.properties, or in the Tomcat Java Arguments, right?
Posted on 12-10-2021 08:32 AM
I added the following as a second line. Does anyone know how to update to the recent version?
Posted on 12-10-2021 08:50 AM
Any indication whether this affects Jamf Infrastructure Manager?
Posted on 12-10-2021 10:00 AM
ooohhhh.....I wanna know this as well....! I have JIM's in my environment.
Posted on 12-10-2021 12:33 PM
Sure looks like it from what I can see.
Posted on 12-10-2021 10:11 AM
I applied the mitigation and I have been checking the JSSAccess.log I don't see anything out of the ordinary.
All seems ok? What would I be looking for? Running a few scans on the server just to make sure all is ok.
I went through this with Exchange in March and didn't like it at all! 😞
Posted on 12-10-2021 10:43 AM
Our friend @bentoms shared this link in MacAdmins #security in which Jamf CISO posted about Third-Party Security Issue. I cross-posted in comments, in case official Jamf response differs at all from this.
Thanks, @Elies !
Posted on 12-10-2021 01:21 PM
I added the extra line to log4j2.component.properties on an on-prem Jamf Pro 10.32 server and then restarted Tomcat. It took a long time to begin responding to http requests, but it did eventually come back up. Is there a way to test that this successfully mitigated the CVE?
12-10-2021 01:57 PM - edited 12-10-2021 02:03 PM
If you are running Windows server and IIS you can also check your IIS logs for lines that contain 'jndi'. They will be located in a directory similar to this: C:\inetpub\logs\LogFiles\W3SVC1\
Also, the default path to the JSSAccess.log on Windows Server is C:\program files\jss\logs\JSSAccess.log
Posted on 12-11-2021 02:04 PM
I’m looking through the JSSAccess.log I really don’t see anything out of the ordinary what am I looking for?
Posted on 12-14-2021 10:15 AM
@mvanstone Hi. In your JSSAccess.log you would want to look for unusual account names, or possibly failures. Look for anything that seems out of the ordinary. If you run IIS I highly recommend you search your IIS logs for the string 'jndi'. The string containing jndi will most likely be the attack string.
Posted on 12-10-2021 03:41 PM
Posted on 12-10-2021 05:04 PM
For anyone who comes back to this thread, official word is out:
Posted on 12-11-2021 11:15 AM
Jamf just released 10.34.1 to remediate the zero-day vulnerability.
Posted on 12-11-2021 11:59 AM
Thanks @donmontalvo. As @Eric_Wacker pointed out with the link, Jamf Support passed the mitigation steps out to use for those whom don't want to take the jump right away..
Posted on 12-11-2021 01:07 PM
Yep, same effort for us, we chose the dot update since it was released so quickly. Plus it’s raining here.
12-13-2021 02:38 AM - edited 12-13-2021 02:51 AM
I have applied the patch from Jamf and can confirm that JNDI code from the log is no longer triggered.
log4j2.formatMsgNoLookups: true is no longer necessary if you are on 10.34.1.
If you want to test it yourself, generate a domain at http://www.dnslog.cn/ and build a jndi command with the domain and try to log in to your jss with the jndi string. If you are still vulnerable, your dns records should be visible on the page where you generated the domain.
Posted on 12-13-2021 06:48 AM
We have just confirmed our on-premise server is compromised, found a malicious jamf.ps file, not sure if the best course of action is to restore from backup and update server or to simply remove jamf.ps file and update server?
Posted on 12-13-2021 06:50 AM
Where did you find this file?
Posted on 12-13-2021 06:52 AM
It was initially downloaded to the root of c:
Posted on 12-13-2021 06:59 AM
Depends on the content of the script. Can you read powershell and understand what is being done there?
12-13-2021 07:01 AM - edited 12-13-2021 07:06 AM
The jamf.ps script is encoded, our security team are currently trying to access it
02-08-2022 09:16 AM - edited 02-08-2022 09:17 AM
I would strongly recommend against using a service based in China to test/reveal whether your system is vulnerable or compromised. Really bad idea.
Posted on 12-13-2021 07:36 AM
^^^Just adding so it comes up in a search.
Posted on 12-13-2021 08:53 AM
What would be the best course of action on investigating if your server has been compromised?
Posted on 12-13-2021 09:02 AM
Not sure about your environment but our security team detected the use of encoded powershell on our jss from a specified IP that downloaded a jamf.ps file to our JSS server, root of c:. We blocked the IP, isolated JSS, triaging now.
Posted on 12-13-2021 10:51 AM
When did you patch your server?
Posted on 12-14-2021 12:31 AM
Server is isolated at present, looking to patch today hopefully
Posted on 12-13-2021 12:16 PM
I don't find any of the files referenced in this mitigation article.:
Are they someplace else?
12-14-2021 12:55 AM - edited 12-14-2021 01:02 AM
I found this a good resource for information https://www.cisa.gov/uscert/apache-log4j-vulnerability-guidance
12-14-2021 12:25 PM - edited 12-14-2021 12:36 PM
Apparently 2.15.0 was only a partial mitigation. log4j 2.16.0 has been released that disables JNDI completely. CVE