by Peter Kieseberg, Peter Frühwirt and Sebastian Schrittwieser (SBA Research)
In recent years, standard end-to-end encryption protocols have become increasingly popular for protecting the security of network communication of smartphone applications, as well as user privacy. On the whole, this has been a good thing, but this reliance has also resulted in several issues related to testing.
Software products have been becoming increasingly closely connected, particularly since the rise of mobile environments. Even programs doing menial tasks now require the user to go online, either to use cloud-based resources, or simply because the software provider does not charge users directly, but generates revenue by collecting and selling user preferences and advertising space. While the latter is often to be considered unethical, a study indicates that even those who complain are actually quite willing to give up privacy at a rather small price (see also for the ‘privacy paradox’ [1]).
This increase in connectivity is accompanied by a larger attack surface open to potential malicious actors. Furthermore, the time to market of software products is getting shorter as the market is getting increasingly competitive, resulting in a virtual omnipresence of security issues in current productive software. Even more problematic is the fact that most of the issues currently impairing software security are not based on new scientific findings or large-scale (criminal) organisations conducting intense research for new vulnerabilities to put to criminal use, but rather exploit known weaknesses introduced either by ignorance, or by putting trust into well-known security measures that were never designed for the problem at hand.
While the first problem refers to the problem of diminishing resources during the software development process and can be fixed using training, appropriate management and, most importantly, by setting aside resources, the latter is far more problematic and often touches at the very core of the design process of the software: Developers intrinsically assume certain aspects of their software and its use without further analysing the real attack surface. One very prominent example is the use of transport layer protection in mobile environments, with Transport Layer Security (TLS)[L1] being the de-facto standard for transport encryption. During a case study we analysed a set of mobile apps with respect to the usage of this protocol. We focussed on mobile environments since they possess some characteristics that are different from typical web-based applications. Condensing the results, we typically encountered two major issues with the use of TLS:
- TLS was designed to provide secure end-to-end communication, always assuming the two endpoints to be trusted entities, i.e., removing them from the attacker model. Likewise, many software designers seem to assume that they possess full control over the client side of the software, which is clearly a problematic view in the case of mobile apps, where the client needs to be identified as a potential attacker. Many reasons for client side attacks can be found, e.g., in the realm of mobile messenger apps, users could try to impersonate other people in order to access or spoof messages. Particularly in apps that require the user to pay for the services provided, the motivation for attacking from the client side is rather straightforward.
- Developers seem to rely far too much on the powers of TLS, even assuming capabilities, a protocol for transport layer protection can never hold up to. All TLS does is allow encrypted communication. ITLS cannot, for example, fix a protocol for authentication that is fundamentally flawed from a logical perspective. Nevertheless, we got the impression that in many apps TLS is seen as the silver bullet to fix any security-related issues.
These issues should typically be uncovered during the test phase, but our study on many popular apps, including mobile messengers, mobile games, social networks and even online ticketing shops, revealed an astonishing number of insecure protocols and a general misconception of the attacker surface. Our testing approach for uncovering insecure protocols (see [2] and [3]) relied on the fact that the smartphone the app is running on is under full control of us as adversaries, especially since any attacker having physical access to the phone can potentially manipulate hard- and software, including the operating system (or even run the whole app on a emulator without any actual smartphone). Since we controlled the smartphone we could make the phone route all of the (encrypted) traffic through a proxy, which was also controlled by us (see Figure 1). While TLS protected the communication from the phone to the proxy and from the proxy to the server of the service provider of the app, all the information is visible on the proxy, thus making every aspect of the protocols visible for analysis. For this approach, only standard tools are required, not only making this a good strategy for attacking apps, but also a viable and cost-effective measure for testing.
Figure 1: Testing approach.
In conclusion, it is clear that the topic of software testing needs far more focus, especially considering the new dangers of fully integrated and interconnected environments as envisioned by ubiquitous computing and the ‘internet of things’. Based on the experiments carried out in order to grasp the major problems and assess them, we will put our efforts into defining a testing approach suitable for interconnected environments, starting with the design phase of the software. Furthermore, we plan to support this approach with tools that will speed up the testing process for well-known and important protocols. Nevertheless, one of the major issues still prevalent with software testing, the issue of resources, cannot, in our opinion, be fixed on a technical level, but requires far more awareness on the management level.
Link:
[L1] https://tools.ietf.org/html/rfc5246
References:
[1] P. A. Norberg, D. R. Horne, D. A. Horne. “The privacy paradox: Personal information disclosure intentions versus behaviors”, in Journal of Consumer Affairs 41, no. 1, 100-126, 2007.
[2] P. Kieseberg,et al.: “Security tests for mobile applications – Why using TLS SSL is not enough”, in 2015 IEEE Eighth International Conference on Software Testing, Verification and Validation Workshops (ICSTW), 2015.
[3] R. Mueller, et al.: “Security and privacy of smartphone messaging applications”, International Journal of Pervasive Computing and Communications, vol. 11, 2015.
Please contact:
Peter Kieseberg, SBA Research, Vienna, Austria
