Third-Party Library Permission Piggybacking in Android Apps

Third-party libraries are widely used in Android apps and take over some functionality, thus making app development easier. As these libraries inherit the privileges of the app, they can often be overprivileged. Libraries, can abuse these privileges, oftentimes through extensive data collection. This article delves into the issue of permission piggybacking, a technique where libraries probe permissions and adapt their behaviour accordingly, without making any permission requests of their own. We thoroughly analysed the top 1,000 applications on Google Play for permission piggybacking. Our results prove that it is extremely widespread, imposing a significant problem that needs urgent attention.

The image shows a pig carrying a cardboard box tied to its back with twine. The pig is walking along a dirt path in a rural setting, with green fields visible in the background. The overall impression is whimsical and humorous, illustrating permission piggybacking.

The Android operating system is home to millions of applications, each providing users with a unique set of features and services. To ensure that these applications interact safely with user data and other app components, Android employs a permission system. However, the reality is far from ideal. The main application often employs Third-party libraries to offload certain tasks and functionalities, which inherit all permissions from the main app. Mostly, these permissions are more than the library requires. Many libraries use this characteristic to probe already granted permissions and use or collect accordingly available data.

Understanding Permission Piggybacking

Permission piggybacking occurs when third-party libraries, integrated within a main app, probe and adapt their behavior according to the already granted permissions, without explicitly requesting any permissions of their own. Libraries utilizing this technique can access user data and critical functionalities, particularly when embedded in an application with high privileges.

Not just a few apps exhibit this issue. Most apps, from gaming apps to critical banking applications, employ libraries. Each app often uses five to ten, sometimes up to 50 libraries, and the app developer often does not know in detail how each library works and what it does in the background. This makes it a significant concern, as these libraries can gather more personal and sensitive user data than required for their primary functionality, posing a considerable privacy risk.

The Research Approach

Our research aimed to assess the prevalence and impact of permission piggybacking in third-party libraries. To achieve this, we developed a novel analysis technique that can detect opportunistic permission usage by third-party libraries. Normal behaviour would be that if a library requires permission to a resource, it first checks if the permission was already granted. If not, the library would generate a permission pop-up to request the permission and then use the restricted resource. During permission piggybacking, the library only checks and uses the permissions already granted, but it never requests it.

In our approach, we used a static analysis to first search for check permissions API calls. Afterwards, we compare it with the permission request API calls. Finally we assign the different API calls to the main app or to the different integrated libraries. As previously described, we evaluated the checked and requested permission API calls on a per library basis. We flag a library as permission piggybacking whenever it checks more permissions than requested.

Evaluation Results

We then put this technique to the test by analysing the top 1,000 applications on Google Play. We aimed to measure the extent of opportunistic permission usage by third-party libraries and determine the prevalence of this technique.

Pie chart showing a 36% fraction with no piggybacking, 50% piggybacking and 14% unknown behavior of 851 different libraries.

Out of the 1000 apps, we have extracted 851 different libraries. In 14% of the libraries we were unable to certainly determine if permission piggybacking is used due to the limits of the static analysis. However, we were able to determine that an overwhelming 50% of the 851 libraries use permission piggybacking.

Interestingly, the permissions most often piggybacked were almost exclusively dangerous permissions as defined by Android documentation. Specifically, those were the fine and coarse location (GPS/mobile network cell) and read phone state. These permissions provide access to sensitive user data and make it possible to uniquely identify and track devices as described in our fingerprinting article.

Top 15 of piggybacked permissions in the top 1000 Android apps, by the number of occurrence in non-obfuscated libraries
Top 15 of piggybacked permissions in the top 1000 Android apps, by the number of occurrence in non-obfuscated libraries

Furthermore, our analysis revealed that most libraries engaging in permission piggybacking were related to advertising, usage statistics and tracking. These libraries, by their nature have strong interest in extensive data collection.

