What's New with Whatsapp & Co.? Revisiting the Security of Smartphone Messaging Applications

What's New with Whatsapp & Co.? Revisiting the Security of Smartphone Messaging Applications

What’s new with WhatsApp & Co.? Revisiting the Security of Smartphone Messaging Applications Robin Mueller Sebastian Schrittwieser Peter Fruehwirt Vienna University of St. Poelten University of SBA Research Technology Applied Sciences Austria Austria Austria pfruehwirt@sba- e0926507 sebastian.schrittwieser research.org @student.tuwien.ac.at @fhstp.ac.at Peter Kieseberg Edgar Weippl SBA Research SBA Research Austria Austria pkieseberg@sba- eweippl@sba- research.org research.org ABSTRACT Keywords In recent years mobile messaging and VoIP applications Mobile Security, Smartphone Messengers, Transport Layer for smartphones have seen a massive surge in popularity, which has also sparked the interest in research related to the security of these applications. Various security researchers 1. INTRODUCTION & RELATED WORK and institutions have performed in-depth analyses of specific With the ever increasing popularity of OTT (over-the- applications or vulnerabilities. This paper gives an overview top) messaging in recent years and massively successful ap- of the status quo in terms of security for a number of se- plications such as WhatsApp, Line and WeChat claiming to lected applications in comparison to a previous evaluation have active monthly user bases of up to 400 million users conducted two years ago, as well as performing an analysis or more [13, 10, 12], large numbers of similar applications on some new applications. The evaluation methods mostly have emerged on the mobile app market trying to imitate focus on known vulnerabilities in connection with authen- those huge successes. In 2012 the number of messages sent tication and validation mechanisms but also describe some over OTT networks had eclipsed the number of SMS mes- newly identified attack vectors. The results show a predomi- sages, with researchers projecting OTT messages to exceed nantly positive trend for new applications, which are mostly SMS by a factor of 4 by the year 2017 [18]. The fast growth being developed with robust security and privacy features, and large number of available applications in a relatively while some of the older applications have shown little to no young field naturally causes many of them being developed progress in this regard or have even introduced new vulner- without sufficient security in mind. Schrittwieser et al. [15] abilities in recent versions. and Cheng et al. [3] describe various attack scenarios and possible implications of security vulnerabilities related to these kinds of applications. Other research focused further on the consequences of vulnerabilities in those applications, Categories and Subject Descriptors e.g. privacy[17] or the system architecture [2]. The security C.2.4 [Distributed Systems]: [Distributed Applications]; functionality of smartphone operating systems are widely D.4.6 [Security and Protection]: Access controls studied [5, 6, 7, 4, 8], app specific vulnerabilities further exist. The goal of this paper is to follow up previous research General Terms by re-evaluating existing applications to show advances in the security field as well as examining newly emerged ones Security, Experimentation for known or potentially new vulnerability patterns. User authentication is a popular field of ongoing research [16, 1], especially in web services [9] and distributed systems [11]. We re-evaluate the security of the authentication system of mobile messaging apps two years after the publication of Permission to make digital or hard copies of all or part of this work for critical vulnerabilities. personal or classroom use is granted without fee provided that copies are As the number of OTT messaging applications is very not made or distributed for profit or commercial advantage and that copies large, we will focus only on a subset of the available applica- bear this notice and the full citation on the first page. To copy otherwise, to tions (namely those that utilize the users' phone number for republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. establishing their identity) and attempt to circumvent the Copyright 2014 ACM 978-1-4503-3001-5/14/12 ...$15.00. various included authentication and security mechanisms. Section 2 will give an overview of the basic features and iOS characteristics of the applications in question as well as their The iOS API that integrates with phone features, such as platforms. The evaluation methods used and possible at- incoming and outgoing SMS, is rather limited by design { tacks are described in Section 3. Section 4 contains the de- for instance it does not allow an application to automatically tailed results of the evaluation along with identified weak- extract the phone number (which means a new registrant al- nesses or potential problems. Section 5 will conclude the ways has to enter the number her/himself) nor does it allow results of the research and give some final recommendations it to programmatically send and receive text messages (it for future development in the area. can however open the messaging app with a pre-populated recipient and message field { the application Forfone does 2. MESSAGING APPLICATIONS this, for example). This means that generally the registra- tion process cannot be automated and the user's input is Similar to the previous work of Schrittwieser et al. [15] we usually required at least twice - first when entering their are only looking at applications that solely rely on the users' phone number and subsequently when entering the verifica- phone number in the verification process, i.e. no passwords tion code. are involved. Generally this means that a new user has to One thing that stood out positively in regards to privacy enter his phone number when registering an account. The was the fact that whenever an application tried to upload application will use this number as a means of identifying the phone's contact list, a dialogue would open, asking the the user. To prevent malicious attackers from simply en- user whether this should be allowed or not. If the user re- tering arbitrary phone numbers to impersonate their target, fused, most applications would simply continue operating most applications include some sort of verification process without uploading the contacts. to make sure that the entered phone number actually be- longs to the user. The way this verification is done varies Android between applications, but it usually involves some kind of Android on the other hand has a very flexible and pow- authentication token (in most cases this is simply a 4 to 6- erful API that allows lots of advanced features. Most of digit number) being communicated between the server and the analyzed applications would automatically extract the the phone in a way that enables the server to establish the phone number and pre-populate the input field (although authenticity of the entered phone number. This is almost one could edit the number in all cases) and some even had a universally done through SMS, although the actual protocol completely automated verification system: They would send can be vastly different in terms of implementation and secu- the registration request to the server, intercept the incoming rity. Most applications will simply send a short verification SMS from within the application and immediately parse and code per SMS to the number that the user is trying to reg- attempt to validate the received code. This usually worked ister which they then have to copy into the application in fine when registering a legitimate phone, but as soon as a order to prove that they are actually the owner of the given different number was entered (so the verification message phone number. The individual protocols and their identified would not be sent to the correct phone) most of the applica- flaws will be outlined in Section 4. tions would simply open a prompt to enter the received code It should also be noted that while many popular instant manually. The Android API even allows automated send- messaging applications use the aforementioned (or a simi- ing of SMS messages from within the application which was lar) approach, there is also a multitude of applications avail- used in some cases for a sort of reverse-verification, where able that use more traditional username/password or email- the phone would send an active text message to the server address/password combinations for authenticating users. instead of the other way around. This approach comes with Those applications and methods may introduce their own its own set of vulnerabilities, which will be described in the vulnerabilities, but in general their potential for abuse and appropriate section. impersonation is somewhat lower as usernames can be cho- Furthermore, the way Android's permission system works sen arbitrarily and are not directly associated with a per- (the user has to accept a set of required permissions only son's identity in the same way a phone number or an email once during installation of an application) makes the appli- address are. On the other hand, email authentications usu- cations intransparent with respect to what they are doing ally use some sort of activation email to verify the legitimacy with one's data. Contacts will be uploaded automatically of the address and the identity of the user { in that regard in most cases with no way of opting out (other than not they are technically similar to some of the SMS-based pro- installing the application), and access to the messaging sys- tocols described here, although email-based authentication tem means that the application could theoretically send out methods are a much older concept and as such are generally unrequested (paid) messages to any of the user's contacts. more refined and better established than the relatively new, SMS-based protocols. 3. EVALUATION Platform Specifics Since testing was done on two different platforms, Android 3.1 Methods (4.1.2) and iOS (6.1.3), we outline some of the more common The actual evaluation consisted of two groups of appli- differences we have experienced between them regarding the cations - first we re-evaluated all of the applications that authentication mechanisms.

View Full Text

Details

  • File Type
    pdf
  • Upload Time
    -
  • Content Languages
    English
  • Upload User
    Anonymous/Not logged-in
  • File Pages
    11 Page
  • File Size
    -

Download

Channel Download Status
Express Download Enable

Copyright

We respect the copyrights and intellectual property rights of all users. All uploaded documents are either original works of the uploader or authorized works of the rightful owners.

  • Not to be reproduced or distributed without explicit permission.
  • Not used for commercial purposes outside of approved use cases.
  • Not used to infringe on the rights of the original creators.
  • If you believe any content infringes your copyright, please contact us immediately.

Support

For help with questions, suggestions, or problems, please contact us