64345410
A Survey on HTTPS Implementation by Android Apps: Issues and Countermeasures
Abstract As more and more sensitive data is transferred from mobile applications across unsecured channels, it seems imperative that transport layer encryption should be used in any non-trivial instance. Yet, research indicates that many Android developers do not use HTTPS or violate rules which protect user data from man-in-the-middle attacks. This paper seeks to find a root cause of the disparities between theoretical HTTPS usage and in-the-wild implementation of the protocol by looking into Android applications, online resources, and papers published by HTTPS and Android security researchers. From these resources, we extract a set of barrier categories that exist in the path of proper TLS use. These barriers not only include improper developer practices, but also server misconfiguration, lacking documentation, flaws in libraries, the fundamentally complex TLS PKI system, and a lack of consumer understanding of the importance of HTTPS. Following this discussion, we compile a set of potential solutions and patches to better secure Android HTTPS and the TLS/SSL protocol in general. We conclude our survey with gaps in current understanding of the environment and suggestions for further research.
17054021
A Study on MITM (Man in the Middle) Vulnerability in Wireless Network Using 802.1X and EAP
The security of wireless LAN is being strengthened through a combination of EAP with an 802.1X-based authentication server, with 802.11i as the standard. As such a security technique effectively defends the existing WEP or protocol vulnerabilities, another approach is needed to prove the vulnerability of the wireless LAN. This paper proposes the wireless MITM (man in the middle) framework, which can actively prove the vulnerability of MITM by applying the MITM technique in the wireless LAN environment, whose security is applied using 802.1X and EAP. It also describes the designing of the required functions and modules. This paper proposes that it is possible to collect the wireless LAN authentication information of the unauthorized user using the designed wireless MLTM-framework under the EAP-MD5 and EAP-TTLS environment.
110063493
Packet Sniffing In a Switched Environment
This paper focuses on the threat of packet sniffing in a switched environment, and briefly explores the effect in a non-switched environment. Detail is given on a number of techniques, such as "ARP (Address Resolution Protocol) spoofing", which can allow an attacker to eavesdrop on network traffic in a switched environment. Third party tools exist that permit sniffing on a switched network. The result of running some of these tools on an isolated, switched network is presented, and clearly demonstrates that the threat they pose is real and significant.
17392257
Revisiting SSL : A Large-Scale Study of the Internet ' s Most Trusted Protocol
Much of the Internet's end-to-end security relies on the SSL protocol along with its underlying certificate infrastructure. We offer an in-depth study of real-world SSL and X.509 deployment characteristics from an unprecedented vantage point, based on a data set of more than 1.4 billion SSL sessions collected at the border of five operational sites. Our contributions are twofold: First, we revisit results from past work with a recent data set that allows us to reassess previous findings and identify recent trends. Second, we provide a detailed study on a range of further SSL/X.509 deployment properties that have not yet seen the attention they deserve, including the intricate web of intermediate certificate authority (CA) relationships, characteristics of SSL session reuse, usage of vendor-specific protocol extensions, and nonstandard CA root hierarchies. While in general we find that today's SSL deployment functions well, we also identify new support for the inherent weaknesses of the system. Along the way, we gain deep insight into specifics and oddities of SSL/X.509 usage, including a surprising difficulty of aligning certificate validation with what typical browsers do. *International Computer Science Institute, 1947 Center Street, Suite 600, Berkeley, California, 94704 § University California, Berkeley, 2200 University Drive, Berkeley, California 94720 ⱡ Lawrence Berkeley National Laboratory, 1 Cyclotron Road, Berkeley, California, 94720 This work was partially funded by the Deutscher Akademischer Austausch Dienst (DAAD) through a postdoctoral fellowship.
64478256
Mitigating Android Application SSL Vulnerabilities using Configuration Policies.
TENDULKAR, VASANT SUDHAKAR. Mitigating Android Application SSL Vulnerabilities using Configuration Policies. (Under the direction of Dr. William Enck.) Android apps are becoming more and more personalizable, dealing with a user’s personally identifiable information. Such apps have a responsibility to protect this sensitive information that they send over the Internet. Recent research has showed that many applications are not protecting this information in transit. This work shows that developers are not implementing SSL correctly, thus leaving applications vulnerable to Man-In-The-Middle attack. This work identifies multiple reasons why developers use SSL incorrectly. We present an analysis of 240 open source and 13,000 popular free Android applications downloaded from the official Google Play Store. We show that a majority of SSL vulnerabilities in Android applications arise from incorrect implementation of SSL Pinning and residual active debug code in the deployed version of the application. We present solutions based on specification of SSL verification policy in the Android Manifest file. Our results show that using such configuration based solutions is a effective approach to mitigate SSL vulnerabilities in Android applications. © Copyright 2013 by Vasant Sudhakar Tendulkar
207207215
An empirical study of cryptographic misuse in android applications
Developers use cryptographic APIs in Android with the intent of securing data such as passwords and personal information on mobile devices. In this paper, we ask whether developers use the cryptographic APIs in a fashion that provides typical cryptographic notions of security, e.g., IND-CPA security. We develop program analysis techniques to automatically check programs on the Google Play marketplace, and find that 10.327 out of 11,748 applications that use cryptographic APIs -- 88% overall -- make at least one mistake. These numbers show that applications do not use cryptographic APIs in a fashion that maximizes overall security. We then suggest specific remediations based on our analysis towards improving overall cryptographic security in Android applications.
1744415
Why do programmers make security errors?
A large number of software security vulnerabilities are caused by software errors that are committed by software developers. We believe that interactive tool support will play an important role in aiding software developers to develop more secure software. However, an in-depth understanding of how and why software developers produce security bugs is needed to design such tools. We conducted a semi-structured interview study on 15 professional software developers to understand their perceptions and behaviors related to software security. Our results reveal a disconnect between developers' conceptual understanding of security and their attitudes regarding their personal responsibility and practices for software security.
17043826
When HTTPS Meets CDN: A Case of Authentication in Delegated Service
Content Delivery Network (CDN) and Hypertext Transfer Protocol Secure (HTTPS) are two popular but independent web technologies, each of which has been well studied individually and independently. This paper provides a systematic study on how these two work together. We examined 20 popular CDN providers and 10,721 of their customer web sites using HTTPS. Our study reveals various problems with the current HTTPS practice adopted by CDN providers, such as widespread use of invalid certificates, private key sharing, neglected revocation of stale certificates, and insecure back-end communication. While some of those problems are operational issues only, others are rooted in the fundamental semantic conflict between the end-to-end nature of HTTPS and the man-in-the-middle nature of CDN involving multiple parties in a delegated service. To address the delegation problem when HTTPS meets CDN, we proposed and implemented a lightweight solution based on DANE (DNS-based Authentication of Named Entities), an emerging IETF protocol complementing the current Web PKI model. Our implementation demonstrates that it is feasible for HTTPS to work with CDN securely and efficiently. This paper intends to provide a context for future discussion within security and CDN community on more preferable solutions.
207207215
An empirical study of cryptographic misuse in android applications
Developers use cryptographic APIs in Android with the intent of securing data such as passwords and personal information on mobile devices. In this paper, we ask whether developers use the cryptographic APIs in a fashion that provides typical cryptographic notions of security, e.g., IND-CPA security. We develop program analysis techniques to automatically check programs on the Google Play marketplace, and find that 10.327 out of 11,748 applications that use cryptographic APIs -- 88% overall -- make at least one mistake. These numbers show that applications do not use cryptographic APIs in a fashion that maximizes overall security. We then suggest specific remediations based on our analysis towards improving overall cryptographic security in Android applications.
54171215
Developer-Resistant Cryptography
“Properly implemented strong crypto systems are one of the few things that you can rely on” Edward Snowden. So why is mass surveillance so successful? One (big) problem is endpoint security. Another is that strong crypto systems are sufficiently difficult to implement that often either mistakes are made resulting in catastrophic loss of security, or cryptography is not used at all. What can we do to make cryptography easier to use and more resistant to developer errors?
207198722
Why eve and mallory love android: an analysis of android SSL (in)security
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.
34437511
HTTPS connections over Android
In this article we discuss a programming model to establish a secure communication channel by using HTTPS protocol in Android platform, using some public key infrastructure features like public keys and digital certificates.
207198712
The most dangerous code in the world: validating SSL certificates in non-browser software
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.
9228699
Rethinking SSL development in an appified world
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.
10452961
Here's my cert, so trust me, maybe?: understanding TLS errors on the web
When browsers report TLS errors, they cannot distinguish between attacks and harmless server misconfigurations; hence they leave it to the user to decide whether continuing is safe. However, actual attacks remain rare. As a result, users quickly become used to "false positives" that deplete their attention span, making it unlikely that they will pay sufficient scrutiny when a real attack comes along. Consequently, browser vendors should aim to minimize the number of low-risk warnings they report. To guide that process, we perform a large-scale measurement study of common TLS warnings. Using a set of passive network monitors located at different sites, we identify the prevalence of warnings for a total population of about 300,000 users over a nine-month period. We identify low-risk scenarios that consume a large chunk of the user attention budget and make concrete recommendations to browser vendors that will help maintain user attention in high-risk situations. We study the impact on end users with a data set much larger in scale than the data sets used in previous TLS measurement studies. A key novelty of our approach involves the use of internal browser code instead of generic TLS libraries for analysis, providing more accurate and representative results.
8561199
Analyzing Forged SSL Certificates in the Wild
The SSL man-in-the-middle attack uses forged SSL certificates to intercept encrypted connections between clients and servers. However, due to a lack of reliable indicators, it is still unclear how commonplace these attacks occur in the wild. In this work, we have designed and implemented a method to detect the occurrence of SSL man-in-the-middle attack on a top global website, Facebook. Over 3 million real-world SSL connections to this website were analyzed. Our results indicate that 0.2% of the SSL connections analyzed were tampered with forged SSL certificates, most of them related to antivirus software and corporate-scale content filters. We have also identified some SSL connections intercepted by malware. Limitations of the method and possible defenses to such attacks are also discussed.
38756919
Semantically rich application-centric security in Android
Smartphones are now ubiquitous. However, the security requirements of these relatively new systems and the applications they support are still being understood. As a result, the security infrastructure available in current smartphone operating systems is largely underdeveloped. In this paper, we consider the security requirements of smartphone applications and augment the existing Android operating system with a framework to meet them. We present Secure Application INTeraction (Saint), a modified infrastructure that governs install-time permission assignment and their run-time use as dictated by application provider policy. An in-depth description of the semantics of application policy is presented. The architecture and technical detail of Saint are given, and areas for extension, optimization, and improvement are explored. We demonstrate through a concrete example and study of real-world applications that Saint provides necessary utility for applications to assert and control the security decisions on the platform. Copyright © 2012 John Wiley & Sons, Ltd.
12643864
emphaSSL: Towards Emphasis as a Mechanism to Harden Networking Security in Android Apps
The use of secure HTTP calls is a first and critical step toward securing the Android application data when the app interacts with the Internet. However, one of the major causes for the unencrypted communication is app developer's errors or ignorance. Could the paradigm of literally repetitive and ineffective emphasis shift towards emphasis as a mechanism? This paper introduces emphaSSL, a simple, practical and readily-deployable way to harden networking security in Android applications. Our emphaSSL could guide app developer's security development decisions via real-time feedback, informative warnings and suggestions. At its core of emphaSSL, we use a set of rigorous security rules, which are obtained through an in-depth SSL/TLS security analysis based on security requirements engineering techniques. We implement emphaSSL via the PMD and evaluate it against 75 open- source Android applications. Our results show that emphaSSL is effective at detecting security violations in HTTPS calls with a very low false positive rate, around 2%. Furthermore, we identified 164 substantial SSL mistakes in these testing apps, 40% of which are potentially vulnerable to man-in-the-middle attacks. In each of these instances, the vulnerabilities could be quickly resolved with the assistance of our highlighting messages in emphaSSL. Upon notifying developers of our findings in their applications, we received positive responses and interest in this approach.
142767
The Matter of Heartbleed
The Heartbleed vulnerability took the Internet by surprise in April 2014. The vulnerability, one of the most consequential since the advent of the commercial Internet, allowed attackers to remotely read protected memory from an estimated 24--55% of popular HTTPS sites. In this work, we perform a comprehensive, measurement-based analysis of the vulnerability's impact, including (1) tracking the vulnerable population, (2) monitoring patching behavior over time, (3) assessing the impact on the HTTPS certificate ecosystem, and (4) exposing real attacks that attempted to exploit the bug. Furthermore, we conduct a large-scale vulnerability notification experiment involving 150,000 hosts and observe a nearly 50% increase in patching by notified hosts. Drawing upon these analyses, we discuss what went well and what went poorly, in an effort to understand how the technical community can respond more effectively to such events in the future.
2551582
Markov chain fingerprinting to classify encrypted traffic
In this paper, we propose stochastic fingerprints for application traffic flows conveyed in Secure Socket Layer/Transport Layer Security (SSL/TLS) sessions. The fingerprints are based on first-order homogeneous Markov chains for which we identify the parameters from observed training application traces. As the fingerprint parameters of chosen applications considerably differ, the method results in a very good accuracy of application discrimination and provides a possibility of detecting abnormal SSL/TLS sessions. Our analysis of the results reveals that obtaining application discrimination mainly comes from incorrect implementation practice, the misuse of the SSL/TLS protocol, various server configurations, and the application nature.
9309350
One year of SSL internet measurement
Over the years, SSL/TLS has become an essential part of internet security. As such, it should offer robust and state-of-the-art security, in particular for HTTPS, its first application. Theoretically, the protocol allows for a trade-off between secure algorithms and decent performance. Yet in practice, servers do not always support the latest version of the protocol, nor do they all enforce strong cryptographic algorithms.
 To assess the quality of HTTPS servers in the wild, we enumerated HTTPS servers on the internet in July 2010 and July 2011. We sent several stimuli to the servers to gather detailed information. We then analysed some parameters of the collected data and looked at how they evolved. We also focused on two subsets of TLS hosts within our measure: the trusted hosts (possessing a valid certificate at the time of the probing) and the EV hosts (presenting a trusted, so-called Extended Validation certificate). Our contributions rely on this methodology: the stimuli we sent, the criteria we studied and the subsets we focused on.
 Moreover, even if EV servers present a somewhat improved certificate quality over the TLS hosts, we show they do not offer overall high quality sessions, which could and should be improved.
