Knock-Knock: The Unbearable Lightness of Android Notiﬁcations

Constantinos Patsakis and Efthimios Alepis

Department of Informatics, University of Piraeus, 80, Karaoli & Dimitriou str.,18534, Piraeus, Greece

Keywords:

Android, Notiﬁcations, Phishing, Local DoS.

Abstract:

Android Notiﬁcations can be considered as essential parts in Human-Smartphone interaction and inextricable

modules of modern mobile applications that can facilitate User Interaction and improve User Experience. This

paper presents how this well-crafted and thoroughly documented mechanism, provided by the OS can be ex-

ploited by an adversary. More precisely, we present attacks that result either in forging smartphone application

notiﬁcations to lure the user in disclosing sensitive information, or manipulate Android Notiﬁcations to launch

a Denial of Service attack to the users’ device, locally and remotely, rendering them unusable. This paper

concludes by proposing generic countermeasures for the discussed security threats.

1 INTRODUCTION

Modern mobile devices have penetrated our daily

lives in the past years, making them an indispensable

part of our daily lives. Initially, their goal was to pro-

vide communication to users via various means e.g.

calls, short messages, video conference and chatting.

Nevertheless, currently, they have stormed other ac-

tivities such as infotainment, Internet browsing, ﬁt-

ness monitoring, or even ﬁnance. The fact that these

devices are small enough to be seamlessly carried on

daily basis and the fact that they are able to perform

multiple tasks and process data from a plethora of em-

bedded sensors has enabled developers to create nu-

merous applications and a new niche market.

The interaction between users and mobile devices

increases over the years and as a result the means of

realizing this bi-directional communication has also

evolved. Back in 2014 a comprehensive study on mo-

bile phone notiﬁcations (Pielot et al., 2014) revealed

that users had to deal with 63.5 notiﬁcations on aver-

age per day, mostly from messengers and email. Ob-

viously, this number has been increased signiﬁcantly

over the last years with the rise of apps such as What-

sApp and Facebook messenger and notiﬁcation mes-

sages overpassing billions in daily basis (ZDNet, ).

At the same time recent studies reveal that push

notiﬁcations draw users’ attention, with user average

opening notiﬁcation rates being over 90% (Biznes-

sapps, ). Notiﬁcations also allow developers to in-

crease user engagement with their app and improve

user retention rates (Biznessapps, ). Mobile notiﬁca-

tions seem to clearly inﬂuence user engagement pos-

itively and also improve user conversion rates. As

stated in (Caitlin O’Connell, ):

“In 2015, users who enabled push notiﬁca-

tions launched an app an average of 14.7

times per month, whereas users who did not

only launched an app 5.4 times per month. In

other words, users who opted in to push mes-

sages averaged 3x more app launches than

those who opted out.”

Equivalent ﬁndings are also reported in (Urban Air-

ship, ):

“Analysis of 63 million app users’ ﬁrst 90-

days reveals more frequent messaging in-

creases mobile app retention rates by 3X to

10X”.

In view of the above this paper illustrates the ne-

cessity of providing mobile users with secured and

trusted mechanisms for their interaction with mobile

devices. Towards this end, this paper analyzes the ba-

sic interaction mechanisms available in Android, the

worlds’ most popular mobile platform to date. Our

research illustrates ﬂaws in the Android’s notiﬁcation

mechanisms which can lead to a number of attacks,

presented in this work. Subsequently, this paper also

discusses about countermeasures in order to provide

defense solutions to the attacks.

Main Contributions: The main contribution of this

work is to illustrate successful attacks in the most

recent versions of Android, using AOSP as a refer-

ence. These attacks can affect additively the majority

Patsakis, C. and Alepis, E.

Knock-Knock: The Unbearable Lightness of Android Notiﬁcations.

DOI: 10.5220/0006603200520061

In Proceedings of the 4th International Conference on Information Systems Security and Privacy (ICISSP 2018), pages 52-61

ISBN: 978-989-758-282-0

of Android users to date. More speciﬁcally, this pa-

per presents forging notiﬁcation attacks that include

home-screen shortcuts, attacks in notiﬁcations that re-

sult in DOS and also attacks concerning web push no-

tiﬁcations. To the best of our knowledge, and accord-

ing to the malware samples of (Wei et al., 2017), no-

tiﬁcations are used for aggressive advertisement via

the malware families of Airpush and Kuguo. Over-

all, we aim in providing a thorough analysis in the

core means of realizing Human-Smartphone interac-

tion, both for providing a way to detect ﬂaws and also

for better locating their corresponding working solu-

tions.

Organization of this Work: The rest of this work is

organized as follows. In the next section we present

the related work. Section 3 provides the background

and the basis for the problem setting. Then, Section

4 presents two distinct categories of attacks on An-

droid Notiﬁcations. Finally, the article concludes dis-

cussing possible countermeasures.

2 RELATED WORK

Android was designed to run in devices with con-

strained capabilities in terms of both computation or

size. The size of the device, as Android mainly targets

handheld devices, implies many restrictions in the UI.

As a result, the UI can be considered as a set of layers

which are stacked one on top of the other. However, as

highlighted in (Chin et al., 2011): “Phishing attacks

can be mounted convincingly because the Android UI

does not identify the currently running application.”.

This was exploited by (Niemietz and Schwenk, 2012)

who managed to create the ﬁrst UI redressing attack

for Android. While drawing on top of other activities

and partially covering them, researchers have recently

started to ﬁnd novel ways to do it. The bulk of the

attacks exploit a recently introduced Android permis-

