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 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)

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 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)

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.

iOS Privacy Manifest: Empowering Data Privacy Evaluation

Staying informed about how apps collect and use your data is crucial in digital privacy. Addressing this, Appicaptor finds privacy-related app issues and extracts contents of the iOS Privacy Manifest. All information is correlated with results from static and dynamic analysis to provide enhanced privacy insights.

In today’s interconnected digital landscape concerns related to data privacy are in focus. App developers, platform providers and smartphone OS manufacturers face pressure to prioritize user privacy and transparency. In response to these concerns Apple has introduced an initiative: the iOS Privacy Manifest. This feature serves as a documentation how apps access, utilize and transmit privacy-related data. Appicaptor uses the information from the iOS Privacy Manifest, enabling users and companies to make well-informed decisions.

Understanding the iOS Privacy Manifest

iOS Privacy Manifests are attached to the app’s binary as property list (plist) and hold information regarding the collection and usage of privacy-related data by the app and included third-party SDKs. Not providing valid information within the iOS Privacy Manifest may lead to notifications or rejection throughout the app submission process. Strict enforcement in the App Store is scheduled starting in May 2024.

Privacy Manifest Components

When it comes to populating a iOS Privacy Manifest, there are several key data structures that developers must adhere to:

  • Required Reason APIs:  Apple introduced a class of APIs referred to as Required Reason APIs to address concerns regarding fingerprinting. Any app or SDK utilizing an API from this list must explicitly state a valid purpose for their usage.
  • Data Usage Categories: Developers must provide a breakdown of data usage categories in their privacy manifests. This includes specifying the data collected, whether it’s linked to end-users’ identities, its usage for tracking purposes, and a list of reasons justifying. Apple provides a predefined set of purposes that developers have to reference.
  • External Domain Usage: All external tracking domains used in the app or third-party SDKs must be listed in the iOS Privacy Manifest. This provides users with clear visibility into the presence of all domains utilized for tracking purposes. When tracking permission (via the App Tracking Transparency framework) is not granted by the user, network requests to these domains will be blocked by iOS.

Appicaptor: iOS Privacy Manifest as additional App Evaluation Source

Appicaptor extracts the contents of the iOS Privacy Manifest and presents them in human-readable format. But beyond that, Appicaptor correlates the manifest’s content with privacy-related findings discovered from the app binary through static analysis. Therefore, Appicaptor offers users a comprehensive understanding of how their privacy-related data is handled by the apps:

  • Privacy Transparency: By presenting the iOS Privacy Manifest contents in a human-readable format, Appicaptor users gain transparency into the app’s data collection practices.
  • Informed Decision-Making Elevated: Armed with in-depth understanding of an app’s privacy practices, Appicaptor users can make informed decisions about whether to engage with the app. Correlation of the manifest contents with static analysis findings in coordination with Appicaptor’s ability to define custom rulesets empowers companies to assess the privacy risks associated with using the app to make choices aligned with their privacy preferences and concerns.
  • Enhanced Privacy Insights: Appicaptor’s static analysis enables an examination of the app’s codebase, revealing privacy insights in addition to what is disclosed in the iOS Privacy Manifest. By correlating these findings, users gain a more granular understanding of how their data is collected, used, and shared by the app.
  • Accountability and Trust Building: Appicaptor’s evaluation reports promotes accountability and trust by ensuring alignment between stated privacy practices and actual implementation. By correlating the results, Appicaptor users can identify and address any discrepancies between the documentation and implementation of privacy-related data usage.
Uncorrelated iOS Privacy Manifest information prestenation in Appicaptor

Conclusion

In an era where trust between users and tech companies is important, transparency regarding data collection practices is non-negotiable. Using the iOS Privacy Manifest as an additional source of evaluation, Appicaptor enhances its app evaluation capabilities and gives users a more thorough understanding of how their data is handled by various apps. This integration enforces Appicaptor’s commitment empowering users with transparent and informed decisions regarding app security.

Appicaptor’s solution contributes to the overall integrity of the digital ecosystem by promoting transparency, accountability, and responsible data usage. By empowering users with comprehensive privacy insights and encouraging developers to uphold best practices and that the implementation is inline with documentation, Appicaptor’s approach supports a culture of trust and integrity that benefits everyone involved.

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 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.
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

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.

Trivial Bypass of iOS MDM Restrictions Apple doesn’t fix

Apple promotes MDM restrictions that should prevent data flows between managed and unmanaged apps. These restrictions can be bypassed easily and effortlessly using an app that is pre-installed on every new iOS device: the Shortcuts App. This is a finding of our practical tests on iOS 17.1 that should concern all enterprises that rely on these restrictions to use iOS devices in a compliant way with their enterprise policy for personal enabled usage.

Update: Problem is not only related to iOS Shortcuts App. MDM Restrictions can also be bypass with iOS Files App and iOS E-Mail client.

Apple promotes the data flow control between managed and unmanaged apps as a solution for data separation between personal and corporate data, “to keep it protected from both attacks and user missteps“. To achieve this protection, many enterprises configure the following Mobile Device Management (MDM) restrictions for the managed iOS devices:

