When assessing an attack surface, we came across an instance of Jamf Pro installed on premise. To us, when we saw this paradigm of deploying Jamf Pro to the internet and having it externally exposed, our security research team was quite curious about potential vulnerabilities that existed within it.
In particular, we were interested in pre-authentication vulnerabilities, but after spending a huge chunk of time auditing the pre-authentication attack surface, we concluded that a pretty good job had been done at locking this down. Generally, we were impressed that we were not able to find any serious pre-authentication issues, and credit is due to Jamf for this.
However, when looking under the hood at some of the post-authentication functionalities that Jamf Pro had to offer, we discovered a server-side request forgery vulnerability within the Jamf product. This vulnerability also existed in Jamf’s SaaS offering (Jamf cloud) leading to AWS metadata access in Jamf’s account.
The CVE’s associated with the SSRF vulnerabilities discovered in Jamf Pro can be found below:
Jamf Pro is an application used by system administrators to configure and automate IT administration tasks for macOS, iOS, iPadOS, and tvOS devices. Jamf offers on-premises and cloud-based mobile device management.
There are two deployment options for Jamf Pro, cloud (SaaS) and on-premise. In order to do this research, we obtained a copy of Jamf Pro on-premise.
Jamf Pro is one of the most popular MDM solutions for Apple products, and hence it was an attractive target to do source code analysis and vulnerability research on.
Mapping out the attack surface
We went through every route defined in the <span class="code_single-line">web.xml</span> file systematically and ruled out all of the pre-authentication attack surface. After doing this exercise and not discovering any serious issues, our team looked for sinks that could lead to dangerous functionality and then reverse engineered their way back up to the source. This proved to be a very effective mechanism when finding dangerous functionality inside Jamf regardless of whether or not authentication was required.
Due to our previous experiences with large enterprise products and SSRF, we decided to pinpoint what HTTP clients were in use by Jamf and then find all references to these HTTP clients. When auditing enterprise software, it is not uncommon to find a HTTP client wrapper that is used by the rest of the code base. This was the case for Jamf, where we found a HTTP client defined in <span class="code_single-line">jamf.war.src/WEB-INF/classes/com/jamfsoftware/jss/utils/HTTPUtils.java</span>:
As the source code suggests, the <span class="code_single-line">getBytes</span> function was the sink which was responsible for making the HTTP request.
With this in mind, we were able to discover numerous SSRF vulnerabilities that were possible to trigger once authenticated to Jamf. For this blog post, we will focus on the SSRF that had the most impact.
Discovering the SSRF
Simply searching the entire code base for <span class="code_single-line">getBytesFromSSLMutualAuthEndpoint</span>, returned a single result in <span class="code_single-line">jamf.war.src/WEB-INF/classes/com/jamfsoftware/jss/edu/EducationStudentPhotoRepositoryImpl.java</span>:
In order to trace this function back to the source, we identified all usages of <span class="code_single-line">getBase64EncodedImageWithoutClientAuth</span> and discovered the following snippet of code in <span class="code_single-line">jamfsoftware/jss/edu/settings/EduFeatureSettingsTestHTMLResponse.java</span>:
While a post-authentication SSRF does not sound that exciting, since Jamf offer a cloud version of their software hosted on AWS, server-side request forgery vulnerabilities can have critical impact.
In this case, through the SSRF demonstrated in this blog post, it was possible to access the AWS metadata IP address and obtain temporary security credentials to Jamf’s AWS environment. After proving the concept of obtaining the AWS credentials for my own Jamf cloud instance, incident response kicked off on Jamf’s side.
Jamf’s AWS monitoring tools noticed the anomalous behaviour and an investigation was started. Their team recognized it was an SSRF after inspecting it and the IP address doing the behaviour was blocked. The Jamf Pro instance that the exploit was performed on was also disabled.
Until a more robust fix was in place, Jamf employed a web application firewall (WAF) rule that effectively blocked exploitation for all of Jamf cloud. A fix was merged into Jamf Pro RC within 3 days of exploitation.
Jamf have a well defined vulnerability disclosure process that we used to submit the vulnerability. They were responsive and gave the vulnerability the due dilligence necessary and worked on a fix very quickly. As a company, Jamf also enabled and encouraged disclosure of this issue.
In order to remediate this vulnerability, we recommend upgrading to the latest version of Jamf Pro on premise.
Often when assessing source code, it is important to focus on certain classes of issues and be as holistic as possible. While no pre-authentication vulnerabilities were found, serious vulnerabilities were discovered in Jamf Pro by focusing on a specific bug class (SSRF) and by tracing the vulnerability in a reverse fashion (sink to source).
While there were more instances of SSRF within Jamf Pro, the one discussed in this blog post had the most impact as the full HTTP response was returned for arbitrary URLs. Even though this vulnerability affected a component only available once authenticated to Jamf Pro, it had significant impact due to the architectural decisions of Jamf Cloud.
The Jamf security team had an excellent response to this vulnerability and we encourage others to report any security issues to Jamf. They went above and beyond when dealing with this disclosure and were a pleasure to work with.
Your subscription could not be saved. Please try again.