Enterprise Mobile Threat Update Q3-2016 - Bitpipedocs.media.bitpipe.com/io_13x/io_133272/item...any...

Enterprise MobileThreat Updatewww.appthority.com FOLLOW US AT: Blog: www.appthority.com/enterprise-mobile-threats Twitter: @Appthority © 2016 Appthority, Inc.

Q3-2016

https://www.appthority.com/

https://www.appthority.com/enterprise-mobile-threats/

Enterprise Mobile Threat Update | Q3-2016 | © 2016 Appthority, Inc. www.appthority.com 2

Table of Contents

3 Introduction

4 Section 1 – Recent Android VulnerabilitiesMalware Still Surfacing in App StoresMobile Malware that Roots Devices is on the RiseOverlay Malware - An Emerging TrendEnterprise Security Implications

8 Section 2 – Security vs. SpeedAre Faster Apple App Review Times Making Apps Less Safe?

11 Section 3 – Can Android's New Permission Model Make Apps Safer?



Executive Summary

IntroductionThe mobile threat landscape continued to evolve in the second quarter of 2016. The Appthority Enterprise Mobile Threat Team saw a growing concern among enterprises around new breeds of mobile threats and a desire to understand how changes in app store policies may be affecting the security of applications in enterprise environments.

Accordingly, in this quarter’s update, we review two major vulnerability types surfacing in Android apps: autorooting and overlay malware. We also present some analysis on whether Apple’s faster app review times coincided with the spate of vulnerabilities that plagued the Apple App Store starting last summer. Finally, we assess the new Android permissions model to see if apps are getting safer with its more granular runtime permissions.



Section 1 Recent Android Vulnerabilities

Malware Still Surfacing in App Stores Despite app vetting processes that include basic security checks, both Apple and Google have been challenged by app developers circumventing security protocols to introduce malware via apps that are vetted for and available in the Apple App Store and the Google Play Store.

In our Q2 2016 Mobile Threat Report, we discussed the unsettling and repeated instances of malware found in the Apple App Store. Here, we present an overview of some of the major malware examples that have recently surfaced in the Google Play Store, namely Godless, LevelDropper, and Overlay.

Mobile Malware that Roots Devices is on the RiseGodless was discovered by Trend Micro researchers on June 21, 2016. In a blog post1, researcher Veo Zhang says, “We came across a family of mobile malware called Godless (detected as ANDROIDOS_GODLESS.HRX) that has a set of rooting exploits in its pockets…[which] can target virtually any Android device running on Android 5.1 (Lollipop) or earlier. As of this writing, almost 90% of Android devices run on affected versions. Based on the data gathered from our Trend Micro Mobile App Reputation Service, malicious apps related to this threat can be found in prominent app stores, including Google Play, and has affected over 850,000 devices worldwide."

46.19%

10.27%

9.47%

6.31%

5.01%

2.12%

1.87%

1.85%

1.51%

0.90%

14.50%

India

Indonesia

Thailand

Philippines

Malaysia

Vietnam

Japan

Russia

United States

Iran

Others

June 2016 - A Bad Month for Malware Global Distribution of Infected Apps


http://blog.trendmicro.com/trendlabs-security-intelligence/godless-mobile-malware-uses-multiple-exploits-root-devices/


Godless operates in a similar way to exploit kits, using an open source rooting framework to identify and exploit vulnerabilities that root the device. The malware infects apps including WiFi, flashlights, and popular games. After an infected app is installed, the malware waits for the device screen to turn off and then begins to root the device. Once rooted, the malware can download and silently install other apps on the device, deliver unwanted ads, and install backdoors to spy on users. The researchers also found a large number of benign apps in the Google Play Store and elsewhere with corresponding malicious versions that share the same developer certificates. "Thus, there is a potential risk that users with nonmalicious apps will be upgraded to the malicious versions without them knowing about the apps’ new malicious behavior,” says Zhang.

Earlier versions of the Godless malware implemented a standalone Google Play client to download and install apps. New versions bypass security checks by Google Play and other app stores by downloading the rooting exploit and payload from a remote command and control server located at hxxp://market[.]moboplay[.]com/softs[.]ashx, after the app has been installed.

