Content uploaded by Marian Harbach
Author content
All content in this area was uploaded by Marian Harbach on May 28, 2014
Content may be subject to copyright.
A preview of the PDF is not available
Rethinking SSL development in an appified world
Abstract and Figures
The Secure Sockets Layer (SSL) is widely used to secure data transfers on the Internet. Previous studies have shown that the state of non-browser SSL code is catastrophic across a large variety of desktop applications and libraries as well as a large selection of Android apps, leaving users vulnerable to Man-in-the-Middle attacks (MITMAs). To determine possible causes of SSL problems on all major appified platforms, we extended the analysis to the walled-garden ecosystem of iOS, analyzed software developer forums and conducted interviews with developers of vulnerable apps. Our results show that the root causes are not simply careless developers, but also limitations and issues of the current SSL development paradigm. Based on our findings, we derive a proposal to rethink the handling of SSL in the appified world and present a set of countermeasures to improve the handling of SSL using Android as a blueprint for other platforms. Our countermeasures prevent developers from willfully or accidentally breaking SSL certificate validation, offer support for extended features such as SSL Pinning and different SSL validation infrastructures, and protect users. We evaluated our solution against 13,500 popular Android apps and conducted developer interviews to judge the acceptance of our approach and found that our solution works well for all investigated apps and developers.
Figures - uploaded by Marian Harbach
Author content
All figure content in this area was uploaded by Marian Harbach
Content may be subject to copyright.
... CryptoShield's detection correctly identified 89 of the misuse cases (false negative rate: 13 %) and did not produce any false positives. All missed misuses were caused by hardcoded CSPRNG seeds (7) or PBE salts (6). Most issues can be traced back to a limitation in our prototype, which for efficiency reasons only considers hardcoded byte arrays of at least 4 bytes. ...
... If an attacker was to find and exploit a vulnerability in CryptoShield, they could carry out operations on the device that might harm the user. For our prototype, we took great care to follow security best practises for the Android platform, and we publish our source code for examination by fellow security researchers 6 . Before deploying our solution in a real-world scenario, an independent code audit is advisable for ascertaining the implementation's security and trustworthiness. ...
... For instrumenting third-party applications on unrooted devices, our prototype implementation modifies APK files, re-signing them with 6 Source code is available at https://extgit.iaik.tugraz.at/fdraschbacher/cryptoshield a new certificate in the process. Like any other solution that takes advantage of this approach, it is affected by signature checks that some developers integrate into their programs as protection against maliciously modified redistributions. ...
Misuse of cryptographic APIs remains one of the most common flaws in Android applications. The complexity of cryptographic APIs frequently overwhelms developers. This can lead to mistakes that leak sensitive user data to trivial attacks. Despite herculean efforts by platform provider Google, countermeasures introduced so far were not successful in preventing these flaws. Users remain at risk until an effective systemic mitigation has been found.
In this paper, we propose a practical solution that mitigates crypto API misuse in compiled Android applications. It enables users to protect themselves against misuse exploitation until the research community has identified an effective long-term solution. CryptoShield consists of generic mitigation procedures for the most critical crypto API misuse scenarios and an implementation that autonomously extends protection onto all applications on an unrooted Android device. Our on-device CryptoShield Agent injects an instrumentation module into application packages, where it can intercept crypto API calls for detecting misuse and applying mitigations. Our solution was designed for real-world applicability. It retains the update flow through Google Play and can be integrated into existing MDM infrastructure.
As a demonstration of CryptoShield's efficiency and efficacy, we conduct automated (1604 apps) and manual (99 apps) analyses on the most popular applications from Google Play. Our solution mitigates crypto API misuse in 96 % of all vulnerable apps, while retaining full functionality for 92 % of all apps. On-device application instrumentation takes roughly 11 seconds per application package on average, with minimal impact on package size (5 %) and negligible runtime overhead (571 ms on average app launches).
... As described in Section 6.1, while a plethora of security and privacy literature exists concerning developers in similar platforms such as the mobile app ecosystem, no prior studies have focused explicitly on the experiences of voice app developers. Within the domain of mobile app development, extant research reveals that developers are prone to engaging in risky practices, including the disregard of security implications [4], code reuse from online sources [33], excessive permission requests [23,24,66], privacy policy violations [7,61,76], neglect of Transport Layer Security (TLS) [21,22], and improper usage of cryptographic APIs [20,48]. Developers face several challenges when it comes to regulatory compliance, having trouble understanding privacy requirements [8,41,55]. ...
Voice applications (voice apps) are a key element in Voice Assistant ecosystems such as Amazon Alexa and Google Assistant, as they provide assistants with a wide range of capabilities that users can invoke with a voice command. Most voice apps, however, are developed by third parties-i.e., not by Amazon/Google-and they are included in the ecosystem through marketplaces akin to smartphone app stores but with crucial differences, e.g., the voice app code is not hosted by the marketplace and is not run on the local device. Previous research has studied the security and privacy issues of voice apps in the wild, finding evidence of bad practices by voice app developers. However, developers' perspectives are yet to be explored. In this paper, we report a qualitative study of the experiences of voice app developers and the challenges they face. Our findings suggest that: 1) developers face several risks due to liability pushed on to them by the more powerful voice assistant platforms, which are linked to negative privacy and security outcomes on voice assistant platforms; and 2) there are key issues around monetization, privacy, design, and testing rooted in problems with the voice app certification process. We discuss the implications of our results for voice app developers, platforms, regulators, and research on voice app development and certification.
... Issues with usability, steep learning curves, and limited library support reduce the adoption of such tools by developers [7,27,44,79,128]. Poor default configurations in tools and libraries, confusing security APIs, and insufficient documentation lead to errors in their usage [22,39,41,48,73] and in developers' correct disclosure of libraries' data practices [81]. The lack of interoperability of cryptographic libraries on multiple platforms also impedes collaboration between teams and oversight of a security architect [60]. ...
Privacy and security are complex topics, raising a variety of considerations and requirements that can be challenging to implement in software development. Determining the security and privacy-related factors that have an influence on software systems development and deployment project outcomes has been the focus of extensive and ongoing research over the last two decades. In order to understand and categorize the factors that have an impact on developers’ adoption and implementation of privacy and security considerations and practices in software development, we carried out a narrative review of the literature. The resulting mapping of factors provides a foundation for future interventions targeting organizational and individual behavior change, to increase the adoption of privacy and security practices in software development.
... However, one crucial aspect is the quality of the available documentation that developers use to solve their tasks. These are often either easy to use but insecure or secure but hard to use [5,6,27,68] with many examples showing that developers copy and paste insecure code from online resources [4,5,24,27]. Acar et al. write [4]: "our results confirm that API documentation is secure but hard to use, while informal documentation such as Stack Overflow is more accessible but often leads to insecurity." ...
Software developers are rarely security experts and often struggle with security-related programming tasks. The resources developers use to work on them, such as Stack-Overflow or Documentation, have a significant impact on the security of the code they produce. However, work by Acar et al. [4] has shown that these resources are often either easy to use but insecure or secure but hard to use. In a study by Naiakshina et al. [44], it was shown that developers who did not use resources to copy and paste code did not produce any secure solutions at all. This highlights how essential programming resources are for security. Inspired by the Let’s Encrypt and Certbot that support admins in configuring TLS, we created a programming aid called Let’s Hash to help developers create secure password authentication code easily. We created two versions. The first is a collection of code snippets developers can use, and the second adds a wizard interface on top that guides developers through the decisions which need to be made and creates the complete code for them. To evaluate the security and usability of Let’s Hash, we conducted a study with 179 freelance developers, asking them to solve three password programming tasks. Both versions of Let’s Hash significantly outperformed the baseline condition in which developers used their regular resources. On average, Let’s Hash users were between 5 and 32 times as likely to create secure code than those in the control condition.
A priori power analysis would be very beneficial for researchers in the field of developer-centered usable security since recruiting developers for studies is challenging. Power analysis allows researchers to know how many participants they need to test their null hypotheses. However, most studies in this field do not report having conducted power analysis. We conducted a meta-analysis of 54 top-tier developer study papers and found that many are indeed underpowered even to detect large effects. To aid researchers in conducting a priori power analysis in this challenging field, we conducted a systematization of knowledge to extract and condense the needed information. We extracted information from 467 tests and 413 variables and developed a data structure to systematically represent information about hypothesis tests, involved variables, and study methodology. We then systematized the information for tests with categorical independent variables with two groups, i.e., Fisher's exact, chi-squared, McNemar's, Wilcoxon rank-sum, Wilcoxon signed-rank, and paired and independent t-tests to aid researchers with power analysis for these tests. Additionally, we present overview information on the field of developer-centered usable security and list recommendations for suitable reporting practices to make statistical information for power analysis and interpretation more accessible for researchers.
Software security practices are critical in minimizing vulnerabilities and protecting unauthorized access to the code and the system. However, software security practices outside Western countries need to be better understood. This need for understanding security practices is further necessitated by the increased outsourcing of software development which can result in vulnerabilities on a global scale. This paper addresses this gap, focusing on Bangladesh, a country that represents a booming software industry in the Global South. In this study, we conducted semi-structured interviews with 15 developers to understand their security perceptions and identify the factors influencing software security practices in Bangladesh. Our findings unpack how security fits in the local software development life cycle and shed light on the challenges deterring security practices in Bangladesh. Based on our results, we provide recommendations for developing situated and sustainable strategies to support software security practices in the local context.
In practical realizations of a Federated Learning ecosystems, the parties cooperating during the training process, and that later use the trained/global model may consist of competing institutions. This can result in incentives for malicious behavior, which can infringe on the safety and data privacy of other participants. Additionally, even in cases devoid of foul play, the format of the data stored locally, and the equipment available for training, may differ between participating institutions. This necessitates creation of a flexible and adaptable preprocessing pipeline, including a comprehensive registration and data preparation process. Among others, it should identify the affiliation of the joining device(s), maintain appropriate data privacy mechanisms, and compensate for the heterogeneity of the devices that are to participate in model training. In this context, the practical aspects of deploying federated learning solutions, in real-life production environments, are discussed.KeywordsFederated learningInternet of ThingsData privacyBusiness requirementsCoopetition
In the past few years, mobile devices (smartphones, PDAs) have seen both their computational power and their data connectivity rise to a level nearly equivalent to that available on small desktop computers, while becoming ubiquitous. On the downside, these mobile devices are now an extremely attractive target for large-scale security attacks. Mobile device middleware is thus experiencing an increased focus on attempts to mitigate potential security compromises. In particular, Android incorporates by design many well-known security features such as privilege separation. The Android security model also creates several new security sensitive concepts such as Android's application permission system and the unmoderated Android market. In this paper we look to Android as a specific instance of mobile computing. We first discuss the Android security model and some potential weaknesses of the model. We then provide a taxonomy of attacks to the platform demonstrated by real attacks that in the end guarantee privileged access to the device. Where possible, we also propose mitigations for the identified vulnerabilities.
The popularity and adoption of smart phones has greatly stimulated the spread of mobile malware, especially on the popular platforms such as Android. In light of their rapid growth, there is a pressing need to develop effective solutions. However, our defense capability is largely constrained by the limited understanding of these emerging mobile malware and the lack of timely access to related samples. In this paper, we focus on the Android platform and aim to systematize or characterize existing Android malware. Particularly, with more than one year effort, we have managed to collect more than 1,200 malware samples that cover the majority of existing Android malware families, ranging from their debut in August 2010 to recent ones in October 2011. In addition, we systematically characterize them from various aspects, including their installation methods, activation mechanisms as well as the nature of carried malicious payloads. The characterization and a subsequent evolution-based study of representative families reveal that they are evolving rapidly to circumvent the detection from existing mobile anti-virus software. Based on the evaluation with four representative mobile security software, our experiments show that the best case detects 79.6% of them while the worst case detects only 20.2% in our dataset. These results clearly call for the need to better develop next-generation anti-mobile-malware solutions.
Android's permission system is intended to inform users about the risks of installing applications. When a user installs an application, he or she has the opportunity to review the application's permission requests and cancel the installation if the permissions are excessive or objectionable. We examine whether the Android permission system is effective at warning users. In particular, we evaluate whether Android users pay attention to, understand, and act on permission information during installation. We performed two usability studies: an Internet survey of 308 Android users, and a laboratory study wherein we interviewed and observed 25 Android users. Study participants displayed low attention and comprehension rates: both the Internet survey and laboratory study found that 17% of participants paid attention to permissions during installation, and only 3% of Internet survey respondents could correctly answer all three permission comprehension questions. This indicates that current Android permission warnings do not help most users make correct security decisions. However, a notable minority of users demonstrated both awareness of permission warnings and reasonable rates of comprehension. We present recommendations for improving user attention and comprehension, as well as identify open challenges.
Permission models have become very common on smartphone operating systems to control the rights granted to installed third party applications (apps). Prior to installing an app, the user is typically presented with a dialog box showing the permissions requested by the app. The user has to decide either to accept all of the requested permissions, or choose not to proceed with the installation. Most regular users are not able to fully grasp which set of permissions granted to the application is potentially harmful. In addition to the knowledge gap between user and application programmer, the missing granularity and alterability of most permission model implementations help an attacker to circumvent the permission model. In this paper we focus on the permission model of Google's Android platform. We detail the permission model, and present a selection of attacks that can be composed to fully compromise a user's device using inconspicuously looking applications requesting non-suspicious permissions.
Many Android apps have a legitimate need to communicate over the Internet and are then responsible for protecting potentially sensitive data during transit. This paper seeks to better understand the potential security threats posed by benign Android apps that use the SSL/TLS protocols to protect data they transmit. Since the lack of visual security indicators for SSL/TLS usage and the inadequate use of SSL/TLS can be exploited to launch Man-in-the-Middle (MITM) attacks, an analysis of 13,500 popular free apps downloaded from Google's Play Market is presented.
We introduce MalloDroid, a tool to detect potential vulnerability against MITM attacks. Our analysis revealed that 1,074 (8.0%) of the apps examined contain SSL/TLS code that is potentially vulnerable to MITM attacks. Various forms of SSL/TLS misuse were discovered during a further manual audit of 100 selected apps that allowed us to successfully launch MITM attacks against 41 apps and gather a large variety of sensitive data. Furthermore, an online survey was conducted to evaluate users' perceptions of certificate warnings and HTTPS visual security indicators in Android's browser, showing that half of the 754 participating users were not able to correctly judge whether their browser session was protected by SSL/TLS or not. We conclude by considering the implications of these findings and discuss several countermeasures with which these problems could be alleviated.
We explore the threat of smartphone malware with ac-cess to on-board sensors, which opens new avenues for il-licit collection of private information. While existing work shows that such "sensory malware" can convey raw sen-sor data (e.g., video and audio) to a remote server, these approaches lack stealthiness, incur significant communica-tion and computation overhead during data transmission and processing, and can easily be defeated by existing pro-tections like denying installation of applications with ac-cess to both sensitive sensors and the network. We present Soundcomber, a Trojan with few and innocuous permis-sions, that can extract a small amount of targeted private information from the audio sensor of the phone. Using targeted profiles for context-aware analysis, Soundcomber intelligently "pulls out" sensitive data such as credit card and PIN numbers from both tone-and speech-based inter-action with phone menu systems. Soundcomber performs efficient, stealthy local extraction, thereby greatly reducing the communication cost for delivering stolen data. Sound-comber automatically infers the destination phone number by analyzing audio, circumvents known security defenses, and conveys information remotely without direct network access. We also design and implement a defensive architec-ture that foils Soundcomber, identify new covert channels specific to smartphones, and provide a video demonstration of Soundcomber.
Recent trends in public-key infrastructure research explore the tradeoff between decreased trust in Certificate Authorities (CAs), resilience against attacks, communication overhead (bandwidth and latency) for setting up an SSL/TLS connection, and availability with respect to verifiability of public key information. In this paper, we propose AKI as a new public-key validation infrastructure, to reduce the level of trust in CAs. AKI integrates an architecture for key revocation of all entities (e.g., CAs, domains) with an architecture for accountability of all infrastructure parties through checks-and-balances. AKI efficiently handles common certification operations, and gracefully handles catastrophic events such as domain key loss or compromise. We propose AKI to make progress towards a public-key validation infrastructure with key revocation that reduces trust in any single entity.
SSL (Secure Sockets Layer) is the de facto standard for secure Internet communications. Security of SSL connections against an active network attacker depends on correctly validating public-key certificates presented when the connection is established.
We demonstrate that SSL certificate validation is completely broken in many security-critical applications and libraries. Vulnerable software includes Amazon's EC2 Java library and all cloud clients based on it; Amazon's and PayPal's merchant SDKs responsible for transmitting payment details from e-commerce sites to payment gateways; integrated shopping carts such as osCommerce, ZenCart, Ubercart, and PrestaShop; AdMob code used by mobile websites; Chase mobile banking and several other Android apps and libraries; Java Web-services middleware including Apache Axis, Axis 2, Codehaus XFire, and Pusher library for Android and all applications employing this middleware. Any SSL connection from any of these programs is insecure against a man-in-the-middle attack.
The root causes of these vulnerabilities are badly designed APIs of SSL implementations (such as JSSE, OpenSSL, and GnuTLS) and data-transport libraries (such as cURL) which present developers with a confusing array of settings and options. We analyze perils and pitfalls of SSL certificate validation in software based on these APIs and present our recommendations.
While Apple has checked every app available on the App Store, Google takes another approach that allows anyone to publish apps on the Android Market. The openness of the Android Market attracts both benign and malicious developers. The security of the Android platform relies mainly on sandboxing applications and restricting their capabilities such that no application, by default, can perform any operations that would adversely impact other applications, the operating system, or the user. However, a recent research reported that a genuine but vulnerable application may leak its capabilities to other applications. When being leveraged, other applications can gain extra capabilities which they are not granted originally. We present DroidChecker, an Android application analyzing tool which searches for the aforementioned vulnerability in Android applications. DroidChecker uses interprocedural control flow graph searching and static taint checking to detect exploitable data paths in an Android application. We analyzed more than 1100 Android applications using DroidChecker and found 6 previously unknown vulnerable applications including the re-nowned Adobe Photoshop Express application. We have also developed a malicious application that exploits the previously unknown vulnerability found in the Adobe Photoshop Express application. We show that the malicious application, which is not granted any permissions, can access contacts on the phone with just a few lines of code.
The popularity of "Trust-on-first-use" (Tofu) authentica- tion, used by SSH and HTTPS with self-signed certificates, demonstrates significant demand for host authentication that is low-cost and simple to deploy. While Tofu-based applications are a clear improvement over completely inse- cure protocols, they can leave users vulnerable to even simple network attacks. Our system, PERSPECTIVES, thwarts many of these attacks by using a collection of "no- tary" hosts that observes a server's public key via multiple network vantage points (detecting localized attacks) and keeps a record of the server's key over time (recognizing short-lived attacks). Clients can download these records on-demand and compare them against an unauthenticated key, detecting many common attacks. PERSPECTIVES ex- plores a promising part of the host authentication design space: Trust-on-first-use applications gain significant at- tack robustness without sacrificing their ease-of-use. We also analyze the security provided by PERSPECTIVES and describe our experience building and deploying a publicly available implementation.