Earlier this year the Appthority Enterprise Mobility Threat Team discovered a previously unknown sandbox violation (0-day) within Apple’s iOS. The violation impacts all MDM clients as well as any mobile apps distributed via an MDM that use the “Managed App Configuration” setting to configure and store private settings and information. In order to “auto-fill” account setup for the MDM client and MDM-distributed apps, IT will commonly send the credential and authentication information along with the managed app binary for installation on corporate mobile devices. We found this information often included access to the “corporate data security jewels”, including server url’s, credentials with plaintext passwords, etc. The end goal with this practice is a more streamlined user experience, where the user can gain virtually instant access to their corporate apps (and corporate data) without having to enter long strings of authentication credentials.
The underlying issue with our critical sandbox violation discovery is that not only can a mobile app (or the MDM vendor app itself) have access to this sensitive set-up and authentication information stored on the device, but anyone (or any other app on the device) can also see the credential information on the mobile device as it is stored ‘world readable’. We’ve worked directly with the Apple Security Team since this was discovered leading to the fix rolled in the latest iOS update (8.4.1).
Most enterprises use an MDM/EMM to manage and control access to corporate data, corporate email, and corporate apps on employees’ mobile devices. When an employee first joins the company, IT creates an MDM account for the employee and installs the MDM client on their mobile device. From there on, any corporate apps, along with their configuration settings and credentials, are sent through the MDM and pushed to the mobile device.
An example of a managed app configuration file configured inside an MDM is below, where the variable strings are filled in by the MDM and pushed to the employee device:
The sandbox violation occurs after the managed configuration is pushed to the mobile device. Managed app configuration settings (located in “/Library/Managed Preferences/mobile/”) can be accessed by any other app with just the following piece of code:
A corporate app with the bundle identifier of “com.acme.DemoApp” may contain the values below in a .plist file (note that credentials, including passwords, are stored in plaintext):
The managed app configurations in the “/Library/Managed Preferences/mobile/” directory are, in theory, app specific and matched using the bundle identifier. For example, a managed app with the bundle identifier of “com.acme.DemoApp” would be stored as “/Library/Managed Preferences/mobile/com.example.app.plist”. Managed apps then have access to their own configuration using the API:
Access to their configuration should be limited to the corresponding app to avoid information disclosure (like it’s done with the local app preferences using NSUserDefaults). But, as Appthority discovered and demonstrated here, this is not the case. All configuration files are readable for all applications on the device!
An attacker could target as many enterprises it can get into (using the iTunes store to spread an app designed to read and share the configuration files), or a specific target (traditional spear-phishing attack, through targeted e-mail, etc). In either case, they would develop an app that has a high chance of being installed in the enterprise, such as a productivity app. Once the app gets downloaded and installed on the devices, it would continuously monitor the directory for configuration settings being written to the world readable directory, harvesting and sending them to the attacker. Because all apps have access to the directory, it could hide in plain sight and operate as one of the many legitimate apps that have access to the directory in question.
An attacker (or a malicious app) with access to an MDM managed device can read all managed configuration settings for an unpatched device. Managed configuration is used to make the provisioning of apps easier and enterprise apps may use this mechanism to provision credentials or details about internal infrastructure this way. Those can be used by the attacker to gain access to those services.
The impact on the security of a specific enterprise highly depends on the kind of information they are provisioning using managed configurations. To gauge severity of the vulnerability we ran a search across our global app collection of millions of apps residing on enterprise managed devices. We then narrowed down the apps that have a dependency on managed configurations, finding the majority were MDM clients, corporate apps to access work e-mail and business documents, or secure web browser apps used to access enterprise networks. We also found apps used in the healthcare industry, giving doctors access to patient data and records (a likely HIPAA violation). We then looked at the managed settings used by these apps, and were surprised to find:
- Close to half (47%) referenced credentials, including username, password and authentication tokens.
- 67% referenced server identification information.
Appthority has been working directly with our MDM partners to implement best practices on the handling these types of sensitive information.
Storing any credentials or authentication tokens on the mobile device filesystem should be avoided. Although this sandbox violation has been patched by Apple, the patch only protects devices which update to iOS 8.4.1; Appthority has identified that up to 70% of iOS devices are not running the latest version of iOS, even several months after an update is issued. Further, even on devices that are patched, the risk exists that the mobile device is compromised and no amount of sandboxing will protect the data stored on the iOS device. If this option is unavoidable, we recommend:
- Not using this mechanism to provision secret / confidential data
- Credentials and other secrets should always be stored using the device keychain
- A possible way to provision this data would be to use url schemes
- Use iOS single-sign-on profiles if possible