Further insights on our used detection mechanism can be read in our extensive paper at Scitepress, published at the ICISSP conference 2025. This paper was awarded as the best paper of this conference.

Conclusion and Outlook

Our research underscores that permission piggybacking remains a significant and widespread issue with 50% of all libraries leveraging this technique. Thus, in practice chances of having a piggybacking library installed are very high. To effectively address this, implementing a more granular permission system at the library level is being a viable solution.

As a result, users must be mindful of the permissions they grant to the apps they install until Google implements such measures in Android. Even though for example giving the location permission to a navigation app seems legit, advertisement, or usage statistics libraries integrated into the app potentially piggyback and abuse these permissions for data collection. Depending on the use case of an app, it might be also an option to manually provide the location to the app, e.g. by entering the town name for the weather app once instead of granting the location permission that allows all included libraries to track any location changes of the user.

Appicaptor is already capable of analysing the possible types of accessed data, used permissions as well as integrated third-party libraries. Thus, Appicaptor results already pose a viable foundation for a user’s informed app selection. We are currently working on integrating the permission piggybacking detection approach into Appicaptor for our customers.

Apple’s Required Reason API: Aftermath after one year in practice

Apple designed the “Required Reason” API to enhance user privacy and trust. It helps ensure that app developers clearly communicate the reasons for requesting access to personal data or certain device capabilities. The guideline is now active for almost a year, and we’ve observed that this approach seems to generally work. But in practice, we observe some developers sneaking around these restrictions without Apple acknowledging this fact.

A smartphone with a shield symbol on the screen is shown beside a red apple with a bite taken out of it, symbolizing incomplete privacy.

As we approach the first anniversary of Apple’s Required Reasons API, we feel it’s time to recap it’s privacy gains in practice.

For developers, the Required Reasons API acts as a gatekeeper into the app store. It requires them to provide clear justifications for using certain APIs that access sensitive user data or system capabilities. The users can then inspect and evaluate the provided reason during app install. The principle behind this API is to promote transparency and user control over personal data. A significant contribution is the seamless integration of third-party library required reasons into the main app. This has ensured that the privacy measures extend beyond the core app, covering all the integrated elements.

Diving into the Details: Boot Time Example

To illustrate this, let’s take the example of boot time. The boot time of a device in microseconds is unique and can easily be used for device identification. Thus, such data requires sufficient protection to hinder device fingerprinting and therewith protecting the user’s privacy. Apple has identified two boot time related APIs: systemUptime and mach_absolute_time(). These require developers to provide specified reasons for their use. Apps or libraries accessing these methods must provide a reason in the app’s/library’s PrivacyInfo.xcprivacy file. This XML-file contains among other things a key specifying a resource linked with a reason for accessing this resource. Apple provides different short identifiers which specify a usage purpose as shown here:

<key>NSPrivacyAccessedAPICategorySystemBootTime</key>
<string>35F9.1</string>

In this example, the short identifier specifies the following reason, documented by Apple:

“Declare this reason to access the system boot time in order to measure the amount of time that has elapsed between events that occurred within the app or to perform calculations to enable timers. Information accessed for this reason, or any derived information, may not be sent off-device. There is an exception for information about the amount of time that has elapsed between events that occurred within the app, which may be sent off-device.”

A Year of Practice: The Good…

To evaluate these advancements in practice, we have collected the most popular third-party libraries for iOS apps. Next, we searched for libraries, known for device fingerprinting activities. The Required Reason API typically impacts such libraries the most, since they heavily rely on this data. In practice, the top three libraries leveraging device fingerprinting techniques make up more than 80% market share. Thus, analysing the top three libraries already provides broad coverage. We found that the top three libraries in fact use APIs from the “Required Reasons API” list, but provide a proper reason declaration. This means, that whenever a respective API is used, an appropriate cause in the PrivacyInfo.xcprivacy is provided. Thus, developers are adhering to the rules, and/or Apple is effectively enforcing these rules in the App Store.