sion, the System Alert Window (Ying et al., 2016a;

Fratantonio et al., 2017). According to Google De-

veloper resources (Android Developer, ): “Very few

apps should use this permission; these windows are

intended for system-level interaction with the user”.

Nevertheless, due to backward compatibility issues,

an adversary may easily use this permission without

the user’s knowledge or consent by targeting lower

API levels in the app. While the attacks have rather

severe impact, the apps that can exploit this feature

are rather limited and can be easily found by simply

scanning the manifest for the corresponding permis-

sions. On the contrary, a more stealth attack allows

an adversary to overlay activities without requesting

any permission from the user (Alepis and Patsakis,

2017b).

However, in order to timely present the user a

screen which requires him to provide his credentials,

one needs to be aware of which is the foreground

activity. Methods to do this are discussed in (Chen

et al., 2014; Alepis and Patsakis, 2017b), however,

they are rendered useless as of Nougat, since access

to /proc has been signiﬁcantly shrinked. To counter

this lack of knowledge, an adversary may resort to

other means, e.g. masquerade as a legitimate app and

convince the user to interact. Note that all apps are

aware of which apps are already installed in the de-

vice, so the adversary can easily ﬁnd a target one. In

this regard, in (Xu and Zhu, 2012); a closely related

work to us, a set of attacks which exploit notiﬁcations

was proposed. The concept is that the user has been

tricked into installing a malicious app named Notish

which issues notiﬁcations that look like ones from

other legitimate apps luring them to disclose sensitive

information e.g. credentials. The attacks that the au-

thors demonstrate apply not only to Android, but iOS

and Blackberry, while a spam scenario also exists.

Perhaps the most relevant to ours can be consid-

ered the work of (Xu and Zhu, 2012), for this reason

it is further analyzed. Back in 2012 the authors where

supporting that they ﬁrst presented a paper regarding

the security of notiﬁcations in mobile phones. Specif-

ically regarding Android, they covered platforms 2.3

and 4.0 (API level 14). Nevertheless, many years have

passed and considering the small mobile OS lifetime,

this period was quite signiﬁcant for many reasons.

Most importantly, Android has changed a lot since

2012, providing 12 newer API levels to date, with

the introduction of Android Oreo, always hardening

its security. To this end, notiﬁcation services can be

considered as much different compared with the sit-

uation in 2012. More speciﬁcally, not only are their

security mechanisms more improved, but also the at-

tacks described in (Xu and Zhu, 2012) do not actu-

ally apply in the settings of Android in its latest ver-

sions. The most basic reason is that these attacks de-

pended on hard-coded resource graphics, which, after

being submitted for publication to Google Play Store,

they would immediately be discarded by the Google

Bouncer as it would ﬁnd them fraudulent. Moreover,

most of the notiﬁcations’ functionalities that are ex-

ploited in this paper, such as replacing the notiﬁca-

tions’ icon, where introduced very recently. e.g. the

“Notiﬁcation.Builder setSmallIcon (Icon icon)” func-

tion was added in API level 23. Furthermore, in the

last versions of Android, the app name has been sup-

plementarily added in notiﬁcations, enhancing their

security even more, once again rendering past attacks

useless.

Knock-Knock: The Unbearable Lightness of Android Notiﬁcations

The interested reader may refer to (Felt and Wag-

ner, 2011; Virvilis et al., 2014) for more on phishing

attacks on Android.

3 HUMAN-SMARTPHONE

INTERACTION

Analyzing the interaction between humans and smart-

phones, we may come up in itemizing the most pro-

found and basic reasons for humans using this “spe-

cial” computing device, namely the smartphone, that

has drown much of the users’ interest over the last

decade. The categorization of these actions could

inarguably differ, facilitating other points of view,

however, for the purposes of this study we split them

in the following four categories: (a) Communicat-

ing with others (calling, texting etc.) (b) Internet

browsing, (c) Using 3rd party applications (m-bank-

ing, infotainment etc.), (d) Responding to notiﬁca-

tions To conclude to these four basic categories of ac-

tions in using a mobile device, we investigated why,

how, when and under what conditions an average user

might be using a smartphone. While there might be

overlaps in these categories, discussed in the follow-

ing paragraphs, we consider these reasons of realizing

human-smartphone interaction as distinct.

Communicating with others via calling, texting

etc. are basic and fundamental actions performed in

mobile devices even before the existence of smart-

phones, namely since the appearance of feature

phones. This kind of interaction is accomplished

through applications that accompany the OS and are

developed by the OS vendor. Certainly, both phone

calling and text messaging can be also realized by

third party applications, while VoIP solutions are also

rapidly appearing. Nevertheless, this can be consid-

ered as a fundamental reason for using a mobile de-

vice, since its very existence and before having these

devices being able to connect to the Internet.

Using the well-known mobile browsers for visit-

ing and interacting with web pages through mobile

devices is also considered as a very important reason

of human-smartphone interaction. Notably, in 2016

mobile phone users who visit the WWW overpassed

the corresponding number of personal computer users

(StatCounter GlobalStats, ). The latter not only high-

lights the importance of such an interaction, but it also

indicates the closer connection to humans’ lives that

smartphones have managed to acquire.

Using third party applications in a smartphone can

be considered as one of the most important and ba-

sic reasons of interaction between users and mobiles.

The incorporation of all kinds of applications that

are of the users’ interests has been perhaps the ba-

sic reason for smartphones having operating systems

that support this kind of functionality and thus make

them considerably distinguishable to “ordinary” fea-

ture phones. The extraordinary adoption of app stores

where users can browse and install applications of

