Phishing on Mobile Devices

Adrienne Porter Felt∗

University of California, Berkeleyapf@cs.berkeley.edu

David WagnerUniversity of California, Berkeley

daw@cs.berkeley.edu

ABSTRACTWe assess the risk of phishing on mobile platforms. Mobileoperating systems and browsers lack secure application iden-tity indicators, so the user cannot always identify whether alink has taken her to the expected application. We conducta systematic analysis of ways in which mobile applicationsand web sites link to each other. To evaluate the risk, westudy 85 web sites and 100 mobile applications and discoverthat web sites and applications regularly ask users to typetheir passwords into contexts that are vulnerable to spoof-ing. Our implementation of sample phishing attacks on theAndroid and iOS platforms demonstrates that attackers canspoof legitimate applications with high accuracy, suggest-ing that the risk of phishing attacks on mobile platforms isgreater than has previously been appreciated.

1. INTRODUCTIONUser interfaces for mobile devices are constrained by the

devices’ small screens. In particular, mobile operating sys-tems and browsers lack secure application identity indica-tors. A user cannot definitively tell what mobile applicationor web site she is interacting with. This exposes users to therisk of mistaking a malicious application for a trusted one.

Mobile applications and web sites often link to each otherto share data or refer the user to a related service. Forexample, a music-themed web site might link the user tothe iTunes application to buy a song. In a normal inter-application link, the sender application links to a secondtarget application. After following the link, the user mightprovide the target application with authentication creden-tials or payment information.

In this paper, we discuss phishing attacks that imitatenormal inter-application links. The lack of secure identityindicators means that an inter-application link could be sub-verted, and the user would be unable to tell that she hadbeen sent to the wrong target. In a direct phishing attack,the sender is a malicious application that links the user toits own spoof screen instead of the real target application.In a man-in-the-middle attack, the sender is benign, butanother party intercepts the link and loads a spoofed targetapplication in place of the intended target application.

∗This material is based upon work supported under a Na-tional Science Foundation Graduate Research Fellowship.Any opinions, findings, conclusions or recommendations ex-pressed in this publication are those of the author(s) anddo not necessarily reflect the views of the National ScienceFoundation.

Phishing attacks exist because users become accustomedto entering their passwords in familiar, repeated settings.If users frequently encounter legitimate links whose targetsprompt them for private data, then users will become con-ditioned to reflexively supply the requested data [9]. 40%of smartphone users enter passwords into their phones atleast once a day [8]. We study 50 Android applications, 50iOS applications, and 85 web sites to evaluate how oftenthey link users to password-protected or payment-relatedapplications. We find that web sites and mobile applica-tions commonly link the user to password-protected socialnetwork and payment applications, thus conditioning usersto reflexively enter their credentials after following links.

Based on this analysis of common behavior, we identify anumber of new phishing attacks against mobile platforms.We demonstrate that, on Android and iOS, it is possible tobuild phishing attacks that convincingly mimic the types ofinter-application links that our study found to be common.We categorize the attacks according to whether the senderand target are mobile applications or web sites: mobile-to-mobile, mobile-to-web, web-to-mobile, and web-to-web. Foreach of the four categories, we present both direct and man-in-the-middle attacks.

The contributions of this paper are:

• We believe we are the first to discuss phishing attacksbetween mobile applications and web sites.

• We present data on how mobile applications and websites interact. This provides insight into the applica-tion behaviors that users are familiar with.

• We present and evaluate 15 types of phishing attacks.13 of the attacks are novel, and 1 improves a knownmobile browser spoofing technique.

2. BACKGROUNDWe focus on Android and iOS, the two most popular mod-

ern smartphone operating systems [3]. Our phishing con-cerns also apply to other smartphone platforms with user in-terface space constraints and inter-application control trans-fers, such as Windows Phone 7.

2.1 User Interfaces on Mobile DevicesSmartphone operating systems and browsers have mini-

malist user interfaces to accommodate the small size of mo-bile devices. In particular, their user interfaces lack ap-plication identity indicators that are available in desktopoperating systems and browsers.

Mobile Application Identity. Only one mobile applica-tion can control the screen at a time, even in platforms thatsupport multi-tasking. The foreground application fills thescreen and receives all user input, with the exceptions ofinput-method applications (e.g., alternate keyboards) andthe Apple App Store (which uses pop-up dialogs for in-application purchases). No major smartphone operatingsystem displays the identity of the foreground application.Users can find a list of running processes, but no part of thescreen identifies the current foreground application.

Web Site Identity. Mobile browsers display only onebrowser window at a time. The Android and iOS browsersdisplay the URL of the current window at the top of thescreen, similar to desktop browsers. However, web sites canhide the URL bar once the page has loaded; this commonlyused feature allows the web site to fill the available screen.(For example, Figure 2a shows weather.com in mobile Sa-fari without the URL bar.) If a user wants to see the URLbar, she can tap the top of the screen.

2.2 Platform SecurityMobile applications are less trusted than their desktop

counterparts. In Android and iOS, applications are isolatedfrom each other by default; for example, applications cannotread each other’s databases or network traffic. Additionally,Google and Apple attempt to prevent users from installingmalware by controlling how users install applications.

Android applications are restricted with an applicationpermission system. Permissions control access to privacy-and security-relevant parts of the system API, such as theability to read a user’s contacts or send a text message.When a user installs an application, the application’s de-sired permissions are displayed to the user. The user canthen decide whether to grant all of the permissions and con-tinue with the installation. This informs users of the risksof installing an application.

Users of iOS devices can only install applications fromthe App Store. In order to be listed in the App Store, ap-plications must undergo a formal review process. Althoughspecific details of the App Store review process are secret,the process likely includes a security review.