…and the Bad

However, we have observed instances in some used libraries where developers have found ways around these obligations. These libraries use other methods for querying boot time, such as sysctl and sysctlbyname.

In iOS, sysctl and sysctlbyname are system calls enabling access to kernel parameters at runtime. They allow developers to query essential information about the system, such as CPU and memory statistics or the boot time. The sysctlbyname call offers a more user-friendly access method by using string identifiers instead of integers. Thus, an alternative way to query the boot time with this function would be:

sysctlbyname("kern.boottime", &bootTime, &size, nil, 0)

Additionally enforcing these APIs would require evaluating the arguments during the static analysis in Apple’s app publishing process. Evaluating the arguments during a static code analysis can sometimes be complicated if the argument isn’t a constant. Advanced techniques like symbolic execution or data dependency analysis might be necessary, features already applied in Appicaptor.

We have already contacted Apple on May 2nd, 2024 and informed them about missing items in their Required Reason API. However, they did not respond up until this day. We think that Apple is well aware of these APIs but doesn’t want to confirm this due to political reasons.

The Road Ahead

In conclusion, we see that Apple strides in the right direction, but there are still loopholes that need to be addressed. We look forward to seeing Apple continue to enhance its privacy measures, closing remaining gaps. Meanwhile, we continue to monitor Apple’s Required Reason APIs usage with Appicaptor and check for violations.

iOS Privacy Manifest: Data Collection and Usage in Top Free iOS Apps

Since May 2024, the inclusion of an iOS Privacy Manifest has been a requirement for app submissions with newly added third-party SDKs. We analyzed first results about data collection practices, compliance issues with Apple’s guidelines, and privacy risks posed by SDK providers.

Apple mandates that all app submissions with specific newly added third-party SDKs have to include a comprehensive iOS Privacy Manifest. This manifest outlines the data collection and usage practices of apps, providing users with transparency and empowering them to make informed decisions about their digital privacy. As outlined in our previous blog post, Appicaptor correlates the privacy manifest contents with additional privacy findings through static analysis.

In our evaluation, we analyzed the iOS Privacy Manifests definitions of our app sample set, that consists of the most popular 2,000 free iOS apps available on the German Apple App Store in June 2024.

Apple mandates that apps with newly added third-party software development kits (SDK) of one of the 86 listed third-party SDKs have to include a iOS Privacy Manifest (see Apple Developer Support). Our analysis of the app sample set revealed the presence of all 86 SDKs in at least one app. We evaluated whether apps integrating these SDKs adhered to the privacy manifest requirement: Our findings indicate that only 47 out of the 86 SDKs were associated with at least one app that defined a privacy manifest. Conversely, the remaining 39 SDKs were utilized at least within one app within the sample set, but no app employing these SDKs defined a privacy manifest. This discrepancy may stem from the following factors: either the SDK developers may have not provided a privacy manifest template for their SDKs, or the app developers have not incorporated SDK versions that include privacy manifest template or explicitly deleted the manifest entry, or the app update does not include a newly added third-party SDK from the list. So our analysis can only investigate the Privacy Manifest declarations of about half of the libraries that Apple has selected. However, these first results already provide interesting insights in the data analytics industry.

What data is requested in real apps and why?

As first evaluation on the manifest content, we evaluated the data types declared within the iOS Privacy Manifests of our app sample set. Our analysis revealed that 50% of the apps declare in the manifest that they collect data types such as OtherDiagnosticData, CrashData, and DeviceID. Especially the data type DeviceID is privacy-sensitive as it provides the possibility to correlate actions of users across the sandbox boundaries of individual apps.

The full list of collected data types and the number of apps in which such data is collected according to the privacy manifest is given in the following graph. It can be seen, that a wide range of data types are defined in the app set, including very sensitive data types as Health (Health and medical data), PhysicalAddress, PreciseLocation and SensitiveInfo (racial or ethnic data, sexual orientation, pregnancy or childbirth information, disability, religious or philosophical beliefs, trade union membership, political opinion, genetic information, or biometric data).

