Smart contracts hold the potential to revolutionize various industries, but their implementation requires thorough testing due to the associated financial risks. Mutation testing is a powerful technique that can boost the fault-detection capabilities of a test suite, but it can also foster a deeper understanding of smart contract behavior. This work investigates the productivity of mutants with respect to their capabilities in disclosing Solidity issues. Based on these findings, it proposes an enhanced mutation strategy to better assist smart contract auditors during code inspection activities. 9 novel mutation operators are introduced in this paper and 13 existing operators are improved. The results show a $30 \%$ reduction in the number of generated mutants and time savings of $62 \%$, while increasing the set of productive mutants related to issues by $43 \%$ overall. We note that the most valuable type of mutants that could help disclose an issue as a result of manual mutant inspection was increased by $125 \%$.

Fuzzing is a widely used automated testing technique that uses random inputs to provoke program crashes indicating security breaches. A difficult but important question is when to stop a fuzzing campaign. Usually, a campaign is terminated when the number of crashes and/or covered code elements has not increased over a certain period of time. To avoid premature termination when a ramp-up time is needed before vulnerabilities are reached, code coverage is often preferred over crash count to decide when to terminate a campaign. However, a campaign might only increase the coverage on non-security-critical code or repeatedly trigger the same crashes. For these reasons, both code coverage and crash count tend to overestimate the fuzzing effectiveness, unnecessarily increasing the duration and thus the cost of the testing process.

Static code analysis is often used to scan source code for security vulnerabilities. Given the wide range of existing solutions implementing different analysis techniques, it is very challenging to perform an objective comparison between static analysis tools to determine which ones are most effective at detecting vulnerabilities. Existing studies are thereby limited in that (1) they use synthetic datasets, whose vulnerabilities do not reflect the complexity of security bugs that can be found in practice and/or (2) they do not provide differentiated analyses w.r.t. the types of vulnerabilities output by the static analyzers. Hence, their conclusions about an analyzer's capability to detect vulnerabilities may not generalize to real-world programs. In this paper, we propose a methodology for automatically evaluating the effectiveness of static code analyzers based on CVE reports. We evaluate five free and open-source and one commercial static C code analyzer(s) against 27 software projects containing a total of 1.15 million lines of code and 192 vulnerabilities (ground truth). While static C analyzers have been shown to perform well in benchmarks with synthetic bugs, our results indicate that state-of-the-art tools miss in-between 47% and 80% of the vulnerabilities in a benchmark set of real-world programs. Moreover, our study finds that this false negative rate can be reduced to 30% to 69% when combining the results of static analyzers, at the cost of 15 percentage points more functions flagged. Many vulnerabilities hence remain undetected, especially those beyond the classical memory-related security bugs.

Software protection in practice addresses the yearly loss of tens of billion USD for software manufacturers, a result of malicious end-users tampering with the software (”software cracking”). Software protection is prevalent in the gaming and license checking industries, and also relevant in the embedded and other industries. State of the art research in the area of software tamper protection against man-at-the-end (MATE) attackers focuses on the localization of integrity checks. The goal of this paper is a general assessment of the resilience of software self-checking, protected themselves by obfuscations against (1) (automated) detection and (2) (automated) bypass, without deobfuscating the code. Using dynamic taint analysis on a benchmark set of programs, we study how easy it is to detect and bypass combinations of self-checking and various obfuscation transformations. We aim at generalizing these findings across different programs rather than focusing on one particular program instance. To this end, we perform a set of controlled experiments using a data set of real-world programs, the MiBench suite and open-source games, and show that all of these can be broken by dynamic taint analysis attacks. To counter such attacks, we propose and implement improvements to an existing obfuscation implementation. We evaluate the implemented improvement and discuss the security-performance trade-offs.