numerous categories supports the aforementioned ar-

gument. Additionally, recent studies (Flurry Analyt-

ics, ) between smartphones provide strong indications

that mobile applications are the users’ preferred way

of interaction when using their smartphone for some

reason (e.g. play a game, buy tickets, check a per-

sonal bank account balance), compared with the cor-

responding services relying in web pages. The us-

age of third party applications of course implies the

existence of notiﬁcations in a high percentage of use

cases, such as receiving and consequently responding

to instant messages. This part of interaction, however,

is covered separately in the following paragraphs.

Finally, as already mentioned, we consider that re-

sponding to notiﬁcations is a special interaction be-

tween humans and smartphones. By using the term

“responding”, we consider both the cases when users

actually respond to received notiﬁcations by “open-

ing” them, as well as the cases of even more basic

actions, such as using the smartphones’ built-in noti-

ﬁcation drawer to see and/or read the messages of the

notiﬁcations, even if the users, in some cases, decide

not to “open” a notiﬁcation and just “clear” it after

reading part of its message. This kind of interaction

can be considered of great importance as it forms a

very common reason of using the smartphone in mod-

ern human-smartphone interaction and because it is

expected to grow even more and become more im-

portant in the years to come. A smartphone can re-

ceive notiﬁcations for a large number of reasons that

include, yet are not limited to, the following:

• Having missed a phone call

• A newly received text message

• System automatically updated applications

• Results from periodically scheduled jobs such as

software update checking and virus scanning

• Messages from carriers

• Push notiﬁcations coming from external re-

sources, corresponding to installed applications.

Perhaps the most notable ones in this category

are instant messaging applications such as What-

sApp, Viber and Facebook messenger

• Web push notiﬁcations that constitute a quite “re-

cent” addition in most mobile browsers’ capabil-

ities, where even not used web pages are able to

ICISSP 2018 - 4th International Conference on Information Systems Security and Privacy

transmit their notiﬁcations to targeted mobile de-

vices

• Local app notiﬁcations, where third party apps

create and issue a notiﬁcation in order to be read

by the user, or require an action taken by the user

The aforementioned categories of notiﬁcations are

signiﬁcant and basic, however one should investigate

the underlying reasons why this “kind” of interac-

tion is important more thoroughly. Thus the reader

may have both a rational explanation and also the ev-

idence deriving from the users’ experience about the

authors’ claims. Notifying in terms of mobile com-

puting means, at its fundamental deﬁnition, implies

ﬁnding a way to reach the user, gain his/her attention.

This can be variously achieved, aligned with the Op-

erating System’s supported corresponding functional-

ities. A foreground application being used by a smart-

phone user can change/update its Graphical User In-

terface (GUI) to provide new information to the user.

The same use-case may occur in a web environment,

where a web page may dynamically adjust its con-

tent. When considering applications that are not cur-

rently active, or are running in the background, or

are even closed since the mobile device is switched

off, the ways to accomplish user notiﬁcation changes

signiﬁcantly, since additional parameters have to be

taken into account. Notably, new information that

would change the contents of an Android activity but

would not be launched until a user actually opened the

corresponding application cannot be considered as a

timely, nor an acceptable way to realize user atten-

tion. On the contrary, modern mobile notiﬁcations try

to “force” user interaction and do not rely on wait-

ing when or whether the user decides to check their

corresponding app.

In this sense, native mobile applications may

choose among a variety of programmatically feasi-

ble solutions in order to draw users’ attention, such as

newly launched activities, opened web pages through

browsers, dialog messages, toast messages and of

course native Android notiﬁcations. The latter, how-

ever, has some considerable advantages to count, as it

will be further explained, thus may be chosen as the

prevailing solution in a majority of use cases where

an application is not being used, or when a device is

switched off.

Essentially, all the aforementioned “solutions”

can work towards the direction of informing the user

about something. Nevertheless, as it will be further

discussed, in the cases where users are either not us-

ing their mobile device, or a speciﬁc app, developers

may opt in favor of the native Android notiﬁcations to

accomplish user-app interaction. Toast messages in-

volve two basic drawbacks in these cases. First, they

are useless when a mobile device is switched off or

locked, since they will not appear. In the case where

the mobile device is unlocked and awaken, a dis-

played toast message can only provide short informa-

tion to a user, for only 5 seconds without necessarily

providing the identity of the issuer. Newly launched

activities, or launched mobile pages through mobile

browsers are deﬁnitely more “permanent” than toast

messages solutions, since they do not disappear af-

ter a speciﬁc period of time, nor get affected by the

state of the mobile device, namely when they are

closed and/or locked. However, both are invasive in

terms of user-mobile interaction since they impose

their presence as the foreground app in the mobile

device’s main User Interface (UI). Moreover, there

is no guarantee that they are going to be the fore-

ground app when the user unlocks the phone, since

other, newer, activities might have been launched,

putting them in the background. Android dialog mes-

sages suffer the same disadvantages too. Addition-

ally, dialog messages are required to hold the quite

“dangerous” system permission that allows them to

draw over other screens to accomplish the desirable

result, namely the SYSTEM

ALERT WINDOW per-

mission, that can be maliciously used (Fratantonio

et al., 2017).

Deductively, we lead to reason why the Android

notiﬁcations are the preferred, and the suggested by

Google, way of realizing the communication between

a user and an unused app, or even more precisely, be-

tween a user and an application that is not in the fore-

ground. In addition, the internal design of Android

notiﬁcations provides them with some valuable assets

in terms of establishing an effective and accepted so-

lution for asynchronous or semi-synchronous back-