Although Apple clearly specifies how data type classes should be defined in the iOS Privacy Manifest, we found 205 apps within our app sample set that included malformed or self-defined data types in iOS Privacy Manifests. Consequently, these do not align with Apple’s specified requirements and the discrepancy highlights issues in the implementation and adherence to Apple’s guidelines.

Following the evaluation of data types, we proceeded to assess the given purposes. The next graph presents the distribution of purposes defined in the iOS Privacy Manifests per app. Our analysis indicates that collecting data is declared for the purposes of AppFunctionality or Analytics in over 60% of the apps of the sample set. Consistent with our findings in the data type evaluation, we observed that a substantial number of apps (235 apps) which included purpose definitions deviate from Apple’s expected values. These are summarizes in the category Malformed / Self-defined Purpose in the chart below.

Do the declared data type and their reasoning align?

Further analysis was conducted to determine which data types are collected for which specific purpose and in how many apps of the app sample set this occurs. For this evaluation, we analyzed the iOS Privacy Manifest definitions of the 2,000 apps in our sample set, focusing on tuples of data types and associated purposes. The following graphic illustrates which data types are accessed for which purposes. The size of the circles corresponds to the number of apps in which that specific data type-purpose tuple was defined in the iOS Privacy Manifest. It is interesting to see, that collecting certain sensitive data types such as SensitiveInfo, PhysicalAddress, PreciseLocation and Health are declared for purposes besides AppFunctionality and almost all data types are used also for the purpose of Analytics, which could have an effect on user’s privacy.

Are there component providers that stand out in terms of data type and usage?

Data types and purposes are defined for specific components in the iOS Privacy Manifest. For that reason, our next focus was to investigate if specific purposes to collected data types are specific to certain component providers. Therefore, the following analysis examines the purposes for collected data types grouped for each component provider within the iOS Privacy Manifest. The following graph highlights the relationship between purposes and the SDK provider. To do so, we associated the providers to their SDKs and extracted the 20 most frequently contained SDK providers in the Privacy Manifests within the evaluated app set. We analyzed in how many apps each purpose is defined for these top 20 providers within the app set. In the diagram it can be seen that certain providers, such as Firebase, concentrate on a few specific and targeted purposes. In contrast, others, like Adjust, request data for a wide array of purposes. As the purposes relate to the activities of the SDK providers, this can be seen as summary on the functionality aspects provided by the SDK components and their providers.

Similar to the evaluation of the specific purposes related to component providers, we expanded the view to cluster the information according to the data types accessed. To do so, we again took the 20 most frequently mentioned SDK component providers in the Privacy Manifests within the evaluated app set and counted how many apps declare a data type and purpose tuple for these top 20 component providers. In the following graph the size of the circles in the graph corresponds to the number of apps in which each specific data type-purpose tuple was declared in the iOS Privacy Manifest. Like the former evaluation, this graph shows, that certain component providers (like Firebase) focus on certain data type and purpose tuples, whereas other component providers define various data type and purpose tuples (e.g, Google and Facebook).

The data type definition may additionally contain boolean processing flags, that should specify external usage of the data. The processing flag linked specifies that the data type is linked to the user’s identity, whereas tracked specifies that the data type is used to track users. Our final evaluation of the Privacy Manifest data of the app sample set focus on the aspect whether certain data providers specify data types with these processing flags or not.

Data types flagged with tracked can be shared with a data broker. Therefore, if the processing flag tracked or linked/tracked is set, this may threaten the user’s privacy significantly. Therefore, we examined what processing flags are set by different component providers for requested data types. We took the ten most frequently mentioned SDK component providers in the Privacy Manifests within the evaluated app set and analyzed how many apps declare a data type, processing type and purpose tuple for these top ten component providers. The size of the circles in the following graph corresponds to the number of apps in which each specific data type-processing flag-purpose tuple was defined in the iOS Privacy Manifest. The graph groups the data types in relation to the requested purpose in circle groups. The circle group’s label states which processing flags are set to true: If the circle group is labeled with linked, then only the data type is linked to the user’s identity. If circle group is labeled with linked/tracked, then the data type is linked to the user’s identity, and it is used to track users. Elements of a circle group that has no label are neither linked nor tracked.

