Secure Provision and Consumption
in the Internet of Services
FP7-ICT-2009-5, ICT-2009.1.4 (Trustworthy ICT)
Project No. 257876
www.spacios.eu
Deliverable D2.4.1
Definition of Attacker Behavior Models
Abstract
Models of the behavior of the attacker, be they abstract or concrete, play
a significant role in the test case generation technologies that are being developed in SPaCIoS. This deliverable describes the attacker models that are
being developed and used in the context of SPaCIoS.
Deliverable details
Deliverable version: v1.0
Date of delivery: 01.10.2012
Editors: all
Classification: public
Due on: 30.09.2012
Total pages: 70
Project details
Start date: October 01, 2010
Duration: 36 months
Project Coordinator: Luca Viganò
Partners: UNIVR, ETH Zurich, KIT/TUM, INP, UNIGE, SAP, Siemens,
IeAT
D2.4.1: Definition of Attacker Behavior Models
(this page intentionally left blank)
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
2/70
D2.4.1: Definition of Attacker Behavior Models
3/70
Contents
I
II
Introduction
8
High-level Attacker Models
11
1 Model-based Fault Injection Library
11
1.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Model-based Fault Injection . . . . . . . . . . . . . . . . . . . 13
1.3 Instantiation of Abstract Attack Traces . . . . . . . . . . . . . 19
2 Attacker Behavior
2.1 Attack Steps Injection .
2.2 Vulnerability Injection .
2.3 Attack Results Injection
2.4 Summary . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
23
23
24
25
27
3 Related Work
28
3.1 Mutation-based Security Testing . . . . . . . . . . . . . . . . . 28
3.2 Attacker-behavior Models for Security Testing . . . . . . . . . 30
III
Low-level Attacker Models
31
4 Statecharts, Syntax and Semantics
33
4.1 Formalization . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
4.2 Modelling Risk and Impact . . . . . . . . . . . . . . . . . . . . 36
5 Attack libraries
5.1 Code Injection Flaws in HTML Forms
5.2 SQL Injection Attacks . . . . . . . . .
5.3 Source Disclosure . . . . . . . . . . . .
5.4 File Enumeration . . . . . . . . . . . .
5.5 Remote File Inclusion . . . . . . . . . .
5.6 XML Signature Wrapping Attack . . .
5.7 Cross Site Request Forgery . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
37
37
39
43
44
45
47
52
6 An Evolutionary Fuzz Testing Approach to Detect Cross Site
Scripting Vulnerabilities
54
6.1 Command Injections in Interpreted Languages . . . . . . . . . 55
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
6.2
6.3
4/70
Approach Overview . . . . . . . . . . . . . . . . . . . . . . . . 55
Formalization and Extension to Similar Faults . . . . . . . . . 60
7 Related Work
62
IV
65
Conclusions
References
66
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
5/70
List of Figures
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
Overview of attacker models . . . . . . . . . . . . . . . . . . .
Link between model-based fault injection and low level vulnerabilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Instantiation Objects from the Instantiation Library . . . . . .
Attacker behavioral model example . . . . . . . . . . . . . . .
Low level general injection attacker model . . . . . . . . . . .
Low level SQL injection attacker model . . . . . . . . . . . . .
Low level source disclosure attacker model . . . . . . . . . . .
Low level file enumeration attacker model . . . . . . . . . . .
Low level remote file inclusion attacker model . . . . . . . . .
Expected SOAP Message . . . . . . . . . . . . . . . . . . . . .
Type 1: Wrapping . . . . . . . . . . . . . . . . . . . . . . . .
Type 2: Duplicating . . . . . . . . . . . . . . . . . . . . . . .
Type 3: Removing Signature . . . . . . . . . . . . . . . . . . .
Low Level Attacker Behavior Model of XML Signature Wrapping Attack . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Low Level Attacker Behavior Model of Cross Site Request
Forgery Attack . . . . . . . . . . . . . . . . . . . . . . . . . .
High Level View of the approach . . . . . . . . . . . . . . . .
Overview of the Smart-Fuzzing Approach . . . . . . . . . . . .
Inputs of the smart-fuzzing approach . . . . . . . . . . . . . .
Command Injection: SUT overview from a BlackBox perspective
An example of P T (Om , GO ), a reflection-aware parse tree of
Om with respect to GO . . . . . . . . . . . . . . . . . . . . .
An example of Reflection-Aware Tree Pattern for XSS . . . . .
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
10
12
20
32
40
42
44
46
48
49
49
50
51
52
54
55
56
58
60
61
61
D2.4.1: Definition of Attacker Behavior Models
6/70
List of Tables
1
2
3
4
5
6
Atomic (Syntactic) Operators . . . . . . . . . . . .
Sample instantiation library for SQL injections . . .
Vendor specific queries . . . . . . . . . . . . . . . .
Sample instantiation library for source disclosure .
Sample instantiation library for source disclosure .
Sample instantiation library for remote file inclusion
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
13
38
41
43
45
46
D2.4.1: Definition of Attacker Behavior Models
7/70
Acronyms
AAT
Abstract Attack Trace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
AC
Add Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
ANC
Add New Constant . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
ASLan++ AVANTSSAR Specification Language . . . . . . . . . . . . . . . . . . . . . . . 11
CCF
Comment out Sanitizing or Validity Checking Function. . . . . .14
DIF
Define and Inject Facts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
MBT
Model-Based Testing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
RBAC
Role Based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
SUV
System Under Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
TEE
Test Execution Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
XSS
Cross Site Scripting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
8/70
Part I
Introduction
There are two main test case generation technologies developed in SPaCIoS:
property-driven and vulnerability-driven testing.
1. In property-driven testing, test cases are generated using an abstract
model of the system under test (SUT). The abstract model, written in
ASLan++, includes an attacker model which reflects the capabilities of
malicious entities that interact with the SUT. The steps the abstract
attacker would take need to be concretized in order to be used for
testing.
2. In vulnerability-driven testing, test cases are generated using vulnerability libraries and common attacker behaviors. The attacker model
used for vulnerability-driven testing reflects the common steps needed
to perform an attack, and also the data that would typically touch
upon the vulnerability.
Therefore, in both these technologies, models of the behavior of the attacker, be abstract or concrete, play a significant role. In this deliverable
we describe the attacker models that are developed and used in the context
of SPaCIoS. Figure 1 gives an overview of the attacker models, at different
levels of abstraction, used in SPaCIoS. We briefly describe the components
of this figure.
In property-driven testing, we consider that a behavioral model of the
SUT is available (or, has been inferred). This is shown in the figure with
the arrow labelled ASLan++, entering the Model-Level Analysis box. The
behavioral model is analyzed along with a high-level attacker model. The
most common high-level attacker model for communication protocols is the
so-called Dolev-Yao model [15]. The Dolev-Yao model is an integral part of
the AVANTSSAR platform, and it is indeed supported in SPaCIoS. Furthermore, we consider two extensions to this attacker model:
• In Section 1, we describe the idea of model-based fault injection. Since
we start from a secure model (an attacker behaving according to the
Dolev-Yao Model cannot find any vulnerabilities in the secure model)
the Dolev-Yao attacker model is not enough to generate test cases for a
System Under Validation (SUV). Therefore we extend the Dolev-Yao
attacker model by adding the possibility of fault injections. The attacker then still start from a secure model, but profits now from the
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
9/70
capability of mutating a model to generate test cases and test the SUV
if the SUV is vulnerable. Intuitively, mutating a model means injecting faults into the model in order to reflect common mistakes that
programmers have made (and continue to make) when implementing
security-sensitive systems. The injected faults are at the model level,
i.e. they are meant to capture concrete programming errors in an abstract way. Then, suitable security goals are added to the model.
• In Section 2, we allow the attacker to perform operations that are not
immediately available to the Dolev-Yao attacker. Examples include
guessing certain passwords. This empowers the attacker at the abstract
level, hence resulting in finding more abstract attack traces.
The result of model-level analysis is an abstract trace that needs to be concretized to be useful for testing. We come back to the concretization step
after describing low-level attacker models.
The low-level attacker models we consider in SPaCIoS are not coupled
with any behavioral model of the SUT, and they are not subject to formal
analysis. Instead, low-level attacker models reflect the common steps an attacker would take in order to exploit low-level vulnerabilities, as in, e.g. code
injection attacks. Note that low-level vulnerabilities often cannot be reflected
in the abstract level. Arguably, the cause of many low-level vulnerabilities
is this very fact; e.g. in buffer-overflow faults, the abstract understanding
of the programmer (use a buffer to store data) does not reflect the concrete
behavior of the software (the buffer is used to inject code).
We consider two sorts of low-level attacker models in SPaCIoS. The first
can be seen as an extended Mealy machine, in order to model the attacker
steps. This model is given in Section 4. A number of examples of attack
patterns, specified using our attacker model, are described in Section 5. The
second is a fuzz testing setting, driven by a Genetic Algorithm (GA). This
model is given in Section 6. It tackles command injections in interpreted
languages, e.g. XSS attacks.
These low-level attacker models both come with an instantiation library,
which reflects the attacker data model needed to instantiate the attacker
steps. For example, when performing an SQL injection attack, the attacker
needs to inject an SQL command. The content of the command is derived
from the attacker data model, provided in the instantiation library. The
attacker behavior model drives which values will be picked up. In the case
of GA fuzz testing, a fitness function performs this choice.
The selection of low-level attacker models and their instantiation libraries
can be further refined in a filtering step. This optional filtering step is based
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
10/70
Figure 1: Overview of attacker models
on the available information on the SUT, which can be either provided by
an expert or possibly extracted from the model.
Both property-driven testing and vulnerability-driven testing techniques,
described above, result in traces that need to be concretized with, e.g., the
IP address of the SUT, the username and passwords used to interact with
the SUT, etc. These information are available in the configuration library.
The concretization step receives a trace and uses the configuration library to
generate a concrete test case that can be executed on the SUT.
Structure of the deliverable
The rest of the deliverable is structured in three parts. Part II describes
the high-level attacker models, and contains a section on the previous work
related to these models. Part III describes the low-level attacker models,
contains a number of detailed examples, and also compares our work with
the existing research. We conclude the deliverable in Part IV.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
11/70
Part II
High-level Attacker Models
1
Model-based Fault Injection Library
In order to inject known vulnerabilities to a secure AVANTSSAR Specification Language (ASLan++) model, we developed a library of fault injection
operators. This library is used to both model known vulnerabilities at the
ASLan++ level and to provide specific values for the instantiation of potential Abstract Attack Traces (AATs). After giving an overview of this library
in Section 1.1, Section 1.2 presents some fault injection operators used to
inject faults at the model level. Then, Section 1.3 describes the selection of
specific values to instantiate AATs that exploit the injected faults.
1.1
Overview
In this section we describe model-based fault injection and the instantiation
of abstract values as part of the instantiation of AATs. According to the
overall interaction between the Security Analyst, the SPaCIoS Tool, and the
SUV (see Figure 3 in [50]) model-based fault injection belong to the box “3.
Mutate Model” whereas instantiation of AATs is part of the box “7. Testcase
Generation”.
The model-based fault injection library is a structured collection of fault
injection operators. Such fault injection operators are defined before the test
expert starts to test a web application. To build the fault injection library we
analyzed WebGoat, a web application with well-known and documented low
level vulnerabilities. Each fault injection operator in the library combines
a low level vulnerability with a high level security goal. The relationship
between these two artifacts is that the presence of the low level vulnerability
is likely to lead to the violation of the assigned security goal. Furthermore
we represent these low level vulnerabilities at the model level. The idea is
to represent the fundamental concept of such vulnerabilities at an abstract
model level so that they can be injected into abstract models. In our case
these fault injection operators are applicable to ASLan++ models.
The link between fault injection operators and low level vulnerabilities
is sketched in Figure 2. These low level vulnerabilities are not explicitly
mentioned in Figure 2 but are implicitly given by whose vulnerabilities that
are exploitable by the low-level attacker model. The up going red link is
important at the time the fault-injection operators are designed because they
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
12/70
Figure 2: Link between model-based fault injection and low level vulnerabilities
represent the low-level attacker model related vulnerabilities at the model
level. The down going red link is important during the instantiation of AATs
(see Section 1.3).
Such fault injection operators modify existing models. Some of them
simply add additional parts to the model, whereas others modify existing
parts. In both cases, configuration files might be needed to adapt the fault
injection operator to the syntax and semantic of the underlying model so
that it can successfully be applied.
For now we assume to start with a secure model which is a model where
all traces fulfill the specified security properties. We apply a fault injection
operator to the model with the intention that after the application the model
checker will report a violated security goal. In case an attack trace is indeed
reported the trace is a direct consequence of the application of the fault
injection operator because it was not reported using the secure, non-modified
model. Because of the combination of the violated security goal and the low
level injected vulnerability, a reported AAT is therefore understood as an
interesting test case.
A reported attack trace of the model checker indicates a security problem
at the model level. Due to the missing link between the implementation and
the model (not to confuse with the red link in Figure 2), a violation of a
security goal at the model level does not automatically imply a violation of
the goal at implementation level. Therefore a reported attack trace needs
to be instantiated and executed on the SUV. This step of instantiating
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
ANC
AHC
AC
AVTV
CCF
MS
DIF
RF
AG
13/70
Atomic (Syntactic) Operators
Add New Constant
Add Horn Clause
Add Condition
Assign Value to Variable
Comment out Sanitizing or Validity Checking Function
Modify Signature Definition
Define and Inject Facts
Retract Fact
Add Goal
Table 1: Atomic (Syntactic) Operators
abstract attack traces requires that abstract messages and abstract values
are mapped to concrete ones. In [51] we already addressed the part how
abstract messages are mapped to browser actions. Therefore we focus in the
following subsections on how abstract values are instantiated.
The set of abstract values in an AAT can be partitioned into 2 parts. The
first part consists in values that conform with the specification and these values are handled according to the specification by the web application. The
second part consists in malicious values that have to be injected at some specific location in an AAT. These values do not conform with the specification
of the web application and trigger a malicious effect. After the model checker
has reported an AAT it must be clear which values represent malicious input
and which values conform with the web application specification.
To distinguish malicious abstract values from specification-conforming
abstract values in an AAT, either the fault injection operators have to be
designed in such a particular way that this knowledge is extractable from
the reported AAT, or the AAT has to be post-processed and compared with
intermediate step information produced by the model checker.
The same argument also applies to the step where the effect of the injected
malicious data has to be verified. This knowledge must be extractable from
the reported AAT as well.
1.2
Model-based Fault Injection
The fault injection library consists of a structured set of fault injection operators. These injection operators are built out of atomic (syntactic) operators
(see a non exhaustive list in Table 1).
The atomic (syntactic) operators described in Table 1 are syntactic opera-
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
14/70
tors that can be applied to ASLan++ models. Atomic (syntactic) operators
can be combined to form fault injection operators. To demonstrate how
atomic (syntactic) operators work, let’s have a quick look at an example.
Command injection is the possibility where the operating system executes
commands provided as user inputs. In particular it’s the possibility to inject
malicious commands into the application that are forwarded to and executed
by the operating system. The fault of a malicious command injection is
represented by the command injection fault injection operator that is a combination of several atomic (syntactic) operators: Add New Constant (ANC)
(introducing a new constant to indicate where malicious data has to be injected), Add Condition (AC) and Define and Inject Facts (DIF) (define a
fact named “malicious” and introduce the fact together with the new introduced value under certain conditions, introduce the fact that the modeled
user as dishonest, make all private keys of the dishonest user known to the
intruder with the iknows fact.1 , and introduce a fact that a symbolic function
is implemented using shell commands), Comment out Sanitizing or Validity
Checking Function (CCF) (comment out the sanitizing function so that the
malicious input is used non-modified as given by the user). Let us give an
example of the atomic (syntactic) operators that are used for the command
injection fault injection operator.
ANC atomic (syntactic) operator is used to introduce a new constant
to the model. This operator is useful if e.g. some properties should be derived
from the constant name. An example is trivial:
Listing 1: ANC atomic (syntactic) operator example
symbols
m al i ci ou s _p as s wo r d : text ;
Such a new added constant together with an appropriate malicious fact
enables the test expert to know that this constant represents a malicious
password whenever this constant appears in the reported AAT. Such kind of
information is useful when it comes to the instantiation of abstract values.
CCF atomic (syntactic) operator Depending on the implementation a
command to be executed should be accordingly sanitized before being passed
to the operating system. In the command injection example sanitizing a
1
For any A, iknows(A) facts are predefined facts that make the expression A available
to the intruder i. From this moment on, the intruder may use A for attacking security
goals.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
15/70
parameter x is abstractly represented by introducing the fact
sanitizedCommandLine(x).
It represents an implementation level function to sanitize a value for the
execution in a shell. The CCF atomic (syntactic) operator in this example
addresses such sanitizedCommandLine facts by commenting out or removing
them (see Listing 2).
Listing 2: CCF atomic (syntactic) operator example
% =======================================
% BUILDING BLOCK : Command line sanitizing
% =======================================
s a n i t i z e d C o m m a n d L i n e ( Password );
% =======================================
% Mutation :
%
% s a n i t i z e d C o m m a n d L i n e ( Password ); // commented out
% =======================================
AC and DIF atomic (syntactic) operator The AC atomic (syntactic)
operator is bounded to a DIF atomic (syntactic) operator because a fact
should only be introduced under certain conditions. In our command injection example a password check function to check the “goodness”2 of the
password is represented with a symbolic function. At the implementation
level this function is realized with the help of shell command execution. At
the model level the same functionality is represented with a symbolic function
because we do not further specify how this function is indeed implemented
(besides the fact that shell commands are used). Due to this left-out implementation details we over-approximate the effect of a malicious input by
applying the malicious fact to the symbolic function itself. We introduce the
fact for the symbolic function only if the corresponding input is malicious
and not sanitized. Listing 3 shows how this is implemented in our example.
Listing 3: AC and DIF atomic (syntactic) operators examples
if ( m a l i c i o u s P a r a m e t e r D e r i v e d ( Password ) &
!( s a n i t i z e d C o m m a n d L i n e ( Password ))) {
maliciousText ( checkPassword ( Password ));
}
The combination of the ANC, CCF, AC, and DIF atomic (syntactic)
operators represents a missing, wrongly implemented, or wrongly applied
sanitizing function that leads to a command injection vulnerability. In addition to the list of atomic (syntactic) operators, the fault injection operator
contains a security property which is violated by the presence of the low
2
We assume a “goodness” metric for password is given.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
16/70
level vulnerability. In our example such a security property for command
injection might be specified as given in Listing 4. Informally it expresses
that a response page must not contain malicious values under the following
conditions: (1) parts of the page was generated with shell commands, (2)
the page contains data that is malicious and not temporarily sanitized; or
the page contains output of a faulty function that uses malicious and not
temporarily sanitized parameters.
Listing 4: Simple Security Goal for Command Injection
goals
n oC o mm an d In je c ti o n :
forall Page ParameterSet Function Output . []
(!( getPageFact (? , Page , ParameterSet )
& containedInSet ( ParameterSet , ( Function , Output ) )
& i m p l e m e n t e d W i t h S h e l l C o m m a n d s ( Function )
& m a l i c i o u s T e x t D e r i v e d ( Output )
& !( s a n i t i z e d C o m m a n d L i n e ( Output ))
));
A fault injection operator specifies both a set of atomic (syntactic) operators that represent a low level vulnerability and a high level security goal.
Therefore, if a model checker finds an attack trace that violates a high level
security goal, the applied fault injection operator tells us the reason as well.
Since we start off with a secure model, the injected low level vulnerability of
the fault injection operator is responsible for generating the reported attack
trace.
In order to apply fault injection operators to the model its applicability
requires the understanding of the syntax and semantics of specific parts of
the model. To illustrate that, let us consider the CCF atomic (syntactic)
operator in combination with a Role Based Access Control (RBAC) system.
Having such a system one for instance wants to test the consequences of a
broken authentication mechanism. Therefore it makes sense to comment out
symbolic functions at a server component that represents an authorization
check. Listing 5 shows an exemplary ASLan++ model of the functionality
that requires authorization. Commenting out the authorization function in
Listing 5 results in the elimination of the line ?U->isAuthorizedToView(?A).
To achieve that, applying the CCF atomic (syntactic) operator needs to know
the semantic of symbolic functions, in particular of the function “isAuthorizedToView”. Two simple approaches to achieve this are: (1) tagging symbolic functions, and (2) naming conventions for symbolic function names. In
the current version of SPaCiTE, we follow the naming convention approach.
This functionality is implemented via a configuration file as shown in Listing 6. The configuration file uses the short form “isAuthorizedToView” for
“agent1->isAuthorizedToView(agent2)”. The semantic of defining the short
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
17/70
form “isAuthorizedToView” within the XML structure <ACflow> is “perform a check whether user agent1 is allowed to view the profile of agent2.”.
Providing such a configuration file means that the symbolic authorization
function should be commented out.
Listing 5: Partial RBAC model
select {
% the server acts upon receiving messages from a client
% ViewProfile action
on (? U * - > Actor : viewProfileOf (? A )
& authenticated (? U )
& ?U - > i sA ut h or i ze dT o Vi e w (? A ) % Comment out this to exhibit an attack
): {
% get the profile of A
% select { on (A - > hasProfile (? Profile )):{} }
Actor * - >* U : profileOf ( A );
}
}
Listing 6: Configuration File for CCF atomic (syntactic) operator
< configuration >
< ACflaw >
< funcname > isAuthorizedToView </ funcname >
</ ACflaw >
</ configuration >
The atomic (syntactic) operators in Table 1 can arbitrarily be combined
to express some more complex vulnerabilities. While atomic (syntactic) operators represent small syntactic changes that not necessarily represent a
vulnerability, fault injection operators modify a logical step in the web application and represent a fault that might occur in this step. Examples of such
logical steps are: (1) sanitize input, (2) store input in a data base, (3) read
data from a data base, (4) display data in the browser, (5) use input for a
computation, and so on. Depending on the combination of atomic (syntactic)
operators, fault injection operators can be used to test a web application for
different issues. For the following steps in the workflow, we distinguish two
different approaches: fault injection operators can be used to test a web application against already pre-defined security goals, or against security goals
that are important, but missing.
Generation of test cases for pre-defined security goals
The modeler of the web application has provided at least one security goal
that the model has to fulfill. The modeler thought about a specific goal that
the web application has to achieve. We assume that the model of that web
application is initially secure. This means that no trace in such a model
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
18/70
violates the specified security goal. The goal of the fault injection operator
is to mutate the model in such a way that a model checker will generate
traces that are tailored to this security goal. In this scenario fault injection
operators are selected from the library that address the same security goal as
the one that comes along with the model. Because the security goal is already
present along with the model, the security goal contained in the chosen fault
injection operator is ignored and not injected into the model. The rest of the
fault injection operator (the set of atomic (syntactic) operators) is applied
as usual. Since the fault injection operator does not modify the goal section,
but only the model itself, the model checker potentially reports an AAT
that violates the original security property of the modeler. Such a trace is
enabled by the application of the fault injection operator because beforehand
the model was secure and that trace was not part of the model.
Obviously, this workflow is only applicable if the modeler was aware of
specific security goals the web application has to fulfill. The scenario where
the security goal is missing, is address in the following.
This approach has the difficulty that the fault injections in the model have
to be adapted to the security goal specified by the modeler. To match both
components (the set of atomic (syntactic) operators and the specified security
goal) the fault injection operator needs to be enriched by a configuration file
provided by the test expert. An example of such a configuration file was
already described when the CCF atomic (syntactic) operator was applied to
a RBAC system.
Excursion: generation of test cases for missing security goals
This approach is tailored to scenarios where the modeler has simply forgotten
to think about a specific security goal the web application has to guarantee.
Since the fault injection operator binds a low level vulnerability to a high
level security goal the vulnerability and the security goal can be injected at
the same time. The semantic is that test cases generated for security goals
that are not specified along with initial model, but addresses the security
goal defined in the fault injection operator. Such a missing security goal
could nevertheless be important because traces either in the original model
or traces enabled by the injected vulnerability might violate it.
Using this approach we face the same adaptability difficulties as previously described. The atomic (syntactic) operators need to be adapted to the
underlying model. The same is true for the provided security goal of the fault
injection operator. So far, as already described, this problem is addressed
with configuration files.
Models that miss a security goal as specified in a fault injection operator
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
19/70
are handled in the following way:
1. The corresponding security goal of the fault injection operator only
is assigned to the model and a model checker verifies if the original
model already violates the newly added security goal. In case an attack
trace is reported, the initial model already contains a vulnerability that
violates the security goal. Therefore no additional vulnerability needs
to be injected.
2. Similar, the described vulnerability of the fault injection operator only
is injected into the model. The assigned security goal is ignored for
the moment and the mutated model is model checked. If an attack
trace is reported, it is considered as a test case because the presence of
a injected vulnerability leads to a violation of a different, but already
specified security goal. This scenario corresponds to the paragraph
“Generation of Test Cases for Pre-defined Security Goals”.
3. If neither of the above approaches lead to the generation of an attack
trace, both the vulnerability is injected into the model and the security
goal of the chosen fault injection operator is assigned to the mutated
model. The mutated model is model checked again to find any traces
that violated the newly assigned security goal.
1.3
Instantiation of Abstract Attack Traces
In this section we assume that we successfully applied a fault injection operator to a model and that the model checker reported an AAT. As an
example, let us assume that the model checker reported the AAT given in
the upper part of Figure 3. This AAT needs to be instantiated so that it
can be executed on the SUV. From analyzing the AAT we know that steps
1 - 8 guide the SUV into the state where a vulnerability exists, line 9 is used
to inject the malicious input (indicated by the highlighted and underlined
value “malicious_password”), and the effect has to be verified after step 10.
Besides the fact that all messages have to be mapped to actions executable
in the browser in order to instantiate the AAT, abstract values need to be
mapped to concrete values as well.
Mapping abstract actions to actions executable in a browser is already
described in [51]. In this section we focus on instantiating abstract values.
Retrieving concrete values for abstract ones is implemented with the help of
an instantiation library. This library offers an interface that allows the Test
Execution Engine (TEE) to query for concrete values that fulfill some selection criteria. For such criteria the used model-based fault injection operator
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
20/70
Figure 3: Instantiation Objects from the Instantiation Library
might be considered because it encapsulates knowledge about the low level
vulnerability it represents. This is represented by the down going red link in
Figure 2. In the example shown in Figure 3 the AAT addresses the command
injection vulnerability. Therefore the TEE queries the instantiation library
for concrete inputs that can be used as a command injection. The result of
such a query is a set of runtime objects that are sent back to the TEE by
the instantiation library.
A returned runtime object implements a well defined interface which defines two methods. A method called “getInputData()” that can be invoked to
retrieve a concrete value, and a method “verifyEffect()” that allows to verify,
whether the injected concrete value received from “getInputData()” leads to
the desired effect. Listing 7 shows the corresponding signatures of the methods implemented in Java where SUV represents a connector component that
allows to communicate with the SUV.
Listing 7: Interface of Java Objects in the Instantiation Library
public Object getInputData ( SUV s );
public boolean verifyEffect ( SUV s );
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
21/70
Whenever we reach the step during execution where concrete values have
to be injected, the TEE queries the library for an appropriate runtime object
and invokes the method “getInputData()” of the received runtime object.
The return value of that method is used as the injection value.
More interesting than knowing how concrete values are retrieved is the
question how such values are generated. The returned value can either be
determined statically when the runtime object is compiled, or the value must
be determined at runtime just before it is injected into the SUV. In the
following we give 2 examples of Java runtime objects, one implementing
“getInputData()” for static values, the second one for dynamic values.
A Java runtime object used in the scenario of a Reflected Cross Site
Scripting (XSS) attack might implement a “getInputData()” method returning a static value (see Listing 8).
Listing 8: Static input and verification for a reflected XSS attack
public Object getInputData ( SUV s ) {
String input = ‘‘< script > alert ( ’ ATTACK ’); </ script > ’ ’;
return input ;
}
public boolean verifyEffect ( SUV s ) {
String str = s . switchTo (). alert (). getText ();
if ( 0 == str . compareTo (" ATTACK ") ) {
return true ;
} else {
return false ;
}
}
Because the input is a complete javascript code that can be injected into
a web application running in a browser, this script can be provided as a
static value. Invoking “getInputData()” returns the javascript as a string.
Such a string is successfully injected into a SUV if after the injection a popup
window with the text “ATTACK” is displayed in the browser. Therefore the
corresponding “verifyEffect()” method simply checks if an alert window is
visible that shows the text as specified in the injected script.
Such simple examples are not always possible when more sophisticated
attacks are desired. An example where dynamic value are needed as input
values is an SQL injection. The success of an injection highly depends on the
underlying source code. The source code determines how the SQL query is
constructed and which parts of the query contain user inputs. If access to the
source code is not given, information on how the query is constructed has to
be determined in another way. One possibility is to observe the interaction
between the web application and the SQL server and to record the performed
queries. Analyzing them at runtime reveals information that can be used to
create a situation-specific value.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
22/70
Let’s have a look where dynamic values are useful. Let’s assume that the
web application creates the following query where “user_input” represents
the value read from the browser.
Listing 9: SQL query
SELECT email , passwd ,
FROM members
WHERE email = ’ user_input ’;
A possible malicious SQL attack consists of deleting existing tables in the
SQL database using the query skeleton given in Listing 9. This attack faces
the problem that the table name of the table to be deleted has to be known.
If no access to the source code is given, table names can be determined at run
time by analyzing the communication between the web application and the
SQL server. Doing so one can learn the table name “members” and construct
the malicious SQL input given in Listing 10.
Listing 10: Malicious SQL query
public Object getInputData ( SUV s ) {
// Dynamically determine table name by observing and analyzing
// sample queries
tableName = ...
String input = ‘‘x ’; DROP TABLE ’’ + tableName + ‘ ‘; --’ ’ ’;
return input ;
}
Malicious SQL Query :
SELECT email , passwd ,
FROM members
WHERE email = ’x ’; DROP TABLE members ; - - ’;
Such a malicious query can only be constructed if crucial values can be
learned from the source code or observing the run time behavior of an application, under the assumption that the method “getInputData()” can observe
the SUV.
The method “verifyEffect()” is invoked at the step where the result of
the injection has to be verified. In contrast to the “getInputData()”, that
is focused only on what has to be injected, the method “verifyEffect()” also
implements necessary functionality used to verify if the malicious effect is
present. Because the injected malicious input determines the way how the
effect has to be verified, both information is closely coupled and stored in
the same runtime object. To be able to verify the effect of injected malicious
code, the method “verifyEffect()” must have access to a connector object
that allows access to the SUV. This is represented by the parameter “SUV”
in the signature of the method “verifyEffect()”.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
23/70
Let’s now have a quick look to the scenario how such runtime objects
received from the instantiation library are used. Querying the instantiation
library for runtime objects might result in receiving a set of such objects. The
AAT is then instantiated for each received object. Doing so we can make
use of the same AAT several times by differently instantiation the abstract
values.
2
Attacker Behavior
One of the objectives of the SPaCIoS project is to perform property-based
testing via model-level analysis. Our aim here is not simply to try to check
if a property holds in a specification but also check if a vulnerability can be
used by the attacker in order to violate such a property. This is because
with this analysis we want to consider faults that depend on implementation
errors or vulnerabilities present at provision and consumption time. In this
context, we want to test for attacks like XSS where the classical Dolev-Yao
intruder model is not enough to find them. We thus have to consider also
the behavior of the attacker in order to have the possibility to perform such
testing; to that end, we have defined the ASLan-level attacker behavior as
three different sets of mutants:
2.1
Attack Steps Injection
The mutation involves the addition of steps in the model such as message
sending, data manipulation and other actions performed by the intruder
(identified in the specification by the agent name “i”). These steps correspond to the actions an intruder is supposed to do in order to perform the
attack, e.g. in the brute force attack against a password such actions will
include several attempt to log in the system as a legitimate user. In general,
the added steps are not part of the expected use case of the modeled application but will be present in the abstract trace generated by the model-level
analysis. This kind of mutations could also require the acquisition by the
intruder of some knowledge, e.g. in the brute force example, after several
attempts, in order to get an abstract trace, the intruder should get the real
password, modeling the fact that he was able to guess it. In other words, we
mutate the model in order to inject intruder actions that otherwise would not
appear in the abstract attack traces provided by the model checkers. This is
possible because we add those actions to the specification using agent name
“i”, forcing somehow the model checker to execute such operations as they
are embedded in the transition system (represented by ASLan steps). This
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
24/70
procedure allows us to alter the intruder behavior.
Example In Brute Force attack 3 , some asset (information, functionality,
identity, etc.) is protected by a finite secret value. The attacker attempts to
gain access to this asset by using trial-and-error to exhaustively explore all
the possible secret values in the hope of finding the secret (or a value that is
functionally equivalent) that will unlock the access to the asset. Examples
of secrets can include, but are not limited to, passwords, encryption keys,
database lookup keys, and initial values to one-way functions.
The idea of this mutation is that if the intruder can try to guess access
credentials an arbitrary number of times we can assume that he will also guess
the right credentials obtaining access to the resource/system he is attacking.
In order to model the fact that the intruder can guess the login credentials
and obtain access to a system we mutate the specification adding n times
the login attempt of the intruder:
i −> L o g i n _ e n t i t y : i . username . password_0 ;
[...]
i −> L o g i n _ e n t i t y : i . username . password_n ;
and at the end of the list of attempts the login entity will give access to the
system at the intruder, e.g.:
iknows ( a c c e s s _ c r e d e n t i a l s ) ;
Once the resulting attack trace, if actually found by the model checker, has
been concretized we can probe the implementation with n requests to login
with wrong credentials.4 If the n attempts to login can be executed without
any intervention by the system aiming to prevent repeated requests, e.g.
timeout between attempts or CAPTCHA, we can assume that the system is
likely 5 to be vulnerable to brute force attacks on login.
2.2
Vulnerability Injection
The mutation mostly involves those parts of a specification modeling server
components of the SUT as they usually contain most of the security measures and mechanisms. Indeed, the most common example of this typology
3
http://capec.mitre.org/data/definitions/112.html
Recall that the original model is safe (no attack found) thus in the obtained trace the
injected steps will play a crucial role, and thus this is also reflected in the corresponding
concrete trace
5
As written in http://capec.mitre.org/data/definitions/112.html: “a secret
space that will likely take hundreds of years to explore is likely safe from raw-brute force
attacks”.
4
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
25/70
of mutants is represented by a slightly change in the behavior of the Policy
Decision Point (PDP) of the system. The mutation is designed to obtain a
faulty PDP which likely leads to security vulnerabilities. This category of
mutants often removes parts of condition guards about certificates, permissions and access control policies in general, or replace them with the “true”
or “false” constants. Aim of this set of mutants is to inject a vulnerability
in the specification and verify, via model checking, if the intruder has the
capability to exploit such a vulnerability, i.e. if an abstract attack trace can
be found.
Example Suppose a secure model6 contains the following statement within
entity “S” representing the behavior of the Server components:
on ( ?C ∗−>∗ Actor : r e q u e s t ( ?R) &
?C −> c a n A c ce s s ( ?R ) ) :
{R −> r e l e a s e d T o (C)}
Actor is the server agent name (we are in the scope of Server entity), “C”
is a variable for the client agent name, R is the resource requested by C and
“?C -> canAccess(?R)” is a check on C’s right to access R. If we mutate the
model removing such a check, as in
on ( ?C ∗−>∗ Actor : r e q u e s t ( ?R ) ) :
{R −> r e l e a s e d T o (C)}
we will probably obtain an abstract attack trace from the model checkers
analysis and this is due to the injected vulnerability (i.e. a missing check
over the permission to access R).
2.3
Attack Results Injection
This category of mutants assumes that a particular attack can be performed
e.g. cookie leakage or password theft. The purpose is then to see which are
the consequences with respect to the defined properties of this preliminary
attack. Mutants belonging to this category often imply the addition of information to the intruder knowledge by the assertion of iknows() facts in
the specification in order to formalize the consequences of the preliminary
attack.
Example As already mentioned one example of this kind of mutants is
the cookie leakage. In order to define this mutants we refer to the attack
6
A specification on which the model checkers do not report any abstract attack trace
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
26/70
pattern “Accessing/Intercepting/Modifying HTTP Cookies” 7 . This attack
relies on the use of HTTP Cookies to store credentials, state information and
other critical data on client systems. The first form of this attack involves
accessing HTTP Cookies to mine for potentially sensitive data contained
therein. The second form of this attack involves intercepting this data as
it is transmitted from client to server. This intercepted information is then
used by the attacker to impersonate the remote user/session. The third form
is when the cookies content is modified by the attacker before it is sent back
to the server. Here the attacker seeks to convince the target server to operate
on this falsified information.
We refer to this attack pattern in the sense that we assume the intruder
was able to perform such an attack. Since the result of this attack is to
obtain the cookie we want to reflect in the model the fact that the intruder
has been able to obtain the cookie (e.g. by interception and/or decryption).
To do so, we mutate the model in order to add the cookie to the intruder
knowledge. Then, after the initialization in the Client entity, the following
code:
Cookie := v a l u e ;
has to be changed in:
Cookie := v a l u e ;
iknows ( Cookie ) ;
After this mutation we can already check the model in order to find if
the interception only of the cookie produces spurious attacks i.e. secrecy
of the cookie or about some of its fields. If we get such a trace we apply
another mutation removing secrecy goals for cookies in order to avoid them
(we suppose that at least one other goal is be present in the model). and
then the following code:
goals
( some g o a l _ d e f ) ∗
S e c r e t _ c o o k i e : ( _) { e n t i t y 1 , e n t i t y 2 }
( other goal_def )∗
has to be changed in:
goals
( some g o a l _ d e f ) ∗
%% S e c r e t _ c o o k i e : ( _) { e n t i t y 1 , e n t i t y 2 }
( other goal_def )∗
7
http://capec.mitre.org/data/definitions/31.html
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
27/70
Now, we can check again the model in order to produce interesting abstract attack traces (most likely violations of authorization constraints/goals).
2.4
Summary
Each mutant operator will lead to one or more attack traces having specific characteristics stemming directly from the mutation category (described
in Section 2.1, Section 2.2, Section 2.3) they belong to. We summarized in
this paragraph and their impact in the subsequent concretization phase are
further discussed.
The attack steps injection technique “forces” the model-level analysis
to find abstract traces containing specific intruder steps. The vulnerability
injection approach alters the component of the specification describing the
system in order to allow any involved principal to perform extra actions on
the system. Finally, the attack results injection does not perturb the system
nor the intruder model, it instead gives further knowledge to the intruder.
There is another relevant difference between the three described mutation
approaches: the degree of difficulty in the concretization of the resulting
abstract traces. For the vulnerability injection category the steps composing
the execution of an attack are obtained by the model-level analysis of the
original model, but this is not the case for the other two. This is a huge
issue in terms of the concretization phase. In fact, in the first case the
message exchange schema of the abstract trace follows the original model
(which should be strongly bounded to the real implementation of the SUT,
assuming the good programmer axiom), for the attack steps and the result
injection case, there may be no way to concretize the abstract trace. This
could be due to the impossibility to perform/concretize the attack steps
injected in the model (steps injection) or to come up with a set of messages
and actions which reproduces the condition of the preliminary attack (attack
results injection). In other words, in the attack step/result injection cases
the mutations add to the original model intruder behaviors or information
which may not have a respective concrete representation. For example, in
the case of the mutation representing the brute force attack, an intruder
could fail to guess any secret. The Brute Force mutant operator is not a
good example to show that AATs generated by mutants belonging to the
attack step injection category may be impossible to concretize. This is due
to the fact that the last action of the intruder, which include the potentially
impossible step to concretize (i.e., the fact the intruder was able to guess the
secret), is not really necessary. Indeed, the first n login attempts are already
sufficient to conclude that the system is likely to be vulnerable to Brute Force
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
28/70
attacks. Nevertheless, we cannot exclude that in other cases there could be
steps impossible to concretize that are necessary to conclude that the SUT
is vulnerable.
On the contrary, the Cookie leakage example is a perfect example to show
the impossibility to concretize an AAT. Providing the intruder with a piece
of information, in this case through the addition of an iknows fact, implies
the fact that at implementation level the intruder is able to steal that piece
of information. This is not always the case and, in particular, it might be
impossible for the intruder to obtain the cookie. Thus there might be no
ways to concretize something that is impossible at implementation level.
These kind of mutant operators, belonging to the attack result injection
category, might be difficult to use directly for testing the implementation,
nevertheless they are useful for risk analysis purposes. Indeed it is possible
to use them to analyze the possible the collection of abstract attack traces
that can be obtained by applying them to the model. This eases the job
of security analysts who have to decide which countermeasures are worth
employing for the system. Even if this is a typical task for earlier modeling
phases, it may turn out that some countermeasures not adopted are indeed
useful and have to be actually implemented.
3
Related Work
We briefly discuss the related works on mutation-based security testing, and
attacker behavior models for test case generation.
3.1
Mutation-based Security Testing
Our work is at the intersection between Model-Based Testing (MBT) and
penetration testing (pentesting). As we rely on mutation operators to introduce implementation-level vulnerabilities into the secure model and on
model-checkers to generate attack traces, we describe here works related to
mutation testing and security testing from a model-checker.
On one hand, security testing is usually performed by penetration testers
that either use manual techniques, based on their knowledge and by following
guidelines like the OWASP testing guide8 , or automated techniques thanks
to penetration testing tools9 . Such tools differ from our work as they do
not rely on models for generating test cases. In [17] such “point-and-click
pentesting” tools are evaluated and the authors report that the crawling
8
9
https://www.owasp.org/images/5/56/OWASP_Testing_Guide_v3.pdf
http://sectools.org
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
29/70
part (discovering new pages) is a critical and challenging task for these tools
that determines the overall ability to detect vulnerabilities by black-box web
vulnerability scanners. One way to overcome this weakness is to use a whitebox testing approach, dedicated to applications written in a specific language.
For example, the Ardilla tool [30] looks for SQL injections and XSS attacks
in php applications but does not address the problem of user interactions.
The Apollo tool [6] does address user interactions but is restricted to php
crashes or malformed html outputs. Such white-box testing tools combine
concrete and symbolic (concolic) executions [23] by using a modified php
virtual machine.
On the other hand, formal models and model-checkers have been used for
test case generation since at least 1998 [3], in a variety of contexts that has
been surveyed elsewhere [22]. Most of this work concentrates on generating
test cases that satisfy structural criteria on the model (e.g., state coverage,
transition coverage, MC/DC coverage). As there is still no evidence of a
strong relationship between such coverage criteria and fault detection effectiveness [34], we choose to rely on a domain-specific fault model. Our work
is closely related to mutation testing [14, 28]. Even though mutation testing usually aims at assessing the effectiveness of a test suite to detect small
syntactic changes introduced into a program, it can also be used to generate
test cases, instead of assessing them. This idea was successfully applied for
specification-based testing from AutoFocus, HLPSL or SMV models in the
security context [2, 9, 13, 60]. Our work differs in that we start by real
vulnerabilities in web applications and correlate them with specific mutation
operators. That also means that in contrast to syntactic mutation operators,
our mutation operators are fault injections and therefore rather semantic mutation operators. In the area of semantic mutation testing, J.A. Clark et al.
describe in [12] an approach where they semantically change the language in
which a description is written. An example is the mathematical division of
integers. Depending on the specification language, e.g. -12/5 has value -2 or
-3. Their semantic mutation operators address misunderstandings of the description language. In contrast to [12] we represent fault-injection operators
as semantic mutations of the implemented web application logic.
In addition, we do not stop after test generation but also provide a semiautomatic way to execute the generated test cases on real implementations,
in our case, a web application.
More recently, the authors of [4] have described work closely related to
ours but for protocols instead of web applications. They start from an already
insecure model described at the HTTP level and provide an automatic testing
approach that relies on a mapping from each abstract HTTP element in
the model to HTTP messages suitable for the SUV. The fully automatic
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
30/70
procedure is achieved at the price of describing the model at the HTTP
level. Even though this low level description is acceptable for protocols, we
think it is more suitable to describe web applications at a higher abstraction
and ask, if needed, the test expert to provide additional information during
the testing procedure.
3.2
Attacker-behavior Models for Security Testing
The test cases generation process in the context of model-based testing for
security purposes is a task which depends on the attacker model considered.
There are three main approaches that have been taken so far.
The attacker, or intruder, can be part of the model as in [5], where it
is modeled as a standard Dolev-Yao. We follow a similar approach as the
Dolev-Yao intruder is built in the AVANTSSAR’s backends, but we extend
the intruder capabilities by applying mutant operators injecting intruder’s
actions. This allows more attacks to be found in the model level, compared
to a standard Dolev-Yao as used by [5]; the cost one has to pay is a more
challenging concretization step.
The second approach consists in considering a separate model for the
attacker, possibly used along with a behavioral model for the SUT for the
purpose of test case generation. An example of this approach is [42] where the
authors have three separated models: system, implementation and attacker
models. Another difference between the this approach and our work on the
ASLan attacker is the abstraction level at which intruder actions have been
defined. We considered more abstract actions while in [42] the attacker works
closer to the implementation level, following the implementation model. In
this latter case, the attacker model can therefore be directly used for (semiautomated) test case generation. This is more related to the work on state
charts described in Section 4.
Finally, one could exclude the attacker and test the functionality of a
(security-sensitive) system, given its behavioral model. An example of this
last scenario can be found in [37].
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
31/70
Part III
Low-level Attacker Models
The modeling approach is an efficient way of targeting specific kinds of vulnerabilities, such as logic errors in the application infrastructure. When
it comes to some well known vulnerability types however, such as cross site
scripting or SQL injection, the vulnerabilities themselves have to be modeled,
reducing the cost-effectiveness of the testing. An alternative approach would
be the actual testing in the system of the vulnerabilities using well-known
attack patterns to target specific vulnerabilities in a black-box approach.
While the results would only be heuristic, it would help a security expert to
localize possible security holes in application and allow more efficient testing.
Approach A: state charts and attack libraries (see Section 4 and
Section 5) We suggest the creation of a framework for the use of extended
state charts that will guide a security expert in the testing of the application,
while at the same time allowing semi-automated testing by providing the
possibility of using tools which are able to parse these state-charts. The
processes for the use of these low level attacker models will be discussed in
the deliverable 3.3.
These state charts will describe generic attack approaches for well-known
vulnerabilities, while placing generic information used by the model, such
as attack strings, in instantiation libraries and further allowing the use of
system specific information located in configuration files.
To motivate this approach, consider the following example. Let IO be
a list of triples of the form (Input, Output, Vendor) where all elements are
strings. Let U RL and Cookie two parameters (also strings). We define
snd(U RL, Cookie, F ields, M ethod) as a function producing an HTTP request message with the given parameters for target URL, eventual cookies,
fields and the request method (i.e. POST, GET etc.). Similarly rcv(s) models
an HTTP response, with content s.
Now consider the state-chart depicted in Figure 4. We use a Mealy machine with parametric inputs and outputs, local variables and guards, similar
to a UML State-Chart to model the attacker behavior. In other words, we
think of an adversary as a reactive model to the HTTP responses of a webapplication. This State-Chart can be used for modelling a wide range of
low-level vulnerability-driven attackers. Assume for example that the contents of IO are among others:
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
32/70
Figure 4: Attacker behavioral model example
(0 , MySQL Error, MySQL), (”, MSSQL Error, Microsoft)
representing the injection on a field (say a tic for a particular vendor, or a
double tic for another based on information available in SQL Injection cheat
sheets) and the expected output (in case of a vulnerability presence). Then
the automata execution should be interpreted as follows: first, the adversary
sends an HTTP request to the URL containing the application 10 , and a given
cookie (containing for example session information, but optional). Then a
primitive function listFields will parse the actual response state for form fields
and the results are saved to the variable x, which contains triples of the form
(Field, Method, Target). Then the adversary will send an HTTP request for
each field (to its target) and for each pair of input string contained in IO by
appending this string to the value of the field. If the expected value is found
in the corresponding HTTP response, expressed by the condition E(s), then
the adversary succeeds in finding a vulnerability. Otherwise it keeps trying
until exhausting all fields/strings in IO.
Notice that the model of Figure 4 can be used for discovering reflected
cross-site scripting simply by defining an appropriate IO list. We call U RL
and Cookie a configuration and IO an instantiation library. We will formalize
this approach in Section 4 and give more examples in Section 5.
Approach B: evolutionary fuzzing In Section 6, attacker behavioral
model is driven by a Genetic Algorithm that evolves SUT input sequences.
The selection of interesting input parameters is done via a data-flow analysis
10
We consider a single page of an application per execution
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
33/70
over slices of the SUT model. Those slices are either selected by an analyst
or by a random length limited exploration of the SUT model.
Values of those interesting input parameters are instantiated from an
Attack Input Grammar and evolved through the Genetic Algorithm (GA)
operations (mutation and crossover). Test verdict is related to the considered
vulnerability (only Cross Site Scripting is targeted yet) and derived from
observable tree patterns in the SUT outputs. In addition to test verdicts, a
fitness function assesses the most interesting observed test sequences.
4
Statecharts, Syntax and Semantics
We give a formal syntax and semantics for attacker models. Attacker models
can be seen as an extension of Mealy machines [35] with guarded transitions
and variables. Similarly, one can see similarities between the attacker models
and UML statecharts. The formal syntax and semantics given below however clarifies the differences between attacker models and Mealy machines or
UML statecharts (there are many different semantics for UML statecharts;
e.g. see [56, 20]). In particular, attacker models do not have a notion of
composition.
We remark that the purpose of our formalization of the syntax and semantics of attacker models is to give a basis to correctly interpret and execute
them. Currently we do not intend to perform any formal reasoning on attacker models. For that purpose, it is then enough to consider non-concurrent
models representing the reactions of an attacker to a system’s outputs. Moreover, we are interested in modelling single monolithic attacks and therefore
a notion of attack composition is out of scope.
4.1
Formalization
Fix a term algebra Σ, where ∈ Σ0 and snd, rcv 6∈ Σ1 . We write TΣ(V ) for
the set of terms induced by Σ using a finite set of variables V that is disjoint
from Σ. A substitution σ is a total function that maps V to Σ0 . We now
introduce guards and commands.
• A guard g is a term in TΣ(V ) .
We assume access to an oracle Ω: Ω is a computable function where
for any guard g and substitution σ, we have Ω(gσ) ∈ {0, 1}.
• A command c is a term in TΣ(V ) .
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
34/70
We assume access to a transformation function θ: θ is a computable
function where for any command c and substitution σ, θ(c, σ) is a
substitution.
An input event is either or of the form rcv(m) with m ∈ TΣ(V ) . An
output event is either a finite (possibly empty) list of commands, or of the
form snd(m) with m ∈ TΣ(V ) . We write for the empty sequence.
An attacker model is a finite directed graph whose edges are all annotated
with triplets of the form [g]i/o where g is a guard, i is an input event, and o is
an output event. We write i/o as a trivial shorthand for [true]i/o. Moreover,
one or more nodes of the graph are assumed to be designated as initial states.
We give an operational semantics for attacker models. Given an attacker
model, its configuration is uniquely determined by a node that denotes the
current state of the attacker, and a substitution σ that records the values
assigned to the variables.
Let s1 and s2 be two nodes in an attacker model, where s1 is connected
to s2 with an edge annotated with [g]i/o. The attacker model “moves” from
x/y
configuration hs1 , σ1 i to configuration hs2 , σ2 i, denoted hs1 , σ1 i ⇒ hs2 , σ2 i,
according to the four rules given below.
Configurations change according to the attacker’s reactions to system
outputs. Formally, input and output actions are pairs written x/y that can
be respectively snd and rcv actions, or if no output/input action takes
place.
The semantics of an attacker model is then the set of all sequences of
input/output actions that are produced by the attacker model. Below, we
write snd 6∈ o to denote that o does not contain any term constructed using
snd. This will be useful to distinguish the case where an adversary produces
an output (and thus a snd action) and the case where he is merely doing
internal computations.
• Rule 1 :
[g]/o
s1 → s2
Ω(gσ1 ) = 1 snd 6∈ o
/
hs1 , σ1 i ⇒ hs2 , θ(o, σ1 )i
where the list of commands in o are composed sequentially as in an
imperative programming language. That is, if o = o1 , . . . , on then:
θ(o, σ1 ) = on (. . . o1 (σ1 ) . . . )
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
• Rule 2:
s1
[g]/snd(m)
→
hs1 , σ1 i
• Rule 3:
s1
[g]rcv(m)/o
→
hs1 , σ1 i
s2
35/70
Ω(gσ1 ) = 1
s2
/snd(mσ1 )
⇒
hs2 , σ1 i
Ω(gσ̂) = 1 snd 6∈ o
rcv(mσ̂)/
⇒
hs2 , θ(o, σ̂)i
where σ̂ is any substitution such that σ̂(v) = σ1 (v) for any variable
v ∈ V that does not appear in m.
• Rule 4:
s1
[g]rcv(m)/snd(m0 )
→
hs1 , σ1 i
s2
Ω(gσ̂) = 1
rcv(mσ̂)/snd(m0 σ̂)
⇒
hs2 , σ̂i
where σ̂ is any substitution such that σ̂(v) = σ1 (v) for any variable
v ∈ V that does not appear in m.
Note that a transition annotated with [g]rcv(m)/o may apply only if the
received message can instantiate the variables in m (if any), and the guard
g is satisfied after the instantiation. Otherwise, the received message will
be ignored, i.e., the attacker model consumes the received message without
making any transitions. This completes the attacker model with respect to
incoming system messages, in case some messages are not explicitly covered.
To illustrate the semantics consider the example in Fig. 4. The first
transition is covered by Rule 2 since the attacker starts the interaction with
the system by sending a message requesting a particular URL. In the first
node there are three possible actions to be taken, however initially only the
action guarded by [undef(i)] is satisfied since the variable i has not been set.
This transition is covered by Rule 3, since there is no immediate reaction from
the attacker to the received message, but only a change in the configuration.
With the new configuration (the new values of x, l and i) we have two possible
transitions: i) to the final state, and ii) the to the third state.
The transition to the final state is covered by the Rule 1, since there are
no more fields to check (or the page pointed by URL doesn’t contain any
fields), and the attacker gives up by outputting failure. The two transitions,
outgoing and ingoing, to, and from, the third state are covered by Rule 1.
There is no reaction from the attacker, only a configuration change for the
variables j, l0 (for the outgoing vertex), and i (for the ingoing vertex).
In the upper-right state the ingoing transition is covered by Rule 2. In
this case the attacker sends a message with the j-th payload in IO (to be
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
36/70
delivered to the i-th field in the page) without receiving a message (in that
case this transition would be covered by Rule 4).
The outgoing transitions are both covered by the Rule 3, since the attacker
receives a message and change his state according to its content. If the
message doesn’t contains the expected output the state will change in order
to check the next payload or the next field; on the other hand if the attacker
receives the expected output he has found a vulnerability thus outputting
success.
4.2
Modelling Risk and Impact
So far we have considered attacker models with no notion of risk, impact
or skill level involved. This aspect is however interesting since it allows one
to prioritize tests according to the potential impact of vulnerabilities, as it
will be discussed in Deliverable 3.3. In this subsection we comment briefly on
possible extensions to attacker models and their semantics in order to include
the aforementioned aspects. Note that this discussion is very preliminary:
details on how the impact, risk and likelihoods are calculated are yet to be
determined.
The meta-level Let L = {M1 , . . . Mn } be an attacker library (see for
example Section 5). where Mi are attacker models. One can associate a pair
(c, s), with c ∈ N and s ∈ N+ , to each model. Here, c represents the loss
the user of the SUT would incur if the attack is successful, e.g. expressed in
Euros. And, s is as the attacker skill level required to perform the attack,
e.g. in a scale from 1 to 5. We (negatively) correlate s to the likelihood of the
attack being actually performed by arguing that: a higher s means a more
challenging task for the attacker, hence less likely to be performed 11 .
The pair (c, s) would allow one to prioritize testing the models in L based
on their impact or the skills of the attacker involved in them. We can also
choose attacker models out of L based on the risk factor associated to them;
that is c × 1s . Note that this number refers to the risk the attacks in L induce
from the point of view of the user of the SUT.
Further extending automata Another extension possibility is to include
likelihood annotations directly in the attacker model’s transitions. For instance, one could add a likelihood factor p ∈ ]0, 1] denoting the probability
11
A possible extension would be to consider automata with more than one goal: we could
associate losses and skills to nodes instead of globally to the Mealy machine. However for
simplicity we do not consider this possibility for the time being.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
37/70
than an attacker performs a certain configuration change. This could be
applied to situations where a step, although potentially leading to a vulnerability discovery, could expose the attacker. An interesting consequence of
having a likelihood factor is that, by interpreting it as a priority order, a
non-deterministic automata becomes automatically deterministicif the likelihoods associated to the outgoing transitions of each node for the same action
(if any) are different.
At this point of the project we need to further explore this extension
possibilities; notice however that they are independent to the syntax and
semantics so far and would not invalidate the considered attacker models.
5
Attack libraries
5.1
Code Injection Flaws in HTML Forms
In this section, we describe a general approach to exploiting different kinds of
injection flaws, and provide low level attacker model that is able to perform
a wide range of injection attacks against web applications.
Injection flaws have become one of the most critical type of vulnerability in web applications (number one and two risks in Application security
OWASP Top 10 201012 ). While injection flaws in web application come in
various forms, Cross Site Scripting and SQL Injection are among the most
famous examples.
The basic principle for exploitability shares a common form in many cases:
The input interface contains one or more parameters which are not properly
filtered and these parameters get executed by some back-end or, in the case
of reflected cross site scripting, by the client itself in the returned page. By
sending commands appropriate to the targeted execution engine and analyzing the returned content it is possible to discover indicators of the presence
of vulnerabilities, though the quality of indicators greatly depends not only
on the output analysis, but also on the input used. It is also important to
note, that this technique covers only those kinds of injection attacks that
leave an indication of the flaw in the returned content after the vulnerability
was exploited. Therefore attacks such as stored cross site scripting or blind
SQL injections are, in general, not covered by this attacker model.
Approach The common mechanism for the type of code injection described
above allows a general attack process which takes advantage of the present
flaw, irregardless of the targeted execution engine. It influences only the
12
https://www.owasp.org/index.php/Top_10_2010-Main
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
Input
’42
&quot;42
“42
38/70
Output
Unexpected end of command in statement
Unexpected end of command in statement
Unexpected end of command in statement
Table 2: Sample instantiation library for SQL injections
commands being sent as part of the exploitation, as well as the indicators
for the flaw present in the returned content. In the context of the low level
attacker model presented here, the commands being sent can be abstracted
as inputs, the indicators as outputs. In the case of this model, these are
provided by an external instantiation library and worked through iteratively.
Alternative methods for providing these are possible, such as the approaches
in 5.2, 5.3 or 6. This allows the use of the model for a wide range of attacks
by choosing the right instantiation library based on the expert’s knowledge
of the SUT.
The attacker model here presented allows a methodological approach to
test the presence of injection vulnerabilities of the aforementioned type in
the input forms located in the page at that URL. It is worth noting that this
approach limits the use of attacker models to web pages containing static
forms, excluding approaches such as webservices using json.
Instantiation library The instantiation library contains a set of tuples
consisting of input and output. The input contains values inserted into the
target fields containing some kind of injectable code. The output contains
strings which can be used in order to verify that the injection was successful.
Some sample entries can be found in table 2.
Configuration values The model presented below uses the following values from a configuration description:
• URL: Contains the target URL.
• Cookie: Contains an authentication cookie for the application.
Model Given a specific URL of a web application retrieved from the configuration, the low level attack model depicted in figure 5 uses the primitive
snd to send a request to the web server. The server response which returns
the content (in this case using the parametrized rcv message), which is used
by the attacker to assign variables used to count the number of forms in the
returned page (using the listForms and length primitives.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
39/70
In the next step, all fields contained within a form are fetched (using
listFields). By retrieving the input parameter from the instantiation library selected, and embedding that attack string into an input field, an attack
request can be generated. Executing such a request returns content from the
server. By parsing this content for the corresponding indicator available from
the instantiation library (output), it is possible to find out whether an attack
was seemingly successful.
If this is done in turn for all available forms, fields as well as all possible
elements of the instantiation libraries attack string in an iterative manner,
an exhaustive list of attack requests can be generated. As soon as such a
seemingly successful attack has been found, the automata reaches a final
state and notifies the security expert. The expert is then able to test this
conjecture either by running additional tests against the field, possible by
using the same process described with additional patterns from either the
same, or a different instantiation library, or by using further manual tests.
The process in this case largely depend on the targeted system as well as the
information available.
5.2
SQL Injection Attacks
While the general approach presented above can be used in order to fully
automate the vulnerability testing process in some cases, if protection mechanisms are in place a security expert is needed. As discussed before, the
general injection model can be used to test the potential presence of an SQL
injection vulnerability, based on the presence of certain default database errors that will vary according to particular vendors.
Approach To perform the actual SQL Injection implies however expert
knowledge that is difficult to automatize. But if an injection is possible, it
would be desirable to automatize the tedious process of testing for common
known injections in order to gather information about the vulnerable system
(to query for the administrator DB password, OS execution, list of tables,
users etc.).
Instantiation library The instantiation library is extended by adding an
additional parameter to the tuples called vendor, which denotes the database
which can be identified using the output parameter. Additionally the instantiation library contains a mapping function Att, which maps each vendor to
a list of queries which contain useful information. A small example can be
seen in table 3.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
Figure 5: Low level general injection attacker model
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
40/70
D2.4.1: Definition of Attacker Behavior Models
41/70
Att:Vendor→Value
Vendor
Value
master..xp_cmdshell ’net users’
MS SQL
SELECT * FROM information_schema.tables
SELECT name FROM master.sys.sql_logins
SELECT * FROM informaMySQL
tion_schema.tables
SELECT user FROM mysql.user
SELECT @@version
SELECT
usename
FROM
PostgreSQL
pg_user
SELECT
datname
FROM
pg_database
Table 3: Vendor specific queries
Configuration values The model presented below uses the following values from a configuration description:
• URL: Contains the target URL.
• Cookie: Contains an authentication cookie for the application.
Model In Figure 6 we model this situation by extending the general injection model presented in 5.1. Once a vulnerability has been identified, which
also returns a guess for the type of database system used in the vendor property, the user is queried (using the askUser primitive) for a transformation
function λ which allows the attacker model to send correct SQL commands
to the database of the web application.
Having identified the vulnerable query type, and being able to correctly
execute SQL commands by means of the user supplied transformation function λ, the Att map of the instantiation library is queried for useful information commands for the identified type of database. Each such command is
executed on the database back-end and the result is saved in a list called list.
This shows a different strategy from the general injection model presented in
5.1, where the models intent was the discovery of a single vulnerability, after
which the automata halted. After retrieving all useful information the list is
returned to the user and the automata reaches a final state.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
Figure 6: Low level SQL injection attacker model
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
42/70
D2.4.1: Definition of Attacker Behavior Models
Φ
s/$/%00/
s/$/;/
s/.java/.jav
43/70
Ψ
m/<?php/
m/#!\//
m/include java./
Table 4: Sample instantiation library for source disclosure
5.3
Source Disclosure
A specific type of information disclosure is source disclosure. Sometimes it
is possible to trick either a web application or a web server into not parsing
the script content of a file, but rather display it directly to the user. While
there are a variety of different mechanisms that can trigger this, one common
approach revolves around abusing the script detection mechanism of the web
application, often by using alternative file names that describe the same file,
but are not detected as scripts (e.g. due to the file ending being different).
One such example is appending the NULL character to the filename.
Approach The URL referencing the target document, either as part of the
base URL or in one of the parameters, is modified in different ways using
transformation functions in order to slide the document past the interpreter.
The response by the server is tested using verification functions which, based
on the type of transformation function used, try to determine if the document
contains unparsed source code.
Instantiation library Let Φ be the URL transformation function described above. It receives a URL as an input, and outputs another URL. It
is strongly coupled with the verification function Ψ, which parses the output
received from the server in order to determine whether it includes unparsed
source code and returns a boolean. Both are stored in the instantiation library as tuples. Some example entries in the form of regular expressions can
be seen in table 4.
Configuration values The model presented below uses the following values from a configuration description:
• URL: Contains the target URL.
• Cookie: Contains an authentication cookie for the application.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
44/70
Model The model displayed in figure 7 starts by iterating over the transformation function Φ from the instantiation library. It applies each function
Φ to the URL. That modified URL is then sent to the server, and the response is then validated using the verification function Ψ. If Ψ returns true,
therefore suggesting some kind of unparsed back-end code was found, then
the modified URL is added to a list. After querying the server using all
transformed URLs, that list is displayed to the user and the model reaches
a final state.
Figure 7: Low level source disclosure attacker model
5.4
File Enumeration
In order to conduct a security assessment, it is necessary to perform an analysis of the attack surface of the web application. If a model is either incomplete
or not available, it becomes important to create a map of those parts of the
web application that can not be reached by simple web crawling. This includes forgotten administration pages, setup files or readable configuration
files.
The information so gathered, can then used in later steps to identify
security issues, either manually or by using the newfound URLs as input for
other low level attacker models.
Approach In this model a brute-force approach will be used. The server
will be queried for a list of files and directories. By checking the response
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
45/70
input
/.svn
/phpinfo
/web-console/Invoker
Table 5: Sample instantiation library for source disclosure
code of the server it becomes possible to create a list of files on the server.
While this approach is by no means exhaustive, it is a simple mechanism
which allows to easily find default files remotely.
Instantiation library The instantiation library consists of a list of files
and directories under a parameter input. Some sample entries can be found
in table 5.
Configuration values The model presented below uses the following values from a configuration description:
• URL: Contains the target application URL. The values from the instantiation library will be appended to this URL.
• Cookie: Contains an authentication cookie for the application.
Model The low level attacker model for file enumeration, displayed in figure 8, iterates over all the input from the instantiation library. For every
value therein contained, it creates a new request by appending that value to
the URL from the configuration input. It then checks whether the response
code of the server for that query indicates that the file or directory exists
(see Γ).
If the document exists, then its URL is stored in a list called files (which
is initialized in the first transition). After testing all the inputs from the instantiation library, that list is returned to the user and the automata reaches
a final state.
5.5
Remote File Inclusion
The remote file inclusion (RFI) attack exploits vulnerable code in web applications in order to load and execute resources from a remote server. This
security issue has been exploited by worms and botnets, where a compromised server searches for servers containing well-known remote file inclusion
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
46/70
Figure 8: Low level file enumeration attacker model
Φ
λ(x, y) : (x.name, y)
λ(x, y) : (x.name,“import ”++y)
λ(x, y) : (x.name,“eval ”++y)
Table 6: Sample instantiation library for remote file inclusion
vulnerabilities using search engines, and then exploits the new server in order
to compromise the new system.
Approach Similar to the injection attacker model described in 5.1, a web
page is parsed for all possible input fields. These fields are then targeted
using well-known remote file inclusion attack vectors pointing to the local
system. All the while a sever is listening in the background for incoming
traffic. If, after sending the prepared requests to the web application, a
connection opens on the local sever, the web application probably contains
a vulnerability that might lead to remote file inclusion.
Instantiation library The instantiation library contains a transformation
function Φ which adds the RFI-attack vector to a field. A small list of
samples containing simple lambda functions can be found in table 6. The
first parameter consists of the local address, the second of the corresponding
input field. It returns a tuple consisting of a field name and a value.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
47/70
Configuration values The model presented below uses the following values from a configuration description:
• URL: Contains the target URL.
• Cookie: Contains an authentication cookie for the application.
• LocalAddr: Contains the address of the current system.
Model The attacker model uses the openSocket primitive to create a listening socket at the address LocalAddr, specified as a configuration value. It
additionally fetches the document located at URL and iterates over all forms
and their fields. As in 5.1, a HTTP request in generated by modifying those
fields according to the transformation function Φ defined in the instantiation
library. The modified field can be encapsulated in a request which might
lead to a successful attack.
If, after submitting such a request, a connection on the local socket is
established (checked using the listen and isConnected primitives), then the
remote file inclusion attack was successful. In that case the user is notified and the automata reaches a final state. Otherwise it continues trying
all combinations of fields and transformation functions from the instantiation library, and afterwards reaches the final state notifying the user of an
unsuccessful attempt using the failure primitive.
5.6
XML Signature Wrapping Attack
In this section, we describe the XML Signature Wrapping attack, and provide
a low level attacker model for this attack.
XML Signature is the standard protection means for XML encoded messages, SOAP included. The so-called XML Signature Wrapping Attack illustrated that, with a typical usage of XML Signature to protect SOAP
messages, an adversary may be able to gain unauthorized access to protected
resources, by injecting unauthorized data into a signed XML document alongside a possible restructuring in a way that the document’s integrity is still
verified [49]. In the following, we use SOAP messages as an example to explain the possible ways to perform XML Signature Wrapping attacks, but
please be aware that this attack could be applied to other XML encoded
messages, e.g., Authentication Response in SAML SSO.
Suppose a valid or expected SOAP message is depicted in Figure 10. In
this section, we consider the following three types of restructuring of the
XML encoded message:
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
48/70
Figure 9: Low level remote file inclusion attacker model
Wrapping. In this type of restructuring, the signed node in the expected
SOAP message is put inside a “wrapper” node, and an “attack” node
is created in the previous position of the signed node. An example of
the modified SOAP message is depicted in Figure 11. In this case, the
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
49/70
Figure 10: Expected SOAP Message
Figure 11: Type 1: Wrapping
signature will be verified successfully by the signature validation logic,
and the application logic will perform the operation described in the
“attack” node.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
50/70
Figure 12: Type 2: Duplicating
Duplicating. In this type of restructuring, the signed node is left untouched,
and an “attack” node is created in the same position of the XML node
hierarchy before or after the signed node. An example of the modified
SOAP message is depicted in Figure 12. If the application logic just
fetches the first or the last SOAP body, the operation described in the
“attack” node will be performed.
Removing signature. In this type of restructuring, the signature node is
simply removed, and the signed node is changed to the “attack” node.
An example of the modified SOAP message is depicted in Figure 13. If
the default return value of the signature validation logic is “True”, the
application logic will perform the attack operation.
In order to apply the XML Signature Wrapping Attack, we need to reach
the “point” where an XML document containing an XML Signature is expected. This point depends on the specific application we are testing. In this
section, we provide the low level attacker behavior model of XML Signature
Wrapping Attack which is targeting SAML SSO, where the Authentication
Response message is such an XML document, where the authentication assertion is signed. We perform testing on Service Provider (SP) by creating
and sending variations of the Authentication Response to SP and checking
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
51/70
Figure 13: Type 3: Removing Signature
the feedback received from it. The prerequisite of performing this testing is
that we have a valid account in Identity Provider (IdP).
The model is depicted in Figure 14. In this model, the variable index
represents the index of the current test case which is a variation of a valid
Authentication Response, the variable limit is the total number of test cases
we are going to generate, and URL is the address of the SP. At first, we
send a normal resource request message to SP (transition from starting state
to state “a”). From the message received from SP, we extract IdP, SAML
Request and Relay State, and construct a message which should be sent to
IdP (transition from state “a” to state “b”). After sending the message to IdP
(transition from state “b” to “c”), we receive the Authentication Response
message from IdP. From this message, we extract the valid SAML Response
and Relay State, and call a fuzzing function to obtain Data (transition from
state “c” to state “d”). The Data is a pair of strings, where Data[0 ] is the
variation of Authentication Response, and Data[1 ] is a “checking string”. For
example, in the case of duplicating the assertion, the checking string is the
“wrong” user ID contained in the duplication. Then, we send Data[0 ] to SP
(transition from state “d” to “e”) and increase index by 1. If the checking
string is contained in the feedback received from SP, we stop the testing and
report an error (transition from state “e” to the final state). Otherwise, if
we haven’t executed all the test cases we could generate, we send the initial
resource request message to SP to restart the procedure (transition from
state “e” to “a”). In case we executed all of them, we stop the procedure
and report success (transition from state “e” to “f ” and then to the final
state).The kernel component of this testing procedure is the fuzzing function
creating all the variations of Authentication Response from a valid one. This
function needs to be implemented separately.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
52/70
Figure 14: Low Level Attacker Behavior Model of XML Signature Wrapping
Attack
5.7
Cross Site Request Forgery
In this section, we describe the Cross Site Request Forgery (CSRF) attack,
and provide a low level attacker model for this attack.
Cross-Site Request Forgery is an attack that tricks the victim into loading
a page that contains a malicious request. It is malicious in the sense that
it inherits the identity and privileges of the victim to perform an undesired
function on the victim’s behalf, like change the victim’s e-mail address, home
address, or password, or purchase something. CSRF attacks generally target
functions that cause a state change on the server but can also be used to
access sensitive data.
For most sites, browsers will automatically include with such requests any
credentials associated with the site, such as the user’s session cookie, basic
auth credentials, IP address, Windows domain credentials, etc. Therefore, if
the user is currently authenticated to the site, the site will have no way to
distinguish this from a legitimate user request.
In this way, the attacker can make the victim perform actions that they
did not intend to, such as logout, purchase item, change account information, retrieve account information, or any other function provided by the
vulnerable website.
The general recommendation as a countermeasure of the CSRF attack is
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
53/70
to adopt the Synchronizer Token Pattern. The synchronizer token pattern
requires the generating of random “challenge” tokens that are associated with
the user’s current session. These challenge tokens are then inserted within
the HTML forms and links associated with sensitive server-side operations.
When the user wishes to invoke these sensitive operations, the HTTP request
should include this challenge token. It is then the responsibility of the server
application to verify the existence and correctness of this token. By including
a challenge token with each request, the developer has a strong control to
verify that the user actually intended to submit the desired requests.
As an example, when a Web application formulates a request (by generating a link or form that causes a request when submitted or clicked by the
user), the application should include a hidden input parameter with a namesuch as “CSRFToken”. The value of this token must be randomly generated
such that it cannot be guessed by an attacker as depicted in the following.
<form action=“/sensitive_action“ method=“post“>
<input type=“hidden“ name=“CSRFToken“
value=“OWY4NmQwODE4ODRjN2Q2NTlhMmZlYWEwYzU1YWQwMTVhM2Jm=“>
...
</form>
In Figure 15, we present a model for testing whether a synchronizer token
is included in the parameters of a sensitive action. This model can also be
considered as an attacker’s behavior in order to decide whether the sensitive
action is vulnerable to CSRF attack.
Initially, a REQUEST is given as a valid request to perform a sensitive
action. It contains URL and body, and it could be a GET or POST request.
In the transition from starting state to state “a”, the list of parameters are
obtained in variable p, whose length is l. If the REQUEST is a GET request,
the transition from “a” to “b” will be enabled, where the value of parameter
p[i] will be changed. If the REQUEST is a POST request, the transition from
“a” to “c” will be enabled, where the value of parameter p[i] will be changed.
After that, a message with changed parameter value is sent out to SUT. If the
user session is rejected because of this change, we decide that this parameter
is the synchronizer token, and report “failure”. If the user session is not
rejected because of this change, and there are still parameter values to be
changed, we go back from state “d” to “a”. If the user session is not rejected
because of this change, and there is no more parameter value to be changed,
we decide that there is no synchronizer token with this sensitive action, and
report “success”. The implementation of the function sessionRejected()
depends on the specific application being tested. For example, when there
is a page selector parameter like in WebGoat, although changing it to an
invalid site would return an error, it is not a synchronizer token. In certain
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
54/70
Figure 15: Low Level Attacker Behavior Model of Cross Site Request Forgery
Attack
cases, the help from user is needed.
6
An Evolutionary Fuzz Testing Approach to
Detect Cross Site Scripting Vulnerabilities
One of the objectives of the SPaCIoS project is to perform low-level vulnerability detection. Especially because high-level verdicts (violation of security
properties) might depend on the ability to detect such low-level vulnerabilities. In this section, we present a (semi)-automated approach that detects
Cross Site Scripting vulnerabilities in a Black-Box SUT harnessing. This
approach uses a low-level SUT model and is driven by a Genetic Algorithm guided by our fitness function - that iteratively evolves concrete SUT inputs
until the tester defined stopping criteria are met.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
Taint Dataflow
Malicious Inputs Generation
- taint inputs
- infer taint in outputs
- annotate model
- generate inputs
- attack successful?
- evolve inputs
55/70
Figure 16: High Level View of the approach
6.1
Command Injections in Interpreted Languages
Dynamic web applications use Interpreted Languages - languages for which
compilation and execution are performed sequentially “on the fly”: HTML,
Javascript, SQL, XML, XPATH, LDAP,... Thus it makes sense to invest
into detecting low level vulnerabilities such as command injection. In this
vulnerability family, parts of the output are tainted with respect to a given
input parameter value, and such reflections are not confined [55] with respect
to the output grammar and they permit attacker controlled remote code
execution within the victim’s browser context (see Section 6.3.1).
Cross Site Scripting We concentrate on Cross Site Scripting, also know
as XSS. It is an injection of content (e.g., HTML, JavaScript, CSS,..) that is
interpreted by a browser (e.g., Firefox, Chrome, Internet Explorer, Safari...)
within the BODY part of a SUT HTTP REPLY output for the victim’s
browser to run an attacker controlled behavior. For a formalization of the
problem, see Section 6.3.1 and [18]. [59] provides insights on string transformations that browsers apply when rendering HTML5 documents.
6.2
Approach Overview
Our proposed approach combines fuzzing and evolutionary algorithms to
automatically generate malicious concrete SUT input sequences for detecting instances of the targeted fault (XSS). The quality of test sequences is
evaluated and Genetic Algorithms (GA) are used to combine “interesting
sequences” into new ones.
Knowledge of a SUT model is assumed (1 webpage = at least 1 state).
This model can be derived from an ASLan++ description or inferred from
traces of valid/expected SUT execution. In order to know where an attacker
can exert control, this model is first annotated for possible reflections using
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
56/70
Evolutionary Fuzzing
SUT
Model
+concrete
traces
Genetic
Algorithm
creation
crossover
mutation
Grammar
attack input
grammar
Indiv
Indiv
Indiv
idual
idual
idual
fitness
fault detection
Vulnerability
Test Driver
SUT
Figure 17: Overview of the Smart-Fuzzing Approach
input taint data-flow analysis (left box of Figure 16). Then, to determine if an
attacker can exert a dangerous control on the SUT, a smart fuzzing approach
is applied (right box of Figure 16): concrete SUT inputs (called individuals in
the GA terminology) are generated with respect to an Attack Input Grammar
which produces fuzzed values for reflected SUT input parameters. Individuals
of a given population are evolved via mutation and crossover operations (GA
terminology). Individuals are sent to the SUT, and are assessed by a fitness
function depending on the obtained SUT outputs. The test verdicts - whether
a fault was detected or not - is computed at the same time.
Figure 17 exhibits an overview of the relations between the aforementioned
notions:
Algorithm 1 contains the pseudo-code for the major steps of the approach:
6.2.1
Parameterization
This approach is parametrizable as show in Figure 18:
Below is a list and a brief description of the reasons behind most significative parameters, and an intuition of how to provide them.
6.2.2
Common requirements
• SUT Model + traces, SUT Driver. A standard driver objective harnessing - consists in matching high level input parameters (in the
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
57/70
Algorithm 1 Genetic Algorithm pseudo-code
1:
. 1. Annotating the model for reflections
2:
. taint-dataflow analysis
3:
. 2.1. Creating the first generation: n individuals
4: for i ∈ [1..n] do
5:
Population[i] ← generateIndividual(SUTModel,GAI )
6: end for
7:
. 2.2. Evolving the population
8: repeat
9:
for all I in Population do
10:
Submit I to SUT
11:
Compute
FITNESS(I,SUTModel,O)
+
VERDICT(I, O, TreePatterns)
12:
. taint-dataflow analysis
13:
end for
14:
CROSSOVER: f fittest individuals to produce m Children
15:
for all C in Children do
16:
MUTATE(C) with respect to a given probability distribution
17:
end for
18:
Population ← (n − m) fittest parents + m Children
19: until stopCondition
model) with parameters at the concrete low level. The provided SUT
Model is a input in the fitness function and, jointly with the SUT driver,
for generating test input sequences.
6.2.3
Inputs Taint Data-flow - Where can an attacker exert control?
• Taint data-flow inference. XSS is a special case of Command Injection in the case of Interpreted Languages. As such, attackers inject
data that are reflected (similar strings, eventually with minor transformations) in the outputs. We look for correlations, using string distance
between a given input parameter value and a substring of the output.
This distance is a dimension of the fitness function that will be detailed in [52]. This process consists in inferring the SUT data-flow for
a tainted input parameter value.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
58/70
Attack Input
Grammar
Output
Grammar
Parser
i
Smart-Fuzzing
n
approach for
p
u Command Injection
t
detection
s
SUT Model
+ traces
SUT driver
Reflection Aware
Tree Patterns
concrete
attack
found?
yes
concrete
input
sequence
+ output
no
parameters
string distance
EA
stopping
metric
Parameters
conditions
+ limits
Figure 18: Inputs of the smart-fuzzing approach
6.2.4
Malicious Inputs Generation - Can an attacker exert a dangerous control?
After having observed where reflections occur, the approach seeks to determine if dangerous control can be exerted by attackers around those positions.
During this step, following items are used:
• Attack Input Grammar Today, several XSS Attack Vectors - inputs
that exhibit XSS vulnerabilities and that are crafted to bypass browsers
XSS protection filters - are well known[25] [54] [40] [24] [19]. It could
be interesting to use those catalogs as such; a problem is that web
application developers may also rely on those to sanitize their applications. Therefore we use a generalization of those known XSS attack
vectors in the form of an Attack Input Grammar, manually provided.
Words produced by such a grammar are fuzzed values of reflected input
parameters, that were found during previous step.
• Output Grammar Parser serves for computing the quality - “fitness
value” of a test sequence - and the test verdict. In the case of XSS, the
output grammar GO is HTML and its sub-grammars. To avoid having
to intrusively instrument browsers or to write our own HTML parser,
we use a parser from one existing browser, as they automatically build
a Document Object Model (DOM) tree when rendering a webpage, and
this DOM can easily be read. Thus the considered output grammar is
DOM trees. So far we use the latest stable Firefox browser.
• Reflection-Aware Tree Patterns serve for the test verdict: is a given
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
59/70
reflection a successful XSS attack? These patterns are written by the
method expert. Concrete SUT outputs are matched against the tree
patterns. If at least one pattern matches, then the input sequence is
an XSS attack.
6.2.5
Similarities and Differences with the Attack Libraries section
Similarities
• SUT awareness requirement: both approaches require a SUT driver.
The smart-fuzzing approach also requires a low-level SUT model for
generating input sequences.
• instantiated values: in Section 5, input parameter values are generated from an instantiation library, in Section 6 they are from an Attack
Input Grammar.
Differences
• automation level: Section 5 models are meant to help a manual pentester, whereas in Section 6, the test generation is automated assuming
a low-level SUT model is available.
• attacker behavioral model: in Section 5 examples, the attacker
iteratively submits all values of an instantiation library. In the smartfuzzing approach, the attacker behavior is driven by the Genetic Algorithm (see Algorithm 1) and input parameter values are instantiated
from the Attack Input Grammar.
• automatic detection of input parameters to be fuzzed: thanks
to the first model annotation step, interesting input parameters are
automatically detected ; in contrary of being manually marked by the
method expert as in Section 5.
• test verdict: in Section 5, tests verdicts are pass (no attack found)
or fail (at least one attack found). In the smart-fuzzing approach, in
addition, the likelihood of a given input sequence to trigger a fault is
computed via the fitness function.
• type-1 vs type-2 XSS: attacker models in Section 5 target type-1 vulnerabilities (that is the effect of an actual vulnerability is visible in the
immediate output of the given transition in which an attacker crafted
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
input
...
parameters j
iα
...
I1
I= ...
iu
β
Ij
...
...
60/70
decoding i(j,α)
decoding i(u,β)
filter1
at least 1
transition
concrete
O
SUT O= ...1
outputs
O
encodi
ng γ
m
o
1 m
o2
~~
m
...
filter2
om
3
m
m
o4
~~
o
5
... o
filter
(k-1)/2
m
k-2
m
o k-1
~~
SUT
processing
m
o
k
Figure 19: Command Injection: SUT overview from a BlackBox perspective
input parameter value is submitted, whereas in type-2, the output is observed in at least the second output after the fuzzed value submission).
The smart-fuzzing approach in Section 6 also targets type-2 XSS.
6.3
6.3.1
Formalization and Extension to Similar Faults
Formalization
XSS belongs to a more general class of vulnerabilities: Command Injection.
The following is a formalization of the command injection problem in the
case of interpreted languages:
For a given m, input sequence length, the attacker goal is to find at least
1 input sequence I = (I1 , I2 , ..., Im ) where Il = (il1 , il2 , ..., ilnl ), such that ∃j
∈ [1..m] and α ∈ [1..nj ], such that:
m
m
• there exists at least 1 concrete SUT output Om =om
1 , o2 , ..., ok in which
j
the value of input parameter iα is reflected
• and there exists a subtree of P T (Om , GO ) - the parse tree of Om with
respect to the output grammar GO (e.g., Figure 20) - that is matched by
at least 1 reflection-aware tree pattern (e.g., Figure 21) for the targeted
fault:
Reflection Let D(s1 , s2 ) be a string distance and t a threshold. A
m
m
string input parameter iα is reflected in the string Om = om
1 .o2 ....ok , iff
m
∃j ∈ [1..k], such that D(iα , oj ) ≤ t. For instance, it is the case j = 4 in the
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
TD
childNodes
0
61/70
nodeName
nodeType
script
childNodes
..
script
3
0
data
"location=’http://..’;"
Figure 20: An example of P T (Om , GO ), a reflection-aware parse tree of Om
with respect to GO
script
childNodes
*
nodeType
data
3
*
Figure 21: An example of Reflection-Aware Tree Pattern for XSS
example in Figure 19. Let om
denote that om
j
j is the result of at least one
j
input parameter value reflection (e.g., om
4 is a reflection of the value of iα in
Figure 19).
Reflection-Aware Tree Pattern As show in Figure 21, reflectionaware tree pattern is a tree that contains at least one leaf that has a substring
that is the reflection of at least one input parameter value.
In the case of XSS the output grammar GO is HTML and its subgrammars (CSS, JS, ...).
6.3.2
Extension to Other Command Injection Faults
That method is tuned for generating inputs for detecting XSS flaws. This
approach is parametrizable as shown in Figure 18 and could be adapted to
other Command Injection attacks: SQL injection, Local File Inclusion...
One would have to change the parser, the attack input grammar, and
the tree detection patterns. SUT harnessing might have to be adapted: for
instance in the case of SQL injection, this approach requires the ability to
observe communications between the website and the SQL database backend.
For the time being, we only focus on XSS. In the future we may apply
this method to such vulnerabilities.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
7
62/70
Related Work
In general modelling attackers allows one to predict how an attacker may
behave under certain circumstances. To this respect, attack tree models
[46] have received attention due to its simplicity and ease of analysis [41].
An attack tree centers on the goal of the attacker. The attacker wants to
materialize a certain threat. In complex systems, there are several attack
trees with several root nodes, each representing the violation of a different
goal. For instance, an attacker may aim for gaining unauthorized access to
certain confidential data or for modifying vital configuration data without
proper authorization. The root of an attack tree is the target of the attack.
It represents a certain threat that may materialize. A threat for instance
may be an unauthorized information disclosure. A node in an attack tree
is an intermediate goal from a leaf to the root. It represents an attack
step. Intermediate goals may represent either re-usable sub-trees or attack
patterns, such as the ones described by [11]. For instance Bruce Schneier
strongly advocates libraries of attack (sub-)trees. Formalizations of attack
trees include [63, 33, 29].
On the other hand, stochastic models (for example [36, 62, 64, 21, 38, 65])
have been also advocated. While attack tree models do not capture complex
dependencies among events and also are not amenable for modelling dynamic
nature of the attacks and countermeasures, the fitness of stochastic models
is yet to be established as there is not sufficient evidence to show that attack
and defense behaviors follow some known distributions. The same applies to
data mining techniques discussed in [43, 44, 45, 61].
Attack Nets attempt to modify on and improve plain attack trees. They
are based on Petri nets. They introduce concepts such ability for self-repair,
recurring attacks, performance metrics, and time domain analysis13 . Attack
graphs, a generalization of attack trees, are considered formally for network
attacks in [48, 27].
Test Oracle for Command Injection [55] proposes a test oracle for
detecting SQL injections. If a reflected string is not syntactically confined
with respect to a subset of the SQL Grammar authors carefully chose, then
it is a sufficient condition for an SQL injection attack. [47] proposes a dataflow taint based approach for the test verdict: is a given input sequence
a successful attack (applied to SQL injection, Cross Site Scripting, Shell
Command injections)? They propose a string edit distance. If the distance
between a substring of an output and a sent input parameter value is lower
13
From: http://powercyber.ece.iastate.edu/penet_meth.html
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
63/70
than a given threshold with respect to false positive objectives, then the
input parameter is said to be reflected. Authors wrote their own parser that
propagates the taint. Then they matched the obtained Abstract Syntax Tree
with lexical detection rules. Thanks to their approach, their parser, and their
SUT harnessing, they obtained no false positive in detecting attack vectors.
Thus they were able to block the vectors before they would reach the SUT
interpreter (database back-end, browser, shell interpreter). [57] considers
that XSS aims at stealing sensitive data from inside the browser such as
document.cookie. The propagation of data tainting is tracked inside the
Firefox JavaScript engine and the DOM. This process is done via rules for
propagating the taint dynamically and with use of static analysis.If a tainted
statement accesses sensitive data and attempts to send those to another
domain, then it is a XSS and such a request is blocked.
In [8], the oracle is not based on the similarity between an output parts
and a previously sent input, but on the differences between outputs observed
in the attack phase with ones observed before. They first build a safe model
of the web application, that is an union of all the parse trees of SUT HTML
outputs with respect to to rules they designed. In the latter attack phase, if
an output does not conform to that safe model, then an XSS vulnerability is
detected. In their experiments, they do not have false positive. They assume
the SUT is deterministic, it would though be interesting to see how their
approach handles advertisement that changes at each output.
Using Genetic Algorithm for Evolving Test Sequences is well studied [1, 8, 10, 32, 53]. [32] is particularly interesting for its way of computing
an adaptive crossover rate for generating tests in a BlackBox harnessing. [8]
generates and evolves tests for detecting XSS. It has similarities with Section 6, the main difference being they benefit from source code knowledge
and they also use constraint solver. [1] is a state describing use of Genetic
Algorithm (GA) for testing non functional properties. In [10], authors used
GA for evolving malicious SUT inputs: attacker scripts are evolved and the
fitness function computes number of achieved attacker goals. A Grammar
is used only for generating first individuals. In [53] authors tackle the problem of detecting in memory vulnerabilities in a greybox harnessing. Thus,
they are aware of the control flow. Their fitness function favors previously
unexplored paths are well as ones not likely to be executed.
Model Based Black-Box Fuzz-Testing In [26], authors passively infer a
formal model of the SUT, and then apply fuzzing operators on inputs to trigger in memory vulnerabilities. A fitness function favors inputs that traverse
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
64/70
more states of the SUT model. The authors of [16] propose a technique for
inferring a (partial) model (symbolic Mealy machine) for Web applications,
in a black-box manner. So far, their crawler infers a static approximation of
dynamic pages: it is limited to HTML code (that is transitions triggered via
other means such as JavaScript are not inferred). Then they use an existing
fuzzer (w3af [39]) for generating inputs and fuzz testing the Web application
under test, taking into account also the inferred model. The main contribution of the paper pertains to guiding the fuzzer to properly use the model.
For instance, if at state 1 giving input x would make the Web application to
irrevocably move to state 2, then the fuzzer should (a) either avoid giving
input x before sufficiently fuzzing the application at state 1, or (b) reset the
Web application under test and guide it to state 1, so to sufficiently fuzz the
input parameters values at this state. On the considered SUTs, their approach found more states and vulnerabilities than w3af alone and skipfish,
which are considered by security testers to be some of the “must have” tools.
Attack Vector Generation Related work on attack vector generation
can be divided into two groups:
Attack Input Grammar Generation [58] learns the structure from
an attack vector corpus with respect to a Hidden Markov Model and then
mutates them to generate new input sequences.
Other approaches use concrete and symbolic execution for generating
input values [31, 7]. Yet such approaches requires source code knowledge,
which is not an assumption we make in Section 5 or Section 6. For the value
of fuzzed input parameters, some rely on attack libraries .
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
65/70
Part IV
Conclusions
Models of the behavior of the attacker, be abstract or concrete, play a significant role in the test case generation technologies that are developed in
SPaCIoS. In this deliverable we describe the attacker models that are developed and used in the context of SPaCIoS.
We describe the high-level attacker models of SPaCIoS, namely modelbased fault injection and attacker behavior models, which extend the standard Dolev-Yao threat model [15] in different directions. We also present our
low-level attacker models, namely a statechart-like model to reflect attack
steps and a fuzzing technology. We also a number of detailed examples of
common attack patterns that can be defined in our low-level attacker model.
In the future, we intend to further refine the proposed attacker models, in
order to fit them into the workflow of the SPaCIoS Platform. We also plan
to analyze what class of low-level attack patterns can be encoded using our
model.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
66/70
References
[1] W. Afzal, R. Torkar, and R. Feldt. A systematic review of search-based
testing for non-functional system properties. Information and Software
Technology, 51:957–976, 2009.
[2] P. Ammann, W. Ding, and D. Xu. Using a model checker to test safety
properties. In ICECCS, pages 212–221, 2001.
[3] P. E. Ammann, P. E. Black, and W. Majurski. Using model checking to
generate tests from specifications. In ICFEM, pages 46–54, 1998.
[4] A. Armando, D. Balzarotti, R. Carbone, A. Merlo, and G. Pellegrino.
From model-checking to automated testing of security protocols: Bridging the gap, 2011. Submitted.
[5] A. Armando, G. Pellegrino, R. Carbone, A. Merlo, and D. Balzarotti.
From model-checking to automated testing of security protocols: Bridging the gap. In A. Brucker and J. Julliand, editors, Tests and Proofs,
volume 7305 of Lecture Notes in Computer Science, pages 3–18. Springer
Berlin / Heidelberg, 2012. 10.1007/978-3-642-30473-6_3.
[6] S. Artzi, A. Kiezun, J. Dolby, F. Tip, D. Dig, A. Paradkar, and M. Ernst.
Finding bugs in web applications using dynamic test generation and
explicit-state model checking. TSE, 36(4):474–494, 2010.
[7] S. Artzi, A. Kiezun, J. Dolby, F. Tip, A. M. Paradkar, and M. D. Ernst.
Finding bugs in dynamic web applications. In International Symposium
on Software Testing and Analysis, pages 261–272, 2008.
[8] A. Avancini and M. Ceccato. Grammar based oracle for security testing
of web applications. In Automation of Software Test (AST), 2012 7th
International Workshop on, pages 15–21. IEEE, 2012.
[9] M. Büchler, J. Oudinet, and A. Pretschner. Security mutants for
property-based testing. In TAP, pages 69–77, 2011.
[10] J. Budynek, E. Bonabeau, and B. Shargel. Evolving computer intrusion
scripts for vulnerability assessment and log analysis. In Genetic and
evolutionary computation, GECCO ’05, pages 1905–1912. ACM, 2005.
[11] CAPEC. CAPEC – Common Attack Pattern Enumeration and Classification, release 1.6. The MITRE Corporation, 2010. Available at
http://capec.mitre.org/.
[12] J. A. Clark, H. Dan, and R. M. Hierons. Semantic mutation testing,
2010.
[13] F. Dadeau, P.-C. Héam, and R. Kheddam. Mutation-based test generation from security protocols in HLPSL. In ICST. IEEE, March 2011.
To appear. 9 pages.
[14] R. A. DeMillo, R. J. Lipton, and F. G. Sayward. Program Mutation: A
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
[15]
[16]
[17]
[18]
[19]
[20]
[21]
[22]
[23]
[24]
[25]
[26]
[27]
[28]
67/70
New Approach to Program Testing. In Infotech State of the Art Report,
Software Testing, pages 107–126, 1979.
D. Dolev and A. Yao. On the Security of Public-Key Protocols. IEEE
Transactions on Information Theory, 2(29), 1983.
A. Doupé, L. Cavedon, C. Kruegel, and G. Vigna. Enemy of the state:
A state-aware black-box web vulnerability scanner. USENIX Security,
2012.
A. Doupé, M. Cova, and G. Vigna. Why johnny can’t pentest: an
analysis of black-box web vulnerability scanners. In DIMVA, pages 111–
131, 2010.
F. Duchene, R. Groz, S. Rawat, and J.-L. Richier.
XSS Vulnerability Detection Using Model Inference Assisted Evolutionary
Fuzzing. In the Third International Workshop on Security Testing (SECTEST), in association with the Fifth International Conference on Software Testing, Verification and Validation (ICST),
pages 815–817, Apr 2012.
talk: http://bit.ly/HvMtGL, paper:
http://ieeexplore.ieee.org/xpl/articleDetails.jsp?tp=
&arnumber=6200193&contentType=Conference+Publications.
L. Erwan g4l4dr1m Abgrall, University of Luxembourg. Xss testing
framework. http://xss2.technomancie.net/. Accessed on 2012-0825.
R. Eshuis. Reconciling statechart semantics. Sci. Comput. Program.,
74(3):65–99, Jan. 2009.
Q. Feng, Y. Yang, Y. L. Sun, and Y. Dai. Modeling attack behaviors in
rating systems. In ICDCS Workshops, pages 241–248. IEEE Computer
Society, 2008.
G. Fraser, F. Wotawa, and P. Ammann. Testing with model checkers:
a survey. STVR, 19(3):215–261, 2009.
P. Godefroid, M. Levin, and D. Molnar. Automated whitebox fuzz testing. In NDSS, 2008. 16 pages.
M. Heiderich. HTML5 security. http://html5sec.org/. Accessed on
2012-08-25.
G. Heyes and various hackers. Shazzer - shared xss fuzzer, 2012. http:
//shazzer.co.uk. Accessed on 2012-08-25.
Y. Hsu, G. Shu, and D. Lee. A model-based approach to security flaw
detection of network protocol implementations. In International Conference on Network Protocols, pages 114–123, 2008.
S. Jha, O. Sheyner, and J. M. Wing. Two formal analysis of attack
graphs. In CSFW, pages 49–63, 2002.
Y. Jia and M. Harman. An analysis and survey of the development of
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
[29]
[30]
[31]
[32]
[33]
[34]
[35]
[36]
[37]
[38]
[39]
[40]
[41]
[42]
68/70
mutation testing. TSE, 37(5):649–678, 2011.
A. Jürgenson and J. Willemson. Serial model for attack tree computations. In D. Lee and S. Hong, editors, ICISC, volume 5984 of Lecture
Notes in Computer Science, pages 118–128. Springer, 2009.
A. Kieyzun, P. J. Guo, K. Jayaraman, and M. D. Ernst. Automatic
creation of sql injection and cross-site scripting attacks. In ICSE, pages
199–209, 2009.
A. Kiezun, P. J. Guo, K. Jayaraman, and M. D. Ernst. Automatic creation of SQL Injection and cross-site scripting attacks. In International
Conference on Software Engineering, pages 199–209, 2009.
M. Last, S. Eyal, and A. Kandel. Effective BlackBox Testing with Genetic Algorithms. In Haifa Verification Conference, pages 134–148, 2005.
T. Leinmüller, R. K. Schmidt, E. Schoch, A. Held, and G. Schäfer.
Modeling roadside attacker behavior in vanets. In Proceedings of 3rd
IEEE Workshop on Automotive Networking and Applications (AutoNet
2008), 2008.
E. Martin and T. Xie. A fault model and mutation testing of access
control policies. In WWW, pages 667–676, 2007.
G. H. Mealy. A Method for Synthesizing Sequential Circuits. Bell System
Technical Journal, 34(5):1045–1079, 1955.
G. Oikonomou and J. Mirkovic. Modeling human behavior for defense
against flash-crowd attacks. In ICC, pages 1–6. IEEE, 2009.
M. Oostdijk, V. Rusu, J. Tretmans, R. G. de Vries, and T. A. C.
Willemse. Integrating verification, testing, and learning for cryptographic protocols. In J. Davies and J. Gibbons, editors, IFM, volume
4591 of Lecture Notes in Computer Science, pages 538–557. Springer,
2007.
S. H. Razavi and O. Das. Security evaluation of layered intrusion tolerant systems. In Proceedings of the 17th international conference on Analytical and stochastic modeling techniques and applications, ASMTA’10,
Analytical and Stochastic Modeling Techniques and Applications, pages
145–158, Berlin, Heidelberg, 2010. Springer-Verlag.
A. Riancho. w3af - web application attack and audit framework. http:
//w3af.sourceforge.net.
RSnake. XSS Cheat Sheet Esp: for filter evasion. http://ha.ckers.
org/xss.html. Accessed on 2012-08-25.
V. Saini, Q. Duan, and V. Paruchuri. Threat modeling using attack
trees. J. Comput. Sci. Coll., 23:124–131, April 2008.
P. A. P. Salas, P. Krishnan, and K. J. Ross. Model-based security vulnerability testing. In ASWEC, pages 284–296. IEEE Computer Society,
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
[43]
[44]
[45]
[46]
[47]
[48]
[49]
[50]
[51]
[52]
[53]
[54]
[55]
69/70
2007.
M. B. Salem and S. J. Stolfo. Masquerade attack detection using
a search-behavior modeling approach. Technical Report cucs-027-09,
Computer Science Department Columbia University New York, USA,
2009.
M. B. Salem and S. J. Stolfo. Detecting masqueraders: A comparison of
one-class bag-of-words user behavior modeling techniques. In MIST’10,
Morioka, Iwate, Japan, June 2010 2010.
M. B. Salem and S. J. Stolfo. Modeling user search behavior for masquerade detection. In Proceedings of the 14th International Symposium on
Recent Advances in Intrusion Detection, pages 1–20. Springer, September 2011.
B. Schneier. Attack trees. http://www.schneier.com/paper-attacktreesddj-ft.html, december 1999.
R. Sekar. An Efficient Blackbox Technique for Defeating Web Application Attacks. In Network and Distributed System Security Symposium,
2009.
O. Sheyner, J. W. Haines, S. Jha, R. Lippmann, and J. M. Wing. Automated generation and analysis of attack graphs. In IEEE Symposium
on Security and Privacy, pages 273–284, 2002.
J. Somorovsky, M. Heiderich, M. Jensen, J. Schwenk, N. Gruschka, and
L. Lo Iacono. All your clouds are belong to us: security analysis of
cloud management interfaces. In Proceedings of the 3rd ACM workshop
on Cloud computing security workshop, CCSW ’11, pages 3–14, New
York, NY, USA, 2011. ACM.
SPaCIoS. Deliverable 4.1: SPaCIoS Tool mock up, Technology survey,
Validation methodology patterns v.1, 2011.
SPaCIoS. Deliverable 2.1.2: Modeling security-relevant aspects in the
IoS, 2012.
SPaCIoS. Deliverable 3.3: SPaCIoS Methodology and technology for
vulnerability-driven security testing, 2013.
S. Sparks, S. Embleton, R. Cunningham, and C. Zou. Automated Vulnerability Analysis: Leveraging Control Flow for Evolutionary Input
Crafting. In Annual Computer Security Applications Conference, pages
477–486, 2007.
D. Stuttard and M. Pinto. The Web Application Hacker’s Handbook:
Discovering and Exploiting Security Flaws, 2nd Edition. Wiley, 2011.
Z. Su and G. Wassermann. The essence of command injection attacks in web applications. In POPL ’06: Conference record of the 33rd
ACM SIGPLAN-SIGACT symposium on Principles of programming lanFP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876
D2.4.1: Definition of Attacker Behavior Models
[56]
[57]
[58]
[59]
[60]
[61]
[62]
[63]
[64]
[65]
70/70
guages, pages 372–382, New York, NY, USA, 2006. ACM.
J. Tenzer and P. Stevens. On modelling recursive calls and callbacks
with two variants of unified modelling language state diagrams. Form.
Asp. Comput., 18:397–420, November 2006.
P. Vogt, F. Nentwich, N. Jovanovic, E. Kirda, C. Kregel, and G. Vigna.
Cross Site Scripting Prevention with Dynamic Data Tainting and Static
Analysis. In Network and Distributed System Security Symposium, 2007.
Y.-H. Wang, C.-H. Mao, and H.-M. Lee. Structural Learning of Attack Vectors for Generating Mutated XSS Attacks. Computing Research
Repository, abs/1009.3, 2010.
J. Weinberger, P. Saxena, D. Akhawe, M. Finifter, R. Shin, and D. Song.
A systematic analysis of xss sanitization in web application frameworks.
In Computer Security–ESORICS 2011, pages 150–171. Springer, 2011.
G. Wimmel and J. Jürjens. Specification-based test generation for
security-critical systems using mutations. In ICFEM, pages 471–482,
2002.
X. Xu. Machine learning for sequential behavior modeling and prediction. In A. Mellouk and A. Chebira, editors, Machine Learning, Vienna,
Austria, 2009. I-Tech.
Q. Zhang, W. Wei, and T. Yu. On the modeling of honest players in
reputation systems. J. Comput. Sci. Technol., 24(5):808–819, 2009.
Y. Zhang, X. Fan, Y. Wang, and Z. Xue. Attack grammar: A new
approach to modeling and analyzing network attack sequences. In 2008
Annual Computer Security Applications Conference ACSAC, pages 215–
224. Ieee, 2008.
Y. Zhang, X. Fan, Z. Xue, and H. Xu. Two stochastic models for security
evaluation based on attack graph. In ICYCS, pages 2198–2203. IEEE
Computer Society, 2008.
Z. Zhang, F. Nait-Abdesselam, and P.-H. Ho. Boosting markov reward
models for probabilistic security evaluation by characterizing behaviors
of attacker and defender. In Proceedings of the 2008 Third International Conference on Availability, Reliability and Security, pages 352–
359, Washington, DC, USA, 2008. IEEE Computer Society.
FP7-ICT-2009-5, ICT-2009.1.4
Project No. 257876