Yury Zhauniarovich

CRêPE: A System for Enforcing Fine-Grained Context-Related Policies on Android

Current smartphone systems allow the user to use only marginally contextual information to specify the behavior of the applications: this hinders the wide adoption of this technology to its full potential. In this paper, we fill this gap by proposing CRêPE, a fine-grained Context-Related Policy Enforcement System for Android. While the concept of context-related access control is not new, this is the first work that brings this concept into the smartphone environment. In particular, in our work, a context can be defined by: the status of variables sensed by physical (low level) sensors, like time and location; additional processing on these data via software (high level) sensors; or particular interactions with the users or third parties. CRêPE allows context-related policies to be set (even at runtime) by both the user and authorized third parties locally (via an application) or remotely (via SMS, MMS, Bluetooth, and QR-code). A thorough set of experiments shows that our full implementation of CRêPE has a negligible overhead in terms of energy consumption, time, and storage, making our system ready for a production environment.

MOSES: Supporting and Enforcing Security Profiles on Smartphones

Smartphones are very effective tools for increasing the productivity of business users. With their increasing computational power and storage capacity, smartphones allow end users to perform several tasks and be always updated while on the move. Companies are willing to support employee-owned smartphones because of the increase in productivity of their employees. However, security concerns about data sharing, leakage and loss have hindered the adoption of smartphones for corporate use. In this paper we present MOSES, a policy-based framework for enforcing software isolation of applications and data on the Android platform. In MOSES, it is possible to define distinct Security Profiles within a single smartphone. Each security profile is associated with a set of policies that control the access to applications and data. Profiles are not predefined or hardcoded, they can be specified and applied at any time. One of the main characteristics of MOSES is the dynamic switching from one security profile to another. We run a thorough set of experiments using our full implementation of MOSES. The results of the experiments confirm the feasibility of our proposal.

DEMO: Enabling trusted stores for android

In the Android ecosystem, the process of verifying the integrity of downloaded apps is left to the user. Different from other systems, e.g., Apple App Store, Google does not provide any certified vetting process for the Android apps. This choice has a lot of advantages but it is also the open door to possible attacks as the recent one shown by Bluebox. To address this issue, this demo presents how to enable the deployment of application certification service, we called TruStore, for the Android platform. In our approach, the TruStore client enabled on the end-user device ensures that only the applications, which have been certified by the TruStore server, are installed on the user smartphone. We envisage trusted markets (TruStore servers, which can be, e.g., corporate application markets) that guarantee security by enabling an application vetting process. The TruStore infrastructure maintains the open nature of the Android ecosystem and requires minor modifications to Android stack. Moreover, it is backward-compatible and transparent for developers, and does not change the application management process on a device.

Towards Black Box Testing of Android Apps

Many state-of-art mobile application testing frameworks (e.g., Dynodroid [1], EvoDroid [2]) enjoy Emma [3] or other code coverage libraries to measure the coverage achieved. The underlying assumption for these frameworks is availability of the app source code. Yet, application markets and security researchers face the need to test third-party mobile applications in the absence of the source code. There exists a number of frameworks both for manual and automated test generation that address this challenge. However, these frameworks often do not provide any statistics on the code coverage achieved, or provide coarse-grained ones like a number of activities or methods covered. At the same time, given two test reports generated by different frameworks, there is no way to understand which one achieved better coverage if the reported metrics were different (or no coverage results were provided). To address these issues we designed a framework called BBOXTESTER that is able to generate code coverage reports and produce uniform coverage metrics in testing without the source code. Security researchers can automatically execute applications exploiting current state-of-art tools, and use the results of our framework to assess if the security-critical code was covered by the tests. In this paper we report on design and implementation of BBOXTESTER and assess its efficiency and effectiveness.

Demonstrating the effectiveness of MOSES for separation of execution modes

In this paper, we describe a demo of a light virtualisation solution for Android phones. We named our solution MOSES (MOde-of-uses SEcurity Separation). MOSES is a policy-based framework for enforcing software isolation of applications and data. In MOSES, it is possible to define distinct security profiles within a single smartphone. Each security profile is associated with a set of policies that control the access to applications and data. One of the main characteristics of MOSES is the dynamic switching from one security profile to another. Each profile is associated with a context as well. Through the smartphones sensors, MOSES is able to detect changes in context and to dynamically switch to the security profile associated with the current context. Our current implementation of MOSES shows minimal overhead compared to standard Android in terms of latencies and battery consumption.