A significant difference in the processing flag usage can be seen when comparing the results for Google and Facebook. Google defines the processing flag linked or no processing flag for most data types and purposes. In contrast, Facebook sets the processing flag with the most possible extent linked/tracked for most data types and purposes.

Conclusion

The analysis of iOS Privacy Manifests for the 2,000 most popular free iOS apps on the German Apple App Store in June 2024 reveals several insights about data collection practices and compliance with Apple’s guidelines.

About half of the Privacy Manifests in apps have declared to collect data type OtherDiagnosticData, CrashData or DeviceID, with various sensitive data types also being collected. However, the presence of apps with malformed or self-defined data types indicates inconsistencies in adhering to Apple’s guidelines. Additionally, the observed entries for data collection purposes were found to violate Apple’s specification. This undermines the effectiveness of the privacy manifest and hopefully will be addressed with checks by Apple during the app review process.

However, even in this preliminary analysis with a lot of data missing for SDKs, the benefit of the Privacy Manifests can be seen. This way, it is possible to inspect the relations between collected data types, purposes and components, showing that in some apps sensitive data types are collected for purposes not related to the app’s functionality.

The examination of specific data type-purpose tuples and their association with component providers revealed that certain SDK providers, focus on targeted purposes, while others, request data for a broader range of purposes. Notably, the processing flags for data types, particularly those flagged as tracked, pose significant privacy risks. The contrast between providers, which primarily uses the linked flag, and those which extensively use the linked/tracked flag, may underscore the varying levels of privacy impact across different SDK providers.

Vulnerable Third-Party Libraries in Mobile Apps

As mobile app usage grows, so do concerns about security vulnerabilities. One significant aspect contributing to these vulnerabilities is the inclusion of third-party libraries in app development. In this article, we explore the importance of monitoring vulnerable third-Party Libraries in apps, and conducting risk analysis based on that information. Appicaptor analyses unveil that numerous apps include third-party libraries in versions known to have vulnerabilities. What’s more troubling is that some of these vulnerable versions are known to be attackable for years.

Third-party libraries are pre-existing code modules or components developed by external parties. Developers integrate these libraries into their applications to streamline development, enhance functionality, or access specialized features. Ranging from simple utility functions to complex frameworks, third-party libraries serve as building blocks for mobile app development. While beneficial, they also introduce dependencies that can impact the security of the app.

Like any software component, third-party libraries can contain vulnerabilities that malicious actors exploit to compromise the security of the app and its users. These vulnerabilities may arise due to coding errors, insecure configurations, outdated dependencies, or inadequate security practices during development.

Finding Vulnerable Third-Party Libraries

Appicaptor executes an evaluation of iOS and Android apps including their third-party libraries and their impact on app security by:

  • Recognizing included libraries and their versions: Identifying the included third-party libraries and their specific version in Appicaptor. This identification is based on the analysis on the iOS or Android app’s binary, the library signatures, class/method structures and metadata.
  • Library Vulnerability Lookups: With the third-party libraries and versions identified, Appicaptor holds a database with information about known vulnerabilities found within third-party libraries broadly utilized in the iOS or Android app development landscape. By referencing sources such as CVE entries, Appicaptor compiles the list of known vulnerabilities and weaknesses relevant to the app’s third-party dependencies.

Vulnerable Third-Party Library Analysis

In the following we present the Appicaptor results analyzing the 2,000 most popular free apps for iOS evaluating app libraries and JavaScript libraries.

