JAMF Software Security and Vulnerability Assessments

Security took center stage of the JAMF Nation User Conference as members of the NCC Group—formerly Matasano Security—explained how they perform periodic penetration testing and vulnerability assessments on various JAMF Software products and services, such as the JAMF Software Server (JSS) web application, JAMF binary, JSS PKI, and JAMF Nation. At JAMF Software, we take security very seriously. One aspect of that is periodic penetration testing of our products. I first got to deal with this when bringing Bushel to market and have been pleasantly surprised at each step by how thorough the security process is for various releases of the Casper Suite. During this session, Jason Van Zanten (JVZ as we affectionately call him) introduced Matasano Security, the vendor that performs our third-party assessments.

Daniel Mayer and Graham Buckholz, both Principal Security Consultants with the NCC Group, walked the crowd through security and vulnerability assessments and touched on how these help ensure the security of JAMF Software products, including JAMF Nation, the JSS, OS X and Mobile Configurations. These assessments include intercepting traffic (e.g. using burp), source code review, fuzzing the apps (automated injection of randomized packets, which I was surprised they do), sending systems into unsupported states, etc.

The session also included a good overview of the classic authentication vs. authorization concepts, which is where most of the security training I’ve done starts (e.g. the CISSP). I really liked the real-world examples that the speakers covered, like explaining how TouchID factors into authentication and using privilege escalation as an example of what authorization is. The explanation of injection flaws (Cross-Site Scripting attacks, SQL injection) and how we protect against that by not trusting just any old user input was great. Here, the discussion was about how we check input for SQL and HTML before committing information into our databases.

They also talked cryptography. This is always hard with a mixed audience. But the speakers did a great job in not going too in depth and loosing the audience, while also covering a few basics, such as randomization, key management, well designed ciphers, and possibly most importantly, dependency flaws. It’s been a focus at JAMF to make sure that any third party plug-ins we use are not introducing such flaws. Something the guys on stage often help JAMF with.

One great aspect of this session is that they looked at a few examples of security flaws that have been found with the JSS. These included the following:

A script was downloaded to the /tmp directory using a policy prior to being executed. Here, NCC used a custom script in that directory to set a file as immutable without escalating to root, and then had a check-in execute the script with root privileges. Obviously, this isn’t something we want to happen, so NCC reported it to the JSS team and we of course fixed it by setting isolated directories as chroot and therefore not allowing anyone to write into that directory without already having root privileges.

Insufficient authorization controls in AJAX not port properly handling a user’s privileges. This allowed for a specific request to be issued as an admin user even though the user wasn’t using a correct account. Our development team was able to add an explicit check to each state change of a user and correct the flaw.

The JSS was that we were using a small DES key size. Here, the cipher we used (ECB) was weak and so revealed information about the underlying plaintext (even if an attacker couldn’t actually decrypt a full file or payload. This type of flaw often shows up with a traditional Nessus scan, and the development team was able to resolve the flaw by simply selecting a stronger algorithm.

Outdated dependencies showed up and NCC was able to point to the Common Vulnerability Enumeration (CVE) for each. Updating these packages are the easy part of resolving a vulnerability like this; however, putting in place a process to keep them updated is a bit more challenging, as often times updating a third party software package or library used in our software also requires us to upgrade our own code here and there.

Once challenge that NCC pointed out that isn’t a few, would be things our customers can do to increase the security of their environments. These include:

Allowing any host to request another hosts information. To further secure a customers environment, NCC recommends our customers enable message signing using the host’s certificates.

Software distribution can be weakly encrypted. To further secure a Casper Suite environment, NCC recommends using only securable protocols, such as HTTPS or SMB 3.

FileVault 2 supports both individual and institutional recovery keys. These are validated in a JSS when the device checks in for an inventory. These can be intercepted, and so NCC recommends that customers use an institutional recovery key instead. They also identified using HTTPS as the protocol that you’d want to use if you were using individual keys.

Make sure that you’re not using SHA1 and that all of your certificates have been issues using SHA256. NCC also recommends not using RCC4.

Use limited access mode for servers that are exposed to the Internet, which only allows devices to check in.

JVZ also mentioned that there’s a hardening guide for the JSS coming to the JAMF Software website.

Obviously, not all of these security options will be applicable in all environments. You may have a very different outlook on what you need to secure and the best practices you choose to employ. This is why they’re options and not forced on our customers. For example, many customers in the audience of this session took exception to the findings about FileVault as it breaks a lot of workflows where we, as administrators, need to provide individual keys to users. This is a great example of both Apple and JAMF Software making decisions for our customers based on usability and security.

At the JAMF Nation User Conference, we usually try to have the community as involved as possible. In this regard, this session was pretty unique, as NCC is a team of security researchers rather than people from the Apple administrative community. But the session did tie into the community by encouraging the JAMF Nation community to help with the process by reporting anything that they happen to find.