Posts

Posted on

Rise and Fall of Specific Unique Identifiers

Retrieving a unique identifier may allow app developers, advertisers, analytic companies and others to identify the user’s device or the user himself. Furthermore, most of these identifiers are persistent means for tracking, advertising and marketing activities on devices. Unique identifiers might however be also necessary for certain app functionality to work as expected.

Appicaptor tracks app’s access to various unique identifiers that can be categorized in three different groups:

  • The first group refers to mobile communication relevant IDs. Examples of this category are access to the phone’s IMEIs and MAC addresses, country code of the mobile network provider, as well as the phone / voice mail number, serial number of the SIM card and mobile subscriber ID (IMSI / TIMSI) of the user.
  • The second group is identification information about the hardware or operating system given by the operating system itself. When the mobile operating system is compiled different parameters for model, hardware, serial and display size are included in the operating system build. Furthermore, a build fingerprint can distinguish different operating system builds even if the operating system version is equal.
  • The third group consists of identifiers
    • like the Android Device ID, Advertisement ID,
    • properties that the user could configure like font size / type, audio volume, timezone, display orientation lock and screen brightness, Bluetooth pairings, power saving mode configuration, audio singnal output port (speaker, headphones, Bluetooth, etc.)
    • installed app list
    • hardware parameters like cpu and set of available hardware sensors (gyroscope, barometer, …)
    • other parameters like battery or device memory (RAM and data) usage.

Every month Appicaptor evaluates the IT security quality of thousands of Android and iOS apps. The following two charts depict for each month which identifier usage is rising and which is falling. The charts plot the identifier usage (total number of apps within the 2,000 most popular apps in German Google Play Store that accesses an identifier) relatively to the identifier usage in January 2020.

Rising Unique Identifiers: identifier usage within the 2,000 most popular apps in German Google Play Store relatively to the identifier usage in January 2020
Falling Unique Identifiers: identifier usage within the 2,000 most popular apps in German Google Play Store relatively to the identifier usage in January 2020

As the relative change (given in the two charts before) does not give the perspective, which identifiers are commonly utilized and to which extent, the following table provides the absolute numbers. This table shows how many apps within the 2,000 most popular apps in German Google Play Store access an identifier in the Appicaptor analysis runs of January 2020 and February 2021. Furthermore, based on every monthly analysis run between January 2020 and February 2021 we predict a trend if the identifier usage is rising or falling based on our data.

NameIdentifier Uage
(in January 2020) 		Identifier Uage
(in February 2021)		Trend
Unique Android ID1,944 1,947stable
Build model1,9471,945stable
Build
manufacturer		1,9161,941▲
Build fingerprint1,6791,873▲
Build product1,6331,760▲
Build brand1,5371,712▲
Build hardware1,1791,632▲
Build display1,4781,486stable
Country Code +
Mobile Network
Code		9221,158▲
Build serial8771,016▲
Mobile Country
Code		8621,000▲
Wifi-MAC address754717▼
IMEI/MEID689591▼
MAC address(es)547380▼
Phone number281264▼
Subscriber ID
(IMSI)		312258▼
SIM card serial243178▼
Voice mail
number		6962stable
Total number of apps that access an identifier according to Appicaptor analysis of the 2,000 most popular apps in German Google Play Store

The analysis of Appicaptor shows that the access to (generally speaking) unspecific unique identifiers (like the build related parameters) is currently rising. One might think that the access to unspecific unique identifiers (like the build brand or hardware) may be not an privacy issue since they are equal at thousands of devices/users. And that the access to a more specific unique identifier (like the SIM serial or phone number) should be more an privacy issue. However, there is more to take into consideration.

A detailed manual inspection of access patterns and looking on the landscape of the mobile value-chain shows that most of the accesses of unspecific unique identifiers are executed in 3rd party libraries, which are included in the app by the developer. Furthermore each of these unspecific information portions (if seen alone) can not be utilized to identify a specific device or person. But certain libraries access a magnitude of these unspecific unique identifiers, creating a device fingerprint from all them and transmit the data to a server backend. As an other example, an open source library of this type can be found here. It claimes to create a device identifier from all available Android platform signals, that is fully stateless and will remain the same after reinstalling or clearing application data.

