There is no doubt we truly live in an “App Economy.” From personal to professional, we direct and live our lives through our smart phones. But while we enjoy the latest games, stream the latest content or catch up on our friend's activities, few think about the “App Dichotomy”– The fact that we are at least as much the consumed, as we are the consumer. This is the first in a pair of blogs that break down and analyze the access we grant to our personal information, behaviours and tendencies when we download an App, and the security and privacy risks that result.
First, we will examine the privacy/security profiles of the most popular iOS apps in the Apple App Store. Apple of course presents an image of a walled and pristine garden where users are safe unless you “bite the apple” and jailbreak your device, exposing it to the evils of unapproved apps. Apple also holds an advantage over Google/Android in that it offers more granular allow/deny control over specific permissions, while still allowing a user to download and use an app. However, it’s well understood that many users do not scrutinize the permissions requested regardless of choices. And for those who do, even with a cursory review, do they understand what they grant when they click “allow”?
Zscaler to date, has analyzed the top 550 most popular iOS apps, via static analysis techniques, specifically tracking permissions for access to functionality such as: the address book, telephony information (carrier, country code, SIM card info., etc.), user geo-location, calendar, email and unique identifiers. One difference in the approach that we’ve taken, in contrast to previously published statistics that we’ve seen, is that we looked for the express use of various functions to determine that an app actually required specific levels of access. We often see stats based on only the inclusion of a framework within an app. While including the framework provides the app with the ability to access specific functionality, it is common for developers to be aggressive with the frameworks that they include but never actually leverage the functionality.There are many interesting findings in the data, but two findings that we found especially concerning were:
- 38% of applications still have access to the now infamous UDID identifier, that was the center of the AntiSec leak in 2012, and since which time, Apple has banned access. Access to UDIDs is a concern because developers could track user behaviour across multiple apps to track unique user. Developers and ad networks may also map UDIDs to user's sensitive information like mobile numbers,name passwords, locations and other information.
- In excess of 60% of Game and Entertainment apps request permission to telephony functions (service provider information and current call information) and geo-location.This is of course more of a privacy concern, than security, but troubling nonetheless. This concerns are important as previously some issues came to light regarding spying on leaky apps.
One last item before we dive deep into the analysis that we feel is compelling to point out, is that – somewhat ironically – we had to jailbreak the devices. This was necessary in order to access the applications in their running state, and then identify various functions called by the apps to understand the access permissions that they require. This increases the value and validity of these stats, and in some cases calls into question the accuracy of some of the iOS stats that we've previously seen. Most are based on simply seeing a framework being imported (potential use) vs what we did which was look for the use of individual functions (actual use).
So, on to the analysis. We have compiled stats for:
- Address book functionality - Provides a programing interface to the Address book in order to allow an application to access the Addressbook database
- Telephony data information - Provides details on usage of the core telephony framework’s methods, which include access to the cellular service provider information like the cellular service carrier and current call information
- Location tracking - Allows apps to determine user’s current location or heading
- Email Functionality - Usage of the MFMailComposeViewController class’s methods, which provide a standard interface to manage the editing and sending of email messages. With this access, an app would not be able to send mails independently, without user involvement. The app would also not be able to read a user's email.
- Calendar data - Allows applications to read/write from/to Calendars, Events and Reminders.
- UUID - Apps can access UUIDs (Universally Unique Identifiers), also known as GUIDs (Globally Unique Identifiers) or IIDs (Interface Identifiers), which are 128-bit values designed to be unique per device.
The following overall results were derived from static app analysis:
Below we see the percentage of applications which are trying to use social media and ad networks.
47% of applications are found to be linked to social networks. We have observed Facebook, Twitter and Instagram as most common social networks used by apps.
75% of applications are found to be linked to advertisingnetworks. This is not a surprising finding given that all of the apps analyzed were free apps and most have a monetization strategy driven by advertising.
UDID vs. UUID:
Apple is pushing developers to stop using the unique identifier (UDID) embedded in iPhones and iPads and started rejecting apps that gather UDIDs after May 2013. App developers were warned not to use the “uniqIdentifier”, although it seems that some developers have neglected these warnings. Developers rely on the UDID value to track user activity for targeted advertising and troubleshooting. Since Apple is prohibiting the option to use the unique identifiers, companies are looking for new ways to keep tabs on users while avoiding personal privacy concerns. As an alternative to UDIDs, Apple has instead introduced the UUID (Universally Unique Identifier) created by CFUUIDCreate method, which we will explain below. Since these changes were implemented, developers are now trying to track the user in the following ways:
- The UDID is tied to the device hardware and no longer permitted by Apple. Apple started rejecting apps which requested the UDID string, although a few legacy apps still exist which use this method.
- The UUID, Apple’s preferred approach is a unique value per app and device. This limits privacy concerns as the user cannot be tracked across apps on a given device. One additional limitation of the UUID is that it is created when the app is first installed and, if the user re-installs the app, a new UUID will be created. In order to get around this limitation, developers are storing the UUID in the user’s keychain to make it persistent across app installs.
- A final option involves querying the MAC address of device. Apple is also now prohibiting the use of MAC addresses tracking. Apple will now reject apps where developers query the MAC address. Additionally, starting with iOS 7, Apple now always returns a fixed value when querying the MAC address to specifically prevent the MAC as base for unique identifier.
Here are some UDID vs. UUID statistics we derived from our scanned applications.
We have found 38% of legacy applications are still using the UDID “uniqIdentifier” string which is no longer permitted by Apple. Apple is pushing very hard to ensure that only UUID values are now used in place of UDID and MAC addresses.In support of that, we can see that 92% of apps are now using UUID values to track users.
Statistics breakdown by App Categories
The following details the results of five permission categories from the iTunes store for the top 25+ applications in their respective categories.
Category: Games
In the Games category, we have found that 28% of apps are accessing Address book functionality, 68% of apps are using telephony information, 76% of apps are trying to use the user’s location, 64% apps are using the Email framework and 60% of apps are asking for calendar access. Also, 84% of games are leveraging UUID’s for tracking user activity for targeted advertising.
Category: Entertainment
In the Entertainment category, we have observed 20% of apps trying to access address book functionality, 75% of apps are asking for telephony data, 86% of apps are using location APIs to track a user’s location, 88% of apps are using the Email framework and 70% of apps are using calendar data. Additionally, 97% of apps are using UUID’s for tracking.
Category: Social Networking
In the Social Networking category, 92% of apps use address book functionality, 72% of apps are asking for telephony information, 96% of apps are using location APIs and the Email framework, while 54% of apps are accessing calendar functionality and 96% of apps track via UUIDs.
Category: Lifestyle
In the Lifestyle category, 59% of apps were found to be accessing the address book, 81% of apps are using telephony data, 85% of apps are using the location and Email framework, 51% apps are accessing calendar functionality and all apps scanned were found to be accessing UUIDs.
Category: Travel
In the Travel category, we observed 54% of apps with access to the address book, 58% of apps have telephony data access, 92% of apps have access to location information, 77% of apps are using email and 61% of apps are using the calendar framework. Additionally, 92% of apps are leveraging UUIDs.
Conclusion:
With 97% apps using at least one of the functionalities being tracked (address book, telephony, location, email calendar or UUID), as stated, we are being consumed as much, if not more, than we consume. In and of itself, this is not a danger. However as threats – and even business practices – evolve, the risk profile of access changes with it. In the case of our findings, while Apple has stated otherwise, it is clear that some developers significantly overreach in permissions requested. And while some “risks” still live inside gates – for example access to Social Media still requires express user permission for an app to post, etc., -- as also stated earlier, many users are click happy and indiscriminate with that permission. I’ll leave you with a specific access and risk analysis for one app, Draw Something Free.
Recommendations:
To avoid security and privacy problems, more knowledge about mobile app risk is necessary. As organizations are moving forward with BYOD, infrastructure knowledge of app behaviors helps to avoid security and corporate privacy risks – from location tracking of executives to leaking corporate data.
Users and IT always must remain vigilant and aware regarding installed app behaviors. Consider the necessity of any functionality requested by an app before you allow it. For example, why does any game app need to access your address book? Should an app for kids really be asking for geolocation? Awareness among users about how much access is granted to particular apps is the only way to build the stronger defense against future mobile threats.
Example:
Methods identified in the decompiled source code for respective areas of functionality:
- Address book access:
- ABAddressBookCreate
- ABAddressBookGetAuthorizationStatus
- ABAddressBookRequestAccessWithCompletion
- ABAddressBookSave
- ABAddressBookAddRecord
- ABAddressBookRemoveRecord
- ABRecordGetRecordID
- ABRecordGetRecordType
- ABRecordSetValue
- ABRecordCopyValue
- ABRecordRemoveValue
- ABRecordCopyCompositeName
- ABPersonCreate
- ABPersonGetTypeOfProperty
- ABAddressBookGetPersonWithRecordID
- ABAddressBookCopyArrayOfAllPeople
Telephony
Information:
- carrierName
- carrierName
- mobileCountryCode
- mobileNetworkCode
Location Access:
- locationManager:didUpdateLocations:
- locationManager:didUpdateLocations:
- locationManager:didFailWithError:
- locationManager:didFinishDeferredUpdatesWithError:
- locationManager:didUpdateToLocation:fromLocation:
- locationManagerDidPauseLocationUpdates:
- locationManagerDidResumeLocationUpdates:
- locationManager:didUpdateHeading:
- locationManagerShouldDisplayHeadingCalibration:
- locationManager:didEnterRegion:
- locationManager:didExitRegion:
- locationManager:monitoringDidFailForRegion:withError:
- locationManager:didStartMonitoringForRegion:
- locationManager:didChangeAuthorizationStatus:
- initWithLatitude
- horizontalAccuracy
- verticalAccuracy
Email access:
- SetSubject
- setToRecipients
- setCcRecipients
- setBccRecipients
Calender access:
- defaultCalendarForNewEvents
- removeEvent
- saveEvent
Unique Identifier
(UUID) access:
- uniqueIdentifier
- CFUUIDCreateString
- CFUUIDCreate
Ad network related
URLs found in source code:
- http://www.flurry.com/resources/privacy/reengagement.html
- http://www.googleanalytics.com/__utm.gif
- utmwv=4.4mi&utmn=%d&utmt=event&utme=5
- http://www.google.com/OAuthCallback
- http://www.googleadservices.com/pagead/aclk
- https://data.flurry.com/aas.do
- https://et.w.inmobi.com/user/e.asm
Social Network
related URLs found in the source code:
- http://twitter.com/WeDrawSomething
- http://www.facebook.com/playdrawsomething
- https://api.twitter.com
- https://api.twitter.com/1/statuses/update.json
- https://api.twitter.com/oauth/access_token
- https://api.twitter.com/oauth/authorize
- https://api.twitter.com/oauth/request_token
References:
https://developer.apple.com/library/ios/navigation/
https://developer.apple.com/news/?id=3212013a
http://techcrunch.com/2013/06/14/ios-7-eliminates-mac-address-as-tracking-option-signaling-final-push-towards-apples-own-ad-identifier-technology/
Posts
