Archive
Preventing user and location inventory information from being changed by the jamf binary’s recon verb
You can allow or prevent local administrators on the computer from changing User and Location inventory information in Jamf Pro with the jamf binary by using the Allow local administrators to use the jamf binary recon verb to change User and Location inventory information in Jamf Pro checkbox. This is a feature which first appeared in Jamf Pro 10.20.x, but may not be well known.
This setting is enabled by default and can be configured by navigating to Settings > Computer Management > Inventory Collection in Jamf Pro.
What this setting affects are the following options associated with the jamf binary’s recon verb:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| -endUsername | |
| -realname | |
| -position | |
| -building | |
| -department | |
| -phone | |
| -room |
Why disable this setting? If you have workflows which leverage the user and location information stored in Jamf Pro, being able to change this setting from a managed Mac using the jamf binary’s recon verb may have security implications. In particular, PKI certificate authorities set up in Jamf Pro may use the user and location information stored in Jamf Pro to issue certificates to managed Macs.
In the context of certificates used for authentication, being able to change the user and location stored in Jamf Pro from the managed Mac’s end may mean that an enduser with the ability to run the jamf binary’s recon verb may be able to get authentication certificates for someone other than themselves assigned to their Mac.
If you do not have any workflows that use the recon verb’s options specified above, my advice is that you disable this setting and remove the ability of managed Macs to change the user and location information stored in Jamf Pro using the jamf binary’s recon verb.
Remediating Log4Shell on Jamf Pro
On Thursday, December 9th 2021, a vulnerability was discovered in the popular Java logging library (log4j) which allowed for Remote Code Execution (RCE) by logging a certain string. This vulnerability has been dubbed Log4shell:
How bad is this? I’ll let the below video of a Minecraft server being changed into a DOOM server via this vulnerability speak to how a remote attacker could use Log4shell to give you a bad day:
It’s bad. It’s hard to overstate how bad. My colleague Ben Toms has a good write up on this issue here:
https://macmule.com/2021/12/11/jamf-pro-and-log4shell-cve-2021-44228
To address this vulnerability, the log4j folks have released an updated version of the logging tool which is not vulnerable. It’s log4j 2.1.5 and is available for download via the link below:
https://logging.apache.org/log4j/2.x/download.html
Update 12-15-2021:
Log4j 2.16.0 has been released to address remaining vulnerabilities in 2.15.0 by completely disabling Java Naming and Directory Interface (JNDI) lookups by default. It can be downloaded via the link below:
https://logging.apache.org/log4j/2.x/download.html
Insecure JNDI lookups are what enable the Log4Shell vulnerability, so having JNDI disabled by default in addition to 2.16.0’s removal of its message lookups functionality fixes the vulnerability .
Jamf has stated that they have evaluated CVE-2021-45046, which prompted the release of 2.16.0, and the results of their evaluation are that it does not appear that the conditions which are covered by CVE-2021-45046 should occur with Jamf’s products.
As of December 15th 2021, Jamf has not provided guidance on updating from log4j 2.15.0 to log4j 2.16.0
The files to download are one of the following two:
- Apache log4j 2 binary (tar.gz)
- Apache log4j 2 binary (zip)
Both have the same contents, the main difference is how they are compressed. Once downloaded and uncompressed, you should have the following files:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| LICENSE.txt | |
| NOTICE.txt | |
| RELEASE-NOTES.md | |
| log4j-1.2-api-2.15.0-javadoc.jar | |
| log4j-1.2-api-2.15.0-sources.jar | |
| log4j-1.2-api-2.15.0.jar | |
| log4j-api-2.15.0-javadoc.jar | |
| log4j-api-2.15.0-sources.jar | |
| log4j-api-2.15.0.jar | |
| log4j-appserver-2.15.0-javadoc.jar | |
| log4j-appserver-2.15.0-sources.jar | |
| log4j-appserver-2.15.0.jar | |
| log4j-cassandra-2.15.0-javadoc.jar | |
| log4j-cassandra-2.15.0-sources.jar | |
| log4j-cassandra-2.15.0.jar | |
| log4j-core-2.15.0-javadoc.jar | |
| log4j-core-2.15.0-sources.jar | |
| log4j-core-2.15.0-tests.jar | |
| log4j-core-2.15.0.jar | |
| log4j-couchdb-2.15.0-javadoc.jar | |
| log4j-couchdb-2.15.0-sources.jar | |
| log4j-couchdb-2.15.0.jar | |
| log4j-docker-2.15.0-javadoc.jar | |
| log4j-docker-2.15.0-sources.jar | |
| log4j-docker-2.15.0.jar | |
| log4j-flume-ng-2.15.0-javadoc.jar | |
| log4j-flume-ng-2.15.0-sources.jar | |
| log4j-flume-ng-2.15.0.jar | |
| log4j-iostreams-2.15.0-javadoc.jar | |
| log4j-iostreams-2.15.0-sources.jar | |
| log4j-iostreams-2.15.0.jar | |
| log4j-jcl-2.15.0-javadoc.jar | |
| log4j-jcl-2.15.0-sources.jar | |
| log4j-jcl-2.15.0.jar | |
| log4j-jdbc-dbcp2-2.15.0-javadoc.jar | |
| log4j-jdbc-dbcp2-2.15.0-sources.jar | |
| log4j-jdbc-dbcp2-2.15.0.jar | |
| log4j-jmx-gui-2.15.0-javadoc.jar | |
| log4j-jmx-gui-2.15.0-sources.jar | |
| log4j-jmx-gui-2.15.0.jar | |
| log4j-jpa-2.15.0-javadoc.jar | |
| log4j-jpa-2.15.0-sources.jar | |
| log4j-jpa-2.15.0.jar | |
| log4j-jul-2.15.0-javadoc.jar | |
| log4j-jul-2.15.0-sources.jar | |
| log4j-jul-2.15.0.jar | |
| log4j-liquibase-2.15.0-javadoc.jar | |
| log4j-liquibase-2.15.0-sources.jar | |
| log4j-liquibase-2.15.0.jar | |
| log4j-mongodb3-2.15.0-javadoc.jar | |
| log4j-mongodb3-2.15.0-sources.jar | |
| log4j-mongodb3-2.15.0.jar | |
| log4j-mongodb4-2.15.0-javadoc.jar | |
| log4j-mongodb4-2.15.0-sources.jar | |
| log4j-mongodb4-2.15.0.jar | |
| log4j-slf4j-impl-2.15.0-javadoc.jar | |
| log4j-slf4j-impl-2.15.0-sources.jar | |
| log4j-slf4j-impl-2.15.0.jar | |
| log4j-slf4j18-impl-2.15.0-javadoc.jar | |
| log4j-slf4j18-impl-2.15.0-sources.jar | |
| log4j-slf4j18-impl-2.15.0.jar | |
| log4j-spring-boot-2.15.0-javadoc.jar | |
| log4j-spring-boot-2.15.0-sources.jar | |
| log4j-spring-boot-2.15.0.jar | |
| log4j-spring-cloud-config-client-2.15.0-javadoc.jar | |
| log4j-spring-cloud-config-client-2.15.0-sources.jar | |
| log4j-spring-cloud-config-client-2.15.0.jar | |
| log4j-taglib-2.15.0-javadoc.jar | |
| log4j-taglib-2.15.0-sources.jar | |
| log4j-taglib-2.15.0.jar | |
| log4j-to-slf4j-2.15.0-javadoc.jar | |
| log4j-to-slf4j-2.15.0-sources.jar | |
| log4j-to-slf4j-2.15.0.jar | |
| log4j-web-2.15.0-javadoc.jar | |
| log4j-web-2.15.0-sources.jar | |
| log4j-web-2.15.0.jar |
The ones relevant to Jamf Pro are the following:
- log4j-1.2-api-2.15.0.jar
- log4j-api-2.15.0.jar
- log4j-core-2.15.0.jar
- log4j-slf4j-impl-2.15.0.jar
For more details, please see below the jump.
Obtaining, checking and renewing Bearer Tokens for the Jamf Pro API
I’ve recently begun looking into uses for the Jamf Pro API, the API which Jamf makes available for Jamf Pro in addition to the Classic API. The two APIs handle authentication differently and for folks coming over to using the Jamf Pro API from the Classic API, the extra steps involved may be a surprise.
For the Classic API, here’s what’s required for authentication:
- One step process.
- Only username and password needed to authenticate an API call.
- Username and password can be in plaintext.
- No tokens are used.
Example Classic API call process:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # Provide username and password as part of the API call: | |
| /usr/bin/curl -su "username_here:password_here" -H "Accept: application/xml" https://server.name.here/JSSResource/packages/id/2 |
For the Jamf Pro API, here’s what’s required for authentication:
- Multi-step process involving multiple API calls.
- Username and password only used to get authentication token, known as a Bearer Token. The Bearer Token is subsequently used for authentication.
- Username and password must be base64-encoded.
- Bearer Tokens are valid for 30 minutes maximum.
- Introduces need to validate authentication Bearer Tokens before making an API call.
Example Jamf Pro API call process:
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| # Get username and password encoded in base64 format and stored as a variable in a script: | |
| encodedCredentials=$(printf username_here:password_here | /usr/bin/iconv -t ISO-8859-1 | /usr/bin/base64 -i -) | |
| # Use encoded username and password to request a token with an API call and store the output as a variable in a script: | |
| authToken=$(/usr/bin/curl https://server.name.here/api/v1/auth/token –silent –request POST –header "Authorization: Basic ${encodedCredentials}”) | |
| # Read the output, extract the token information and store the token information as a variable in a script: | |
| api_token=$(/usr/bin/plutil -extract token raw -o – – <<< “$authToken”) | |
| # Verify that the token is valid and unexpired by making a separate API call, checking the HTTP status code and storing status code information as a variable in a script: | |
| api_authentication_check=$(/usr/bin/curl –write-out %{http_code} –silent –output /dev/null https://server.name.here/api/v1/auth –request GET –header "Authorization: Bearer ${api_token}") | |
| #Assuming token is verified to be valid, use the token information to make an API call: | |
| /usr/bin/curl –silent -H "Accept: application/xml" –header "Authorization: Bearer ${api_token}" https://server.name.here/JSSResource/packages/id/2 |
The differences in authentication are significant enough that I decided to write functions for shell scripting to handle the following tasks for the Jamf Pro API:
- Obtaining Bearer Token.
- Verifying that current Bearer Token is valid and unexpired.
- Renewing Bearer Tokens by using current Bearer Token to authenticate the issuing of a new Bearer Token. (This renewal process creates a new Bearer Token and invalidates the old Bearer Token.)
- Invalidating current Bearer Token.
For more details, please see below the jump.
Der Flounder 
Recent Comments