The further manual inspection of other identified libraries shows as well, that libraries which probably execute device fingerprinting are utilized in many apps of different app types. A linkage between the device fingerprint and your person is possible, when you think of an app that utilizes an library that joins identifiers as device fingerprint and you give that app information about your person (name, email address, etc.). That would bring the provider of the library in the position to track your identity throughout the usage of different apps, based solely on unspecific unique identifiers.

So what can we learn from these numbers?

  • The usage of almost all specific unique identifiers are currently falling. That trend is supposed to be related to privacy preserving functions in the mobile operating systems that limit the app’s access to correct values of these identifiers. If you enable these privacy preserving functions, fake random values are provided.
  • The usage of unspecific unique identifiers is currently rising throughout all identifiers. From our perspective that rising is based on the reasoning outlined above (device fingerprinting) as well as to facilitate user identification in the presence of the current drawbacks (uncertainty if correct or fake specific unique identifiers are reported to the app by the operating system).

Therefore, in the app evaluation process one should take a look at the composition and magnitude of the list of accessed unique identifiers of an app: if many unspecified unique identifiers are accessed, this should draw one’s attention the same way as the access of an specified unique identifier should do.

Posted on

Known TwitterKit Vulnerability, still an Issue?

Nearly 18 months ago we published a vulnerability in our Appicaptor blog that the current Twitter Kit framework for iOS does not properly validate the TLS certificate. This vulnerability can be utilized for man-in-the-middle-attacks.

Twitter stated that there will be no fixed version of the vulnerable library, because it is seen as deprecated and no longer supported. Therefore, developers should have taken action and have removed the TwitterKit from their apps.

Every month Appicaptor evaluates the IT security quality of thousands of Android and iOS apps. So one might ask: Does the German Top 2000 iOS Apps still utilize the vulnerable Twitter Kit library version and is there a trend visible? The following chart depicts for each month the number of apps that are prone to the vulnerability within the 2,000 most popular apps in iOS App Store.

It is visible in the chart that the amount of apps with the vulnerable library quite constantly and slowly decreases throughout the year, reducing the risks for users. Although there is quite some fluctuation on the considered top list, a clear trend is visible, even if it took much longer than thought. But nevertheless, from our point of view, none of the most popular apps should have such a massive vulnerability. Therefore we would like to advise again that app developers should switch to alternative APIs.

Posted on

iOS: 40% Critical Log Statement Usage in Apps

Developers commonly need log statements in their apps to track down problems by printing out information about the current program state. However, this can also lead to serious information disclosure to third parties, as many developers still use the old NSLog statement in about 40% of the Top 2000 German iOS apps. Many developer sites state, that information logged with NSLog will not be persisted on the device and therefore the usage is not critical. However, that’s not correct as we will demonstrate in the following for current iOS devices.

Over the years, Apple has changed a lot under the hood of iOS. Likewise the logging mechanism has changed in multiple aspects. One major change was the introduction of unified logging with iOS 10, which provides log levels, information hiding for sensitive entries and many other configuration capabilities. However, these new feature are only usable if the new os_log macro is used.

When using NSLog, the log messages are stored with default log level persistently for a certain time, which was tested with iOS 12.4, iOS 13.3 and 13.4 on non-jailbroken devices. Depending on the usage intensity of the iOS device, the stored log messages can go back days or months.

Log entries on these iOS devices are stored system-wide in the directory /var/db/diagnostics/Persist in files of the tracev3 binary format, which can be made readable again e.g. with the OSX log tool or platform independent wth UnifiedLogReader. The stored database files are protected by iOS DataProtection class NSFileProtectionCompleteUntilFirstUserAuthentication with the device passcode until the first user’s logon and can only be read by the administrative user root.

This means, in a lost-device scenario for an iOS device without passcode, these logging outputs can be read directly via USB using the iOS sysdiagnose function. If a passcode is set, the passcode is required to read the logging outputs.