LevelDropper, an app with “autorooting”malware was discovered on Google Play by Lookout a week later on June 27, 2016. (The app is a utility app that features a digital version of a handyman’s level, hence the LevelDropper name.) Like the Godless malware, LevelDropper roots Android devices and enables remote installation of applications without the


user’s knowledge or approval. After just 30 minutes, 14 applications had been downloaded without any user interaction, according to researchers. Also like Godless, researchers suspect that the motives are at least partially to increase ad revenue and perceived app popularity.

Additionally, the creators were careful to disguise the rooting actions to prevent them from being detected by Google's Bouncer, a security system used to scan apps before allowing them on the Play Store. The app doesn't show typical signs in the system directory that it has rooted the device (like a superuser binary). Instead, it stealthily leverages rooting exploits already availablein the wild. The app has since been removed from Google Play.

Overlay Malware – An Emerging TrendA day later, on June 28, 2016, FireEye blogged2 about its discovery of overlay malware that was used to steal credentials for mobile banking and messaging apps. Overlay malware is a type of mobile malware that is designed to mimic the look and feel of a target app.

FireEye has identified five known SMS Phishing – or Smishing – campaigns targeting users originally in Russia and now also in Denmark, Italy, Germany, Austria, and the U.K. The campaigns send SMS messages with a notification of a failed shipment and a shortened URL that tricks the victim into clicking and installing the malware.


https://www.fireeye.com/blog/threat-research/2016/06/latest-android-overlay-malware-spreading-in-europe.html?mkt_tok=eyJpIjoiWlRCaVl6UXlabVk0T1dKaiIsInQiOiJTemFKVkYreWZxMVQydXlqXC9vSWpDcHExSzFvRkhXZlwvcmJVOEdqQTRDa3N0aFF3eWVMTWhNOFJzWmh2ZWlJYUs5Wm


According to the researchers, “After landing on the user’s device, the malware launches a process to monitor which app is running in the foreground on the compromised device. When the user launches a benign app into the foreground that the malware is programmed to target (such as a banking app), the malware overlays a phishing view on top of the benign app. The unwary user, assuming that they are using the benign app, will enter the required account credentials, which are then sent to remote C2 servers controlled by threat actors.”

The overlay technique is becoming increasingly popular among attackers because it is effective. It is difficult for users to distinguish the overlay screen from the real app which allows the bad actors to harvest a large number of credentials quickly. Duped users clicked over 160,000 times on the 28 shortened URLs FireEye monitored.

Bad for Employee ProductivityThe promise of increased productivity via mobility is undermined by rooting malware. User productivity is lowered on devices that are using resources to install apps and display ads. Additionally, efforts to uninstall the apps only to have them reappear is a frustrating distraction that needlessly takes attention away from more productive activities.

Bad for Data Security Personal data is very clearly at risk in the banking credentials attacks that overlay software is pursuing now. However, attackers have shown a penchant for constantly adapting their ruses. While phishing for consumer account info now, this approach can be used for any type of credential phishing including accessing corporate apps, data and servers. Similarly, rooted devices that install apps on employee devices can also phish credentials and access corporate environments. Because of this, multifactor authentication is becoming increasingly important.


Enterprise Security Implications Rooted devices can shift control from the user or the enterprise to the hacker. This negatively affects enterprises in multiple ways.

Map of Europe with Infected Countries




1. Implement a mobile protection solution that detects malicious

behavior in apps already in your environment, eliminates

suspicious apps and brings infected and rooted or jailbroken

devices into compliance.

2. Ensure employees have a security app installed to ensure they

are aware of malicious and suspicious apps and proactively

alerted not to install them.

3. Educate employees about the dangers of installing apps

outside of official app stores. Although security is not perfect,

it is far safer to obtain apps through the official stores than via

third party stores.

4. Encourage employees to upgrade to the latest OS possible for

their devices. Each OS update contains significant security

improvements which protect against known malware and

other vulnerabilities.

What to Do NowBad for Enterprises Relying Solely on App Store VettingAs our researchers have continually noted, relying solely on the Apple App Store or the Google Play Store to vet apps is not sufficient to ensure enterprise protection from mobile threats. While we recommend these official stores as a source for public apps, they are not foolproof, nor are they sufficient for enterprise-level security.

