Experimenting with SSL Vulnerabilities in Android Apps
Total Page：16
File Type：pdf, Size：1020Kb
Danger is My Middle Name: Experimenting with SSL Vulnerabilities in Android Apps Lucky Onwuzurike Emiliano De Cristofaro Computer Science Department Computer Science Department University College London University College London [email protected] [email protected] ABSTRACT analysis shows that half of the apps accept all certificates and half This paper presents a measurement study of information leak- fail hostname verification. Dynamic analysis then reveals that 9 in age and SSL vulnerabilities in popular Android apps. We perform 10 apps establish HTTPS connections under attack in scenario (1), static and dynamic analysis on 100 apps, downloaded at least 10M while, in scenarios (2) and (3), about a quarter of them do so (23 times, that request full network access. Our experiments show that, and 29, respectively). Also, 4 apps—Deezer, Duolingo, Pic Col- although prior work has drawn a lot of attention to SSL implemen- lage, and 4shared—actually establish login sessions over HTTP. tations on mobile platforms, several popular apps (32/100) accept Finally, we report that only 3 apps provide relevant feedback in- all certificates and all hostnames, and four actually transmit sen- dicating failure as a result of SSL certificate validation during an sitive data unencrypted. We set up an experimental testbed sim- attack. As a consequence of these vulnerabilities, adversaries can ulating man-in-the-middle attacks and find that many apps (up to access sensitive information, including credit card numbers, chat 91% when the adversary has a certificate installed on the victim’s messages, contact list, files, and credentials. While we acknowl- device) are vulnerable, allowing the attacker to access sensitive in- edge that our work is similar in nature and, partly, in methodology formation, including credentials, files, personal details, and credit to prior research [13,21,22,27] (see Section 2), note that we do not card numbers. Finally, we provide a few recommendations to app only measure whether these are still prevalent, but also investigate developers and highlight several open research problems. and compare them via both static and dynamic analysis. Contributions. In summary, we make the following contributions: We present a measurement study of Android apps security, 1. INTRODUCTION • confirming that SSL vulnerabilities are still prevalent even in Over the past few years, the proliferation of always-on, always- very popular (10M+ downloads) apps. connected smartphones has skyrocketed. In 2013, 73% of mobile We investigate why static and dynamic analysis yield slightly phone users regularly accessed the Internet via their mobile de- • different results. vices [7, 34] and this ratio is bound to increase as sales of smart- We provide recommendations for developers and highlight a phones and tablets keep growing [25, 26]. Naturally, as the num- • ber and the usage of always-on, always-connected smartphones few open research problems. increase, so does the amount of personal and sensitive informa- Paper organization. Next section reviews related work, then Sec- tion they transmit. Thus, it is crucial to secure traffic exchanged tion 3 presents some relevant background information. Section 4 by these devices, especially considering that mobile users might introduces our methodology, while Section 5 discusses our mea- connect to open Wi-Fi networks or even fake cell towers. How- surement results, which we analyze in Section 6. Then, in Section 7 ever, SSL implementations in smartphone applications (in the rest we discuss some recommendations, and conclude in Section 8. In of the paper simply referred to as apps) are actually more buggy the Appendix, we also provide a code snippet developers can be and prone to vulnerabilities than browsers, including to man-in-the build from in order to implement SSL pinning as well as the com- middle (MiTM) attacks [21,27]. Moreover, while browsers provide plete list of analyzed apps. users with visual feedback that the communication is secured (via the lock symbol) and of certificate validation issues, apps do so less 2. RELATED WORK extensively and effectively [9]. Prior work looked at Android security from several perspectives: Although prior work has presented means for detecting vulnera- permissions [10, 11], privilege escalation [14, 18], detecting mali- bilities [13,33], it is unclear whether these are still prevalent in An- cious apps [38, 40], information flow/taint tracking [20, 41], and droid apps, and how so. We set to measure and analyze private in- details of SSL implementations [15,21, 22,27]. formation leakage and SSL vulnerabilities by building a sample of Georgiev et al. [27] study libraries and APIs used in SSL im- 100 popular Android apps requesting full network access (10% of plementations of non-browser apps, and Brubaker et al. [13] in- all apps with at least 10M downloads, as per [2]). We examine them troduce techniques for large-scale testing of certificate validation via static—decompiling using dex2jar [3]—and dynamic analysis, logic. Also, [15] and [33] introduce tools (respectively, MITHYS- where we simulate three MiTM scenarios: (1) an advanced adver- App and SMV-Hunter) for automated vulnerability discovery. sary that has its certificate installed on the user’s device, (2) an SSL A fewstudies [8, 9, 36, 39] analyze issues with SSL warnings in implementation accepting all certificates, and (3) an implementa- web browsers, but not many in the context of apps. In [21], Fahl tion not performing hostname verification correctly. et al. report that numerous apps do not display meaningful warn- Results. We observe that almost all apps in our sample (93/100) in- ing messages in presence of possible attacks, and, in [22], that 312 clude SSL, and most of them (78) use customized SSL code. Static out of 599 apps display warnings, with 254 of them not being de- 1 SSL Implementation in Android. To guarantee end-to-end se- curity, application developers use SSL over HTTP (HTTPS) sock- ets, relying on the android.net, android.webkit, java.net, javax.net, java.security, javax.security.cert, and org.apache.http packages of the Android SDK to create HTTP/HTTPS connection, adminis- ter, and verify certificates and keys. These packages provide de- velopers with TrustManager and HostnameVerifier interfaces, which are used in the SSL certificate validation logic. TrustMan- ager manages the certificates of all Certificate Authorities (CA) used in assessing the certificate’s validity. Only root CAs trusted by Android are contained in the default TrustManager. The cer- tificates are stored in a keystore which is then used to create the TrustManager. HostnameVerifier performs hostname verifi- cation whenever a URL’s hostname does not match the hostname in the peer’s identification credentials. Developers can use default implementations of the TrustMan- ager and HostnameVerifier interfaces provided by the Android SDK, or use customized ones. The latter usually involves developer- Figure 1: SSL Handshake. specified credentials or validation logic on TrustManager and/or HostnameVerifier. Typically, customization is done to support a certificate issued by a CA unknown to the OS, when using self- scriptive of the problem. MITHYSApp [15] also warns users about signed certificates, pinning peer credentials (“SSL pinning”, see vulnerable apps and allows them to decide whether to continue the below), server configuration sending incomplete certificate chain, connection. Work in [21, 22] use static analysis to discover vul- or the use of a single certificate for multiple hosts. nerabilities in Android and iOS apps. Our work extends these by In the rest of the paper, we simply refer to the name of an in- performing both static and dynamic analysis and investigate why terface or its implementation (e.g., TrustManager), whenever it is they differ from each other. We also propose a fail-safe strategy clear from the context. that developers can use to implement SSL securely. Interestingly enough, although prior work, including [21,22,27], has highlighted SSL Pinning involves coupling a host’s trusted credential (e.g., an important vulnerabilities in Android/iOS SSL implementations, 1- X.509 certificate or a public key) to its identity. Any other creden- 2 years later these are still prevalent even in very popular apps. tials received other than that coupled will not be accepted as valid Finally, Bates et al. [12] introduce CERTSHIM, a tool for certifi- for the host, whether or not it was issued by a valid entity or an cate verification retrofitting that is dynamically hooked to SSL and entity trusted by the OS. This is usually done when a developer data transport libraries, while Kranch and Bonneau [30] reveal that knows, beforehand, the trusted credentials of the host. cookies can be leaked from domains that implement key pinning to malicious scripts in HTTP domains they load resources from. 4. METHODOLOGY Experimental testbed. We use an LG Nexus 4 smartphone (run- 3. BACKGROUND ning Android KitKat 4.4.4) with a Lenovo laptop (running Win- In this section, we introduce some background information about dows 8.1) acting as the Wi-Fi Access Point (AP). To capture traffic SSL handshake, man-in-the-middle attacks, implementation of SSL and simulate MiTM attacks, we use Wireshark [6] and Fiddler2 [4]. on Android, and SSL Pinning. Timeline. Experiments presented in this paper were performed in SSL Handshake. SSL sessions always begin with a message ex- August/September 2014, and then revisited in March/April 2015. change between the client and the server – the SSL handshake. All statistics refer to the first round of tests, however, whenever an Specifically, as depicted in Figure 1, the client initiates it by send- app is no longer vulnerable, we report it in the text. ing the client hello message and then verifies the identity of the Analyzed Apps. Our first step is to build a set of 100 popular server. Obviously, if the verification is not implemented correctly, Android apps.