Web sites in mobile browsers are also treated as poten-tially untrustworthy. They must obey the standard SameOrigin Policy [15], meaning that web sites on different do-mains are isolated from each other. Neither Android norApple review or restrict access to mobile web sites.

2.3 Control TransfersA control transfer occurs when the foreground application

or web site changes. As a result of a control transfer, theuser stops interacting with one application and begins inter-acting with another. Although mobile applications and websites are isolated, inter-application communication via ex-plicit channels can lead to control transfers. Control trans-fers can happen in four ways, classified according to whetherthe sender and target are mobile applications or web sites:

• Mobile Sender ⇒ Mobile Target. Android and iOS ap-plications can optionally choose to accept communica-tion from other applications by registering a receiverwith the operating system. In response to a message,the OS transfers control to the target application.

• Mobile Sender ⇒ Web Target. A mobile applicationcan send the user to a web site by invoking the phone’snative browser with the target URL. The browser willcome to the foreground with the target web site.

Alternately, a mobile application can embed web con-tent. As a result, the web content is rendered aspart of the mobile application’s screen. For example,Figure 1b shows Groupon embedding a Twitter loginpage. Embedding can be done by communicating di-rectly with a web site’s data API or by asking theOS to load a web site in a WebView. A WebView issimilar to an iframe: the embedding application cancontrol the size and placement of it within the screen,and browser chrome is not displayed (including the ad-dress bar). Mobile applications can additionally insertarbitrary JavaScript into a WebView. The two types ofembedded web content are difficult to visually differen-tiate. For both, the mobile application retains controlof user input and the screen while the user interactswith the embedded web content.

• Web Sender⇒ Mobile Target. A web site can send theuser to a mobile application if the mobile applicationregisters a data scheme with the OS. A data schemeis a non-standard URL protocol. For example, themobile Skype application registers the skype scheme.Thereafter, clicking on a skype:// link in any website will send the user into the Skype application if itis installed. While this example involves explicit useraction, user involvement is not necessary for such atransfer; a web site can automatically launch an appli-cation by embedding an iframe with the appropriatescheme. (The target application will take full controlof the UI, despite the use of an iframe.)

Applications can also register for HTTP(S) domains.For example, the mobile Google Maps application reg-isters maps.google.com. When a web site links to anapplication-registered domain in Android, the user isasked to choose between the browser and the alternateapplication. After choosing the first time for a domain,the user can set a default application. In iOS, only asmall number of Apple-approved applications (like theApp Store and YouTube) can register themselves forHTTP(S) domains, and the registered applications al-ways override the browser and receive control.

• Web Sender⇒Web Target. Web-to-web control trans-fers are standard links. As on the desktop, web sitescan link to each other, automatically redirect, and em-bed each other in iframes. The primary difference ina mobile setting is that either the target or sender canhide the URL bar.

A developer may not be responsible for a link, e.g., a linkin an e-mail. We focus on control transfers that developershave intentionally inserted into their applications.

Mobile applications (with the exception of financial ap-plications) commonly store their users’ passwords so thatusers won’t need to re-enter them. However, users mustenter their passwords into the web versions of these appli-cations, either in the browser or as embedded web content.Thus, users are still conditioned to enter passwords whenthey see an appropriate login screen for a mobile target.

(a) Pandora’s song descriptionscreen includes this menu.One button opens iTunes tothe song, and another opensthe Mail application with apre-composed e-mail. If theuser decides to purchase thesong, she will be asked forher iTunes password.

(b) Groupon invites users toshare daily deals withfriends. The Twitter but-ton takes the user to thisscreen, which is still part ofGroupon. Groupon createdthe top “Twitter Connect”bar, and the Twitter loginis embedded below.

Figure 1: Screenshots of Pandora and Groupon on iOS.

3. COMMON CONTROL TRANSFERSAs users interact with legitimate applications, they be-

come conditioned to enter their passwords and payment in-formation in certain types of settings [9]. Phishing attacksprey on user expectations by mimicking and then subvertinglegitimate application behavior. We study popular Android,iOS, and web applications to identify how often and whencontrol transfers lead to password or payment entry. Ask-ing a user to enter a password after a control transfer raisesphishing concerns because the user may not know the cor-rect identity of the post-transfer application.

3.1 Mobile SenderWe studied the control transfer patterns of the 50 most

popular free Android 2.21 and iOS 4.32 applications. Wemanually exercised each application and recorded whetherit sends the user to other mobile applications, opens websites in the browser, or embeds web content. Manual testingprovides a lower bound on the number of control transfers.We also observed whether each control transfer involves theentry of information pertaining to:

• Passwords. Is the target application’s content onlyvisible to logged-in users? (For example, a user mustlog in to Facebook to post to her Facebook “wall”.) Ifso, this indicates that the user will not be surprised ifthe target application requests a password.

• Payment. Does the sender link to the target for theexplicit purpose of payment? (For example, Amazonsells books and music.) If so, the user is prepared toenter payment information into the target application.

We found that 89 of the 100 mobile applications containlinks that send the user to another application or web site.

1The Android applications were collected in October 2010.2The iOS applications were collected in March 2011. Wetested iPhone/iPod Touch applications.

Mobile Sender, Mobile Target

Mobile Target Android iOSAnother mobile application 56% 72%A password-protected application 36% 60%An application for payment 10% 34%

Table 1: The rate at which 50 Android and 50 iOS applicationslink the user to another mobile application. Targets may be bothpassword-protected and payment-related. We do not include thebrowser as a target mobile application; the browser is consideredseparately in Table 2.

3.1.1 Mobile Sender ⇒ Mobile TargetTable 1 summarizes the results of our mobile-to-mobile

study. A majority of the studied mobile applications con-tain functionality that will send the user to other mobileapplications. Figure 1a provides an example of a mobile-to-mobile control transfer. We observed four common types ofcontrol transfers that involve passwords or payment: socialsharing and the purchase of upgrades, music, and credits.