However, since users are often asked to send the sysdiagnose data to Apple or App developers (see instructions e.g: https://faq.pdfviewer.io/en/articles/1458505-ios-how-to-send-a-sysdiagnose), in this case third parties will get access to log messages of all utilized apps (within the persisted time frame).

Among many other debug information, the transmitted file sysdiagnose_[date]_iPhone_OS_[device].tar.gz contains the file system_logs.logarchive. It is compressed and needs to be converted first to make use of it. This can be done quite easy on OSX.

The file system_logs.logarchive can be viewed on OSX with the log command:

log show system_logs.logarchive --info --debug > logs.txt

To use the UnifiedLogReader instead, one first has to extract the files from the system_logs.logarchive to a folder and start the python script inside this folder like this, e.g. on Windows systems:

python [path_to]\UnifiedLogReader.py .\ .\timesync\ .\Persist [output_folder]

In the output file logs.txt, one can search for the app binary name to find the related log messages. In the following example the binary is called TestApp:

2020-03-25 15:18:19.707346+0100 0x517db  Default  0x0  737 0 TestApp: My NSLog example GPS: {"geoData": {"latitude": 49.xxx, "longitude": 8.xxx, "radius": 2.818104}, "filters": {}, "exclude": []}
2020-03-25 15:18:25.635420+0100 0x517db  Default  0x0  737 0 TestApp: My NSLog example GPS: {"geoData": {"latitude": 49.xxx, "longitude": 8.xxx, "radius": 5.515101}, "filters": {}, "exclude": []}
2020-03-25 15:18:28.657474+0100 0x517db  Default  0x0  737 0 TestApp: My NSLog example GPS: {"geoData": {"latitude": 49.xxx, "longitude": 8.xxx, "radius": 10.625031}, "filters": {}, "exclude": []}

In these log messages, we often find GPS-positions along with email addresses, generated encryption keys, full credit card information and much more entered user content. Even for apps that primarily do not store sensitive data, the log can also reveal sensitive information such as sensitive app names, their installation dates and how and what was used inside the apps.   

From a user’s perspective, it should now be clear:

  • Do not send sysdiagnose data to anyone!
  • Deny access for Apple (see https://support.apple.com/en-us/HT202100), however, this does not disable the logging nor does this disable the possibility to create sysdiagose files.
  • Use a good passcode to make it harder to access these files unauthorized. 

But the best protection is to use apps, that don’t store sensitive data to logfiles!

So, make a test for yourself and inspect your sysdiagonse file to learn more about your apps and the things they store.

Developers should take a look at iOS Unified Logging with the os_log macro. It can be used to programmatically enable a persistent storage only for cases when needed for remote debugging (if that’s necessary at all). For all other cases it can be configured to use only console output, preventing a data leakage via persitent log files.

Posted on

New Feature: Dynamic App Analysis

We have added a new app analysis method to our Appicaptor infrastructure. From now on all iOS app analysis orders within Appiaptor SmartWeb or Corporate subscriptions are also processed using dynamic analysis. Besides the already existing static code analysis, the apps are automatically invoked in an analysis environment. This way, processing and communication of user data is additionally monitored and analyzed during runtime of the app. To create reproducible results and code coverage, user interactions are simulated with a deterministic interaction model.

The results of the dynamic analysis are correlated with the static code analysis to increase the depth of the Appicaptor app rating regarding security and privacy risks.  For example user related data (address book entries, passwords, GPS positions, etc.) transmitted unprotected, transmitted to untrusted 3rd parties as well as abused by 3rd party libraries exploiting access permissions can be identified.

Posted on

Budget Option: Appicaptor Top 2000 Free (Select)

Besides the targeted and specific weekly app tests with individual security policies of our customers, Appicaptor analyses the top 2,000 iOS and Android Android apps each month. The top 2,000 app test results can be indicatory for app security quality and risk assessment in your mobile device administration. As Appicaptor utilizes a standard policy for medium security requirements for the top 2,000 apps assessment, the results could be directly applied for your app blacklisting.

The Appicaptor backend uses data sources to determine app popularity and usage. This allows Appicaptor to designate the 2,000 most relevant, free apps within the entire iOS and Android app stores. Therefore, the Appicaptor Top 2000 Free test catalog offers a broad coverage of the apps that are relevant for administration practice (all apps of the app stores with the exception of games and sticker apps).

There are two Appicaptor options that provide an app risk assessment for a budget price point:

  • Top 2000 Free evaluates the top 2,000 apps of the iOS or Android app store.
  • Top 2000 Free Select expands the tested apps by 20 self-defined, free apps from the app stores.

Both options cost less than 10 Euro per day for your entire mobile environment. You receive web statistics (including blacklist rating according to the standard Appicaptor policy) and an Excel report of the findings every month.

If you need a specific offer or advice please contact us on appicaptor@sit.fraunhofer.de