ground initiated communication between users and

apps. These assets include great levels of effective-

ness in terms of OSes resources usage, permanence

and user friendliness in terms of providing a nonin-

vasive way of notifying users. Nevertheless, there

are two points that require signiﬁcant attention. All

kinds of notiﬁcations that are issued from a “back-

ground” process when either a device is locked or

when a user is using an irrelevant application also

means that the identity of the notiﬁcation issuer is also

very critical. When a user is actually using an applica-

tion and the application’s content changes, users can

feel quite sure, presumably, that the changed content

originates from the application they use. On the con-

trary, when users receive incoming information from

an application they are not actively using, they ratio-

nally need to be able to verify its actual source. This

is the reason why, when receiving an email from an

unknown source requesting the bank credentials to

Knock-Knock: The Unbearable Lightness of Android Notiﬁcations

proceed to an action issued by a well-known bank,

most users, hopefully, consider this email as fake and

subsequently delete it. Accordingly, a mobile phone

user is expecting to be able to conﬁrm a notiﬁca-

tions’ issuer true identity before proceeding to an ac-

tion that could range from posting an unwanted mes-

sage to a social network, to exposing the user’s login

credentials for his/her bank account, or a company’s

server login. To this end, the notiﬁcations’ nature can

be considered as even more deceptive when they are

asynchronous to the users’ active interaction, since by

deﬁnition are not expected to appear when users are

using the issuing applications and respectively know

their origin.

As already mentioned, the aim of this paper is

twofold. One the one hand, provides evidence, re-

grettably, that Android notiﬁcations can be provably

be insecure in contrast to their wide adoption and in-

creased interest by both developers and users. On

the other hand, the authors also suggest solutions that

may address the arising security issues. Towards this

direction, even though applying the countermeasures

will not provide ground proof that Android notiﬁca-

tions will subsequently become secure, closing secu-

rity holes still improves them and also helps towards

the direction of maturing an ever developing and con-

stantly evolving mobile operating system. For these

reasons, the analyzed underlying security issues and

not only statically illustrated, rather than the causes

of their origin are investigated and generic solutions

as countermeasures are proposed. Leaving the pro-

gramming level and anatomizing the more abstract

level of the Android Notiﬁcations’ infrastructure in

terms of Human-Smartphone interaction not only re-

veals this “mechanism’s” profound architecture, but

also projects both its strengths and weaknesses.

4 ATTACKS ON ANDROID

NOTIFICATIONS

In this section we discuss attacks on Android Notiﬁ-

cations. More speciﬁcally, our main focus will be to

illustrate the feasibility of forging application notiﬁ-

cations, which expose the users’ privacy and security.

Secondly, we present how Android’s notiﬁcations can

be exploited to launch a Denial of Service (DoS) at-

tack, both locally and remotely.

4.1 Forging App Notiﬁcations

As already analyzed in the previous section, the in-

teraction between smartphone apps and users is bidi-

rectional. In the case of users’ initiated interac-

tion, namely user-to-app, users are having knowledge

about the applications that they launch and use. In

this paper we are going to prove that by designing a

ﬁne-tuned, yet based of evidence, attack to Android

users, the app-to-user interaction can be exploited. In

particular, the attack that is illustrated in this section

involves a number of steps from the attacker’s side,

involving fundamental Android components and ser-

vices. The impact of forging notiﬁcations can be con-

sidered rather high, as it can be used to deceive them

to collect user credentials, perform user proﬁling, or

even blackmailing. The steps of the attack are illus-

trated in Figure 2. Following, a use case is also pre-

sented and analyzed. For the purposes of highlighting

the dangers that accompany this attack, in our step-

by-step use case scenario we have chosen “PayPal”

as the “target” app. The steps are the following:

• A user installs a zero-permission app through

Google Play. The apps name is BobApp and re-

quires only Internet access (even this permission

can by bypassed if necessary).

• The installed app retrieves the list of installed ap-

plications in the victim’s device. The list is com-

municated to a service owned by the attacker.

• The attacker determines whether an app that he

would like to make an attack to is available in vic-

tims’ devices. In this scenario it is “PayPal”.

• The attacker issues an update for the app, through

Google Play, where the app’s name is replaced,

namely “BobApp” becomes “PayPal”. The up-

date is expected to be launched automatically,

usually by night, when the device is unattended

(e.g. probably left charging and connected to a

Wiﬁ).

• After a successful application update, the mali-

cious app’s name has been changed, while the user

(owner) has no way to know about it.

• To build a complete notiﬁcation, the malicious

app requires a title, a text and also the target app’s

icon. This is accomplished by utilizing the actual

genuine target app’s resources. More speciﬁcally,

the target app’s package is located and the app’s

graphics are retrieved through the application’s re-

sources and the application’s metadata. As a re-

sult, a new notiﬁcation is triggered, with an iden-

tical to the genuine app interface.

• After triggering the malicious notiﬁcation, the

user is expected to select it and subsequently

launch a malicious activity. The malicious activ-

ity can further utilize the genuine app’s resources

in order to provide a UI that will lure the user.

ICISSP 2018 - 4th International Conference on Information Systems Security and Privacy

Figure 1: A forged notiﬁcation from another app.

• Finally, the user is asked for some private info

(credentials) compromising her/his account.

The above scenario has been tested both locally

and through Google Play. A forged notiﬁcation for

PayPal on Nougat is illustrated in Figure 1. More in-

terestingly, since the ID for an app located in Google

Play consists only of its package name, one can very

easily ﬁnd numerous apps in Google Play sharing the