The initial aspect under evaluation pertains to determining the extent to which discovered vulnerable library versions have been recently published or have been known for an extended period. This inquiry aims to gauge the likelihood of vulnerability resolution, with a high number of recent CVEs suggesting a higher probability of fixes compared to older CVEs. Our methodology involved finding all vulnerable library versions across all analyzed apps and examining the publication year of each CVE of these vulnerable library versions. Then we aggregated the occurrences of applicable CVEs for each year, which were then plotted on a graph.

The second graph focuses on another facet: the age of the oldest CVE found in each app containing vulnerable library versions. This aspect addresses the duration during which an app might remain susceptible to attacks. To accomplish this, we identified the oldest CVE entry for each app featuring vulnerable third-party library versions, and subsequently plotted the sum of occurrences/apps for each year.

Lastly, the final graph delves into identifying the libraries primarily responsible for vulnerabilities in apps, as they are integrated more frequently in versions containing vulnerabilities.

App Libraries Results

Among the 2,000 most popular free iOS apps analyzed, 161 were discovered to have one or more vulnerable versions of app libraries. Assessing the timeline of vulnerability disclosures for each identified vulnerable third-party version within these top-tier iOS apps reveals two key trends: Firstly, certain apps feature multiple vulnerable third-party app libraries, indicating potential widespread susceptibility. Secondly, there appears to be an ongoing effort to patch these vulnerabilities, as evidenced by the increasing total number of CVE-listed vulnerabilities for the 2,000 evaluated apps versions from past to present. This suggests that patched versions of the libraries are being adopted in app updates as they become available, thereby mitigating security risks over time. But we also found occurrences of old CVEs (including our 2019 published TwitterKit vulnerability). The vulnerable versions of app libraries predominantly used in the 2,000 most popular free iOS apps mainly issue communication and data management, with notable examples being nanopd, ssziparchive, and zipfoundation.

Summarized number of CVEs for vulnerable app library versions found in apps by year of the CVE's publication (2,000 most popular free iOS apps)
Summarized number of CVEs for vulnerable app library versions found in apps by year of the CVE’s publication (2,000 most popular free iOS apps)
Summarized number of apps with one or more vulnerable app library versions by year of the oldest CVE's publication (2,000 most popular free iOS apps)
Summarized number of apps with one or more vulnerable app library versions by year of the oldest CVE’s publication (2,000 most popular free iOS apps)
Number of apps containing TOP 3 of vulnerable app libraries (2,000 most popular free iOS apps)
Number of apps containing TOP 3 of vulnerable app libraries (2,000 most popular free iOS apps)

JavaScript Libraries Results

In contrast to the app library evaluation, the analysis of vulnerable JavaScript library versions within the top 2,000 free iOS apps reveals a different scenario. Only 81 apps include vulnerable JavaScript library versions, but these vulnerabilities tend to persist for longer periods. We found 74 occurrences of CVEs that were published nine or more years ago. The chart presenting the oldest CVE for each app shows a similar result: 54 apps include at least one vulnerable JavaScript library version whose vulnerability was published nine or more years ago. The most found vulnerable JavaScript library versions primarily revolve around two key libraries: jquery and angular.js.

Summarized number of CVEs for vulnerable JavaScript library versions found in apps by year of the CVE's publication (2,000 most popular free iOS apps)
Summarized number of CVEs for vulnerable JavaScript library versions found in apps by year of the CVE’s publication (2,000 most popular free iOS apps)
Summarized number of apps with one or more vulnerable JavaScript library versions by year of the oldest CVE's publication (2,000 most popular free iOS apps)
Summarized number of apps with one or more vulnerable JavaScript library versions by year of the oldest CVE’s publication (2,000 most popular free iOS apps)
Number of apps containing TOP 3 of vulnerable JavaScript libraries (2,000 most popular free iOS apps)
Number of apps containing TOP 3 of vulnerable JavaScript libraries (2,000 most popular free iOS apps)