The current app store review processes do not analyze apps with an enterprise use case in mind. Thus, they routinely allow apps with security vulnerabilities -- such as transmitting credentials in clear text or sharing data with unauthorized cloud storage providers and other third parties -- into their app stores.

For these reasons, enterprises still need to comprehensively monitor and prevent threats using solutions that detect not only known malware, but also precursors that indicate malicious potential behavior.



Over the last year, app developers have been excited to see a dramatic shortening of the Apple app review process. Traditionally, developers had to wait several days, sometimes even weeks, before their apps were reviewed and approved to become available for download on iTunes. However, over the last year, the average review period has shrunk to about 1/4 of what the review times were previously, with mean app review time decreasing from 9 days to 23. Apple, which makes over $6 billion per quarter (12% of revenue) from its “Services” division, which includes sales from the app store, has promised to shrink review times even further.

While this is great news for iOS app developers, Appthority's Enterprise Mobile Threat Team (EMTT) wanted to investigate whether the dramatic cut in app review time had any implications on the security quality of apps being approved for distribution. Traditionally, the strict Apple app review process did a great job of preventing malware and other potentially harmful apps from entering the store. However, in the past year, a series of malware infected apps and risky vulnerabilities appeared in the Apple App Store, as noted in our Q2 2016 Mobile Threat Report4. In this section, we explore a potential correlation between faster app reviews and five prominent iOS vulnerability and malware occurrences.

Although Apple does not publish official app review stats, the site Appreviewtimes.com publishes average review time data for iOS that is submitted by developers. In Figure 2-1, we can see the dramatic reduction in review times from July 2015 to June 2016. Other than a large jump in review times in early 2016, the overall trend is downward on an aggressive slope.

Section 2 Are Faster Apple App Review Times Making Apps Less Secure?