same name. Moreover, after thorough research we

have come up with the conclusion that bypassing a

notiﬁcation’s actual app name is almost impossible by

other means in AOSP. Achieving this programmati-

cally requires the “substitute notiﬁcation app name’

’

signature permission, which only 2-3 system apps ac-

tively have. Indeed, our research revealed that these

apps are “Easter Eggs”, “Google Play” and “Shell”.

The combination of using other apps’ resources and

changing the app name arbitrarily through back-

ground silent updates, makes the described attack sce-

nario both effective and real. Indeed, the described

attack proves to the readers that Android users can

be led to a situation where they would not be able to

reason about the origin of their smartphones’ notiﬁca-

tions.

Finally, another part of the Android’s user interac-

tion mechanism that has been found to have ﬂaws is

the home-screen application shortcuts. Home-screen

shortcuts are coupled to notiﬁcations in many cases

since once one or more notiﬁcations have been is-

sued by an application, an indicative change appears

in the corresponding app’s shortcut (e.g. an indicating

number of unread notiﬁcations). Nonetheless, home-

screen shortcuts are also being frequently used by

users to initiate an interaction with an app. Our in-

dependent research has revealed that Android home-

screen app shortcuts can be easily forged and a ma-

licious application can appear on a device’s home-

screen as another application, with identical icon and

name. Both the home-screen icon and also the name

of the shortcut are not hard-coded and do not originate

from the app’s resources. As a result every applica-

tion is able to create a home-screen shortcut as being

another app. In this sense, forged app notiﬁcations

can “cooperate” with forged app home-screen short-

cuts to further deceive the user. Even without having

notiﬁcations issued, home-screen shortcuts provide

attackers with another attack-vector in the human-

smartphone interaction.

Both security issues, regarding forged notiﬁca-

tions and forged home-screen shortcuts, have been

responsibly disclosed to Google’s Android Security

Team.

4.2 DoS through Notiﬁcations

Following another approach, notiﬁcations can be used

to launch a denial of service both locally and re-

motely. The attack exploits a bug in NotiﬁcationMan-

ager when allocating memory for creating a Notiﬁca-

tion. The notiﬁcation’s builder object expects a spe-

ciﬁc size of the icon, yet allocates memory for any

given image graphic. Potentially, this bug may allow

arbitrary code execution, however, to this point, we

were not able to execute it. As a result, the attack;

currently being patched by Android Security Team,

is launched when a properly crafted notiﬁcation is

sent to the NotiﬁcationManger class. After launching

the attack, the System UI process repeatedly crashes

blocking the user from making any other interaction

apart from answering a call and rebooting. Notably,

while answering calls is allowed, the UI does not re-

vert to the original state. Furthermore, by registering

a broadcast receiver Android object waiting for the

“BOOT COMPLETED” event and re-issuing the ma-

licious notiﬁcation makes the device unusable, since

the device will immediately fall to the previous loop-

ing state. Possible countermeasures, before a patch is

applied by Google, is to uninstall the malicious appli-

cation through a possible “safe mode” device state, or

re-ﬂashing the whole device.

To launch this attack, actually almost no code is

required, since only a “big” image of high resolu-

tion is needed to be sent to NotiﬁcationManager for

rendering. In our tests we used a high resolution

(4096x4096) PNG ﬁle, of rather low ﬁle size (2.79

KB), however larger graphics have the same effect.

Such a “malicious” image can either be stored in

the application’s resources, or be loaded dynamically.

Nevertheless, some critical issues arise by its actual

capability to be able to be loaded dynamically, from

other resources than the actual application that is ﬁr-

Knock-Knock: The Unbearable Lightness of Android Notiﬁcations

Figure 2: Attack overview.

ing the notiﬁcation.

Clearly, the above scenario is triggered locally,

by a malicious installed app. Nonetheless, this

can also be triggered remotely. As of API level

23, the Notiﬁcation.Builder class includes a new

method, namely “Notiﬁcation.Builder setSmallIcon

(Icon icon)”, which accepts an icon rather that a re-

source. This way, many apps (e.g. Youtube), use

Internet resources to download their graphics. Since

this information is not private and servers want to take

advantage of caching, such graphics are mostly trans-

mitted via plain HTTP. Using a simple man-in-the-

middle attack, an adversary can replace the requested

graphic with a high resolution graphic and brick the

devices remotely.

Even when examining the case where a device is

targeted in API levels less than 23, where the new

“setSmallIcon” function was not available and even if

there was the possibility of pre-checking the resources

of each app that could be used as icons, the problem

still exists. Namely, since apps’ resources are “pub-

lic” to other installed apps, a malicious application

could very easily scan the device for all installed apps’

resources and select a high resolution image and use

it for the attack.

4.3 Web Push Notiﬁcations

Recently, the ability to ﬁre notiﬁcations has been also

given to web pages, with a big number of modern and

popular mobile browsers supporting this feature. In

our tests we have successfully tested web push noti-

ﬁcations on Android devices running Chrome version

≥ 42, Mozilla version ≥ 44 and Samsung Internet

browser version ≥ 4.0. Having the ability to notify a

user asynchronously was one of the very basic advan-

tages that native mobile applications had in the past,

in contrast to web pages, whose lifetime of interaction

with the user was bounded to the time the user spent

in browsing on a speciﬁc web page.

Web push notiﬁcations were introduced to ﬁll

this gap. This functionality is established through a

“bridge” between the native app world and the web

pages ecosystem, provided by the mobile browser. A

mobile browser is a “special” kind of software entity.

