Black-box web application vulnerability scanners attempt to automatically identify vulnerabilities in web applications without access to the source code. However, they do so by using a manually curated list of vulnerability-inducing inputs, which significantly reduces the ability of a black-box scanner to explore the web application’s input space and which can cause false negatives. In addition, black-box scanners must attempt to infer that a vulnerability was triggered, which causes false positives.To overcome these limitations, we propose Witcher, a novel web vulnerability discovery framework that is inspired by grey-box coverage-guided fuzzing. Witcher implements the concept of fault escalation to detect both SQL and command injection vulnerabilities. Additionally, Witcher captures coverage information and creates output-derived input guidance to focus the input generation and, therefore, to increase the state-space exploration of the web application. On a dataset of 18 web applications written in PHP, Python, Node.js, Java, Ruby, and C, 13 of which had known vulnerabilities, Witcher was able to find 23 of the 36 known vulnerabilities (64%), and additionally found 67 previously unknown vulnerabilities, 4 of which received CVE numbers. In our experiments, Witcher outperformed state of the art scanners both in terms of number of vulnerabilities found, but also in terms of coverage of web applications.

External vendors develop a significant percentage of Windows kernel drivers, and Microsoft relies on these vendors to handle all aspects of driver security. Unfortunately, device vendors are not immune to software bugs, which in some cases can be exploited to gain elevated privileges. Testing the security of kernel drivers remains challenging: the lack of source code, the requirement of the presence of a physical device, and the need for a functional kernel execution environment are all factors that can prevent thorough security analysis. As a result, there are no binary analysis tools that can scale and accurately find bugs at the Windows kernel level.

Dynamic memory allocators are critical components of modern systems, and developers strive to find a balance between their performance and their security. Unfortunately, vulnerable allocators are routinely abused as building blocks in complex exploitation chains. Most of the research regarding memory allocators focuses on popular and standardized heap libraries, generally used by high-end devices such as desktop systems and servers. However, dynamic memory allocators are also extensively used in embedded systems but they have not received much scrutiny from the security community.In embedded systems, a raw firmware image is often the only available piece of information, and finding heap vulnerabilities is a manual and tedious process. First of all, recognizing a memory allocator library among thousands of stripped firmware functions can quickly become a daunting task. Moreover, emulating firmware functions to test for heap vulnerabilities comes with its own set of challenges, related, but not limited, to the re-hosting problem.To fill this gap, in this paper we present HEAPSTER, a system that automatically identifies the heap library used by a monolithic firmware image, and tests its security with symbolic execution and bounded model checking. We evaluate HEAPSTER on a dataset of 20 synthetic monolithic firmware images — used as ground truth for our analyses — and also on a dataset of 799 monolithic firmware images collected in the wild and used in real-world devices. Across these datasets, our tool identified 11 different heap management library (HML) families containing a total of 48 different variations. The security testing performed by HEAPSTER found that all the identified variants are vulnerable to at least one critical heap vulnerability. The results presented in this paper show a clear pattern of poor security standards, and raise some concerns over the security of dynamic memory allocators employed by IoT devices.

Exploring many execution paths in a binary program is essential to discover new vulnerabilities. Dynamic Symbolic Execution (DSE) is useful to trigger complex input conditions and enables an accurate exploration of a program while providing extensive crash replayability and semantic insights.

Software permeates every aspect of our world, from our homes to the infrastructure that provides mission-critical services.

Smartphones are becoming more and more ubiquitous in the modern world, entrusted with such sensitive information as the user's location and banking data. Since Android is the most widespread smartphone platform, reliable and versatile means for Android application analysis are of great importance. Most of the existing code instrumentation approaches for Android suffer from two important shortcomings: the need for root access and limited support for the new Android Runtime(ART). WeaimtofillthisgapbyproposingARTIST, the Android Runtime Instrumentation Toolkit1. ARTIST is a framework that allows analysts to easily monitor the execution of Java and native code using native instrumentation techniques. ARTIST, to the best of our knowledge, is the first tool allowing monitoring of both native and Java code with the same instrumentation technique. ARTIST provides two methods to locate instrumentation targets. First, it can parse OAT executable files in memory to find classes and methods of interest. This allows monitoring a specific set of Java methods. Second, ARTIST can locate internal structures of the Android Runtime in memory. Monitoring function pointers found in these allows the user to track specific interactions of Java code with the Android Runtime. We evaluate the applicability of native instrumentation for Java code using a set of the most popular Android apps. The results show that over 80% of the tested Java methods are targetable using this approach. The performance impact, estimated with the CaffeineMark benchmark suite, does not exceed 20% and therefore can be considered generally acceptable.