Vulnerability Detection using Dynamic Analysis

We have been doing a survey on published research papers which is trying to detect security vulnerabilities in programs or applications using dynamic analysis. Our work is mainly focused on mainly four domains – desktop based binary applications, Android applications, embedded or firmware binaries and web related scripting language based applications. This blog post is a high level overview of our upcoming survey paper.

Before going to the details of our findings, we would like to discuss some of the questions which we had in our mind when we started this project

  • When is a bug a security vulnerability?

A defect in a program which causes the violation of at least one of the basic goals of security – confidentiality, integrity and availability (CIA).

  • What is an exploit?

A piece of code, application or the input that takes the advantage of a security bug present in the vulnerable program to gain some information or cause some abnormality in its behavior.

  • How do we differentiate static and dynamic analysis?

Static analysis evaluates code without executing it while dynamic analysis tests the behavior of code during execution. Dynamic analysis enables monitoring of the code during the program execution.

  • Which all are the dynamic analysis techniques we are going to survey?

We are surveying the following techniques:

Dynamic taint analysis  runs a  program and  observes which  computations are  affected by predefined  taint sources such as user  input.

Symbolic  execution  automatically  builds a logical formula describing a program execution path, which reduces the problem of reasoning about the execution to the domain of  logic.

Concolic testing uses symbolic execution in conjunction with an automated theorem proving or constraint solver to generate concrete inputs with the aim of maximizing code in-order to find new bugs. It is also known as hybrid testing.

Fuzzing involves generation of various – expected, unexpected and random inputs to the program to observe its behavior – mainly crash.

Guided fuzzing uses fuzzing in conjunction with symbolic execution or concolic testing or dynamic taint analysis with an aim to improve the efficiency in finding crashes in the program under testing

    • Which are the various vulnerabilities commonly discovered using these analysis
Vulnerability typeDescriptionCIA triad violation
Program crashCould be due to various reasons including logic errors, critical exceptions, segfault etc.A & I
EIP overwriteExtended Instruction Pointer (EIP) points to the next instruction to be executed. If it is overwritten with an arbitrary value, the program can be crashed or can be diverted to take different execution path which is not intended by the developer of the application.A & I
Integer overflowThe result of an arithmetic operation exceeds the maximum or minimum limit of the integer data type used to store the resulting value and hence it resets to zero. An overflow condition may give results leading to crash or unintended behavior.A & I
Out-of-bound readThis vulnerability allows to read the data past the end or beginning of the buffer/array.C
NULL pointer dereferenceThe application dereferences a pointer that it expects to be valid, but is NULL, typically causing a crash or exitA
Double freeThe program tries to call free() twice on the same memory address causes crashA
Use after freeThis bug occurs when the program tries to read the memory which is already freed. This causes program crash. In certain circumstances doubly freeing memory may result in a write-what-where condition, allowing an attacker to execute arbitrary code.CIA
Race conditionThe program is concurrently executed by different processes using a shared resource with improper synchronization leading to data inconsistencyI
Stack based buffer overflowA condition where the buffer being written is full and the adjacent memory locations on the stack are also overwritten. Buffer overflow often leads to crash, execution of arbitrary code execution and subversion of program executionCIA
Format string vulnerabilityThe program uses a function that accepts a format string as an argument, but the format string originates from an external source. Using this vulnerability, an attacker can either crash the program, execute arbitrary code by changing the value of EIP register or read unauthorized informationCIA
Code injectionIf an application allows user input to contain code segment, there is a possibility that artibitary commands can be executed if the input is not properly sanitizedCIA
Cross site scriptingThe web application incorrectly sanitizes the input and result of the injected script is visible when page is generated. XSS is most commonly used for information disclosure. It can be also used to execute arbitrary codeCIA
SQL injectionThe SQL queries used in the server side of the web application includes an incorrectly sanitized user input. Using this vulnerability, the attacker will be able to read/update/delete the information in the database.C & I
Denial of Service attackThe application could not limit the amount or size of resources requested by user, ending up consuming more resources than intended. This would prevent valid users from accessing the application as the entire system resource is consumed by the attackerA
Privilege escalationAn act of exploiting a bug in the application to gain elevated access to resourcesC
Authentication bypassThe presence of backdoors in the form of hardcoded credentials and intentionally hidden authentication interfaces.C