Since it operates in both of these “worlds”, it is actu-

ally a native mobile application installed in a smart-

phone, while simultaneously its basic purpose is to

serve web pages. As a result, having some special

permissions given by the user explicitly, a web page is

able to send a push notiﬁcation asynchronously to the

browser and consequently, the browser is responsible

for “communicating” this notiﬁcation to the user’s de-

vice, utilizing the OSes native mechanisms.

However, the latter introduces another attack vec-

tor for phishing attacks. Assume the case of a user ac-

cepting notiﬁcations from a malicious web page from

his mobile browser. The web page then can push an

arbitrary notiﬁcation to the device at any given point.

Practically, in our phishing scenario, the malicious

web page pushes a notiﬁcation with the icon of an

app with millions of downloads, expecting users to

respond. The notiﬁcation redirects the user to a web-

page which replicates the UI of the targeted app re-

questing for sensitive information, e.g. credentials.

While the notiﬁcation may verbally state that the no-

tiﬁcation originates from the browser, yet the visual

identity, the displayed icon and the notiﬁcation text,

may lure many users. Under the precondition that a

web page is able to determine which applications a

user has installed in her/his device, recently published

in (Alepis and Patsakis, 2017a), a forging app notiﬁ-

cation use case could be able to appear in web push

notiﬁcations too. Both text and graphics can be easily

arbitrarily be loaded through web resources. How-

ever, the actual notiﬁcations “issuer” in these cases is

ICISSP 2018 - 4th International Conference on Information Systems Security and Privacy

always the name of the browser (e.g. Chrome), ac-

companied by the notiﬁcation’s title. In this sense, a

user may be lured and open a malicious notiﬁcation

believing that one of her/his installed mobile apps has

ﬁred it by seeing the graphic and the text involved.

However, as already mentioned, a more attentive ex-

amination by the user could reveal that the notiﬁca-

tion was ﬁred by the browser and not by the actual

installed app. Nonetheless, since a web notiﬁcation

containing information about an installed app is not

very common, users may more easily be deceived in

such a scenario.

The case of issuing a DoS attach to a device

through web push notiﬁcations has been also inves-

tigated. However, in our experiments, this kind of at-

tack was unsuccessful. The graphic is probably ﬁrstly

“rendered” by the browser to meet the proper size,

thus blocking the attack. Processing a very high deﬁ-

nition graphic by a mobile app would require process-

ing time, which could eventually lead to an Applica-

tion not Responding (ANR) situation. The browsers

in our tests seem to properly handle these situations

and result in either ﬁring the notiﬁcation with its

graphic scaled, or providing a “default”, “harmless”

icon for the notiﬁcation to be issued.

5 DISCUSSION AND

CONCLUSIONS

Due to size constraints, Android UI lacks the source

veriﬁcation of graphic components, exposing the

users to many risks. In the literature, several ap-

proaches have been proposed to counter such issues.

For instance, a third party framework named “Secure-

View” was proposed in (Xu and Zhu, 2012). Secure-

View allows the user to choose a security image as

well as writing a text-based security greeting after in-

stalling an application in her/his device. This way,

whenever a sensitive view is displayed, the applica-

tion can show the security image and greeting on the

sensitive view to provide view authentication to the

user. These kinds of countermeasures can also be

found to have drawbacks. One the one hand, using

such a framework from applications implicitly means

trusting a third party company. On the other, having

users supply both different security images and greet-

ings for a number of their installed applications might

not work for obvious reasons, including user frustra-

tion and negative user experience.

In (Bianchi et al., 2015) the researchers propose

the introduction of a visual identity to facilitate the

user identify which app he is actually interacting.

Their solution tracks the origin of the app that created

the displayed dialog and presents it in the notiﬁcation

bar. Wu et al. monitor the WindowManagerService

to determine the presence of a ﬂoating window by re-

calculating the Z-order of all windows and hooking all

the calls which are triggered when creating and click-

ing on a window (Wu et al., 2016a). This approach

may not counter UI replication attacks, but it defends

many overlay attacks. Ying et al. propose a similar

visual identity to Bianchi et al. for identifying the

source of a UI element also tweaking Window Man-

ager (Ying et al., 2016b). WindowGuard hooks the

Activity Manager, the Window Manager and Package

Manager services to monitor overlaying UI elements

and activity transition in order to detect possible at-

tacks (Ren et al., 2017).

An automated screenshot mechanism is proposed

in both (Malisa et al., 2016; Malisa et al., 2017) to

ﬁnd similarities between apps and determine whether

a UI attack is being made by an app.

Other solutions to UI attacks are presented in (Fer-

nandes et al., 2016; Marforio et al., 2016; Wu et al.,

2016b). For more on phishing attacks and counter-

measures the interested reader may refer to (Heart-

ﬁeld and Loukas, 2016; Aleroud and Zhou, 2017)

From the aforementioned defense mechanisms it

is clear that only some of the proposed mechanisms

can provide only partial measures against our attacks.

The main reason is the context awareness of our app

and the renaming of the app. In this regard, the dis-

played UI is rendered according to the targeted ap-

plications that are already installed in the device, so

screenshot mechanisms are rendered useless. A very

important aspect that needs to be taken into consid-

eration is that the paper’s described attacks are actu-

ally triggered by the user. Consequently, there are no

overlays to be detected by the system and due to the

renaming, all the appropriate visual signatures can be

easily circumvented.

Therefore, when the interaction between human

and smartphone is initiated by the user, then it is of

utmost importance to ensure that the user is actu-

ally launching the application s/he intended to launch.

While using the applications’ basic shortcuts it seems