The malware analysis and detection research community relies on the online platform VirusTotal to label Android apps based on the scan results of around 60 antiviral scanners. Unfortunately, there are no standards on how to best interpret the scan results acquired from VirusTotal, which leads to the utilization of different threshold-based labeling strategies (e.g., if 10 or more scanners deem an app malicious, it is considered malicious). While some of the utilized thresholds may be able to accurately approximate the ground truths of apps, the fact that VirusTotal changes the set and versions of the scanners it uses makes such thresholds unsustainable over time. We implemented a method, Maat , that tackles these issues of standardization and sustainability by automatically generating a Machine Learning ( ML )-based labeling scheme, which outperforms threshold-based labeling strategies. Using the VirusTotal scan reports of 53K Android apps that span 1 year, we evaluated the applicability of Maat ’s Machine Learning ( ML )-based labeling strategies by comparing their performance against threshold-based strategies. We found that such ML -based strategies (a) can accurately and consistently label apps based on their VirusTotal scan reports, and (b) contribute to training ML -based detection methods that are more effective at classifying out-of-sample apps than their threshold-based counterparts.

Man-At-The-End (MATE) attackers are almighty adversaries against whom there exists no silver-bullet countermeasure. To raise the bar, a wide range of protection measures were proposed in the literature each of which adds resilience against certain attacks on certain digital assets of a program. Intuitively, composing a set of protections (rather than applying just one of them) can mitigate a wider range of attacks and hence offer a higher level of security. Despite the potential benefits, very limited research has been done on the composition of protections. Naive compositions could lead to conflicts which, in turn, limit the application of protections, raise false alarms, and worse yet, yield corrupted binaries. More importantly, inadequate compositions of such protections are not tailored for the program at hand and thus the offered security and performance are sub-optimal. In this paper, we first lay out a set of generic constraints for a conflict-free composition of protections. Then, we develop a composition framework based on a defense graph in which nodes and edges capture protections, their relations, and constraints. The conflicts problem together with optimization requirements are then translated into a set of integer constraints. We then use Integer Linear Programming (ILP) to handle conflicts while optimizing for a higher security and lower overhead. To measure the overhead, we use a set of real-world programs (MiBench dataset and open source games). Our evaluation results indicate that our composition framework reduces the overhead by ≈ 39% while maximizing the coverage. Moreover, our approach yields a 5-fold decrease in overhead compared to state-of-the-art heuristics.

Smart contracts are executable programs that enable the building of a programmable trust mechanism between multiple entities without the need of a trusted third-party. At the time of this writing, there were over 10 million smart contracts deployed on the Ethereum networks and this number continues to grow at a rapid pace. Smart contracts are often written in a Turing-complete programming language called Solidity, which is not easy to audit for subtle errors. Further, since smart contracts are immutable, errors have led to attacks resulting in losses of cryptocurrency worth 100s of millions of USD and reputational damage. Unfortunately, manual security analyses do not scale with size and number of smart contracts. Automated and scalable mechanisms are essential if smart contracts are to gain mainstream acceptance. Researchers have developed several security scanners in the past couple of years. However, many of these analyzer either do not scale well, or if they do, produce many false positives. This issue is exacerbated when bugs are triggered only after a series of interactions with the functions of the contract-under-test. A depth-n vulnerability, refers to a vulnerability that requires invoking a specific sequence of n functions to trigger. Depth-n vulnerabilities are time-consuming to detect by existing automated analyzers, because of the combinatorial explosion of sequences of functions that could be executed on smart contracts. In this paper, we present a technique to analyze depth-n vulnerabilities in an efficient and scalable way by combining symbolic execution and data dependency analysis. A significant advantage of combining symbolic with static analysis is that it scales much better than symbolic alone and does not have the problem of false positive that static analysis tools typically have. We have implemented our technique in a tool called MPro, a scalable and automated smart contract analyzer based on the existing symbolic analysis tool Mythril-Classic and the static analysis tool Slither. We analyzed 100 randomly chosen smart contracts on MPro and our evaluation shows that MPro is about n-times faster than Mythril-Classic for detecting depth-n vulnerabilities, while preserving all the detection capabilities of Mythril-Classic.