Sharing. Some applications encourage users to share con-tent (e.g., high scores) with their Facebook, Twitter, or e-mail contacts. This involves transferring the user to a Face-book, Twitter, or e-mail application. These target applica-tions are password-protected.

Upgrades. Developers sometimes publish two versions ofan application: a free version with limited functionality orbanner advertisements, and a paid version with full func-tionality or no advertisements. The free versions of theseapplications link to the Android Market or Apple App Storeto “Upgrade” or “Remove ads.” In order to complete theupgrade, the user may need to enter password or payment in-formation into the store. The Android Market asks the userfor payment information for paid upgrades, and the AppleApp Store prompts the user for a password for both freeand paid downloads. The Apple App Store also frequentlyasks the user to verify stored payment information. Con-sequently, users will likely be accustomed to entering theirpassword after control transfers to an application store.

All of the applications in our sample set were free at thetime of download; users of paid applications will see fewerpayment links than our results suggest. However, the mostpopular free applications are downloaded orders of magni-tude more often than the most popular paid applications.

Music. Music-centric applications typically contain linksto purchase songs. In iOS, these links point to the AppleiTunes Store. For Android, some devices come with a pre-installed Amazon MP3 application for this purpose. Bothtarget applications may require passwords or payment.

Credits. Our sample of popular iOS applications includes34 games, many of which sell game credits through the Ap-ple Game Center or App Store. Game credits are requiredto progress through the games. The Game Center and AppStore both immediately request a password to complete thesale. Periodically, they will also ask the user to verify herpayment information. We did not observe the sale of gamecredits in our sample of Android applications. However,our sample includes only 1 game, so our analysis may un-dercount the rate at which game applications can transfercontrol to a payment application.

Mobile Sender, Web Target

Embedded Web Target Android iOSAnother company’s website 16% 46%A password-protected web site 8% 38%A web site for payment 2% 0%

Web Browser Target Android iOSA web site 30% 18%A password-protected web site 3% 4%A web site for payment 2% 0%

Table 2: The rates at which 50 Android and 50 iOS applicationsembed web sites or open web sites in the browser. Targets may beboth password-protected and payment-related. We suspect thatAndroid web payment rates are low because of biases introducedby sampling only the most popular applications.

Our study demonstrates that users of mobile applicationsare accustomed to seeing links to other mobile applicationsfor social sharing, upgrades, music, and credits. Links to e-mail, Facebook, Twitter, and the platform stores are partic-ularly prevalent. Users are conditioned to enter their pass-words for these operations. Phishing attacks could thereforemimic these control transfers and prompt for a passwordwithout deviating from user expectations.

3.1.2 Mobile Sender ⇒ Web TargetMobile applications can display web content by sending

the user to the browser or embedding the content. Table 2summarizes how often the sampled applications use eitherapproach, and Figure 1b displays an example from our sam-ple set. For embedded web content, we only report the in-clusion of web content from other companies; many mobileapplications seamlessly embed their own web content, butthat practice is not relevant to phishing.

Passwords. Social sharing accounts for nearly all of thelinks from mobile applications to password-protected websites. For iOS applications, social sharing is primarily im-plemented with embedded web content. Within our Androidsample set, applications do not commonly link to password-protected web sites. Instead, they prefer to implement socialsharing with links to mobile applications. This is becausemany Android devices come with pre-installed Facebook andTwitter mobile application clients.

Payment. Within our sample set, web sites are not com-monly used for payment. The iOS applications rely onApple-provided applications (e.g., iTunes and the App Store)to handle financial transactions; this obviates the need forweb-based payments. Two Android applications refer usersto web sites for purchases, but most of the Android appli-cations that we studied either process their own paymentswithin the application or rely on the Android Market. Wesuspect that this is an artifact of popularity; many of thevery most popular Android applications are developed bylarge companies with their own payment processing services.We have independently observed other, less popular Androidapplications using PayPal for donations and non-Market up-grades. For example, PayPal’s web site showcases severalPayPal-enabled applications with a few hundred to a fewhundred thousand users [11]. If our sample had included lesspopular applications, we expect we would have observed ahigher rate of web payments among Android applications.

(a) The Weather Channel linksthe user to the App Store.

(b) Craigslist links the user toYouTube for Craigslist TV.

Figure 2: Web sites with links to mobile applications, in iOS.

Our analysis indicates that users who participate in so-cial sharing are at a high risk for falling for a phishing at-tack. 38% of the sample iOS applications embed password-protected web content, and all of them do so for social shar-ing. Furthermore, a user must log in to a web site everytime she encounters it in a new application because there isno cross-application cookie store for embedded web content.This means that social users may enter their social network-ing site passwords into more than a third of the applicationsthey install, thereby acclimating them to this workflow.

On the other hand, we find that popular mobile applica-tions do not commonly link users to web sites for payment.This reduces the likelihood that people are conditioned toenter their passwords or payment information into a phish-ing application that subverts the web-to-mobile scenario.

3.2 Web SenderWe studied 85 of the 100 most popular Alexa-ranked do-

mains3 to evaluate web site link behavior. For each domain,we collected the links on the home page and one representa-tive page of content, as linked off the home page. We usediPhone and Nexus One browser user-agent strings to receivethe appropriate mobile versions of the web sites.

In order to collect the links, we built a Firefox extensionto crawl each loaded page and find link target values. Someweb sites use JavaScript to create links in a non-standardway; as a heuristic for finding these cases, the extension alsocollected onclick values for div, span, and img elements.We then reviewed the onclick JavaScript to find links, butwe did not follow method calls referenced in the onclick

event handler. We may have missed complex onclick linksor links that are dynamically generated after load.

3.2.1 Web Sender ⇒ Mobile TargetA link to a mobile application could fail, if the appli-