that s/he is protected, since an application using an-

other apps graphic as a the app’s launcher icon re-

quires it being placed in the apps resources, which

consequently would give Google Bouncer the ability

to “intercede” when another apps graphic has been

detected in Google Play. Unfortunately, this is not the

case with home-screen app shortcuts. As already dis-

cussed, home-screen app shortcuts can be easily ar-

bitrarily created by other apps, producing “identical”

forged app shortcuts. In this case, the OS must pro-

vide some new rules and/or checks to overpass this

Knock-Knock: The Unbearable Lightness of Android Notiﬁcations

problem e.g. test whether a speciﬁc icon matches the

resources of another app.

In the cases where the interaction between hu-

man and smartphone is implicitly initiated by appli-

cations, the problem seems a little more complicated.

As it is already mentioned, some “ways” that evolve

in user notiﬁcation, such as activity launches, dialogs

and toasts, have clear disadvantages and are rejected

by developers in most cases. The major contribution

of this work is the investigation of the Android No-

tiﬁcations’ mechanism from its security perspective.

Generically, notiﬁcations are not tightly coupled to

their issuer, since they refer to a way of “leaving a no-

tice” for the user through the OSes features, both en-

hancing user experience and also preserving the valu-

able smartphone resources. Consequently, this notice

is left to be opened by the user end navigate her/him

to another UI to continue her/his interaction, presum-

ably a native mobile app, or even a web page. It may

be considered as “common sense” that anyone who

“picks up” a notice in either her/his mailbox or her/his

mobile navigation drawer, should be able to identify

the sender. As a result, all involved parties in software

development should work towards this direction, safe-

guarding the users, as their ultimate aim.

Having these in mind, regarding the notiﬁcations’

issues, there are several solutions that could be pro-

posed for the OS vendor. Being able to prove the no-

tiﬁcation’s issuer id, would involve an id to be passed

either to the notiﬁcations current app name, or the the

required graphic or even to both. As we have proven

both the name of the notiﬁcation and also the graph-

ics could be easily being forged. The apps’ package

name can be considered as a candidate that identi-

ﬁes each app, which also cannot exist as duplicate in

Google Play. Nevertheless, it has some drawbacks,

since while enhancing users’ security, it negatively

affects user experience. Forcing the icons/graphics

of notiﬁcations originating only from local resources

is another option, which would nevertheless require

the OS to rollback to a previous solution, with clear

negative results in the market. Other kinds of side-

countermeasures could include removing the poten-

tial from apps to being able to determine which apps

are installed in users’ devices, or making a special

check for Google Play apps who are making a change

in their app name and consequently removing them

for the automated updated app list.

The presented work has resulted in four respon-

sibly disclosed to Google security issues that are not

public yet at the time of writing. More speciﬁcally,

two issues regard the described methods in forging

app notiﬁcations in all Android versions from Marsh-

mallow to Oreo, one issue regarding forging home-

screen shortcuts, affecting all Android versions and

one issue regarding the illustrated DoS attack, affect-

ing all Android versions. The authors have followed

all the guidelines regarding the disclosure of the is-

sues, both in terms of following the security proce-

dures and also in terms of giving the company enough

time to be able to prepare patches.

ACKNOWLEDGMENTS

This work was supported by the European Commis-

sion under the Horizon 2020 Programme (H2020), as

part of the OPERANDO project (Grant Agreement

no. 653704) and is based upon work from COST

Action CRYPTACUS, supported by COST (European

Cooperation in Science and Technology). The au-

thors would like to thank ElevenPaths for their valu-

able feedback and granting them access to Tacyt.

REFERENCES

Alepis, E. and Patsakis, C. (2017a). The all seeing eye: Web

to app intercommunication for session ﬁngerprinting

in android: submission title. In The 10th International

Conference on Security, Privacy and Anonymity in

Computation, Communication and Storage (SpaCCS

2017). Springer.

Alepis, E. and Patsakis, C. (2017b). Trapped by the ui:

The android case. In Proceedings of the 20th Interna-

tional Symposium on Research in Attacks, Intrusions

and Defenses. Springer. (To appear).

Aleroud, A. and Zhou, L. (2017). Phishing environments,

techniques, and countermeasures: a survey. Comput-

ers & Security.

Android Developer. Manifest.permission – SYS-

TEM ALERT WINDOW. https://developer.android.

com/reference/android/Manifest.permission.html#

SYSTEM ALERT WINDOW. Date retrieved:

28/03/2017.

Bianchi, A., Corbetta, J., Invernizzi, L., Fratantonio, Y.,

Kruegel, C., and Vigna, G. (2015). What the app is

that? deception and countermeasures in the android

user interface. In Security and Privacy (SP), 2015

IEEE Symposium on, pages 931–948. IEEE.

Biznessapps. What is a push notiﬁcation? and why should

you care? https://www.biznessapps.com/blog/what-

is-a-push-notiﬁcation/. Accessed on 27/07/2017.

Caitlin O’Connell. 2015: The year that push notiﬁca-

tions grew up. http://info.localytics.com/blog/2015-

the-year-that-push-notiﬁcations-grew-up. Accessed

on 01/09/2017.

Chen, Q. A., Qian, Z., and Mao, Z. M. (2014). Peeking into

your app without actually seeing it: Ui state inference

and novel android attacks. In USENIX Security Sym-

posium, pages 1037–1052.

ICISSP 2018 - 4th International Conference on Information Systems Security and Privacy

Chin, E., Felt, A. P., Greenwood, K., and Wagner, D.