Please hold on: Unobtrusive user authentication using smartphone's built-in sensors

Smartphones provide anytime-anywhere communications and are being increasingly used for a variety of purposes, e.g, sending email, performing online transactions, connecting with friends and acquaintances over social networks. As a result, a considerable amount of sensitive personal information is often generated and stored on smartphones. Thus, smartphone users may face financial as well as sentimental consequences if such information fall in the wrong hands. To address this problem all smartphones provide some form of user authentication, that is the process of verifying the users identity. Existing authentication mechanisms, such as using 4-digit passcodes or graphical patterns, suffer from multiple limitations - they are neither highly secure nor easy to input. As a results, recent studies found that most smartphones users do not use any authentication mechanism at all. In this paper, we present a fully unobtrusive user authentication scheme based on micro-movements of the users hand(s) after the user unlocks her smartphone. The proposed scheme collects data from multiple 3-dimensional smartphone sensors in the background for a specific period of time and profiles a user based on the collected hand(s) movement patterns. Subsequently, the system matches the query pattern with the pre-stored patterns to authenticate the smartphone owner. Our system achieved a True Acceptance Rate (TAR) of 96% at an Equal Error Rate (EER) of 4%, on a dataset of 31 qualified volunteers (53, in total), using Random Forest (RF) classifier. Our scheme can be used as a primary authentication mechanism or can be used as a secondary authentication scheme in conjunction with any of the existing authentication schemes, e.g., passcodes, to improve their security.

Security in the Firefox OS and Tizen Mobile Platforms

Emerging mobile platforms Firefox OS and Tizen are learning from Androids security successes and trying to avoid its limitations. Although these platforms offer largely novel solutions, they can still learn from one another.

Small Changes, Big Changes: An Updated View on the Android Permission System

Since the appearance of Android, its permission system was central to many studies of Android security. For a long time, the description of the architecture provided by Enck et al. in [31] was immutably used in various research papers. The introduction of highly anticipated runtime permissions in Android 6.0 forced us to reconsider this model. To our surprise, the permission system evolved with almost every release. After analysis of 16 Android versions, we can confirm that the modifications, especially introduced in Android 6.0, considerably impact the aptness of old conclusions and tools for newer releases. For instance, since Android 6.0 some signature permissions, previously granted only to apps signed with a platform certificate, can be granted to third-party apps even if they are signed with a non-platform certificate; many permissions considered before as threatening are now granted by default. In this paper, we review in detail the updated system, introduced changes, and their security implications. We highlight some bizarre behaviors, which may be of interest for developers and security researchers. We also found a number of bugs during our analysis, and provided patches to AOSP where possible.

Evaluation of Resource-based App Repackaging Detection in Android

Android app repackaging threatens the health of application markets, as repackaged apps, besides stealing revenue for honest developers, are also a source of malware distribution. Techniques that rely on visual similarity of Android apps recently emerged as a way to tackle the repackaging detection problem, as code-based detection techniques often fail in terms of efficiency, and effectiveness when obfuscation is applied [19, 21]. Among such techniques, the resource-based repackaging detection approach that compares sets of files included in apks has arguably the best performance [10, 17, 20]. Yet, this approach has not been previously validated on a dataset of repackaged apps.

Profiling DRDoS Attacks with Data Analytics Pipeline

A large amount of Distributed Reflective Denial-of-Service (DRDoS) attacks are launched every day, and our understanding of the modus operandi of their perpetrators is yet very limited as we are submerged with so Big Data to analyze and do not have reliable and complete ways to validate our findings. In this paper, we propose a first analytic pipeline that enables us to cluster and characterize attack campaigns into several main profiles that exhibit similarities. These similarities are due to common technical properties of the underlying infrastructures used to launch these attacks. Although we do not have access to the ground truth and we do not know how many perpetrators are acting behind the scene, we can group their attacks based on relevant commonalities with cluster ensembling to estimate their number and capture their profiles over time. Specifically, our results show that we can repeatably identify and group together common profiles of attacks while considering domain experts constraint in the cluster ensembles. From the obtained consensus clusters, we can generate comprehensive rules that characterize past campaigns and that can be used for classifying the next ones despite the evolving nature of the attacks. Such rules can be further used to filter out garbage traffic in Internet Service Provider networks.