15032933
Cryptographic strength of ssl/tls servers: current and recent practices
The Secure Socket Layer (SSL) and its variant, Transport Layer Security (TLS), are used toward ensuring server security. In this paper, we characterize the cryptographic strength of public servers running SSL/TLS. We present a tool developed for this purpose, the Probing SSL Security Tool (PSST), and evaluate over 19,000 servers. We expose the great diversity in the levels of cryptographic strength that is supported on the Internet. Some of our discouraging results show that most sites still support the insecure SSL 2.0, weak export-level grades of encryption ciphers, or weak RSA key strengths. We also observe encouraging behavior such as sensible default choices by servers when presented with multiple options, the quick adoption of AES (more than half the servers support strong key AES as their default choice), and the use of strong RSA key sizes of 1024 bits and above. Comparing results of running our tool over the last two years points to a positive trend that is moving in the right direction, though perhaps not as quickly as it should.
11339922
The Inconvenient Truth about Web Certificates
HTTPS is the de facto standard for securing Internet communications. Although it is widely deployed, the security provided with HTTPS in practice is dubious. HTTPS may fail to provide security for multiple reasons, mostly due to certificate-based authentication failures. Given the importance of HTTPS, we investigate the current scale and practices of HTTPS and certificate-based deployment. We provide a large-scale empirical analysis that considers the top one million most popular websites. Our results show that very few websites implement certificate-based authentication properly. In most cases, domain mismatches between certificates and websites are observed. We study the economic, legal and social aspects of the problem. We identify causes and implications of the profit-oriented attitude of CAs and show how the current economic model leads to the distribution of cheap certificates for cheap security. Finally, we suggest possible changes to improve certificate-based authentication.
208028231
Analysis of SSL certificate reissues and revocations in the wake of heartbleed
A properly managed public key infrastructure (PKI) is critical to ensure secure communication on the Internet. Surprisingly, some of the most important administrative steps---in particular, reissuing new X.509 certificates and revoking old ones---are manual and remained unstudied, largely because it is difficult to measure these manual processes at scale. We use Heartbleed, a widespread OpenSSL vulnerability from 2014, as a natural experiment to determine whether administrators are properly managing their certificates. All domains affected by Heartbleed should have patched their software, revoked their old (possibly compromised) certificates, and reissued new ones, all as quickly as possible. We find the reality to be far from the ideal: over 73% of vulnerable certificates were not reissued and over 87% were not revoked three weeks after Heartbleed was disclosed. Our results also show a drastic decline in revocations on the weekends, even immediately following the Heartbleed announcement. These results are an important step in understanding the manual processes on which users rely for secure, authenticated communication.
17679398
Triple Handshakes and Cookie Cutters: Breaking and Fixing Authentication over TLS
TLS was designed as a transparent channel abstraction to allow developers with no cryptographic expertise to protect their application against attackers that may control some clients, some servers, and may have the capability to tamper with network connections. However, the security guarantees of TLS fall short of those of a secure channel, leading to a variety of attacks. We show how some widespread false beliefs about these guarantees can be exploited to attack popular applications and defeat several standard authentication methods that rely too naively on TLS. We present new client impersonation attacks against TLS renegotiations, wireless networks, challenge-response protocols, and channel-bound cookies. Our attacks exploit combinations of RSA and Diffie-Hellman key exchange, session resumption, and renegotiation to bypass many recent countermeasures. We also demonstrate new ways to exploit known weaknesses of HTTP over TLS. We investigate the root causes for these attacks and propose new countermeasures. At the protocol level, we design and implement two new TLS extensions that strengthen the authentication guarantees of the handshake. At the application level, we develop an exemplary HTTPS client library that implements several mitigations, on top of a previously verified TLS implementation, and verify that their composition provides strong, simple application security.
14161008
Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations
Modern network security rests on the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. Distributed systems, mobile and desktop applications, embedded devices, and all of secure Web rely on SSL/TLS for protection against network attacks. This protection critically depends on whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. We design, implement, and apply the first methodology for large-scale testing of certificate validation logic in SSL/TLS implementations. Our first ingredient is "frankencerts," synthetic certificates that are randomly mutated from parts of real certificates and thus include unusual combinations of extensions and constraints. Our second ingredient is differential testing: if one SSL/TLS implementation accepts a certificate while another rejects the same certificate, we use the discrepancy as an oracle for finding flaws in individual implementations. Differential testing with frankencerts uncovered 208 discrepancies between popular SSL/TLS implementations such as OpenSSL, NSS, CyaSSL, GnuTLS, PolarSSL, MatrixSSL, etc. Many of them are caused by serious security vulnerabilities. For example, any server with a valid X.509 version1 certificate can act as a rogue certificate authority and issue fake certificates for any domain, enabling man-in-the-middle attacks against MatrixSSL and GnuTLS. Several implementations also accept certificate authorities created by unauthorized issuers, as well as certificates not intended for server authentication. We also found serious vulnerabilities in how users are warned about certificate validation errors. When presented with an expired, self-signed certificate, NSS, Safari, and Chrome (on Linux) report that the certificate has expired - a low-risk, often ignored error - but not that the connection is insecure against a man-in-the-middle attack. These results demonstrate that automated adversarial testing with frankencerts is a powerful methodology for discovering security flaws in SSL/TLS implementations.
14161008
Using Frankencerts for Automated Adversarial Testing of Certificate Validation in SSL/TLS Implementations
Modern network security rests on the Secure Sockets Layer (SSL) and Transport Layer Security (TLS) protocols. Distributed systems, mobile and desktop applications, embedded devices, and all of secure Web rely on SSL/TLS for protection against network attacks. This protection critically depends on whether SSL/TLS clients correctly validate X.509 certificates presented by servers during the SSL/TLS handshake protocol. We design, implement, and apply the first methodology for large-scale testing of certificate validation logic in SSL/TLS implementations. Our first ingredient is "frankencerts," synthetic certificates that are randomly mutated from parts of real certificates and thus include unusual combinations of extensions and constraints. Our second ingredient is differential testing: if one SSL/TLS implementation accepts a certificate while another rejects the same certificate, we use the discrepancy as an oracle for finding flaws in individual implementations. Differential testing with frankencerts uncovered 208 discrepancies between popular SSL/TLS implementations such as OpenSSL, NSS, CyaSSL, GnuTLS, PolarSSL, MatrixSSL, etc. Many of them are caused by serious security vulnerabilities. For example, any server with a valid X.509 version1 certificate can act as a rogue certificate authority and issue fake certificates for any domain, enabling man-in-the-middle attacks against MatrixSSL and GnuTLS. Several implementations also accept certificate authorities created by unauthorized issuers, as well as certificates not intended for server authentication. We also found serious vulnerabilities in how users are warned about certificate validation errors. When presented with an expired, self-signed certificate, NSS, Safari, and Chrome (on Linux) report that the certificate has expired - a low-risk, often ignored error - but not that the connection is insecure against a man-in-the-middle attack. These results demonstrate that automated adversarial testing with frankencerts is a powerful methodology for discovering security flaws in SSL/TLS implementations.
6163412
Experimenting at scale with google chrome's SSL warning
Web browsers show HTTPS authentication warnings (i.e., SSL warnings) when the integrity and confidentiality of users' interactions with websites are at risk. Our goal in this work is to decrease the number of users who click through the Google Chrome SSL warning. Prior research showed that the Mozilla Firefox SSL warning has a much lower click-through rate (CTR) than Chrome. We investigate several factors that could be responsible: the use of imagery, extra steps before the user can proceed, and style choices. To test these factors, we ran six experimental SSL warnings in Google Chrome 29 and measured 130,754 impressions.
1847126
Android permissions: user attention, comprehension, and behavior
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.
110063493
Packet Sniffing In a Switched Environment
This paper focuses on the threat of packet sniffing in a switched environment, and briefly explores the effect in a non-switched environment. Detail is given on a number of techniques, such as "ARP (Address Resolution Protocol) spoofing", which can allow an attacker to eavesdrop on network traffic in a switched environment. Third party tools exist that permit sniffing on a switched network. The result of running some of these tools on an isolated, switched network is presented, and clearly demonstrates that the threat they pose is real and significant.
17285189
On lightweight mobile phone application certification
Users have begun downloading an increasingly large number of mobile phone applications in response to advancements in handsets and wireless networks. The increased number of applications results in a greater chance of installing Trojans and similar malware. In this paper, we propose the Kirin security service for Android, which performs lightweight certification of applications to mitigate malware at install time. Kirin certification uses security rules, which are templates designed to conservatively match undesirable properties in security configuration bundled with applications. We use a variant of security requirements engineering techniques to perform an in-depth security analysis of Android to produce a set of rules that match malware characteristics. In a sample of 311 of the most popular applications downloaded from the official Android Market, Kirin and our rules found 5 applications that implement dangerous functionality and therefore should be installed with extreme caution. Upon close inspection, another five applications asserted dangerous rights, but were within the scope of reasonable functional needs. These results indicate that security configuration bundled with Android applications provides practical means of detecting malware.
8160734
SAMPLES: Self Adaptive Mining of Persistent LExical Snippets for Classifying Mobile Application Traffic
We present SAMPLES: Self Adaptive Mining of Persistent LExical Snippets; a systematic framework for classifying network traffic generated by mobile applications. SAMPLES constructs conjunctive rules, in an automated fashion, through a supervised methodology over a set of labeled flows (the training set). Each conjunctive rule corresponds to the lexical context, associated with an application identifier found in a snippet of the HTTP header, and is defined by: (a) the identifier type, (b) the HTTP header-field it occurs in, and (c) the prefix/suffix surrounding its occurrence. Subsequently, these conjunctive rules undergo an aggregate-and-validate step for improving accuracy and determining a priority order. The refined rule-set is then loaded into an application-identification engine where it operates at a per flow granularity, in an extract-and-lookup paradigm, to identify the application responsible for a given flow. Thus, SAMPLES can facilitate important network measurement and management tasks --- e.g. behavioral profiling [29], application-level firewalls [21,22] etc. --- which require a more detailed view of the underlying traffic than that afforded by traditional protocol/port based methods. We evaluate SAMPLES on a test set comprising 15 million flows (approx.) generated by over 700 K applications from the Android, iOS and Nokia market-places. SAMPLES successfully identifies over 90% of these applications with 99% accuracy on an average. This, in spite of the fact that fewer than 2% of the applications are required during the training phase, for each of the three market places. This is a testament to the universality and the scalability of our approach. We, therefore, expect SAMPLES to work with reasonable coverage and accuracy for other mobile platforms --- e.g. BlackBerry and Windows Mobile --- as well.