The tabular form of our findings:

#DomainTechniqueMindmap TitlePaper titleVulnerabilities detectedExploits generatedGoogle Link
1AndroidFuzzingAutomated security testing of Android applications on the cloudA whitebox approach for automated security testing of Android applications on the cloudProgram crash
2AndroidFuzzingDroidFuzzerDroidFuzzer: Fuzzing the Android Apps withIntent-Filter TagProgram crash
3AndroidFuzzingIntent fuzzerIntent fuzzer: crafting intents of deathProgram crash
4BinaryConcolic testingAutiomatic Exploit GeneratorAEG: Automatic Exploit GenerationStack based buffer overflow, format stringReturn-to-libc
5BinaryConcolic testingBORGThe BORG: Nanoprobing Binaries for Buffer OverreadsNULL Pointer dereference
6BinaryConcolic testingCAB-FuzzCAB-FUZZ: Practical Concolic Testing Techniques for COTS OperatingSystemsProgram crash
7BinaryConcolic testingCRAXCRAX: Software Crash Analysis for Automatic Exploit Generation by Modeling Attacks as Symbolic ContinuationsEIP OverflowShellcode, return-to-libc
8BinaryConcolic testingMACEMACE: Model-inference-Assisted Concolic Explorationfor Protocol and Vulnerability DiscoveryEIP Overflow, Out-of-bound read, NULL pointer dereference
9BinaryDynamic Taint AnalysisAXGENAutomatic Generation of Control Flow Hijacking Exploits for Software VulnerabilitiesEIP Overflow
10BinaryDynamic Taint AnalysisQ: Exploit HardeningQ: Exploit Hardening Made EasyEIP OverflowROP-exploit
11BinaryGuided FuzzingA Hybrid Symbolic Execution Assisted FuzzingMethodA Hybrid Symbolic Execution Assisted FuzzingMethodProgram crash
12BinaryGuided FuzzingAutomated whitebox fuzztestingAutomated whitebox fuzztestingProgram crash
13BinaryGuided FuzzingBuzzfuzzTaint-based directed whitebox fuzzingProgram crash
14BinaryGuided FuzzingDowserDowsing for overflows: A guided fuzzer to find buffer boundary violationsEIP Overflow
15BinaryGuided FuzzingDrillerDriller: AugmentingFuzzing Through Selective Symbolic ExecutionProgram crash
16BinaryGuided FuzzingTaintscopeTaintScope: A checksum-aware directed fuzzing tool for automatic software vulnerability detectionEIP overflow, Integer overflow, NULL pointer derference
17BinaryGuided FuzzingVUzzerVUzzer: Application-aware Evolutionary FuzzingOut-of-bound read, NULL pointer dereference, Double free
18BinarySymbolic ExecutionDARTDART: directed automated random testingEIP overflow
19BinarySymbolic ExecutionPEX: White Box Test Generation for .NETPex–White Box Test Generation for .NETProgram crash, NULL pointer dereferenec
20BinarySymbolic ExecutionReplayerReplayer: automatic protocol replay by binary analysisProgram crash
21BinarySymbolic ExecutionSoK (state of) the art of war offensive binarySoK (state of) the art of war offensive binaryEIP OverflowROP exploit, Shellcode
22BinarySymbolic ExecutionSymbolic cross checking of data parallel FP codeSymbolic cross checking of data parallel FP codeUse after free
23BinarySymbolic ExecutionUC-Symbolic ExecutionUnder-Constrained Symbolic Execution: Correctness Checking for Real CodeOut-of-bound read, NULL pointer dereference, use after free
24BinarySymbolic ExecutionVeritestingEnhancing Symbolic Execution with VeritestingProgram crash
25EmbeddedConcolic testingAvatarA Framework to Support Dynamic Security
Analysis of Embedded Systems’ Firmwares
Authentication bypass
26EmbeddedSymbolic ExecutionFIRMADYNETowards Automated Dynamic Analysis for
Linux-based Embedded Firmware
EIP overwrite, code injection
27EmbeddedSymbolic ExecutionFirmaliceFirmalice - Automatic Detection of Authentication
Bypass Vulnerabilities in Binary Firmware
Authentication bypass
28ScriptingFuzzingEnemy of the State:A State-Aware Black-Box Web Vulnerability ScannerEnemy of the State:A State-Aware Black-Box Web Vulnerability ScannerXSS, SQLi
29ScriptingSymbolic ExecutionA Symbolic Execution Framework for JavaScriptA Symbolic Execution Framework for JavaScriptCode injection
30ScriptingSymbolic ExecutionFinding bugs in dynamic web appsFinding bugs in dynamic web appsProgram crash
31ScriptingSymbolic ExecutionWalerToward Automated Detection ofLogic Vulnerabilities in Web ApplicationsXSS, SQLi
32ScriptingSymbolic ExecutionWAPTECWAPTEC: whitebox analysis of web applications for parameter tampering exploit constructionXSS, SQLi, DoS