cation is not installed. However, certain applications areguaranteed to be present on every platform. iOS and An-droid phones have common applications like Google Maps,YouTube, and an e-mail client. Each operating system alsohas its own applications (for example, iOS includes the iTunes

3We omitted adult and advertising web sites from the list of100. Advertising home pages do not reflect the content thatusers typically see from that domain.

Web Sender, Mobile Target

Core Application Target Android iOSA core mobile application 38% 47%A password-protected application 22% 41%An application for payment 6% 25%

Total Application Target Android iOSA mobile application 49% 48%A password-protected application 38% 42%An application for payment 6% 25%

Table 3: The rates at which 85 web sites include links to mo-bile applications. The top counts only links to core applications(which are present on every phone). The bottom counts all linksto any application, core or not. Targets may be categorized asboth password-protected and payment-related.

store). We refer to these applications as core applications.Links to core applications are guaranteed to succeed.

Table 3 presents the rates at which web sites link to thecore applications. The Android and iOS rates differ partlybecause of differences in their sets of core applications. Ta-ble 3 also provides the total link rate, which includes links toboth core and non-core applications. The total link rate in-cludes application-defined schemes (like hulu). For Androidwe also count links to http(s) domains that have been reg-istered by the 100 most popular Android applications.

Passwords. Web sites link to mobile applications for thesame reasons as mobile applications link to other mobile ap-plications. Many web sites contain mailto or twitter.com

links to share content with friends; mailto links open themobile e-mail client (a core application), and the twitter.comdomain is registered by a popular and often pre-installed An-droid application. mailto links are also sometimes used tocontact the web site staff.

Payment. Some web sites link to the Apple App Store orAndroid Market to let the user download their application orbuy related items. (In fact, some web sites such as Hulu arenot fully functional on mobile browsers, so the user mustinstall the application to use the service.) The user mayneed to enter his or her account password or verify paymentinformation to install the given application.

Our web analysis shows that web sites commonly link tomobile e-mail and Twitter applications. Twitter, in partic-ular, is an attractive phishing target. We also found thatweb sites often link users to the Apple App Store or An-droid Market to install the company’s mobile application,which indicates that the web-to-mobile installation processcould become a target for phishing attacks.

3.2.2 Web Sender ⇒ Web TargetWeb-to-web links are a standard part of the Internet. All

but one of the web sites we crawled contain multiple links toexternal domains. Although we did not measure their usein our data set, external payment services like PayPal andGoogle Checkout are widely incorporated into web sites.

4. PHISHING ATTACKSWe discuss how phishing attacks can be mounted against

each of the four control transfer scenarios enumerated inSection 2.3. For each scenario, we present two types of at-tacks: direct attacks and man-in-the-middle attacks. In adirect attack, the sender application is malicious and loads

a fraudulent target application. In a man-in-the-middle at-tack, the sender and target applications are both benign,but a malicious party intercepts the control transfer andresponds in place of the legitimate target.

The goal of our attacker is to mimic the legitimate appli-cation behavior that we identified in the application survey(Section 3). An accurate attack should not deviate fromthe user’s expected workflow, and the fake user interfaceshould be indistinguishable from the target user interface.The user should have few or no opportunities to differentiatethe phishing attack from legitimate behavior. We evaluatehow well each attack meets these accuracy goals.

4.1 Mobile Sender ⇒ Mobile TargetIn this scenario, the user believes that one mobile appli-

cation links to another, trusted application. In addition tomimicking a normal workflow and user interface, maliciousmobile applications must face the Android permission modeland Apple review process.

4.1.1 Direct AttackAs presented in Section 3.1.1, mobile applications com-

monly include social sharing and payment buttons. A ma-licious application could similarly include “Share on Face-book” or “Upgrade this application” buttons. Clicking onone of the buttons would send the user to a screen thatspoofs the target application. The phishing screen could re-quest the user’s password or payment credentials, enablingthe malicious application to steal the data. The phishingapplication would then load the real application. If the userdoes not have an existing session with the real application,then the real application will ask the user to enter her pass-word. This resembles normal application behavior after afailed login attempt, so the user might naturally assumethat she had mistyped her password.

Evaluation. Mobile login screens are often very simple, whichmakes them easy to copy. Figure 3 shows a fake Facebooklogin screen, which we constructed in several hours using im-ages and layout values copied from a disassembled versionof the legitimate Android Facebook application. It is highlyunlikely that any user could differentiate between the realFacebook login screen and our fake Facebook login screen.

Android’s permission system would do little to warn usersof this attack; the attack requires no permissions, whichmight give users a false sense of security. At most, the mali-cious application might request the INTERNET permission tosend the stolen data to the attacker. The permission requestwould not be anomalous: 87% of free applications requestInternet access [6]. However, the INTERNET permission is notrequired because the Android API provides several ways tosubmit web requests and exfiltrate captured data withoutthe INTERNET permission. For example, a MediaPlayer ob-ject can be created to load an arbitrary HTTP URL [2].

The Apple application review process might prevent thisattack from appearing in the App Store if reviewers detectthe fraudulent screen. However, the review process is notperfect [14] and there is no guarantee that reviewers woulddetect such an attack. More dangerously, the attacker coulduse web content to evade detection during review. Thefraudulent screen would be constructed with an embeddedweb site that is the full size of the screen, served by the at-tacker. (Recall that embedded web sites do not have browserchrome.) During the application review, the web site could

(a) Real Facebook login. (b) Fake Facebook login.

Figure 3: Our Facebook phishing application for Android. Whena user enters her password, the credentials are captured beforeinvoking the real Facebook application. The other buttons (e.g.,“Sign up”) lead directly to the Facebook’s corresponding page.

