The Dilemma of Security Smells and How to Escape It

A single mobile app can now be more complex than entire operating systems ten years ago, thus security becomes a major concern for mobile apps. Unfortunately, previous studies focused rather on particular aspects of mobile application security and did not provide a holistic overview of security issues. Therefore, they could not accurately understand the fundamental flaws to propose effective solutions to common security problems. In order to understand these fundamental flaws, we followed a hybrid strategy, i.e., we collected reported issues from existing work, and we actively identified security-related code patterns that violate best practices in software development. We further introduced the term ``security smell,'' i.e., a security issue that could potentially lead to a vulnerability. As a result, we were able to establish comprehensive security smell catalogues for Android apps and related components, i.e., inter-component communication, web communication, app servers, and HTTP clients. Furthermore, we could identify a dilemma of security smells, because most security smells require unique fixes that increase the code complexity, which in return increases the risk of introducing more security smells. With this knowledge, we investigate the interaction of our security smells with the 192 Mitre CAPEC attack mechanism categories of which the majority could be mitigated with just a few additional security measures. These measures, a String class with behavior and the more thorough use of secure default values and paradigms, would simplify the application logic and at the same time largely increase security if implemented appropriately. We conclude that application security has to focus on the String class, which has not largely changed over the last years, and secure default values and paradigms since they are the smallest common denominator for a strong foundation to build resilient applications. Moreover, we provide an initial implementation for a String class with behavior, however the further exploration remains future work. Finally, the term ``security smell'' is now widely used in academia and eases the communication among security researchers

The Dilemma of Security Smells and How to Escape It

A single mobile app can now be more complex than entire operating systems ten years ago, thus security becomes a major concern for mobile apps. Unfortunately, previous studies focused rather on particular aspects of mobile application security and did not provide a holistic overview of security issues. Therefore, they could not accurately understand the fundamental flaws to propose effective solutions to common security problems. In order to understand these fundamental flaws, we followed a hybrid strategy, i.e., we collected reported issues from existing work, and we actively identified security-related code patterns that violate best-practices in software development. Based on these findings, we compiled a list of security smells, i.e., security issues that could potentially lead to a vulnerability. As a result, we were able to establish comprehensive security smell catalogues for Android apps and related components, i.e., inter-component communication, web communication, app servers, and HTTP clients. Furthermore, we could identify a dilemma of security smells, because most security smells require unique fixes that increase the code complexity, which in return increases the risk of introducing more security smells. With this knowledge, we investigate the interaction of our security smells with the 192 Mitre CAPEC attack mechanism categories of which the majority could be mitigated with just a few additional security measures. These measures, a String class with behavior and the more thorough use of secure default values and paradigms, would simplify the application logic and at the same time largely increase security if implemented appropriately. We conclude that application security has to focus on the String class, which has not largely changed over the last years, and secure default values and paradigms since they are the smallest common denominator for a strong foundation to build resilient applications. Moreover, we provide an initial implementation for a String class with behavior, however the further exploration remains future work. Finally, the term "security smell" is now widely used in academia and eases the communication among security researchers

A Software Vulnerabilities Odysseus: Analysis, Detection, and Mitigation