Figure 2-1. Average App Review Times (http://appreviewtimes.com/ios/annual-trend-graph)

Jul2015

4 datys

8 days

16 days

12 days

Aug2015

Sep2015

Oct2015

Nov2015

Dec2015

Jan2016

Feb2016

Mar2016

Apr2016

May2016

Jun2016

iOS App Store - Average App Review Times


http://www.bloomberg.com/news/articles/2016-05-12/apple-shortens-app-review-times-in-push-to-boost-service-sales

https://www.appthority.com/enterprise-mobile-threats/2016/05/04/appthority-q2-mobile-threat-report-explores-ios-breaches-and-android-for-work/

http://appreviewtimes.com/ios/annual-trend-graph


As discussed in the Q2 2016 MTR5, there were 5 major iOS malware outbreaks in the official Apple app store from the end of 2015 through early 2016. This marked a dramatic shift from previous years in which the App Store had seemingly been impervious to malware. Naturally, we were curious to see how the timing of these malware outbreaks aligned with

the shortening of the app review process. Figure 2-2 below overlays the discovery of the malware families with the previously discussed average app review times.

XcodeGhost, the first and most public of the iOS malware outbreaks in the app store, was discovered after the review time reduction first started. After that, app review times increased from around five to seven days for about two weeks before the discovery of the YouMiSDK and MobiSage vulnerabilities.

After three public blemishes to Apple’s previously pristine app store reputation, dropped back to pre-XcodeGhost levels before spiking at the beginning of January. This was followed by a huge drop in the review times from approximately two weeks to just under five days. App review times were declining to under four days when JSPatch was discovered and bounced back up over four days when AceDeceiver hit the App Store.

App review times have since decreased, bottoming out at just under two days in late May and stabilizing around two days in June. Next, we explore these vulnerabilities in a bit more detail.


XcodeGhost

YouMi SDK

MobiSage

JSPatch

AceDeceiver

Jul2015

4 days

8 days

16 days

12 days

Aug2015

Sep2015

Oct2015

Nov2015

Dec2015

Jan2016

Feb2016

Mar2016

Apr2016

May2016

Jun2016

Figure 2-2. Average App Review Times (http://appreviewtimes.com/ios/annual-trend-graph)

iOS App Store - Average App Review Times & Malware Outbreaks


https://www.appthority.com/learn/#Content-MobileThreatReports

http://appreviewtimes.com/ios/annual-trend-graph


Faster app review times have not increased the security of apps.

What we can see are two things:1. App review times have been decreasing and it is a stated goal of

Apple to speed reviews as much as possible. Apple has stated that it is investing in faster app review times which will drive service revenues from apps as growth in device sales levels off.

2. Faster app review times have not increased the security of appsfound in the official stores. And, vetted more quickly or slowly,apps with malware and serious security vulnerabilities continue tosurface in the Apple App store (we see the same in the GooglePlay Store).

It is important to keep in mind, that Apple vets apps for consumer, not specifically for enterprise use. From a security standpoint, the current vetting process may be sufficient for consumers but does not meeting the strict security standards of government and commercial enterprises for whom data loss, privacy invasion and other serious risks accrue when relying solely on app stores to vet apps that enter their mobile environment. The “defense in depth” strategy - including a comprehensive mobile security solution - adopted by leading enterprises is strongly recommended to ensure that sensitive data and employee privacy are in compliance with enterprise policy.

Overall, there is not a direct correlation between the timing of infected apps from these outbreaks on the Apple App Store and the the shortening of the app review process. Each of the infections entered the app store over periods stretching several months, not just when review times had decreased. We don’t have visibility into which of many factors such as app submission and update dates or app review processes and checklists may have changed during this time.


VULNERABILITY DATES IN APP STORE# OF APPS INFECTED

CORRELATION TO APP REVIEW TIMES

XcodeGhost Apr 2015 - Nov 2015 478 Infections grew as app review times decreased

YouMi SDK Feb 2014 - Nov 2015 551

Infections peaked prior to the date ranges of the app review timeline, and remained undetected while review times shrank

MobiSage Mar 2015 - Nov 2015 134

Infections peaked prior to the date ranges of the app review timeline, and remained undetected while review times shrank

JSPatch Jun 2015 - Jan 2016 962The infections grew as the average app review time de-creased in the same period

AceDeceiver Jul 2015 - Sep 2015 6This time period had a dramatic drop in app review time

Table 2-1



In late 2015, Google introduced the Android Marshmallow OS update, which among other features, included a more granular permission model than previous OS versions. In the past, users had to grant apps permissions in an “all or nothing” model at the moment of installation. In other words a user had to agree to allow all of the requested permissions or choose not to install the app. With Marshmallow, a subset of permissions which Google has labeled “Dangerous Permissions”, require a user to opt-in when the app behavior is first encountered when the app runs and needs the permission. This runtime permission model is very similar to the iOS permission model.

The Marshmallow permissions model has been out in the wild for just over six months now, giving the Appthority Enterprise Mobile Threat Team an opportunity to explore whether it has had an impact on risky app behaviors. Specifically, the team wanted to see whether Android app permissions have changed now that apps must explicitly request certain permissions when they are needed at runtime, rather than at install.

The team searched the Appthority database of over four million mobile apps installed on enterprise managed devices and identified 6,699 popular Android apps that had both a Marshmallow release and a Lollipop (previous OS) release. We ran these apps through the Appthority dynamic analysis engines to expose which app permissions were requested on apps using API level 23 (the Marshmallow release) and also API level 22 (the last Lollipop release). Table 3-1 shows the change from the pre- to post-Marshmallow OS versions for each “dangerous permission”.

Section 3 Can Android’s New Permission Model Make Apps Safer?

“Dangerous permissions cover areas where the app wants data or resources that involve the user's private information, or could potentially affect the user's stored data or the operation of other apps. For example, the ability to read the user's contacts is a dangerous permission. If an app declares that it needs a dangerous permission, the user has to explicitly grant the permission to the app." Source6

A list of the 24 Dangerous Permissions and their descriptions can be found in Appendix 1.

Google defines Dangerous Permissions as:


https://developer.android.com/reference/android/Manifest.permission.html



Dangerous Permission

# Apps Where This Permission

Changed

% of Apps Where Permission

Changed

% Apps Adding This Permission

% of Apps Removing This

Permission

get_accounts 1082 38.1% 6.0% 32.1%

read_external_storage 1022 35.9% 18.0% 17.9%

read_phone_state 769 27.0% 6.4% 20.6%

access_coarse_location 548 19.3% 6.4% 12.9%

write_external_storage 515 18.1% 6.6% 11.5%

access_fine_location 261 9.2% 5.2% 3.9%

camera 243 8.5% 4.7% 3.8%

record_audio 133 4.7% 2.0% 2.7%

read_contacts 100 3.5% 1.6% 1.9%

call_phone 94 3.3% 1.1% 2.2%

receive_sms 58 2.0% 1.1% 0.9%

send_sms 57 2.0% 0.9% 1.1%

write_contacts 40 1.4% 1.0% 0.4%

write_calendar 40 1.4% 0.9% 0.5%

read_sms 38 1.3% 0.7% 0.7%

read_calendar 32 1.1% 0.7% 0.4%

read_call_log 17 0.6% 0.2% 0.4%

process_outgoing_calls 12 0.4% 0.2% 0.2%

write_call_log 6 0.2% 0.1% 0.1%

receive_mms 6 0.2% 0.1% 0.1%

receive_wap_push 3 0.1% 0.1% 0.0%

body_sensors 2 0.1% 0.1% 0.0%

use_sip 1 0.04% 0.0% 0.04%

add_voicemail 0 0.0% 0.0% 0.0%

Table 3-1Our first question was whether developers would increase or reduce the number of “dangerous permissions” they requested under the new permissions model. In all, 42.4% (2,843) of the apps changed the number of “dangerous permissions” they requested after the Marshmallow update. Of those, 54.7% (1,555) of the apps deleted “dangerous permissions” with the update, while a surprising 31.1% (884) actually added “dangerous permissions” with the Marshmallow update. Additionally, 14.2% (404) of the apps both added and removed at least one “dangerous permission”.

The next question was which “dangerous permissions” were changed most often? To answer this question, we compared the number of times each “dangerous permission” was requested by an app’s Lollipop and Marshmallow version.

The dangerous permission that changed the most with the Marshmallow OS was “Get_Accounts”. Of apps that changed behaviors, 38.1% (1,082) changed this behavior with 32.1% of the apps removing the “dangerous permission” and 6.0% adding it.




Developers use the “Get_Accounts” permission to authenticate users via an email account. Prior to Marshmallow, the permission asked users for access at install and using the title “Identity” (See Figure 3-1). With Marshmallow, this permission is not always needed. As Google’s developer note7 says, “Beginning with Android 6.0 (API level 23), if an app shares the signature of the authenticator that manages an account, it does not need"GET_ACCOUNTS" permission to read information about that account.” This may be one reason that this permission was removed after Marshmallow. Another reason may be that Google has placed this permission in the category of “Contacts” so that, instead of the more appropriate “Identity” category, when requested, the permission uses the term “Contacts” and seems to be asking the user to grant access to the user’s contacts (See Figure 4-1). Developers have been filling message boards in frustration with this since it is misleading and technically not what the permission is requesting.

The high percentage of apps removing the “Get_Accounts” permission, thus, may ultimately be a security win in that apps that don’t need the permission are no longer asking for it. The security gain, however, is somewhat tempered by the confusion for users in what permission and related account or data access they are ultimately choosing to allow or not allow.

Figure 3-1 - API22 (Lollipop) Figure 4-1 - API23 (Marshmallow)


https://developer.android.com/reference/android/Manifest.permission.html#GET_ACCOUNTS

https://developer.android.com/reference/android/Manifest.permission.html#GET_ACCOUNTS


“Dangerous permission” “Read_External_Storage”, which allows apps to read data recorded in the device’s removable storage, was changed in 35.9% (1,022) of the apps where permissions were changed. This permission was added most often by developers with 18.0% of apps adding it. However, 17.9% of developers also removed this permission. It is not clear why such a large number of apps added and removed this permission, but the net effect of adds and deletes represents a very slight increased risk of malicious apps accessing potentially sensitive information stored in the external storage by other apps.

Another “dangerous permission” related to storage, “Write_External_Storage” also saw a significant shift. In this case, the permission was changed in 18.1% (515) of apps, but with more apps (11.5%) removing the permission and only 6.6% of apps adding the permission. “Write_External_Storage” grants an app the permission to not only write to, but also implicitly read external storage.

The “Read_Phone_State” permission also saw a large drop in “dangerous permission” requests. This permission allows a developer to access phone state information, including the phone number of the device, current

cellular network information, the status of any ongoing calls, and a list of any Phone Accounts (methods for making or receiving calls) registered on the device. In all, 27.1% (769) apps changed this permission with 20.7% of the apps removing it and 6.4% adding it. Again, developers removed more than added this “dangerous permission” with their Marshmallow app releases. Since this means less app access to user phone numbers and ongoing call information, this can be seen as enhancing user privacy.

“Access_Coarse_Location”, which grants the app access to a user's approximate location, was the last permission with significant changes between Lollipop and Marshmallow. 19.3% (548) of apps with permission changes changed this permission. 12.9% removed the permission and 6.4% of apps added it. However, “Access_Fine_Location”, which grants an app the ability to see a user’s exact (GPS) location, changed in 9.2% (261) of apps that changed “dangerous permissions” with 3.9% of apps removing it while a higher 5.2% of apps added it. Exact GPS location is considered Personally Identifiable Information (PII) in many countries, since it can point third parties to exactly where a user lives, works, eats, and more. So, while location data permission requests went down overall, an increase in the fine location permission requests is not a positive for user privacy and security.




Another improvement would be increasing the granularity of permissions to narrow the sensitive data being accessed by each permission. For example, two apps may ask for the same permission, “Read_Contacts”, but while one may only read the contact data, the other may read the data and export it, sharing it with a third party. Both use the same permission but one use is much riskier than the other. And, code level vulnerabilities, such as whether the contact data is shared in clear text or encrypted, is not even included as a permission, making this risk invisible to the user.

For these reasons, although the Marshmallow runtime permission model is an improvement over the previous model, in our view, enterprises cannot solely rely on Android or Apple permission models to protect users and their data.

To understand and protect against mobile app risks, enterprises and their employees need to know not only what dangerous permissions an app may request, but also what other hidden risky behaviors lie within the app that will never ask for a permission. To properly secure the enterprise, we recommend implementing a complete mobile threat protection solution with extensive and automated app analysis that supports your unique corporate risk policies.


In our ongoing analysis of apps in enterprise environments, we often see apps that request more information than is needed for the app’s functionality or operation. A flashlight app, for example, may be requesting the user’s location even though this information is not needed for the app to function. This type of user data, previously collected more easily as part of a long permission list when installing the app, would later be sold to third party data brokers and ad networks, helping an otherwise free app to monetize private user data.

The updated Android permission model, however, is bringing some transparency to user permissions by presenting them in context at runtime rather than encouraging a ‘blind approval’ prior to installation. And developers of apps in our sample have reduced the number of “dangerous permissions” being requested post Marshmallow. Nearly half of the 24 “dangerous permissions” saw a net reduction with the new permission model. This is progress for user privacy and data security.

Despite this progress, however, there is more that can be done to help users protect their privacy and their data. One improvement would be requiring developers to follow the best practice of always stating why a certain permission is being requested and explaining how the app would make use of the information. This would further increase transparency and help users make a more educated decision about whether it is appropriate to grant a permission or not.



APPENDIX 1

Android "Dangerous Permissions" July 1 - September 30, 2016

ACCESS_COARSE_LOCATION Allows an app to access approximate location.

ACCESS_FINE_LOCATION Allows an app to access precise location.

ADD_VOICEMAIL Allows an application to add voicemails into the system.

BODY_SENSORS Allows an application to access data from sensors that the user uses to measure what is happening inside his/her body, such as heart rate.

CALL_PHONE Allows an application to initiate a phone call without going through the Dialer user interface for the user to confirm the call.

CAMERARequired to be able to access the camera device. This will automatically enforce the } manifest element for all camera features. If you do not require all camera features or can properly operate if a camera is not available, then you must modify your manifest as appropriate in order to install on devices that don't support all camera features.

GET_ACCOUNTS Allows access to the list of accounts in the Accounts Service.

PROCESS_OUTGOING_CALLS Allows an application to see the number being dialed during an outgoing call with the option to redirect the call to a different number or abort the call altogether.

READ_CALENDAR Allows an application to read the user's calendar data.

READ_CALL_LOG Allows an application to read the user's call log.

READ_CONTACTS

READ_EXTERNAL_STORAGE

Allows an application to read the user's contacts data.

Allows an application to read from external storage. Any app that declares the WRITE_EXTERNAL_STORAGE

permission is implicitly granted this permission.

PERMISSION GROUP PERMISSIONS


https://developer.android.com/reference/android/Manifest.permission.html#WRITE_EXTERNAL_STORAGE


READ_PHONE_STATE Allows read only access to phone state, including the phone number of the device, current cellular network information, the status of any ongoing calls, and a list of any PhoneAccounts registered on the device.

Allows an application to read SMS messages.

Allows an application to monitor incoming MMS messages.

Allows an application to receive SMS messages.

Allows an application to receive WAP push messages.

Allows an application to record audio.

Allows an application to send SMS messages.

Allows an application to use SIP service.

Allows an application to write the user's calendar data.

Allows an application to write (but not read) the user's call log data.

READ_SMS

RECEIVE_MMS

RECEIVE_SMS

RECEIVE_WAP_PUSH

RECORD_AUDIO

SEND_SMS

USE_SIP

WRITE_CALENDAR

WRITE_CALL_LOG

WRITE_CONTACTS Allows an application to read the user's contacts data.

WRITE_EXTERNAL_STORAGE Allows an application to read from external storage. Any app that declares the WRITE_EXTERNAL_STORAGE permission is implicitly granted this permission.

PERMISSION GROUP PERMISSIONS

APPENDIX 1


https://developer.android.com/reference/android/Manifest.permission.html#WRITE_EXTERNAL_STORAGE


Enterprise Mobile Threat Report Q3-2016Appthority's Enterprise Mobile Threat Team (EMTT) monitors and reasearches the latest mobile risks that are direct threats to the enterprise. The purpose is to help organizations holistically assess and protect their people, data, applications, and networks from risks and exposures in the mobile threat landscape. The EMTT is composed of security industry veterans that have decades of experience in protecting mobile devices.

Appthority, the global leader in enterprise mobile threat protection, delivers proactive visibility into mobile risk with the most comprehensive mobile application analysis available. Appthority’s extensive and ongoing threat intelligence eliminates mobile risk blind spots and combines the widest array of customizable policy and remediation options to tailor threat protection to the unique needs of individual enterprises. With Appthority, security teams are informed, employees are productive and enterprise data

is kept private and secure.

Sources 1 http://blog.trendmicro.com/trendlabs-security-intelligence/godless-mobile-malware-uses-multiple-exploits-root-devices/

2 https://www.fireeye.com/blog/threat-research/2016/06/latest-android-overlay-malware-spreading-in-europe.html?mkt_tok=eyJpIjoiWlRCaVl6UXlabVk0T1dKaiIsInQiOiJTemFKVkYreWZxMV QydXlqXC9vSWpDcHExSzFvRkhXZlwvcmJVOEdqQTRDa3N0aFF3eWVMT WhNOFJzWmh2ZWlJYUs5Wm

3 http://www.bloomberg.com/news/articles/2016-05-12/apple-shortens-app-review-times-in-push-to-boost-service-sales

4 https://www.appthority.com/enterprise-mobile-threats/2016/05/04/appthority-q2-mobile-threat-report-explores-ios-breaches-and-android-for-work/

5 https://www.appthority.com/learn/#Content-MobileThreatReports

6 https://developer.android.com/reference/android/Manifest.permission.html

7 https://developer.android.com/reference/android/Manifest.permission.html#GET_ACCOUNTS



APPTHORITY, INC. www.appthority.com

FOLLOW US Blog: www.appthority.com/enterprise-mobile-threats Twitter: @appthority

CONTACT US Email: [email protected] Tel: +1 844-APP-RISK (+1 844-277-7475) +31 570 545 229

535 Mission St., 20th Floor San Francisco, CA 94105


Enterprise Mobile Threat Update Q3-2016 - Bitpipedocs.media.bitpipe.com/io_13x/io_133272/item...any...

Documents

Transcript of Enterprise Mobile Threat Update Q3-2016 - Bitpipedocs.media.bitpipe.com/io_13x/io_133272/item...any...