Conclusion

Monitoring and evaluating third-party libraries are critical components of mobile app security. The presented results show on the one hand, that certain libraries are included in a reasonable number of apps with vulnerable versions. This adoption of vulnerable library versions in popular apps raises serious concerns regarding the security posture of the applications and the data they handle. On the other hand, vulnerable library versions remain far too long in apps after the vulnerability has been published. Even as developers strive to introduce new features and improve user experience, security vulnerabilities often linger, posing a persistent threat to user’s data and privacy.

Security Implications of Apple ID Switching and Keychain Merging in COPE Mobile Environments

The ability to switch Apple IDs on iOS devices poses a security risk for Corporate-Owned, Personally Enabled (COPE) mobile environments. When users opt to retain Keychain entries while transitioning from a corporate Apple ID to a private Apple ID, it results in the merging of passwords to the private Apple ID. This merging poses a significant challenge for organizations that need to maintain strict control over corporate credentials, as enterprise passwords can then be synced with all private devices using the private Apple ID.

Switching Apple IDs on an iOS device involves opening the “Settings” app on an iOS device, navigate to the Apple ID section and opt to sign out of the current Apple ID. This prompts a confirmation step, asking users if they wish to keep a copy of their data on the device or to delete it. This decision is crucial to consider because if the user opts to keep the Keychain data to be stored on the device, this decision will have implications for the passwords associated with the Apple ID currently signing out. Following the sign-out, users can proceed to sign in with the new Apple ID. Once the necessary information is entered and the setup is complete, the iOS device becomes associated with the new Apple ID. The device syncs with the new account, applying apps, data, and settings associated with the updated Apple ID. However, apps installed with the previous Apple ID are still usable.

Saved passwords of personal Apple ID
Saved passwords of personal Apple ID
Saved passwords of corporate Apple ID
Saved passwords of corporate Apple ID

Keychain Merging and Its Effects

When logging into a website using Safari, a pop-up typically appears, asking if the user likes to store the password for AutoFill. This method simplifies the process of adding accounts to the password store. Alternatively, when creating a new account, users receive an automatically generated strong password. In either case, users can add accounts and passwords in the password store. The passwords are stored in the Keychain. If the user chooses to keep the Keychain data stored on the device during the Apple ID switching, this results in a merging of the stored passwords of the former and the latter configured Apple ID on the device.

COPE environments prioritize the separation of work and personal data, but the Keychain merging while switching Apple IDs on iOS devices undermines this separation. This has to be considered in situations where employees use their personal Apple IDs alongside corporate profiles on the same device. If one Apple ID during the Apple ID switching process is the corporate ID and the other is the private ID, that leads to merging of corporate and personal credentials compromising the security posture of COPE mobile environments and/or the privacy of the user’s private credentials.

Data retention dialogue when signing out from one Apple ID: When the "Keychain" option is selected in the dialogue whilst signing out from corporate Apple ID and before signing in to the personal Apple ID, stored corporate passwords are merged with stored personal passwords.
Data retention dialogue when signing out from one Apple ID: When the “Keychain” option is selected in the dialogue whilst signing out from corporate Apple ID and before signing in to the personal Apple ID, stored corporate passwords are merged with stored personal passwords.
Corporate passwords from signed out corporate Apple ID are merged to saved passwords of personal Apple ID. All shown passwords are available in personal Apple ID.
Corporate passwords from signed out corporate Apple ID are merged to saved passwords of personal Apple ID. All shown passwords are available in personal Apple ID.

Lack of Mitigation Through MDM Restrictions

Currently, there is an absence of Mobile Device Management restrictions to mitigate the unintended consequences of password merging during Apple ID switching. The inability to prevent Keychain merging in COPE environments can have a significant impact for organizations. The only measure is to enforce employee education and awareness regarding the risks associated with Apple ID switching and Keychain merging. Training programs should emphasize the importance of choosing secure options during account transitions and the potential impact on corporate and private data security.