This is the link to the mindmap version of the table: Once the diagram is loaded, you can click on the techniques to expand the papers published under that domain.

The aforementioned mindmap diagram is a visual representation of the hierarchical information of our findings.  The central idea of our survey is the vulnerability detection using dynamic analysis.  As mentioned earlier, we have only considered 4 domains: binary, web/scripting, embedded/firmware and Android, mainly because these are the main areas where some significant amount of work is done in finding vulnerabilities. Each domain is further branched to various sub-branched based on various dynamic analysis techniques.

The pink colour nodes in the diagram represent a publication. It is usually the framework developed by the publishers or the title of the research paper to detect vulnerability using the dynamic analysis technique class mentioned in the parent node.  The publication node is always branched into two 1) outcome and 2) framework.

Outcome describes the type of vulnerabilities they were able to discover using their approach and sometimes their system may generate exploit scripts automatically. In most cases, the exploit scripts are generated for:

  1. Return-to-libc attack: when there is a buffer overflow vulnerability and the stack is WX protected, the processor will refuse to execute code at certain memory locations where program can write, failing to execute the user loaded shellcode in the stack. The attacker can circumvent this protection by combing the address of the system calls code (libc) present in memory which is executable.
  2. Return oriented programming is an advanced version of stack-smashing attack where the attacker gains the control over the call stack and uses the sequence of machine code already present in the memory to change the control-flow to perform arbitrary operations.

The sub branches of the framework describes the details of :

  • The novel path prioritization techniques introduced in the paper in-order to reduce the search space. It could be for avoiding loops and path explosion, target code blocks which  are more likely to be vulnerable due to the presence of system calls etc.
  • The reuse or modification of any existing tools like concolic testing or symbolic execution frameworks, fuzzers, constraint solvers, automatic theorem solvers, previously published approaches etc
  • Inputs from the static analysis techniques to construct call graph, extract plausible vulnerable components using data flow analysis etc
  • Test execution environment: whether the application is run on embedded/mobile hardware directly or on emulator
  • Vulnerability analysis module to verify whether the critical exceptions or program crash can be classified as a true positive
  • Exploit development module in the framework

This is a high level overview of our ongoing work, stay tuned for the comprehensive study of the survey on vulnerability detection using dynamic analysis.


PE Imports

The format of an operating system’s executable file is in many ways a mirror of the operating system.
–Matt Pietrek

PE or Portable Executable is the Windows executable file format. Studying the PE format helps us understand how windows internals function which in turn makes us better programmers. It is even more important for reverse engineers who want to figure out the intricate details of often obfuscated binaries.
Continue reading

Robustly Parsing the PE Header

The first thing needed in order to disassemble a program is (obviously) a place to start. For Windows executables, this is usually discovered by parsing the PE header of the executable. This well known, well documented data structure contains the information about the executable that the program loader will need to execute it. This information includes things such as a mapping of the program’s file contents to memory, which libraries need to be loaded into memory, and what we are looking for, the entry point of the program.
Continue reading

Mobile Botnets

Mobile platforms provide botnet creators with new threats and challenges. There is a significant need for academic papers that analyse, predict, or mitigate the production of mobile botnets. Even designing a new botnet as a warning and proof of concept can be beneficial to security researchers. This article describes the state of research in mobile botnets and suggests open problems for academics to solve.
Continue reading

Dynamic Analysis of Applications

There are several ways to analyze Android applications for suspicious behavior. These are typically categorized as static or dynamic analysis. Static analysis evaluates code without executing it while dynamic analysis tests the behavior of code during execution. This article will discuss current dynamic analysis techniques for Android applications and the open problems associated with them.
Continue reading