Programming has become central in the development of human activities while not being immune to defaults, or bugs. Developers have developed specific methods and sequences of tests that they implement to prevent these bugs from being deployed in releases. Nonetheless, not all cases can be thought through beforehand, and automation presents limits the community attempts to overcome. As a consequence, not all bugs can be caught. These defaults are causing particular concerns in case bugs can be exploited to breach the program’s security policy. They are then called vulnerabilities and provide specific actors with undesired access to the resources a program manages. It damages the trust in the program and in its developers, and may eventually impact the adoption of the program. Hence, to attribute a specific attention to vulnerabilities appears as a natural outcome. In this regard, this PhD work targets the following three challenges: (1) The research community references those vulnerabilities, categorises them, reports and ranks their impact. As a result, analysts can learn from past vulnerabilities in specific programs and figure out new ideas to counter them. Nonetheless, the resulting quality of the lessons and the usefulness of ensuing solutions depend on the quality and the consistency of the information provided in the reports. (2) New methods to detect vulnerabilities can emerge among the teachings this monitoring provides. With responsible reporting, these detection methods can provide hardening of the programs we rely on. Additionally, in a context of computer perfor- mance gain, machine learning algorithms are increasingly adopted, providing engaging promises. (3) If some of these promises can be fulfilled, not all are not reachable today. Therefore a complementary strategy needs to be adopted while vulnerabilities evade detection up to public releases. Instead of preventing their introduction, programs can be hardened to scale down their exploitability. Increasing the complexity to exploit or lowering the impact below specific thresholds makes the presence of vulnerabilities an affordable risk for the feature provided. The history of programming development encloses the experimentation and the adoption of so-called defence mechanisms. Their goals and performances can be diverse, but their implementation in worldwide adopted programs and systems (such as the Android Open Source Project) acknowledges their pivotal position. To face these challenges, we provide the following contributions: • We provide a manual categorisation of the vulnerabilities of the worldwide adopted Android Open Source Project up to June 2020. Clarifying to adopt a vulnera- bility analysis provides consistency in the resulting data set. It facilitates the explainability of the analyses and sets up for the updatability of the resulting set of vulnerabilities. Based on this analysis, we study the evolution of AOSP’s vulnerabilities. We explore the different temporal evolutions of the vulnerabilities affecting the system for their severity, the type of vulnerability, and we provide a focus on memory corruption-related vulnerabilities. • We undertake the replication of a machine-learning based detection algorithms that, besides being part of the state-of-the-art and referenced to by ensuing works, was not available. Named VCCFinder, this algorithm implements a Support- Vector Machine and bases its training on Vulnerability-Contributing Commits and related patches for C and C++ code. Not in capacity to achieve analogous performances to the original article, we explore parameters and algorithms, and attempt to overcome the challenge provided by the over-population of unlabeled entries in the data set. We provide the community with our code and results as a replicable baseline for further improvement. • We eventually list the defence mechanisms that the Android Open Source Project incrementally implements, and we discuss how it sometimes answers comments the community addressed to the project’s developers. We further verify the extent to which specific memory corruption defence mechanisms were implemented in the binaries of different versions of Android (from API-level 10 to 28). We eventually confront the evolution of memory corruption-related vulnerabilities with the implementation timeline of related defence mechanisms

A survey of app store analysis for software engineering

App Store Analysis studies information about applications obtained from app stores. App stores provide a wealth of information derived from users that would not exist had the applications been distributed via previous software deployment methods. App Store Analysis combines this non-technical information with technical information to learn trends and behaviours within these forms of software repositories. Findings from App Store Analysis have a direct and actionable impact on the software teams that develop software for app stores, and have led to techniques for requirements engineering, release planning, software design, security and testing. This survey describes and compares the areas of research that have been explored thus far, drawing out common aspects, trends and directions future research should take to address open problems and challenges

Anchor: Locating Android Framework-specific Crashing Faults

Android framework-specific app crashes are hard to debug. Indeed, the callback-based event-driven mechanism of Android challenges crash localization techniques that are developed for traditional Java programs. The key challenge stems from the fact that the buggy code location may not even be listed within the stack trace. For example, our empirical study on 500 framework-specific crashes from an open benchmark has revealed that 37 percent of the crash types are related to bugs that are outside the stack traces. Moreover, Android programs are a mixture of code and extra-code artifacts such as the Manifest file. The fact that any artifact can lead to failures in the app execution creates the need to position the localization target beyond the code realm. In this paper, we propose Anchor, a two-phase suspicious bug location suggestion tool. Anchor specializes in finding crash-inducing bugs outside the stack trace. Anchor is lightweight and source code independent since it only requires the crash message and the apk file to locate the fault. Experimental results, collected via cross-validation and in-the-wild dataset evaluation, show that Anchor is effective in locating Android framework-specific crashing faults.Comment: 12 page

Security in Computer and Information Sciences

This open access book constitutes the thoroughly refereed proceedings of the Second International Symposium on Computer and Information Sciences, EuroCybersec 2021, held in Nice, France, in October 2021. The 9 papers presented together with 1 invited paper were carefully reviewed and selected from 21 submissions. The papers focus on topics of security of distributed interconnected systems, software systems, Internet of Things, health informatics systems, energy systems, digital cities, digital economy, mobile networks, and the underlying physical and network infrastructures. This is an open access book

“And all the pieces matter...” Hybrid Testing Methods for Android App's Privacy Analysis