immediately redirect the user to the legitimate applicationwith no signs of any malice. Once the application has beenadded to the store, or at any subsequent date of the at-tacker’s choice, the attacker could change the web site to afraudulent copy of the target. As discussed further in Sec-tion 4.3.1, web content can be styled to mimic the look andfeel of an application. Alternately, the attacker could tryto evade detection by targeting only a subset of the userpopulation or not serving the attack to users in a certaingeographic region (e.g., Apple’s headquarters in Cupertino).

4.1.2 Man-In-The-MiddleMan-in-the-middle attacks can be launched on mobile ap-

plications in two ways. The first attack, scheme squatting,is weak because it changes the user’s workflow and cannotbe hidden from application reviewers. Task interception is astrong attack, but it can only be implemented on Android.

Scheme Squatting. Some applications register to handleschemes. If the the real application for a scheme is not in-stalled, a malicious application could register for the schemeinstead. Messages intended for the target would instead bedelivered to the attacker, and the attacker could present theuser with a phishing screen upon launching. Scheme squat-ting is a form of an attack named “Activity hijacking” [4].

Evaluation. One strength of this attack is that it does notrequire any Android permissions. However, it suffers fromthree weaknesses. First, to evade detection, the applica-tion would need to emulate the intended target after thelogin screen completes. Otherwise, the user’s expected op-eration would abruptly halt, raising suspicion. Emulationmay be implausible, and this problem is intrinsic to the at-tack. Second, the real application might be installed. If so,iOS and Android would give the user a choice between thereal application or the phishing application. Consequently,the phishing application would need to convince the userto prefer it to the real application, which would likely fail.Third, it would not be possible to hide this behavior from

reviewers because applications must declare their schemesupfront in a file that is bundled with the application.

Task Interception. If an OS lets applications view thelist of running processes, then a malicious application couldpoll the task list and wait for a target application to be-come active. The attacker could then launch itself and dis-play a phishing screen when it is brought to the foreground.When the user enters credentials into the phishing screen,the fraudulent application can exit, leaving the original tar-get application visible. We implemented this attack for An-droid and found that the application needs to poll the run-ning task list every 5ms to prevent the user from noticingthat a new screen replaces the original target. At 5ms orbelow, the transition is not detectable to the naked eye.

Evaluation. Task interception is a very effective attack forAndroid. The attack requires two permissions: one to startthe application in the background after the phone has booted,and another to request the task list. However, both permis-sions are considered non-dangerous, and neither is displayedto the user during installation. We are not aware of a wayto launch this attack on iOS because applications are notallowed to view the task list.

4.2 Mobile Sender ⇒ Web TargetIn this scenario, the user believes that a mobile application

is displaying or linking to a trusted web site.

4.2.1 Direct AttackA malicious application could present the user with but-

tons to share content or purchase an item. The attacker canthen eavesdrop on the user’s interaction with an embeddedweb site or present the user with a site in a fake browser.

Embedded Web Content. Many iOS applications embedpages from password-protected sites, such as Facebook andTwitter, into their screens. This trains users to type theirpassword wherever they see a password prompt, despite thelack of security indicators. The risk is obvious: a maliciousapplication can embed a web site and then eavesdrop onany exchanged credentials. Both Android and iOS allowapplications to insert JavaScript into embedded WebViews,and there is no mechanism for web sites to prevent this.

Evaluation. This attack is close to indistinguishable fromlegitimate behavior. The inserted JavaScript could be ob-fuscated to thwart application analysis. The Android ver-sion of this attack would require the INTERNET permissionto load the target, but so would the legitimate version.

Web Browser. If the target web site hides its URL bar,then the mobile application could load a phishing web site inthe browser. The phishing web site would then hide the URLbar. Many password-protected web sites (such as Bank ofAmerica, Amazon, and Facebook) hide their URL bars [10].

If the target web site does not hide its URL bar, thenthe attacker can spoof the trusted browser chrome. Thereare two ways to do this. First, the attacker could launchthe browser, hide the URL bar, and then present a fakeURL bar. We discuss how to build spoofed URL bars inSection 4.4.1. Alternately, the attacker could display a fakebrowser that looks identical to the real browser, except it liesabout the current URL. Unlike their desktop counterparts,mobile browser interfaces are not customizable; this makesthem easier to falsify. The fake browser could load the real

(a) Real browser. (b) Our fake browser.

Figure 4: Our fake Android browser for a Nexus One phone. Itdisplays the legitimate GMail website.

web site in a WebView and listen to the user’s keystrokes.If the user were to try to use features of the browser thatthe fake browser can’t implement (e.g., history), then theattacker needs to end the attack and launch the real browser.We implemented this for Android (see Figure 4).

Evaluation. The first attack is extremely simple and couldbe effective with users who do not check browser chrome forsecurity indicators. It does not require any notable Androidpermissions, and the target web site could be benign until af-ter Apple’s review process. A security-conscious user coulddetect the ongoing attack by deciding to check the URL bar,although a user study shows that users do not do this inpractice [10]. The second attack is more complete, althoughthe user might notice that the bookmarks button next tothe URL bar is not functional. Niu et al. previously demon-strated that spoofed URL bars can be convincing enough totrick security experts [10]. The third attack would likely foolusers despite some shortcomings. Real browsers have dataand functionality that a fake browser cannot replicate (e.g.,history). For example, the Nexus One browser has 14 menuitems, 3 of which our fake browser cannot handle smoothly.However, it is unlikely that a user would press these buttonsbefore entering her password.

4.2.2 Man-In-The-MiddleWhen users of mobile devices connect to the Internet

over insecure WiFi hotspots, they are at risk of man-in-the-middle attacks. For instance, in one well-known activeattack [12], if a user navigates to an HTTP web site with anHTTPS login form, then the network attacker can changethe HTTP web content so that the login form submits thepassword to the attacker’s server. Security-conscious websites defend against this attack by not including login formsin HTTP pages. Instead, the user must click on a link to goto a separate, all-HTTPS login page. If the attacker redi-rects the user to a login page on a different domain, the userhas the opportunity to notice that the login page in the URLbar is from the wrong domain. This defense against networkattacks relies on the presence of a trusted URL bar, whichmay not be present on a phone.