Managed pasteboard. In iOS 15 and iPadOS 15 or later, this restriction helps control the pasting of content between managed and unmanaged destinations. When the restrictions above are enforced, pasting of content is designed to respect the Managed Open In boundary between third-party or Apple apps like Calendar, Files, Mail, and Notes. And with this restriction, apps can’t request items from the pasteboard when the content crosses the managed boundary.

Allow documents from managed sources in unmanaged destinations. Enforcing this restriction helps prevent an organization’s managed sources and accounts from opening documents in a user’s personal destinations. This restriction could prevent a confidential email attachment in your organization’s managed mail account from being opened in any of the user’s personal apps.

(see Apple Document “Managing Devices and Corporate Data”, accessed October 9th, 2023)

With the first restriction, a user should not be able to paste the content of the pasteboard to an unmanaged app, if the content was copied from a managed app, or vice versa. The second restriction applies the same restriction to documents. And in our tests, iOS prevented us from performing such actions, after the MDM restrictions for the test devices have been activated.

However, the iOS Shortcuts App, which is an integral part since iOS 13 and can be used to automate almost any task on iOS, can be abused to bypass such restrictions. The first shortcut (below on the left side) simply reads the clipboard and copies the content back to the global clipboard, which is then also synced with all other devices that the user has logged in with the same Apple account. When the user activates this shortcut, it strips of the information, that the original content was copied from a managed app and so iOS does no longer prevent the paste action to an unmanaged app. Each shortcut can also be combined with a trigger action that can automated the execution of it. So, the bypass of iOS MDM Restrictions can also be automated.

The second example shortcut uses the input of the share sheet to save the content of a document from a managed app. When using this shortcut in the share sheet, iOS prompts for name and location of the file and stores it without the information, that the content originated from a managed app. This way the document can be opened also from unmanaged apps. We created a video for both bypass methods to show the environment and the results in action. But these are only simple examples of the problem. There are many more possibilities to use actions of the Shortcuts App to bypass the iOS MDM restrictions.

Apparently, the Shortcuts App has privileges to access any data from managed apps, although it is not configured as a managed app through the MDM profile. This way the app can access the data, but when the data is saved by the Shortcuts App, it is saved as an unmanaged app. The fix therefore should be to keep the origin information of the content the Shortcuts app processes. This way the app could still access content from managed apps, but the processed content would be marked as originated from a managed app and this way the data separation would be kept intact.

We reported this flaw via Apple’s responsible disclosure process. However, the issue was rejected. We provided a detailed description, screenshots and videos, but also on a second try, where we explained again that the bypass circumvents an advertised security feature of iOS, it was not accepted. We also reached out to Apple via feedbackassistant.apple.com, but did not receive any answer in 2 months. As the current Shortcuts App version 6.1.2 is still vulnerable, we decided to publish the findings to warn enterprises that they cannot rely on iOS data flow restrictions.

A short-term solution would be to delete the iOS Shortcuts App from the devices and block the installation with the MDM blacklist via the bundle ID “com.apple.shortcuts” or to exclude devices with installed Shortcuts App from the domain as non-compliant, depending on the provided functionality of the MDM solution used. However, in the VMware Workspace ONE UEM (AirWatch) MDM tested, the Shortcuts App blacklisting did not prevent the installation nor was the device marked as non-compliant.

Without a proper blocking of the Shortcuts App, company data can currently be sent unintentionally in unmanaged apps through manually used or automated shortcuts and thus leave the company in an uncontrolled manner.

You can visit us on it-sa Expo&Congress, 10. – 12. October in Hall 6, Booth 210 for further details.

Device Fingerprinting on iOS Apps

Device fingerprinting is a technique that got popular at the end of the 90s by websites, to identify and track users. Apps have in contrast to websites often access to a much wider property range usable for fingerprinting. The unique device identification via fingerprinting across sandbox borders of multiple apps is a relevant privacy issue as it increase the possibilities for tracking users, even without requiring permissions. Many smartphone users are unaware of such practices and possibilities because such activities happen unnoticeably in the background.

Just like each person has an individual fingerprint, electronic devices are also uniquely identifiable. Through manufacturing tolerances, different hardware configurations, software properties and individual software configurability such devices become uniquely identifiable. Depending on the number and the variance of properties used, more or less unique fingerprints can be generated. Typically, several hard- and software device properties are combined through a hashing algorithm to an ideally unique bit sequence.

Motivations for app developers to include tracking libraries are: advertisement, bot detection, account takeover, spam, fraud detection and secure environment detection for payments. Mobile operating systems such as Android and iOS are aware of the user’s transparency through fingerprinting and take steps to empower the user to regain privacy whilst trying to maintain legitimate tracking objectives. The advertisement ID was introduced especially to target device tracking with a resettable ID provided by iOS. It allows advertisers to personalize ads and at the same time give the user options to reset it or hide it for individual apps. Also, Privacy Labels are added to the app store to better explain the app’s data usage to the user. Permissions and Privacy Labels should shed light on the usage of tracking, and it’s purpose during app install and usage. Apple AppStore’s licence agreement also states clear rules on data and identifier usage. However, as shown by Deng et al., many apps exist in the AppStore infringing such rules, working their way around permissions and being dishonest with their Privacy Labels. One increasing way to bypass such restrictions is to use fingerprinting techniques not requiring user consent.