(2011). Analyzing inter-application communication in

android. In Proceedings of the 9th international con-

ference on Mobile systems, applications, and services,

pages 239–252. ACM.

Felt, A. P. and Wagner, D. (2011). Phishing on mobile de-

vices. In Proceedings of the Web 2.0 Security and Pri-

vacy 2011 Workshop.

Fernandes, E., Chen, Q. A., Paupore, J., Essl, G., Halder-

man, J. A., Mao, Z. M., and Prakash, A. (2016). An-

droid ui deception revisited: Attacks and defenses. In

International Conference on Financial Cryptography

and Data Security, pages 41–59. Springer.

Flurry Analytics. U.s. consumers time-

spent on mobile crosses 5 hours a day.

http://ﬂurrymobile.tumblr.com/post/157921590345/us-

consumers-time-spent-on-mobile-crosses-5. Ac-

cessed on 01/09/2017.

Fratantonio, Y., Qian, C., Chung, S., and Lee, W. (2017).

Cloak and Dagger: From Two Permissions to Com-

plete Control of the UI Feedback Loop. In Proceed-

ings of the IEEE Symposium on Security and Privacy

(Oakland), San Jose, CA.

Heartﬁeld, R. and Loukas, G. (2016). A taxonomy of at-

tacks and a survey of defence mechanisms for seman-

tic social engineering attacks. ACM Computing Sur-

veys (CSUR), 48(3):37.

Malisa, L., Kostiainen, K., and Capkun, S. (2017). Detect-

ing mobile application spooﬁng attacks by leveraging

user visual similarity perception. In Proceedings of

the Seventh ACM on Conference on Data and Appli-

cation Security and Privacy, pages 289–300. ACM.

Malisa, L., Kostiainen, K., Och, M., and Capkun, S. (2016).

Mobile application impersonation detection using dy-

namic user interface extraction. In European Sympo-

sium on Research in Computer Security, pages 217–

237. Springer.

Marforio, C., Jayaram Masti, R., Soriente, C., Kostiainen,

K., and

Capkun, S. (2016). Evaluation of personalized

security indicators as an anti-phishing mechanism for

smartphone applications. In Proceedings of the 2016

CHI Conference on Human Factors in Computing Sys-

tems, pages 540–551. ACM.

Niemietz, M. and Schwenk, J. (2012). Ui redressing attacks

on android devices. Black Hat Abu Dhabi.

Pielot, M., Church, K., and de Oliveira, R. (2014). An in-

situ study of mobile phone notiﬁcations. In Proceed-

ings of the 16th International Conference on Human-

computer Interaction with Mobile Devices & Ser-

vices, MobileHCI ’14, pages 233–242, New York, NY,

USA. ACM.

Ren, C., Liu, P., and Zhu, S. (2017). Windowguard: Sys-

tematic protection of gui security in android. In Net-

work and Distributed System Security Symposium.

StatCounter GlobalStats. Mobile and tablet internet

usage exceeds desktop for ﬁrst time worldwide.

http://gs.statcounter.com/press/mobile-and-tablet-

internet-usage-exceeds-desktop-for-ﬁrst-time-

worldwide. Accessed on 01/09/2017.

Urban Airship. New urban airship study re-

veals app publishers that dont message users

waste 95 percent of their acquisition spend.

https://www.urbanairship.com/company/press-

releases/new-urban-airship-mobile-app-retention-

study. Accessed on 01/09/2017.

Virvilis, N., Tsalis, N., Mylonas, A., and Gritzalis, D.

(2014). Mobile devices: A phisher’s paradise. In Se-

curity and Cryptography (SECRYPT), 2014 11th In-

ternational Conference on, pages 1–9. IEEE.

Wei, F., Li, Y., Roy, S., Ou, X., and Zhou, W. (2017).

Deep ground truth analysis of current android mal-

ware. In International Conference on Detection of In-

trusions and Malware, and Vulnerability Assessment,

pages 252–276. Springer.

Wu, L., Brandt, B., Du, X., and Ji, B. (2016a). Analysis of

clickjacking attacks and an effective defense scheme

for android devices. In Communications and Network

Security (CNS), 2016 IEEE Conference on, pages 55–

63. IEEE.

Wu, L., Du, X., and Wu, J. (2016b). Effective defense

schemes for phishing attacks on mobile computing

platforms. IEEE Transactions on Vehicular Technol-

ogy, 65(8):6678–6691.

Xu, Z. and Zhu, S. (2012). Abusing notiﬁcation services

on smartphones for phishing and spamming. In Pro-

ceedings of the 6th USENIX conference on Offensive

Technologies, pages 1–1. USENIX Association.

Ying, L., Cheng, Y., Lu, Y., Gu, Y., Su, P., and Feng, D.

(2016a). Attacks and defence on android free ﬂoating

windows. In Proceedings of the 11th ACM on Asia

Conference on Computer and Communications Secu-

rity, ASIA CCS ’16, pages 759–770, New York, NY,

USA. ACM.

Ying, L., Cheng, Y., Lu, Y., Gu, Y., Su, P., and Feng, D.

(2016b). Attacks and defence on android free ﬂoating

windows. In Proceedings of the 11th ACM on Asia

Conference on Computer and Communications Secu-

rity, pages 759–770. ACM.

ZDNet. Whatsapp: Now one billion peo-

ple send 55 billion messages per day.

http://www.zdnet.com/article/whatsapp-now-one-

billion-people-send-55-billion-messages-per-day/.

Accessed on 27/07/2017.

Knock-Knock: The Unbearable Lightness of Android Notiﬁcations