Embedded Web Content. Consider a legitimate mobileapplication that embeds a web page served over HTTP. Anetwork attacker could change the “login” button on thispage so that it links to a page owned by the attacker. Whenthe user clicks this button, she will be taken to a phishingpage within the embedded web frame. Since there is no URLbar for embedded content, there is no way for the user todetect that she has left the original web site. The attackercan thus steal the user’s credentials. To better mimic theuser’s expected workflow, the attacker could then relay thecredentials to the valid web site and sign the user in.

Evaluation. This attack is not detectable by the user. Ofour 100 sampled applications, 4 applications embed HTTPcontent with login links.

Web Browser. A similar attack is possible when a legit-imate mobile application links the user to an HTTP webpage that will be rendered in the browser. Normally, whennot under attack, a browser would display a URL bar thatindicates what site the user is currently browsing. However,this does not pose a barrier to the attack because mobilebrowser chrome can be hidden and spoofed. (Section 4.4.1describes how to spoof mobile browser chrome.)

Evaluation. This attack tricks the user with a spoofed URLbar, which can be made almost indistinguishable from realbrowser chrome. Of our 100 sampled applications, 7 link toHTTP content with login links in the browser. For example,the popular Android application Shazam links to songs onhttp://www.amazon.com for the user to purchase them.

Applications can prevent these attacks by only sendingusers to HTTPS web pages, and never to a HTTP web page.The site must support HTTPS for all of its pages.

4.3 Web Sender ⇒ Mobile TargetIn this scenario, the user interacts with a web site in the

browser. The web site links to a trusted mobile application.

4.3.1 Direct AttackWeb sites often link the user to mobile applications, as

discussed in Section 3.2.1. Malicious web sites could mimicthis behavior without appearing suspicious. For example, aphishing site might provide a link to buy a song from theiTunes Store. When the user clicks on the button, the website can pretend to transfer the user to the target applica-tion, but actually display a fake version of the target appli-cation. The malicious web site must hide the URL bar andstyle the web site to respond to user touch in the same way asthe mobile application. For example, in Android, form fieldsshould have rounded edges and turn orange when selected.Title text and dialog boxes need subtle drop shadows, andthe browser’s zoom feature should be disabled unless theapplication also supports zooming.

Evaluation. As we demonstrate in Figure 5, it is possible tobuild a web site that looks very similar to a mobile applica-tion. However, the degree to which a web site can emulatean application differs by platform. In iOS, the mobile Safaribrowser places a navigation bar on the bottom of the screen.This makes it impossible for a normal web site to occupy theentire screen. However, users can “install” web sites to theirhome page (i.e., add an icon that launches the browser tothat page). Installed web sites can remove the navigationbutton to mount an attack that would be close to unde-

(a) Real application. (b) Web site in the browser,spoofing the application.

Figure 5: Our web site spoofs the Amazon MP3 Store (an Androidapplication). The browser is the default Nexus One browser.

tectable. However, it may not be feasible for an attacker toconvince a user to install a web site.

In Android, one unavoidable difference is how the spoofedweb application responds to the physical Menu button onthe phone. A web site cannot change the options that thebrowser presents, and the browser will have different Menuoptions than the target application. However, few users willtry to use the Menu when presented with a login screenthat does not allow any other actions. The user will likelybe focused on the task of logging in.

4.3.2 Man-In-The-MiddleWeb-to-mobile links are vulnerable to the same man-in-

the-middle attacks as mobile-to-mobile links (Section 4.1.2),with the same strengths and weaknesses. A malicious mobileapplication can scheme squat or watch the task list for thestart of a target application.

4.4 Web Sender ⇒ Web TargetIn this scenario, the user interacts with a web site in the

browser. The web site links the user to a trusted web site.

4.4.1 Direct AttackNiu et al. present detailed web-to-web phishing attacks

on mobile devices [10]. They discuss how phishing attackscan be built by hiding the browser URL bar or spoofingthe URL bar. URL bar spoofing has three steps: (1) theattacker hides the legitimate URL bar, (2) the attacker addsa spoofed URL bar to the visible top of the page, and (3)the attacker catches any attempts to scroll to the real topof the page and instead jumps to the fake URL bar [10, 13].

Niu et al. describe several differences between the behaviorof their spoofed URL bar and the real browser user inter-face. We find that we can reduce the obviousness of two ofthese glitches. First, they always send the user to the faketop of the page whenever the user attempts to scroll in anydirection. The users in their user study find this annoying.We ease the intrusiveness of our scrolling control by alwaysscrolling a fixed amount away from the current location in

the document, but not to a specific location. The scrollevent therefore might scroll slightly more or less than theuser intended, but the screen will never unexpectedly shifta large amount. Second, they observe that the URL bar isvisible while the page loads and renders, giving the user theopportunity to see the real URL. We reduce the URL load-ing and rendering time by delivering a phishing page that isempty except for a script. The page load will complete veryquickly, so the user cannot read the real URL bar. After thepage load event completes, the script dynamically adds allof the visible elements to the phishing web site.

Evaluation. An observant user could unmask the URL barhiding attack by scrolling up to view the URL. There arealso two weaknesses in the spoofing attack. First, the book-marks button is placed next to the URL bar. In iOS, thebookmarks cannot be faked, and the user might notice anon-functional bookmarks button. (In Android, an applica-tion with the appropriate bookmark permissions can accessthe browser’s bookmark storage.) Second, both browsershave a window selection feature that lets the user view theURLs of the open windows.