Conclusion

The merging of Keychain entries during Apple ID switching on iOS devices poses a significant security challenge, particularly in COPE mobile environments. Organizations currently need to be proactive in addressing this issue through employee education and awareness programs. Collaboration between organizations, MDM providers and Apple, is needed to develop comprehensive solutions that safeguard corporate credentials and mitigate the risks associated with Apple ID switching.

No Patch, no Trust: Consequences of iOS Data Flow Restriction Bypasses for Enterprises

A large, sliced apple stands upright in a grassy field with a winding path leading through its hollow core, creating a tunnel-like effect. The surreal scene opens to a bright, circular light at the end of the path under a clear blue sky.

The number of ways to bypass iOS data flow restrictions meanwhile has further increased, but Apple still does not bother to fix them. So, the question is: How trustworthy are iOS MDM restrictions if even simple tricks to bypass them are not closed by Apple?

In many enterprises, there is the need to separate data of different origins or trust levels. In COPE (company owned, personally enabled) deployments this typically is the separation between private and business apps. Whereas in COBO (company owned, business only) deployments often data of supporting tools (such as travel management) should be separated from confidential enterprise data or other data with higher protection requirements.

Apple acknowledges this demand of controlling the data flow, “to keep it protected from both attacks and user missteps” by applying the Mobile Device Management (MDM) settings “Managed Open In” and “Managed pasteboard”. However, we have already demonstrated that it is possible to circumvent these MDM restrictions with the pre-installed iOS Shortcuts App. Others also reported issues already in 2020 with the possibility to use the “Quick Look” functionality of the native iOS email client for a bypass, also demonstrated in a video.

New Findings

The recently new discovered and reported issues are related to the iOS Files app. The first issue is related to the “Recents” Tab of the Files app. When a user had opened any document in a managed app before and now open an unmanaged document in the “Recents” tab of the Files app, the share action incorrectly presents a list of managed apps instead of unmanaged apps. The opposite direction for the bypass (managed to unmanaged app) is the second newly reported issue. Deleting a managed document with the Files app and copying it to an unmanaged app folder (instead of restoring it) removes the MDM restriction and permits the user to open the document in the unmanaged app. This is also shown in our extended demonstration video, now demonstrating five unfixed issues with the iOS data flow restrictions.

Reactions to Reported Issues

We again reported the two new issues to Apple, but also this time, Apple argued that “MDM profiles provide configuration management but do not establish additional security boundaries beyond what iOS and iPadOS have to offer.” A similar argument was also given for the reported MDM restriction bypass of SySS GmbH.

For all these six bypass issues, there are currently no mitigations available. Taking all the current conversations with Apple into account, and as reported issues of 2020 are still not fixed, there seems to be no justifiable reason to believe that our findings will be fixed sooner.

Consequences for Enterprises

MDM restrictions are a vital instrument for securing the usage of iOS devices in enterprise environments. Only thanks to these restrictions, the requirements of enterprises can be fulfilled for a device that is primarily developed for the consumer market. Even with effective MDM restrictions it is still a challenging task for enterprises to keep up with constantly changed and extended features of mobile smartphone operating systems. And often enough, MDM restrictions that would make new features acceptable for enterprises are released only major versions later, if any (e.g., still no possibility to prevent a mix-up of private and enterprise passwords when switching between private and enterprise Apple IDs in COPE deployments, discussed in an upcoming article).

Experiencing the lack of support for fixing multiple reported issues in advertised security features now raises the question: Which other MDM restrictions are insecure? When one follows Apple’s argument, for any other bypass of such MDM restrictions a patch will be rejected and probably already have been rejected before, as MDM restrictions are always just configuration options per definition. This isn’t then only a technical issue, it becomes an issue of trust in supporting enterprises with reliable solutions.

In consequence, the missing patches reduce the possibilities for a secure iOS enterprise deployment in COPE and COBO scenarios.