• Abstract and Figures
• Public Full-text

See No Evil: Phishing for Permissions with False Transparency Güliz Seray Tuncay, Google, University of Illinois at Urbana-Champaign; Jingyu Qian and Carl A. Gunter, University of Illinois at Urbana-Champaign https://www.usenix.org/conference/usenixsecurity20/presentation/tuncay This paper is included in the Proceedings of the 29th USENIX Security Symposium. August 12–14, 2020 978-1-939133-17-5 Open access to the Proceedings of the 29th USENIX Security Symposium is sponsored by USENIX. See No Evil: Phishing for Permissions with False Transparency Güliz Seray Tuncay Jingyu Qian Google, University of Illinois at Urbana-Champaign University of Illinois at Urbana-Champaign [email protected] [email protected] Carl A. Gunter University of Illinois at Urbana-Champaign [email protected] Abstract Android’s permission system enables access control on sen- Android introduced runtime permissions in order to provide sitive user data and platform resources based on user consent. users with more contextual information to make informed In an effort to foster meaningful consent, Android 6 intro- decisions as well as with finer granularity when dealing with duced runtime permissions to help users understand why a permissions. In this work, we identified that the correct op- permission is needed by an app by asking for it in a relevant eration of the runtime permission model relies on certain use context. In particular, the runtime permission model war- implicit assumptions which can conveniently be broken by rants certain security guarantees to achieve this goal. First, adversaries to illegitimately obtain permissions from the back- it provides a contextual guarantee to ensure that users will ground while impersonating foreground apps. We call this always be given the necessary contextual information to make detrimental scenario false transparency attacks. These attacks informed decisions, by enforcing apps to be in the foreground constitute a serious security threat to the Android platform as when requesting permissions. Second, it provides an identity they invalidate the security guarantees of 1) runtime permis- guarantee to ensure that users are well-aware of the identity sions by enabling background apps to spoof the context and of the app owning the current context during a permission re- identity of foreground apps when requesting permissions and quest, by clearly displaying the name of the requesting app in of 2) Android permissions altogether by allowing adversaries permission dialogs. In line with its ultimate goal of providing to exploit users’ trust in other apps to obtain permissions. context, the model also relies on the cooperation of app de- We demonstrated via a user study we conducted on Ama- velopers to be transparent regarding their need of permissions zon Mechanical Turk that mobile users’ comprehension of during permission requests. runtime permissions renders them susceptible to this attack In this work, we have identified that the security guaran- vector. We carefully designed our attacks to launch strategi- tees of runtime permissions are broken due to some implicit cally in order to appear persuasive and verified the validity assumptions made by the platform designers. To this end, we of our design strategies through our user study. To demon- show how our findings can be used by adversaries to stealthily strate the feasibility of our attacks, we conducted an in-lab obtain runtime permissions. First, Android assumes that an user study in a realistic setting and showed that none of the app in the foreground will always present a meaningful and subjects noticed our attacks. Finally, we discuss why the ex- legitimate context. However, we show that background apps isting defenses against mobile phishing fail in the context of can surreptitiously move to the foreground to request permis- false transparency attacks. In particular, we disclose the secu- sions without being noticed by users by utilizing Android rity vulnerabilities we identified in a key security mechanism APIs and invisible graphical displays. Second, we observed added in Android 10. We then propose a list of countermea- that the naming scheme utilized in the permission dialogs sures to be implemented on the Android platform and on app assumes that the app name will uniquely identify a single app stores to practically tackle false transparency attacks. installed on the user device for its secure operation; however, the Android ecosystem does not readily enforce any rules on these names. As a consequence, apps can spoof the names 1 Introduction of other apps or use irrelevant names that have the poten- tial to mislead users regarding the true source of the request. Be transparent. When you make a permissions The combination of these findings indicate the possibility of request, be clear about what you’re accessing, and phishing-based privilege escalation on runtime permissions; why, so users can make informed decisions. – App a background app (adversary) can now request and obtain permissions best practices by Google [1] permissions while leading the user to believe the request USENIX Association 29th USENIX Security Symposium 415 was triggered by the foreground app (victim), an insidious sign issues, which rendered our attacks still effective on this phishing scenario which we call false transparency attacks Android version and onward. Finally, we propose a list of on runtime permissions. countermeasures that can be practically implemented on the In false transparency attacks, a permission request from an Android platform and on app stores such as Google Play to app is not transparent in the sense of the quote above. Instead, defend against false transparency attacks. its context is literally transparent as a graphical display to en- Our contributions can be summarized as follows: sure that the user only sees the victim app at the time of the re- • We uncovered design shortcomings in Android’s runtime quest. In addition, its origin is intentionally set to mislead the permissions which inadvertently lead to a violation of the user into thinking the request was triggered by the foreground essential security guarantees of this permission model. app. Hence, the adversary can take advantage of both the con- • By utilizing these shortcomings, we built false trans- text and the identity of a victim app for its own requests to parency attacks, which enable adversaries to illegiti- more conveniently obtain permissions. To illustrate, suppose mately obtain permissions using a victim app’s context Vibr is an attack app that launches a false transparency attack and identity. from the background while the widely-used communication • We conducted a user study to understand if users’ com- app Viber is in the foreground. If, for example, Vibr requests prehension of runtime permissions created susceptibility permission to access the user’s contacts, then an unwary user to this attack vector as well as to verify the validity of may grant this if they think the request comes from Viber, our design strategies for stealthy attacks. as users would generally feel comfortable granting contacts permission to a popular communication app that needs it for • We conducted a user study to demonstrate the feasibility its utility [2]. In particular, we argue that these attacks con- of our attacks in a realistic setting. stitute a notable security hazard for the Android platform for • We discovered serious issues in the new security mecha- two reasons. First, they allow background apps to stealthily nism that addresses phishing in Android 10 and later and obtain permissions while providing a spoofed context and showed the feasibility of our attacks on these versions. identity, which clearly defeats the purpose of using runtime • We proposed practical countermeasures that can effec- permissions to provide meaningful contextual information to tively tackle false transparency attacks. users. Second, they create an opportunity for malicious apps to exploit the user’s trust in another, possibly high-profile app to obtain permissions that they would normally not be 2 Background able to acquire, breaking the security guarantees of Android permissions altogether. 2.1 Android Permissions False transparency attacks serve as a platform for adver- Previously, permissions were permanently granted to apps at saries to obtain any set of dangerous permissions by exploit- installation time on Android. With the introduction of Android ing user’s trust in other apps. In order to profitably mislead 6.0 (API level 23), Android switched to runtime permissions users to grant permissions, the permission dialogs triggered where permissions for high-risk resources (e.g., camera, con- by adversaries should appear plausible, justifying the need for tacts etc.) are requested dynamically and could be revoked a permission, as users have a strong tendency towards deny- by the user at any time. This was done in an effort to provide ing requests that seem irrelevant to the app’s use [2,3]. We users more context while making decisions [4]. In this permis- first show via a user study we conduct on Amazon Mechani- sion model, users are presented with a permission dialog on cal Turk that users indeed demonstrate susceptibility to false or before the first use of a sensitive resource that is protected transparency attacks due to a lack of complete understanding with a dangerous permission and are given the ability to allow of the runtime permission model (e.g., security guarantees of or deny a permission request. Furthermore,

Load more

  19

Copy Link