Despite these shortcomings, Niu et al. found that the URLbar hiding and spoofing attacks were very successful on a setof 37 users that included security experts. None of the usersidentified the phishing attacks when the URL bar was hid-den, and only 1 noticed the fake URL bar. The user whonoticed the fake URL bar did so because of a small imple-mentation error in their emulation of the browser chrome.The near-perfect success rate of their phishing attacks onprimed, expert users indicates that these techniques have thepotential to enable highly successful phishing attacks. Theiruser study found that small glitches (e.g., a non-functionalbookmark button) were attributed to browser or web sitebugs and did not raise suspicion.

4.4.2 Man-In-The-MiddleIn Section 4.2.2, we describe an active attacker that sub-

verts HTTPS form submission after a mobile application haslinked the user to an HTTP site. An even more powerfulnetwork attack is possible in the web-to-web setting. If theuser ever visits any HTTP page in the browser while there isan active attacker tampering with the network connection,then all subsequent browsing can be compromised. A net-work attacker could subvert all HTTP web pages so that alllinks to HTTPS pages point to an attacker-controlled server.In a desktop browser, the user would have an opportunity todetect the attack by looking at the URL bar. However, in amobile browser, the attacker can suppress visual indicatorsof the attack with a fake URL bar. This attack could beautomated by a tool like Ettercap [1].

Evaluation. This attack is unobtrusive and would likely goundetected by users. It relies on the mobile browser URLhiding and spoofing techniques, which are demonstrably ef-fective at tricking users. The only way for the user to avoidthe attack is to manually enter HTTPS URLs directly intothe browser URL bar (or with a saved bookmark).

5. RISK EVALUATIONWe consider how likely different phishing attacks are, given

the prevalence of the legitimate application behaviors. Wealso discuss the most targeted web sites.

Legitimate Behavior Prevalence Attack Technique Accuracy

Mobile Sender → Mobile TargetSocial sharing, upgrades, game credits Very Common Fake mobile login screen PerfectSocial sharing, upgrades, game credits Very Common Task interception PerfectSocial sharing, upgrades, game credits Very Common Scheme squatting LowMobile Sender → Web TargetEmbedded login pages Common Keylogging PerfectOpening a target in the browser Very Uncommon URL bar hiding HighOpening a target in the browser Very Uncommon URL bar Spoofing HighOpening a target in the browser Very Uncommon Fake browser HighEmbedded HTTP page links to HTTPS login Very Uncommon Active network attack PerfectApp sends user to HTTP page in browser that Uncommon Active network attack High

links to HTTPS login + URL bar spoofingWeb Sender → Mobile TargetLink to mobile e-mail or Twitter Common Web site spoofs mobile app HighLink to mobile e-mail or Twitter Common Task interception PerfectLink to mobile e-mail or Twitter Common Scheme squatting LowWeb Sender → Web TargetPayment via PayPal or Google Checkout Common Hide the URL bar HighPayment via PayPal or Google Checkout Common Spoof the URL bar HighUser follows link from HTTP to HTTPS Very Common Active network attack High

+ URL bar spoofing

Table 4: We match each attack technique with the legitimate behavior that it subverts, along with how common the legitimate behavioris. The most effective attacks mimic common behavior with perfect accuracy. “Perfect” accuracy means the user cannot distinguish theattack from the original, and “high” accuracy means the user can only identify the attack by doing something unusual.

5.1 AttacksA phishing attack is comprised of two components: the

legitimate behavior that it mimics, and the technique usedto carry out the attack. An attack’s plausibility is thereforea combination of (1) how prevalent the legitimate behavioris in real applications, and (2) how accurately the attackercan copy the legitimate behavior. Table 4 summarizes all ofthe phishing attacks discussed in this paper, along with theprevalence of their corresponding behaviors and an evalua-tion of the accuracy of the mimicry. We judge prevalenceusing the data from our study of iOS applications, Androidapplications, and mobile web sites (Section 3). We assignan accuracy score based on our evaluation of the strengthsand weaknesses of each attack technique (Section 4).

The most effective attacks mimic common behavior withtechniques that perfectly match the target workflow. Of the15 attacks presented in this paper, 8 mimic common legiti-mate behaviors and use highly accurate attack techniques. 5more use highly effective attack techniques, but their associ-ated behaviors are uncommon within our set of applications.

5.2 TargetsWe identify the password-protected applications that are

linked to the most often by the applications in our data set.These target applications are at the highest risk of phishingattacks because legitimate links to them are so common.

Facebook and Twitter are the most common legitimatelink targets. This is likely because developers want to en-courage sharing on social networks for the free marketing.The 100 iOS and Android applications link to Facebook 35times and Twitter 20 times. Notably, login forms for Face-book and Twitter were embedded in 19 and 12 applications,respectively. Additionally, 13 of the 85 web sites link toTwitter. This indicates that Facebook and Twitter wouldbe ideal candidates for phishing attacks. In particular, em-

bedded login links have trained users to enter their Facebookand Twitter passwords into other applications.

Android- and Apple-sponsored stores are also quite pop-ular as link targets. The 50 Android applications linkedto the Android Market 7 times, and the 50 iOS applicationslinked to the three Apple stores (iTunes, the App Store, andthe Game Center) a collective 23 times. 21 of the web sitestargeted at iOS users link to the iTunes and App Store.

6. ATTACK PREVENTIONThe phishing attacks in this paper all exploit the mobile

platform’s pervasive lack of application identity indicators.A user cannot reliably tell what application is currently run-ning or what web site is currently loaded in the browser. Inthe absence of identity indicators, applications and web sitescan mimic each other with a high degree of accuracy.

One solution is to permanently dedicate some small por-tion of the screen to application identity. The operating sys-tem would provide an always-present identity bar that dis-plays the name of the current foreground application, andthe browser could similarly provide a minimalist, always-present address bar that simply displays the domain in asmall font. However, there are three significant problemswith this solution: mobile screen space is limited, usersignore security indicators [5], and users will still be con-ditioned to fall for embedded phishing attacks as long aslegitimate applications continue to ask for passwords withembedded login forms.

