Lessons in Securing Mobility Site Management APIs

Mobile device management systems (MDMs) are a staple in any large enterprise IT toolkit. When your organization has a large number of employees, it’s important to keep a catalog of all devices that have access to the corporate network. IT admins use MDMs to enforce update policies, record any unusual activity, and even wipe devices if they are lost/stolen.

MDMs give an organization the tools it needs to keep its data and employees secure, but can also open the door to large-scale attacks if threat actors were to gain access to the MDM directly. Researchers at Traceable ASPEN recently uncovered vulnerabilities in the API that powered Johnson & Johnson’s Mobility Service Portal, a self-service platform for employees.

We were able to access the details of employee devices by exploiting the underlying PHP APIs on the portal. The vulnerability was reported to J&J and they promptly remediated it after confirming they received our report.

The Mobility Service Portal

The Mobility Service Portal was used by employees to manage their company-provided mobile devices, like iPhones or even iPads. If you are an employee and were having trouble with your device, this is where you would go to troubleshoot and get help. Many large companies have these self-service systems to assist with common issues and avoid the employee having to call a corporate IT helpdesk for help.

When you log in to the Mobility Service Portal, an employee would be greeted with their list of registered mobile devices:

And have the opportunity to carry out remediation actions for common issues, such as changing the passcode and repairing Wi-Fi settings:

There are also some very destructive actions, such as the option to remove all company data from the device.

Importance of securing PHP APIs with Authentication Tokens

Many companies make use of an SSO system to control access to their internal websites. You enter your employee login credentials (username + password, maybe even a two-factor code), and then you will be logged into the website you were navigating to. There is typically no way to bypass that SSO login directly, and it would be inadvisable to attempt to. However, the Mobility Portal has an interstitial page that is briefly displayed when you are not logged in:

It is this page we were able to query. When viewing the source of this page, we were able to see linked JavaScript files. Of particular interest was the “my-devices” file that revealed the underlying PHP APIs:

Normally, the SSO system will set a token or cookie that the originating website will verify to ensure you have access to it. However, in this case, the PHP APIs powering the Mobility Service Portal did not utilize any sort of authentication token. Instead, access was controlled via username in a URL query parameter. The username came from the email address that the user logged in as. This username/email query parameter achieved the intended result of filtering the employee device list, but this parameter was easily changeable and thus insecure. We were able to gain access to everything in 2 steps:

1. Comment out the redirect to the SSO login page.
2. Remove the username from the API calls. Doing so would trigger the API to return all employee devices/information.

The UI (seen in the first image of this post) only showed a simplified view of devices. The API provided a wealth of real-time information about the devices, such as battery %, available memory, and cell network information that went unused in the UI:

Reporting

Traceable ASPEN has been privileged to work with many companies over the past several months to help improve their API security. Johnson & Johnson has a vulnerability disclosure program and we reported our findings there. The timeline is as follows:

• Friday, January 12, 2024: Report sent. A few hours later a member of the Information Security Risk Management (ISRM) team reached out for additional information. We coordinate a call for Jan 16th.

Note: On the evening of the 12th, following receipt of the notification, ISRM coordinated removal of access to this website.

• • Tuesday, January 16, 2024: Phone call with ISRM where we answer their questions and provide additional information. ISRM informed us that the site was taken offline the day of our notification and is not accessible, and a cybersecurity investigation is in progress.
  • Friday, January 26, 2024: Follow-up from ISRM received informing us they are continuing through their internal review process.
  • Thursday, February 15, 2024: ISRM requests another call as a follow-up from the information we had shared.
  • Monday, February 26, 2024: Phone call with ISRM where they confirmed no malicious activity was found after a review.
  • Monday, March 11, 2024: We let ISRM know that any/all sensitive employee information has been deleted on our side, and we would like to share this blog for their review once complete.
  • Monday, April 8, 2024: We share a proposed blog with ISRM for their review and gather feedback.
  • Thursday, April 25, 2024: Phone call with ISRM to discuss blog and review provided feedback.
  • Thursday, May 16, 2024: Blog published.

We were extremely impressed with the prompt responses and their commitment to product security. Their fix was to sunset the mobility portal in favor of a replacement that was already in the works. The new system is secure and is not vulnerable to the same type of attack. They were thorough in validating that no unauthorized access was made to the MDM portal prior to sunsetting it.

Lessons and Takeaways

SSO is a vital part of controlling access to internal resources and every company should use it, but it should not be the sole protection mechanism. What is paramount is that all resources protected by SSO also verify that a valid SSO login has taken place and that a valid authentication token exists. Do not just put SSO on top of an API-heavy application and consider it secured!

In this case, the fix would have been to send the SSO token with each API request and reject unauthorized requests for devices that are not your own. Filtering by username query parameter, while easy to implement, is not a secure way of implementing access controls.

A simple way to think about this: when the client tells you they are username John Doe, are you able to cryptographically verify that is the case? If you send a username via query parameter, the answer is no. It is like showing up at the airport and telling them your name, but not needing to show your passport.

On the other hand, if you receive a login token, such as a JWT (“passport”), the answer is yes because it is a secure form of identification, and you can verify it in a cryptographically secure fashion.

Traceable ASPEN

Traceable ASPEN provides vendor neutral and threat driven research in API security, investigating the latest breaches with world leading expertise and analysis. We believe in securing the world’s APIs with actionable insights from across the industry. We are offensively minded, defensively driven, and focused on your protection.