Conference PaperPDF Available

Abused Android Permissions by Advertising Networks


Abstract and Figures

Android is the leading mobile operating system for smart phone and mobile tablet platforms. Since these mobile devices contain personal and sensitive data, security is a big challenge for them. Even though various security features are supported by Android, its permission model is quite problematic from usability and privacy aspects. When users want to install an application, they must grant all requested permissions. Since manually checking dozens of permissions is cumbersome, users ignore it and accept permissions without reading them. In Google Play Store, there exist thousands of applications that request more permissions than they actually need. Applications with unnecessary permissions can misuse their permissions and endanger their users’ security and privacy. Especially, advertising network libraries, integrated within applications, request many unnecessary permissions and get unauthorized access to users’ personal data. In this paper, we explain the results of our study which analyzes several advertising networks, their permission requests and behavior for accessing critical resources.
Content may be subject to copyright.
Abused Android Permissions by Advertising
Murat Oğul, Selçuk Baktır
Computer Engineering Department
Bahçeşehir University, Istanbul, Turkey
Emin İslam Tatlı
Department of Electrical and Electronics Engineering
Istanbul Medipol University, Istanbul, Turkey
Abstract— Android is the leading mobile operating system for
smart phone and mobile tablet platforms. Since these mobile
devices contain personal and sensitive data, security is a big
challenge for them. Even though various security features are
supported by Android, its permission model is quite problematic
from usability and privacy aspects. When users want to install an
application, they must grant all requested permissions. Since
manually checking dozens of permissions is cumbersome, users
ignore it and accept permissions without reading them. In Google
Play Store, there exist thousands of applications that request
more permissions than they actually need. Applications with
unnecessary permissions can misuse their permissions and
endanger their users’ security and privacy. Especially,
advertising network libraries, integrated within applications,
request many unnecessary permissions and get unauthorized
access to users’ personal data. In this paper, we explain the
results of our study which analyzes several advertising networks,
their permission requests and behavior for accessing critical
Keywords—Android permissions, mobile security, Android
security, advertising networks
NDROID is a Linux-based mobile operating system
acquired by Google in 2005. Since then, Android has
developed very rapidly, increased its market share and today
has dominated the smart phone and mobile tablet platforms.
The global market share of Android smartphones in 2013 is
78.4% 0. It is followed by Apples’s iOS which has only 15.6%
global market share.
Since smart phones are used mostly for personal purposes
and for enterprise activities, they store sensitive personal and
confidential data. Enforcing security and privacy requirements
is therefore inevitable on mobile platforms. Even though
Android provides several security features to protect its
platform and its mobile users, its permission model has critical
design problems. One of these problems is that the
permissions of apps and in-app advertising network libraries
are not separated. This aspect is misused by several over-
privileged advertising networks. They request many
unnecessary permissions and use them to get unauthorized
access to sensitive data like location, contact list, SMS, etc.
In this paper, we analyze 25 different advertising networks
that are integrated in many apps within the official Android
store. We analyze extensively their requested permissions and
behavior for misusing these permissions.
The paper is organized as follows: Section II explains
Android’s security and permission model. Section III explains
the security risks related to the advertising networks. The
details of our analysis are given in Section IV. Section V
discusses the related work and Section VI concludes the paper.
Android platform supports several key security features
such as OS level security through the Linux kernel, mandatory
application sandboxing for applications, secure inter-process
communication, application signing, user-granted and
application-defined permissions, etc. The common target of all
these security features is the protection of user data and
system resources and isolation of applications [2]. Most of
these security features are inherited from the traditional Linux
In our study, we focus on abused application permissions.
Hence, we start by defining Android’s permission model.
Permissions define whether a process, user or application is
granted permission to trigger a critical activity and access a
critical resource. Android gives a unique user and group ID to
each Android application. Having a different process ID, an
application can access only its own data. This is called
application sandboxing. Each application runs in its own
sandbox. If an application wants to access system resources or
another applications’ data, it needs to be first granted the
related permission. During installation, each application
presents which permissions it needs for execution. Users
should accept all the requested permissions if they want to
install and execute this app. It is not possible to grant only
some of the requested permissions. Permissions are defined in
the AndroidManifest.xml file, as shown in Figure1. Similar to
user-granted permissions, there exist application-granted
permissions that define permissions to access data within an
app sandbox as illustrated in Figure 2.
Figure1. Permissions in AndroidManifest.xml
Figure 2. Android’s permission control mechanism
Android permissions are categorized into four threat levels
as defined below:
Normal: This is the default value. Permissions here are
harmless and include low risk to users, system resources
and other applications.
Dangerous: This type of permissions can access private
user data and take control over devices. For example,
RECORD_AUDIO or CAMERA permissions.
Signature: If two applications are signed with the same
certificate, they are granted access each other’s data.
Signature or System: This is a special purpose category
when multiple vendors need to share specific features in
the same system.
Mobile devices and applications are playing an
increasingly more critical role in our lives. People carry them
with themselves everywhere they go, store sensitive data on
them and also share personal information with others,
including exact location information, via apps. This new life
style attracts advertising companies who would like to gain
financial benefits from mobile users. There exist today
several advertising network platforms through which
advertisements can be sent to target user groups. As shown in
the revenue flow in Figure 3, companies and organizations pay
advertising networks for their advertisements. Developers
integrate components and libraries of advertising networks in
their mobile apps, especially in free apps. Both developers and
advertising networks get financial benefit from this life cycle.
Figure 3. Revenue flow in mobile advertising market
All parties in this revenue and data flow are content except
mobile users. Since advertising networks get mostly
unauthorized access to mobile users’ data, they pose a threat to
the security and privacy of mobile users. Advertising network
libraries, integrated within mobile apps, request dozens of
unnecessary permissions to access critical resources. In
general, permission for Internet access is sufficient for
advertising network libraries, but they also request
permissions to access information such as the location
information of the device, SMS messages, contact lists, call
details, audio and video functions, external storage data, phone
state, etc. They use some of this collected data for customized
advertisements. For example, sushi advertisements are sent to
mobile users in Japan, whereas pizza advertisements are sent
in Italy. It is still unacceptable that GPS coordinates are
collected for customization without knowledge of mobile
users. Furthermore, access to certain sensitive data (e.g. SMS)
for customization is both irrelevant and unacceptable.
All permissions requested by an application are declared in
its AndroidManifest.xml file. Permissions required by
advertising network libraries are included in the same
Manifest file. Users should grant all requested permissions in
order to install an application. But they cannot directly
distinguish application permissions from permissions of
advertising network libraries. Unnecessary permissions are
either requested unconsciously by developers or intentionally
by advertising network libraries.
In our study we analyzed several advertising networks,
their permission request models and how these permissions
are used to access critical resources. In order to identify
permissions requested by advertising network libraries, we
examined several free applications from the official Google
Play Store.
We used manual analysis techniques to check permissions
within the Manifest files. In the first step, we checked which
permissions exist within the AndroidManifest.xml file of a
mobile application. For this purpose, the dex2jar utility [11]
was used to convert apk packages to java jar files and access
Manifest files. Afterwards, we decompiled jar files to access
the source codes of the apps. The jar files were decompiled by
using the jd-gui tool [13], as shown in Figure 4. Finally, we
performed manual code review of advertising network
libraries and searched for the relevant method calls which
access the existing permissions in the Manifest file.
Figure 4. Decompiled jar files with the jd-gui utility
We examined approximately 200 free applications in
Google Play Store, and exploited the most relevant apps which
support several different advertising network libraries in our
analyses. These apps are Bitstrips Viewer 1.7 [3], Find Viber
Friends 0.2 [4], Weather Live 2.4 [5], ensogukespriler 1.2 [6],
WetterApp 2.3.3 [7] and CIA 4.0.11 [8]. We installed these
apps on Samsung Galaxy S3 (Android 4.3 and API 18)
running on a free Android emulator called Genymotion v2.2.2
[9]. We configured the emulator to send the network traffic
through the Burp Suit proxy software [10] running on our
local machine. By installing Burp’s CA certificate to the
emulator device, it was possible to inspect both HTTP and
encrypted HTTPS traffic generated by either the apps or the
advertising network libraries, as shown in Figure 5.
Figure 5. Admixer’s HTTP GET request while the Find
Viber Friend app is running
While it is running, Find Viber Friend sends critical user
location information with exact latitude and longitude values
to the Admixer advertising network (see Figure 6). During our
traffic analysis, we also realized that some advertising network
libraries do not try to establish any HTTP sessions. Either they
are not activated or, before execution, they check whether they
are installed on a real device or on an emulator.
After converting apk files to jar files, we used the open-
source AXMLPrinter2.jar tool [11], which converts Android
binary XML files to human-readable XML files, in order to
access the Manifest files and defined permissions. We also
needed to know which java classes and methods are used to
get the Android permissions as defined in the Manifest files.
Figure 6. Private information sent via Find Viber Friend
As Vidas et al. [21] explain in detail, the documentation
about manifest permissions by Google is still a big challenge.
In the official Android documentation, we could not find out
about most of the mappings between methods and permissions
requested by using these methods. We obtained the majority
of the Java methods by searching in Internet and by using the
PScout tool [22] which generates API call mappings.
Considering the identified permissions in the Manifest files
and also the identified mappings between methods and
permissions, we checked the source codes of advertising
network libraries and searched for the identified methods. For
example, if any library includes the getActiveNetworkInfo
method, we assume that this library uses the
We analyzed 6 different apps and 25 different advertising
network libraries that are integrated within these apps. The
results of our analysis, listing advertising network libraries and
their requested permissions, are shown in Table I. Here, X
represents that the related permission is declared in the
AndroidmManifest.xml file of the app and Y represents that
the relevant permission is requested by the relevant
advertising network library.
Our analysis shows several interesting results. Mobile apps
mostly contain several advertising network libraries which
request different permissions, e.g. the CIA app contains 13
different advertising libraries which request too many
unnecessary permissions. They access outgoing calls,
access/modify contact lists, read/write to external storage,
receive and send SMS, and read phone state, calling function,
location, vibration function, read log files, etc. The inMobi
advertising network ( requests 10 different
permissions including recording audio. These are
There are several research studies about Android permission
problems and advertising networks. Shekhar et al. [14] point
out the unnecessary permissions problem of advertising
libraries and propose separation of original applications from
their advertising libraries and running the libraries as separate
applications. Similar to our analysis, Book et al. [15] analyzed
permissions of advertising libraries but they focused on
permission changes of the libraries over time. They conclude
that more and more permissions are requested by the libraries
year by year. Likewise, Stevens et al. [16] investigate 13
popular advertising libraries in terms of Android permissions.
But they exploit only documentations and network analysis to
identify the requested permissions by the libraries. In our
work, we performed additionally manual code review for more
accurate results. Grace et al. [17] analyzed ca. 100 advertising
libraries by using a self-developed static analysis tool, called
AdRisk, which focuses on risks in the context of privacy and
untrusted code downloading and execution. They also show
that most existing libraries collect personal private
information. Pearce et al. [18] focus on privilege separation
and propose a solution, named AdDroid, in which advertising
networks do not provide libraries but the Android API is
extended to support advertising. Zhang et al. [19] propose a
framework called AFrame which isolates untrusted third-party
code (e.g. ad libraries) from host applications. Leontiadis et al.
[20] conducted an extensive analysis of 250,000 Android apps
and identified that the current privacy protection mechanisms
of Android are not effective. They propose thus a privacy-
aware framework as an alternative advertising service. The
framework maintains equilibrium between private information
flow and the advertisement revenue.
Table I. The requested permissions of the analyzed
advertising networks
Android is the leading operating system for mobile
platforms. Mobile smart phones store and process sensitive
personal information including location data. Android
platform provides several security features for protecting user
privacy, but its permission model has critical design problems.
Since permissions of mobile apps and in-app integrated
advertising network libraries are not separated by default, this
is misused by the advertising network libraries. In this paper,
we analyzed 25 different advertising networks, their requested
permissions and their behaviors for misusing the requested
permissions. Our analysis showed that most of the ad libraries
are over-privileged and even access location information and
record audio and deliver them to remote servers. It is therefore
inevitable to separate privileges of mobile Android apps from
advertising networks.
[1] Global market share held by smartphone operating systems from 2009 to
2013. Available:
[2] Android Security Overview, Available:
[3] Bitstrips Viewer,
[4] Find Viber Friends,
[5] Weather Live Free,
[6] Ensogukespriler,
[7] Wetter App,
[8] CIA free caller ID,
[9] Genymotion Android Emulator,
[10] Burp Suite Proxy,
[11] Dex2jar,
[12] AXMLPrinter2.jar,
[13] jd-gui Java Decompiler,
[14] Shekhar, S., Dietz, M., and Wallach, D. S. AdSplit: Separating
Smartphone Advertising From Applications. In USENIX Security
Symposium (SSYM), 2012.
[15] Book, T., Pridgen, A., and Wallach, D. S. Longitudinal Analysis of
Android Ad Library Permissions. In IEEE Mobile Security Technologies
[16] R. Stevens, C. Gibler, J. Cru ssell, J. Erickson, and H. Chen,
“Investigating user privacy in Android ad libraries,” in Mobile Security
Technologies (MoST) 2012.
[17] M. Grace, W. Zhou, X. Jiang, and A. Sadeghi, “Unsafe exposure
analysis of mobile in-app advertisements,” in Proceedings of the fifth
ACM conference on Security and Privacy in Wireless and Mobile
Networks. ACM, 2012, pp. 101–112.
[18] P. Pearce, A. P. Felt, G. Nunez, and D. Wagner. AdDroid: Privilege
Separation for Applications and Advertisers in Android. In Proceedings
of the 7th ACM Symposium on Information, Computer and
Communications Security, 2012.
[19] Xiao Zhang, Amit Ahlawat, Wenliang Du: AFrame: isolating
advertisements from mobile applications in Android. ACSAC 2013.
[20] I. Leontiadis, C. Efstratiou, M. Picone, and C. Mascolo, “Don’t kill my
ads!: Balancing privacy in an ad-supported mobile application market,”
in Proceedings of the Twelfth Workshop on Mobile Computing Systems
& Applications. ACM, 2012, p. 2.
[21] T. Vidas, N. Christin, and L. Cranor. Curbing Android permission creep.
In Proceedings of the Web 2.0 Security and Privacy 2011 workshop
(W2SP 2011), Oakland, CA, May 2011.
[22] K. Au, Y. Zhou, Z. Huang, and D. Lie, “Pscout: Analyzing the Android
permission specification,” in Proceedings of the 19th ACM conference
on Computer and Communications Security. ACM, 2012, pp. 217–22.
Full-text available
The Android platform has about 130 application level permissions that govern access to resources. The determi-nation of which permissions to request is left solely to the appli-cation developer. Users are prompted to approve all application permissions at install time, and permissions are silently enforced at execution time. Although many applications make use of a wide range of permissions, we have observed that some applications request permissions that are not required for the application to execute, and that existing developer APIs make it difficult for developers to align their permission requests with application functionality. In this paper we describe a tool we developed to assist developers in utilizing least privilege.
Full-text available
Android uses a permission-based security model to restrict applications from accessing private data and privileged resources. However, the permissions are assigned at the application level, so even untrusted third-party libraries, such as advertisement, once incorporated, can share the same privileges as the entire application, leading to over-privileged problems. We present AFrame, a developer friendly method to isolate untrusted third-party code from the host applications. The isolation achieved by AFrame covers not only the process/permission isolation, but also the display and input isolation. Our AFrame framework is implemented through a minimal change to the existing Android code base; our evaluation results demonstrate that it is effective in isolating the privileges of untrusted third-party code from applications with reasonable performance overhead.
Full-text available
Modern smartphone operating systems (OSs) have been developed with a greater emphasis on security and protecting privacy. One of the mechanisms these systems use to protect users is a permission system, which requires developers to declare what sensitive resources their applications will use, has users agree with this request when they install the application and constrains the application to the requested resources during runtime. As these permission systems become more common, questions have risen about their design and implementation. In this paper, we perform an analysis of the permission system of the Android smartphone OS in an attempt to begin answering some of these questions. Because the documentation of Android's permission system is incomplete and because we wanted to be able to analyze several versions of Android, we developed PScout, a tool that extracts the permission specification from the Android OS source code using static analysis. PScout overcomes several challenges, such as scalability due to Android's 3.4 million line code base, accounting for permission enforcement across processes due to Android's use of IPC, and abstracting Android's diverse permission checking mechanisms into a single primitive for analysis. We use PScout to analyze 4 versions of Android spanning version 2.2 up to the recently released Android 4.0. Our main findings are that while Android has over 75 permissions, there is little redundancy in the permission specification. However, if applications could be constrained to only use documented APIs, then about 22% of the non-system permissions are actually unnecessary. Finally, we find that a trade-off exists between enabling least-privilege security with fine-grained permissions and maintaining stability of the permission specification as the Android OS evolves.
Full-text available
This paper investigates changes over time in the behavior of Android ad libraries. Taking a sample of 100,000 apps, we extract and classify the ad libraries. By considering the release dates of the applications that use a specific ad library version, we estimate the release date for the library, and thus build a chronological map of the permissions used by various ad libraries over time. We find that the use of most permissions has increased over the last several years, and that more libraries are able to use permissions that pose particular risks to user privacy and security.
Conference Paper
Full-text available
Application markets have revolutionized the software download model of mobile phones: third-party application developers of-fer software on the market that users can effortlessly install on their phones. This great step forward, however, also imposes some threats to user privacy: applications often ask for permissions that reveal private information such as the user's location, contacts and messages. While some mechanisms to prevent leaks of user pri-vacy to applications have been proposed by the research commu-nity, these solutions fail to consider that application markets are primarily driven by advertisements that rely on accurately profiling the user. In this paper we take into account that there are two par-ties with conflicting interests: the user, interested in maintaining their privacy and the developer who would like to maximize their advertisement revenue through user profiling. We have conducted an extensive analysis of more than 250,000 applications in the An-droid market. Our results indicate that the current privacy protec-tion mechanisms are not effective as developers and advert com-panies are not deterred. Therefore, we designed and implemented a market-aware privacy protection framework that aims to achieve an equilibrium between the developer's revenue and the user's pri-vacy. The proposed framework is based on the establishment of a feedback control loop that adjusts the level of privacy protection on mobile phones, in response to advertisement generated revenue.
Full-text available
Advertising is a critical part of the Android ecosystem— many applications use one or more advertising services as a source of revenue. To use these services, developers must bundle third-party, binary-only libraries into their applications. In this model, applications and their adver-tising libraries share permissions. Advertising-supported applications must request multiple privacy-sensitive per-missions on behalf of their advertising libraries, and ad-vertising libraries receive access to all of their host appli-cations' other permissions. We conducted a study of the Android Market and found that 49% of Android applica-tions contain at least one advertising library, and these libraries overprivilege 46% of advertising-supported appli-cations. Further, we find that 56% of the applications with advertisements that request location (34% of all applica-tions) do so only because of advertisements. Such pervasive overprivileging is a threat to user privacy. We introduce AdDroid, a privilege separated advertising framework for the Android platform. AdDroid introduces a new adver-tising API and corresponding advertising permissions for the Android platform. This enables AdDroid to separate privileged advertising functionality from host applications, allowing applications to show advertisements without re-questing privacy-sensitive permissions.
Recent years have witnessed incredible growth in the popularity and prevalence of smart phones. A flourishing mobile application market has evolved to provide users with additional functionality such as interacting with social networks, games, and more. Mobile applications may have a direct purchasing cost or be free but ad-supported. Unlike in-browser ads, the privacy im-plications of ads in Android applications has not been thoroughly explored. We start by comparing the similarities and differences of in-browser ads and in-app ads. We examine the effect on user privacy of thirteen popular Android ad providers by reviewing their use of permissions. Worryingly, several ad libraries checked for permissions beyond the required and optional ones listed in their documentation, including dangerous permissions like CAMERA, WRITE CALENDAR and WRITE CONTACTS. Further, we discover the insecure use of Android's JavaScript extension mechanism in several ad libraries. We identify fields in ad requests for private user information and confirm their presence in network data obtained from a tier-1 network provider. We also show that users can be tracked by a network sniffer across ad providers and by an ad provider across applications. Finally, we discuss several possible solutions to the privacy issues identified above.
In recent years, there has been explosive growth in smartphone sales, which is accompanied with the availability of a huge number of smartphone applications (or simply apps). End users or consumers are attracted by the many interesting features offered by these devices and the associated apps. The developers of these apps benefit financially, either by selling their apps directly or by embedding one of the many ad libraries available on smartphone platforms. In this paper, we focus on potential privacy and security risks posed by these embedded or in-app advertisement libraries (henceforth "ad libraries," for brevity). To this end, we study the popular Android platform and collect 100,000 apps from the official Android Market in March-May, 2011. Among these apps, we identify 100 representative in-app ad libraries (embedded in 52.1% of the apps) and further develop a system called AdRisk to systematically identify potential risks. In particular, we first decouple the embedded ad libraries from their host apps and then apply our system to statically examine the ad libraries for risks, ranging from uploading sensitive information to remote (ad) servers to executing untrusted code from Internet sources. Our results show that most existing ad libraries collect private information: some of this data may be used for legitimate targeting purposes (i.e., the user's location) while other data is harder to justify, such as the user's call logs, phone number, browser bookmarks, or even the list of apps installed on the phone. Moreover, some libraries make use of an unsafe mechanism to directly fetch and run code from the Internet, which immediately leads to serious security risks. Our investigation indicates the symbiotic relationship between embedded ad libraries and host apps is one main reason behind these exposed risks. These results clearly show the need for better regulating the way ad libraries are integrated in Android apps.
A wide variety of smartphone applications today rely on third-party advertising services, which provide libraries that are linked into the hosting application. This situation is undesirable for both the application author and the advertiser. Advertising libraries require additional permissions, resulting in additional permission requests to users. Likewise, a malicious application could simulate the behavior of the advertising library, forging the user's interaction and effectively stealing money from the advertiser. This paper describes AdSplit, where we extended Android to allow an application and its advertising to run as separate processes, under separate user-ids, eliminating the need for applications to request permissions on behalf of their advertising libraries. We also leverage mechanisms from Quire to allow the remote server to validate the authenticity of client-side behavior. In this paper, we quantify the degree of permission bloat caused by advertising, with a study of thousands of downloaded apps. AdSplit automatically recompiles apps to extract their ad services, and we measure minimal runtime overhead. We also observe that most ad libraries just embed an HTML widget within and describe how AdSplit can be designed with this in mind to avoid any need for ads to have native code. [4] Find Viber Friends
  • Bitstrips Viewer
Bitstrips Viewer, [4] Find Viber Friends, [5] Weather Live Free,