An alternate solution is for the operating system to sup-port a trusted password entry mechanism. SpoofKiller isa proposal for such a trusted login mechanism [7]. Whenusing SpoofKiller, a user presses the “Home” button whenshe wants to log in to a web site or application. The op-erating system then presents the user with a standardizedlogin screen that displays security information and any other

relevant security indicators (e.g., SSL status). The primarychallenges for this approach are usability and adoption; usersmust be convinced to always press the button before supply-ing a password, and applications and web sites must supportthis form of password entry.

In general, phishing is an open problem, and the con-straints of mobile devices make it more difficult. As an im-mediate measure, we recommend that companies stop usingembedded login forms. Companies like Facebook and Twit-ter should encourage developers to implement social sharingusing their mobile applications instead of embedded logins.Embedded logins exacerbate the problem of training usersto ignore security indicators.

7. RELATED WORKNiu et al. identify several aspects of the iPhone’s browser

user interface that enable phishing attacks [10]. They per-form a user study and find that users do not notice missingor spoofed browser user interface elements. Their work ap-plied these techniques to the web-to-web phishing scenario.We build an improved version of their address bar spoofingattack and apply it to new scenarios, such as enabling a webapplication to spoof a mobile application.

Rydstedt et al. present framing attacks on web sites dis-played on mobile phones [13]. They spoof the iPhone’sbrowser address bar to perform their “tapjacking” attacks.Their attacks are all intended for the web-to-web attackscenario, although we believe that their attacks could beextended to mobile applications with WebViews.

Dhamija et al. challenged desktop web browser users toidentify phishing attacks, and the best phishing web sitesin their data set fooled 90% of the study participants [5].Simple spoofing attacks (e.g., copying images of SSL indica-tors) fooled users, and a quarter of their participants onlylooked at the contents of web sites (e.g., logos and layout)to determine legitimacy. Given their results, we feel it isunlikely that smartphone users could differentiate betweenour spoofed applications and the legitimate ones.

8. CONCLUSIONWe examine the threat of phishing on mobile devices. A

successful phishing attack has two parts: the user must beconditioned to enter her credentials in a certain setting, andthe attacker must be able to imitate that setting. We studyreal mobile applications and web sites to understand thescenarios in which users enter passwords on mobile phones,and then we propose attacks that subvert these scenarios.

Our analysis of 100 mobile applications and 85 web sitesfinds that mobile applications and web sites commonly in-teract in ways that can be spoofed by attackers. Many ap-plications and web sites link to each other for the purpose ofsocial sharing and payment, both of which require the userto enter her authentication credentials in contexts where theuser has no way to identify who is receiving those credentials.Users are therefore likely accustomed to switching from oneapplication to another and then entering their passwordsinto the second application, without any way to verify theauthenticity of the second application.

We present 15 phishing attacks that mimic this pattern ofinteraction. A malicious application can link the user to asocial networking or payment web site, and then present theuser with a fake login screen. Alternately, an attacker can

intercept the interaction and substitute a fake login screenfor the intended target. We evaluate how accurately the15 attacks can mimic legitimate application behavior andconclude that 13 could occur without user detection.

Our analysis suggests that mobile users’ passwords for sev-eral major sites (notably including Facebook and Twitter)may be at risk. We hope that this research will motivatefurther research into defenses against mobile phishing.

9. REFERENCES[1] Ettercap. http://ettercap.sourceforge.net.

[2] Android bug report. Internet access withoutpermission. http://code.google.com/p/android/issues/detail?id=8007.

[3] Canalys. Google’s Android becomes the world’sleading smart phone platform. Canalys researchrelease 2011/013, 2011.

[4] E. Chin, A. P. Felt, K. Greenwood, and D. Wagner.Analyzing Inter-Application Communication inAndroid. In MobiSys, 2011.

[5] R. Dhamija, J. D. Tygar, and M. Hearst. WhyPhishing Works. In CHI, 2006.

[6] A. P. Felt, K. Greenwood, and D. Wagner. TheEffectiveness of Install-Time Permission Systems forThird-Party Applications. In WebApps, 2011, toappear.

[7] M. Jakobsson and W. Leddy. SpoofKiller.http://www.spoofkiller.com.

[8] M. Jakobsson, E. Shi, P. Golle, and R. Chow. ImplicitAuthentication for Mobile Devices. In HotSec, 2009.

[9] C. Karlof, J. D. Tygar, and D. Wagner.Conditioned-safe Ceremonies and a User Study of anApplication to Web Authentication. In NDSS, 2009.

[10] Y. Niu, F. Hsu, and H. Chen. iPhish: PhishingVulnerabilities on Consumer Electronics. In UPSEC,2008.

[11] PayPal X Developer Network. The ApplicationShowcase Directory. https://www.x.com/community/ppx/showcase/ap_directory.

[12] M. Prandini, M. Ramilli, W. Cerroni, andF. Callegati. Splitting the HTTPS Stream to AttackSecure Web Connections. In IEEE Security & Privacy,volume 8, Issue 6, December 2010.

[13] G. Rydstedt, B. Gourdin, E. Bursztein, and D. Boneh.Framing attacks on smart phones and dumb routers:tap-jacking and geo-localization attacks. In WOOT,2010.

[14] M. Schultz. Handy Light: Tethering App Camouflagedas Flashlight.http://appshopper.com/blog/2010/07/20/

handy-light-tethering-app-camouflaged-as-flashlight/.

[15] M. Zalewski. Browser Security Handbook, part 2:Same-origin policy for DOM access.http://code.google.com/p/browsersec/wiki/

Part2#Same-origin_policy, 2009.