Tracking Possibilities with Fingerprinting

The fingerprint generated by each app containing the same fingerprinting SDK are ideally the same on the same device. The user becomes very transparent by correlating the fingerprint with other data provided during app usage. As an example, one could think of a scenario, pictured in the following figure, where a shopping app, a search engine app and a navigation app all contain the same fingerprinting SDK. All user input of each app like recent purchases, search terms and the device location could be accumulated in the cloud under the same fingerprint. The data collection of each app alone is already a privacy risk to the user, but the combination of different app data makes users fully transparent. Such data is extremely valuable for example for advertisement companies to personally tailor advertisements for individual users.

Example of tracking possibilities with fingerprinting SDKs

Fingerprinting SDKs and Commonly used Properties

To gain insight into the current state of iOS fingerprinting and the latest techniques being used, we identified real iOS fingerprinting SDKs through systematic internet research and conducted manual static and dynamic analysis. The respective SDKs source-code was manually analysed with Ghidra and if possible, the SDK was tested in a minimal app construct. During the manual analysis we judged the SDK as fingerprinter or non-fingerprinter based on the observed behaviour and used properties. This leaves 13 SDKs that we classify as fingerprinters and further analyse in more detail. The SDKs are listed in the following table. We found that all 13 SDKs use the native iOS API to collect device characteristics. Through dynamic analysis of custom-built test apps, we have found that the collection of features shows up through temporal spikes. Most SDKs send the collected device characteristics to a server for further processing, except for OpenIDFA, DFID and DFIDSwift, which are non-commercial products. Additional passive fingerprinting may be performed on the server side. The SDKs that do not include server communication generate a hash on the device and return it. Nevertheless, we argue that fingerprinting is generally only useful when the fingerprint leaves the device. Therefore, it can be assumed that in these cases the caller of the fingerprinting framework handles the network communication. It is obvious from the following table that fingerprinting SDKs share some
collected properties, while other properties are exclusively queried by some SDKs. Very commonly used properties are: device model, identifier for vendor (similar to advertisement ID), device name, storage space properties, battery level and different locale identifiers. Other properties like device fonts, commonly used in web based fingerprinters, is rather seldom used. We suppose, due to the low entropy of this value on iOS devices. In conclusion, one can say that fingerprinters usually use multiple properties and don’t rely on a unique identifier provided through the advertisement ID in iOS.

Used device properties by different fingerprinting SDKs

Fingerprinting Access Pattern

We were able to observe access to common iOS APIs gathered in the previous step. Frida hooks were written to log access to respective APIs in a dynamic app analysis on a jailbroken iPhone X (iOS 14.4.2). In the next step, we analysed several top apps from the app store to see if fingerprinting can be observed based on API access pattern during execution.

Non-fingerprinting App

Firstly, let’s have a look at an example of an app without fingerprinting in the following figure. One can see that different properties were used during the app execution, some less, some more frequently. The accesses to the observed properties came from different caller modules (packages or libraries) from inside the app. Also, the properties were accessed throughout the whole runtime. Access to properties such as timezone and locale are typically required to properly display and run the app and totally legitimate.

Fingerprinting App

Now, let’s look at an app which we judge as fingerprinting in the following figure. One can see that from second 15 to 17, many properties are accessed in a very short timespan. Furthermore, the accesses come from the same caller module called ForterSDK, which is a known fingerprinting SDK. We observed such behaviour for all fingerprinting SDKs: Many properties are collected by the same caller module in a short time frame.

Fingerprinting Detection

As a proof of concept, we developed a fingerprinting detector to detect fingerprinting on the traces of a dynamic app analysis. The analyser is implemented as a sliding window of a certain width. The window of four seconds width slides over the event timeline and counts the number of accesses to known fingerprinting APIs per caller module. Access numbers above a certain threshold are then justified as fingerprinting. In a first test, we were able to correctly detect fingerprinting in 85% of the cases just by analysing access pattern. As further refinements, machine learning could improve accuracy as well as the inclusion of known fingerprinting SDK properties through a static analysis. Further insights on our used detection mechanism can be read in our extensive paper at ACM, published at the EICC conference 2023.

Conclusion

Fingerprinting as of today is used in many apps. Smartphone users are mostly unaware of the existence and the privacy issues related with such. This research lays the fundamentals to identify device fingerprinting in iOS apps. Future work will be to come up with remediation ideas to balance the privacy interests of smartphone users and fingerprinters.

Acknowledgements

This research work was supported by the National Research Center for Applied Cybersecurity ATHENE. ATHENE is funded jointly by the German Federal Ministry of Education and Research and the Hessian Ministry of Higher Education, Research and the Arts.

Note: Fingerprinting detection is currently work in progress and not (yet) part of the Appicaptor service.