Smartphones have become inherent to the every day life of billions of people worldwide, and they are used to perform activities such as gaming, interacting with our peers or working. While extremely useful, smartphone apps also have drawbacks, as they can affect the security and privacy of users. Android devices hold a lot of personal data from users, including their social circles (e.g., contacts), usage patterns (e.g., app usage and visited websites) and their physical location. Like in most software products, Android apps often include third-party code (Software Development Kits or SDKs) to include functionality in the app without the need to develop it in-house. Android apps and third-party components embedded in them are often interested in accessing such data, as the online ecosystem is dominated by data-driven business models and revenue streams like advertising. The research community has developed many methods and techniques for analyzing the privacy and security risks of mobile apps, mostly relying on two techniques: static code analysis and dynamic runtime analysis. Static analysis analyzes the code and other resources of an app to detect potential app behaviors. While this makes static analysis easier to scale, it has other drawbacks such as missing app behaviors when developers obfuscate the app’s code to avoid scrutiny. Furthermore, since static analysis only shows potential app behavior, this needs to be confirmed as it can also report false positives due to dead or legacy code. Dynamic analysis analyzes the apps at runtime to provide actual evidence of their behavior. However, these techniques are harder to scale as they need to be run on an instrumented device to collect runtime data. Similarly, there is a need to stimulate the app, simulating real inputs to examine as many code-paths as possible. While there are some automatic techniques to generate synthetic inputs, they have been shown to be insufficient. In this thesis, we explore the benefits of combining static and dynamic analysis techniques to complement each other and reduce their limitations. While most previous work has often relied on using these techniques in isolation, we combine their strengths in different and novel ways that allow us to further study different privacy issues on the Android ecosystem. Namely, we demonstrate the potential of combining these complementary methods to study three inter-related issues: • A regulatory analysis of parental control apps. We use a novel methodology that relies on easy-to-scale static analysis techniques to pin-point potential privacy issues and violations of current legislation by Android apps and their embedded SDKs. We rely on the results from our static analysis to inform the way in which we manually exercise the apps, maximizing our ability to obtain real evidence of these misbehaviors. We study 46 publicly available apps and find instances of data collection and sharing without consent and insecure network transmissions containing personal data. We also see that these apps fail to properly disclose these practices in their privacy policy. • A security analysis of the unauthorized access to permission-protected data without user consent. We use a novel technique that combines the strengths of static and dynamic analysis, by first comparing the data sent by applications at runtime with the permissions granted to each app in order to find instances of potential unauthorized access to permission protected data. Once we have discovered the apps that are accessing personal data without permission, we statically analyze their code in order to discover covert- and side-channels used by apps and SDKs to circumvent the permission system. This methodology allows us to discover apps using the MAC address as a surrogate for location data, two SDKs using the external storage as a covert-channel to share unique identifiers and an app using picture metadata to gain unauthorized access to location data. • A novel SDK detection methodology that relies on obtaining signals observed both in the app’s code and static resources and during its runtime behavior. Then, we rely on a tree structure together with a confidence based system to accurately detect SDK presence without the need of any a priory knowledge and with the ability to discern whether a given SDK is part of legacy or dead code. We prove that this novel methodology can discover third-party SDKs with more accuracy than state-of-the-art tools both on a set of purpose-built ground-truth apps and on a dataset of 5k publicly available apps. With these three case studies, we are able to highlight the benefits of combining static and dynamic analysis techniques for the study of the privacy and security guarantees and risks of Android apps and third-party SDKs. The use of these techniques in isolation would not have allowed us to deeply investigate these privacy issues, as we would lack the ability to provide real evidence of potential breaches of legislation, to pin-point the specific way in which apps are leveraging cover and side channels to break Android’s permission system or we would be unable to adapt to an ever-changing ecosystem of Android third-party companies.The works presented in this thesis were partially funded within the framework of the following projects and grants: • European Union’s Horizon 2020 Innovation Action program (Grant Agreement No. 786741, SMOOTH Project and Grant Agreement No. 101021377, TRUST AWARE Project). • Spanish Government ODIO NºPID2019-111429RB-C21/PID2019-111429RBC22. • The Spanish Data Protection Agency (AEPD) • AppCensus Inc.This work has been supported by IMDEA Networks InstitutePrograma de Doctorado en Ingeniería Telemática por la Universidad Carlos III de MadridPresidente: Srdjan Matic.- Secretario: Guillermo Suárez-Tangil.- Vocal: Ben Stoc