Oblivious hashing (OH) is an integrity protection technique that checks the (side) effects resulting from the executed code, in contrast to checking the code itself as done by self-checking (SC). SC introduces atypical behavior in the program logic, like reading the code section loaded in memory. Since such atypical behavior can be detected by attackers, OH is more appealing to be employed in practice than SC. However, OH is incapable of protecting a presumable majority of program instructions, those that depend on nondeterministic (input) data or branches, which have to be manually identified and subsequently skipped. In this paper, we extend OH into a practical protection scheme by proposing i) a technique for automatic segregation of deterministic instructions, and ii) a novel extension, Short Range Oblivious Hashing (SROH), for OH to cover control-flow instructions dependent on nondeterministic data. Our SROH technique increases the range of instructions that OH can protect to nondeterministic branches. Moreover, we intertwine OH with SC to cover (nondeterministic) data dependent instructions and enhance the resilience against tampering attacks. We evaluate the performance overhead as well as the security of our scheme using the MiBench dataset and 3 open source games. Our experiments show that the proposed technique yields a 20-fold increase in the median number of protected instructions and, on non-CPU-intensive programs, imposes an overhead of 52%.

The assessment of new vulnerabilities is an activity that accounts for information from several data sources and produces a 'severity' score for the vulnerability. The Common Vulnerability Scoring System (CVSS) is the reference standard for this assessment. Yet, no guidance currently exists on which information aids a correct assessment and should therefore be considered. In this paper we address this problem by evaluating which information cues increase (or decrease) assessment accuracy. We devise a block design experiment with 67 software engineering students with varying vulnerability information and measure scoring accuracy under different information sets. We find that baseline vulnerability descriptions provided by standard vulnerability sources provide only part of the information needed to achieve an accurate vulnerability assessment. Further, we find that additional information on assets, attacks, and vulnerability type contributes in increasing the accuracy of the assessment; conversely, information on known threats misleads the assessor and decreases assessment accuracy and should be avoided when assessing vulnerabilities. These results go in the direction of formalizing the vulnerability communication to, for example, fully automate security assessments.

Popular software applications (e.g. web browsers) are targeted by malicious organizations which develop potentially unwanted programs (PUPs). If such a PUP executes on benign user devices, it is able to manipulate the process memory of popular applications, their locally stored resources or their environment in a profitable way for the attacker and in detriment to benign end-users. We describe the implementation of a tamper detection mechanism based on code self-checksumming, able to detect static and dynamic patching of executables, performed by PUPs or other attackers. As opposed to other works based on code self-checksumming, our approach can also checksum instructions which contain absolute addresses affected by relocation, without using calls to external libraries. We implemented this solution for the x86 ISA and evaluated the performance impact and effectiveness. The results indicate that the run-time overhead of self-checksumming grows proportionally with the level of protection, which can be specified as input to our implementation. We have applied our implementation on the Chromium web-browser and observed that the overhead is practically unobservable for the end-user.

Despite numerous countermeasures proposed by practitioners and researchers, remote control-flow alteration of programs with memory-safety vulnerabilities continues to be a realistic threat. Guaranteeing that complex software is completely free of memory-safety vulnerabilities is extremely expensive. Probabilistic countermeasures that depend on random secret keys are interesting, because they are an inexpensive way to raise the bar for attackers who aim to exploit memory-safety vulnerabilities. Moreover, some countermeasures even support legacy systems. However, it is unclear how to quantify and compare the effectiveness of different probabilistic countermeasures or combinations of such countermeasures. In this paper we propose a methodology to rigorously derive security bounds for probabilistic countermeasures. We argue that by representing security notions in this setting as events in probabilistic games, similarly as done with cryptographic security definitions, concrete and asymptotic guarantees can be obtained against realistic attackers. These guarantees shed light on the effectiveness of single countermeasures and their composition and allow practitioners to more precisely gauge the risk of an attack.

We call changeware software that surreptitiously modifies resources of software applications, e.g., configuration files. Changeware is developed by malicious entities which gain profit if their changeware is executed by large numbers of end-users of the targeted software. Browser hijacking malware is one popular example that aims at changing web-browser settings such as the default search engine or the home page. Changeware tends to provoke end-user dissatisfaction with the target application, e.g. due to repeated failure of persisting the desired configuration. We describe a solution to counter changeware, to be employed by vendors of software targeted by changeware. It combines several protection mechanisms: white-box cryptography to hide a cryptographic key, software diversity to counter automated key retrieval attacks, and run-time process memory integrity checking to avoid illegitimate calls of the developed API.