What's New in Teams Calling, Meetings and Devices March 2024
Attack scripts generation for security validation fr
1. Attack scripts generation for security
validation
Anderson Morais* — Ana Cavalli** — Eliane Martins*
*Institut Télécom / Télécom SudParis
9, rue Charles Fourier, 91011 Évry Cedex, France
{anderson.morais,ana.cavalli}@it-sudparis.eu
** Institute of Computing - State University of Campinas
Av. Albert Einstein 1251, 13083-970 Campinas SP, Brazil
eliane@ic.unicamp.br
ABSTRACT: In this paper we present an original approach to generate attack scripts aiming at
security validation of information systems and applications. The goal is to uncover potential
vulnerabilities that an attacker could exploit to cause security failures of the system. We use
attack modelling to specify the system flaws and derive the corresponding attack scenarios.
The attack scenarios are refined to generic attack scripts using: attack pattern, event-
condition-action rule, keyword-driven testing, and UML diagrams. The generic attack scripts
are then converted to executable scripts for a testing tool. The generated attack scripts are in
a format that is independent of the used tool, i.e., they are reusable. The executable attack
scripts are able to simulated real attacks. Examples are provided to show the usage of the
approach.
RÉSUMÉ: Dans cet article nous présentons une approche originale pour produire des scripts
d'attaque visant la validation de la sécurité des systèmes d'information et d'applications.
L'objectif est de découvrir les potentielles vulnérabilités qu'un attaquant pourrait exploiter
pour causer des défaillances de sécurité du système. Nous utilisons modélisation d’attaque
pour spécifier les failles du système et dériver les correspondants scénarios d'attaques. Les
scénarios d'attaque sont raffinés à des scripts d'attaque génériques avec l'aide de : l’attack
pattern, la règle event-condition-action, le keyword-driven testing, et des diagrammes UML.
Les scripts d'attaque génériques sont ensuite convertis en scripts exécutables pour un outil de
test. Les scripts d'attaque sont générés dans un format qui est indépendante de l'outil utilisé,
c'est à dire, ils sont réutilisables. Les scripts d'attaque exécutables peuvent simuler des
attaques réelles. Des exemples sont donnés pour montrer l'utilisation de l'approche.
KEY WORDS: security validation, attack scripts, security testing.
MOTS-CLÉS: validation de sécurité, scripts d'attaque, test de sécurité.
SEC-SY 2010
2. 2 SEC-SY 2010
1. Introduction
Security and reliability have become a major concern for information systems as
well as for service oriented applications. The security of these systems becomes
even more important since we rely on them for our everyday life activities and tasks.
What we cannot ignore, however, are the systems security vulnerabilities, resulting
not only from bugs introduced during the software development phases but also
from the environment where these systems are deployed for operation, which could
be exploited by malicious adversaries. Software security is in a critical state.
Statistics published by NIST National Vulnerability Database (NIST, 2010) reported
5733 known software vulnerabilities in 2009, which correspond to an increase of
134% from 2004, and an increase of 2% from 2008.
The existence of vulnerabilities does not cause a security failure, and in fact
many times they can remain dormant for a long time. An intrusion is only
materialized when an attack has been successful in exploiting a vulnerability. After
an intrusion, the system might or might not fail, depending on the kind of
mechanisms the system possesses to handle errors introduced by the adversary.
Sometimes an intrusion can be tolerated as the error is detected and isolated, but in
the majority of the current systems, it leads immediately to violation of one or more
security properties (e.g., confidentiality or availability), i.e., a security failure occurs.
Vulnerability removal is thus very important method to reduce the risk of
successful attacks, by reducing the number or severity of vulnerabilities. Different
Verification and Validation (V&V) techniques can be used for that purpose during
the system development, such as static verification techniques: analysis (Edge et al.,
2007), formal proofs (Gray et al., 1995), model checking (Lowe 1998); or dynamic
verification techniques: testing (Orset et al., 2007). The identified flaws may then be
removed by fixing the software code. In this work we focus on dynamic verification,
or usually termed active testing, where the system code is exercised by providing
real inputs while its security mechanisms are evaluated.
Some works have used active testing to evaluate the system security, where
attack scenarios are generated, but a systematic methodology is not employed. For
example, (Thompson et al., 2002) tested software security in a hostile environment.
Faults were injected during runtime by monitoring and modifying system calls made
by the application to the operating system. In this sense, they emulate the behaviour
of a hostile environment. However, they do not mention how to associate this
behaviour with attacks. The work (Wanner et al., 2003) presents the design and
development of a fault injector tool for testing of firewalls and intrusion detection
systems. The fault injector provides functions to the user, such as dnsspoof, tcpkill
and others, to simulate attacks to TCP/IP protocols.
The PROTOS (Protos 2001) and SPIKE (Aitel 2002) tools generate attacks using
Fuzzing – the inputs are randomly generated – and syntax testing techniques, where
the inputs of the application are corrupted with known malicious attack patterns,
3. Attack scripts generation for security validation 3
such as long string or invalid characters. The mutation of inputs is based on the
specification of the input format. But security vulnerabilities are exploited in a
limited way since there is no relation between the provided inputs and the found
vulnerabilities, i.e., inputs that an attacker do use in real-life are hardly replicated
using this technique. In these works it is not mentioned how to model the malicious
inputs that are used during testing, not allowing them to be reused in similar
applications neither ported to different tools. A great number of testing experiments
is needed to detect a vulnerability alone, which impacts on the efficiency of these
approaches.
In this paper we describe an original approach to generate attack scripts in order
to validate the security aspects of the target system. The vulnerabilities can be
detected in the presence of attacks that are emulated running these scripts. Despite of
using mutation technique on the inputs to produce attacks we propose the use of
attack modelling technique to help to uncover security vulnerabilities. The threat
model represents real attacks and known vulnerabilities of the system. The model is
easy to maintain, to keep updated, and can be reused in similar applications.
Attack modelling has been used for: representing the steps of threats to a system
and classifying them (Edge et al., 2007) for helping identifying known
vulnerabilities and weak parts of the system that could be exploited by a attacker;
modelling software components under security perspective by adding security
information to UML diagrams (UMLsec – UML for secure systems); specifying
intrusion scenarios (Hussein et al., 2006) and generating signatures using UML
diagrams (UMLintr – UML for intrusion specifications).
The attack scenarios are automatically generated from the threat model. After
describing these attack scenarios using the attack pattern technique (Moore et al.,
2001), we can represent them with event-condition-action (ECA) rule (Paton et al.,
1993), keyword vocabulary, and intrusion specification UML elements. So we
obtain generic attack scripts from the attack scenarios, which can be converted to
executable attack scripts for testing tools. In this way the approach does not depends
on the system source code neither on a unique testing tool. The goal of the approach
is to increase the testing controllability and decrease the high number of inputs as it
is done in traditional security testing, i.e., improve the overall testing efficiency.
The main contributions this paper brings are:
− An original approach to generate attack scripts based on modelling of real
attacks;
− A complete methodology to convert from attack scenarios to executable
scripts;
− Easy methods to produce generic attacks scripts that are reusable in different
architectures and testing tools.
The paper is structured as follows. Section 2 contains a description of the
4. 4 SEC-SY 2010
approach showing how to obtain attack scenarios from the threat model. Section 3
explains how to transform from attack scenarios to generic attack scripts and after to
executable attack scripts. Section 4 closes the paper by presenting the results and
some directions for future works.
2. Attack modelling approach
The purpose of the approach is to demonstrate how testing engineers or
developers can generate attacks scripts to evaluate the security level of systems and
find potential security flaws in the implementation in a feasible time interval with
good efficiency. Figure 1 illustrates the steps of the approach. Steps from 1 and 2 are
presented in the remainder of this section.
1. Attack modelling: 2. Generate attack
- Identify the threats Threat model scenarios
- Define attacker capabilities
3. Refine attack scenarios: Attack scenarios
Generic attack attack pattern + ECA rule +
scripts keyword vocabulary + UML.
4. Transform attack Executable
scripts: converter attack scripts
Figure 1. Approach to generate attack scripts.
Firstly we take information of vulnerabilities and attacks to the system to define
the threats to be modelled. This information is usually available in vulnerabilities
databases (ex.: NIST - National Vulnerability Database. It contains: general
information of the vulnerability such as: release date, description, etc; metrics of the
vulnerability such as: complexity, exploitability, violated security properties, etc.
For this work we use: description and violated security properties information. Then
what we have to do is: collect as many as possible vulnerabilities related to the
target system from these databases and sort them according to the violated security
property (ex.: integrity, confidentiality). We also have to define the attacker
capabilities, i.e., what means the attacker owns to carry out the attacks (ex.: he has
access to the Web server). In this way, we can make sure the selected attack
scenarios can be executed by the testing tool that represents the attacker.
We have to use the collected vulnerabilities information – description and
violated security properties – and the attacker capabilities parameters to build the
threat model of the target system. Threat models range from attack tree models
5. Attack scripts generation for security validation 5
(Morais et al., 2009) to more formal petri net based methods. Methods based on
UML notations (Hussein et al., 2006), such as use-cases, classes, state-machines
have also been adopted over the last years. The attack tree usage is demonstrated in
work (Morais et al., 2009). But the tester is free to choose the attack model
representation that best satisfies his needs.
The attack scenarios are generated from the threat model. A selection criterion
must be defined to perform the searching on the threat model in order to find the
appropriated attack scenarios to be refined. A criterion can be: “to cover all attack
scenarios matching the attacker capabilities parameters”, i.e., the attack scenarios
that can be emulated by the testing tool. This step is completely automated since
most of tools that support the construction of threat models can also select scenarios
based on a criterion. The obtained scenarios can be used to create an attack library,
which is useful for testing other systems from the same family.
3. Attack scripts generation
The first sub-step of the refinement step is to describe the attack scenario using
the attack pattern technique (Moore et al., 2001). We make use of the following
attack pattern elements to separate the attack scenario into steps: (1) “the overall
goal of the attack” == “the attack scenario”; (2) “a list of preconditions for its use”
== “system or/and environments events”, which are extracted from the attack
description; (3) “the steps for carrying out the attack” == “tasks the attacker must
accomplish”, which are also extracted from the attack description.
We selected the “SSLv.3/TLSv.1 truncation attack” to illustrate the refinement
step. The attack is executed when tearing down an SSL/TLS connection between a
Web browser and a Web server. The attack description is: “the attacker drops the
last application data record (PDU) and the closure Alert Message close_notify
transmitted from the server to the client when closing a TCP connection, making it
appear that the whole message sent to client is shorter”. The violated security
property is: integrity. Figure 2 shows the attack pattern representation for this attack.
(1) Goal: SSLv.3/TLSv.1 truncation attack
(2) Precondition: PDU from the server to the client
(3) Steps:
AND 1. if record (PDU) is application data
2. if record (PDU) is the last one
3. drop last record (PDU)
4. if record (PDU) is Alert Message
5. if record (PDU) of Alert Message is close_notify
6. drop record (PDU) close_notify
Figure 2. Attack pattern for attack scenario.
6. 6 SEC-SY 2010
For the second sub-step of the refinement we use the event-condition-action
(ECA) rule (Paton et al., 1993) to represent the attack pattern elements showed in
Figure 2. An ECA rule performs actions in response to events, given that a stated
condition holds. An ECA rule has the general syntax: <ON event IF condition DO
action>. The event part specifies when the rule is triggered: event == (2)
Precondition. The condition part determines if the data are in a particular state, in
which case the rule fires: condition == (3) Steps, when there is ‘if’. The action part
describes the actions to be performed if the rule fires: action == (3) Steps, when
there is attacker action.
We use a keyword vocabulary to describe the ECA rule parts. This method is
applied in keyword-driven testing1 or table-driven testing, where keywords are
selected by an experienced tester according to software domain during the planning
phase. The tests are developed as data tables using a keyword vocabulary that is
independent of the testing tool used to execute them. Such data table records contain
the keywords that describe the actions we want to perform. In Figure 3 the data table
contain keywords that describe the parts of ECA rule. The software domain taken
into account is a communication system, where participants exchange messages. The
keywords for ECA rule’s part action mean what an attacker can perform on the
communication network, i.e., his capabilities.
ECA rule part Keywords
send(A,B,m,<TP>,<IP_A>,<IP_B>,<Po_A>,<Po_B>),
event rcv(B,A,m,<TP>,<IP_B>,<IP_A>,<Po_B>,<Po_A>)
condition m.PDU_type, m.<field>, var, protocol.<prop>
intercept(m), corrupt(m.<field>),drop(m),
duplicate(m), delay(m), impersonate.create(m),
action impersonate.send(m), store(m.<field>),
restore(m.<field>), sign.set(var), sign.get(var)
Legend:
-send: send a message, – rcv: receive a message. – A: sender, – B: receiver.
– m: message, – <TP>: transport protocol (ex.: TCP, UDP).
– <IP_A>: source IP, – <IP_B>: destination IP.
– <Po_A>: source port, – <Po_B>: destination port.
– m.PDU_type: message PDU type (ex.: data PDU), – m.<field>: message field.
– var: state variable, – protocol.<prop>: protocol specification properties.
Figure 3. Data table for ECA rule.
The attack pattern elements of truncation attack in Figure 2 are then converted to
the ECA rule parts, as shown in Figure 4: event = (2) Precondition; condition = (3)
Steps 1, 2, 4, 5; action = (3) Steps 3, 6. We can group syntactically the elements 1, 2
and the elements 4, 5 using operator AND. Two ECA rules are created. The ECA
1
http://safsdev.sourceforge.net/FRAMESDataDrivenTestAutomationFrameworks.htm
7. Attack scripts generation for security validation 7
rules parts are then specified using the keywords of Figure 3’s table as shown in
Figure 4.
Rule 1:
ON event: send(A,B,m,<TP=TCP>,<IP_A>,<IP_B>,<Po_A>,<Po_B>)
IF condition: (1. m.PDU_type == protocol.<prop=application_data>)
AND (2. m.<field=record_sequence> == LAST)
DO action: 3. drop(m)
Rule 2:
ON event: send(A,B,m,<TP=TCP>,<IP_A>,<IP_B>,<Po_A>,<Po_B>)
IF condition: (4. m.PDU_type == protocol.<prop=alert>) AND
(5. m.<field =alert_description> ==
protocol.<prop=close_notify>)
DO action: 6. drop(m)
Figure 4. ECA rules for attack pattern.
The third sub-step is to identify the UML elements that implement the ECA rule
and the respective keywords to generate the generic attack script. We propose the
use of interface components (Bachmann et al., 2000), which allows a more black-
box approach and allows reusability and flexibility. We define three interfaces:
Attacker, Attack and Victim, which represent three components that provide
services through their operations.
The Attacker interface represents the attacker capabilities and provides
operations to represent ECA rule’s keywords. The Victim interface represents the
target system along with its specification properties. The Attack interface represents
the generated attack scenario and will coordinate the attack steps using operations of
Attacker and Victim interfaces. Table 1 shows the interfaces and their operations.
Attacker and Victim interfaces’ operations are directly mapped to the ECA rule’s
parts and keywords, as shown in Table 1, where: event maps from the Attacker’s
operations for message analysis; condition maps from the Attacker’s operations for
message data extraction, which are compared to the properties of target application
extracted from Victim’s operation; action maps from the Attacker’s operations
related to the attacker capabilities.
The final sub-step consists of implementing the generic attack script: first we take
mainAttack operation of Attack interface that will perform the attack steps; second
we take getProperties operation of Victim interface to extract the system
properties values – the script’s constants; and third we implement the script’s logic
taking the Attacker’s operations in Table 1 that are mapped to the keywords of each
ECA rule part, following the syntax: <ON event IF condition DO action>. Figure 5
shows generic attack script template.
9. Attack scripts generation for security validation 9
1. class Attack_Script implements Attack {
2. mainAttack() {
3. Protocol_Type TCP; Port Webserver_port;
4. PDU_Type application_data; PDU_Type alert;
5. PDU_Field record_sequence; PDU_Field alert_description;
6. PDU_Field lastRecord = LAST; PDU_Field close = close_notify;
7. Boolean truncate; Packet packet; converter Converter;
8. UDP, Webserver_port, application_data, alert, record_sequence,
9. alert_description = converter.getProperties(TLS);
10. while (packet==converter.InterceptPacket()){
11. if (converter.getProtocolType(packet) == TCP)
12. and (converter.getSourcePort(packet) == Webserver_port){
13.Rule_1:
14. if (converter.getPDUType(packet) == application_data)and
15. (converter.getPDUField(packet,record_sequence) == lastRecord){
16. converter.DropPacket(packet);
17.Rule_2:
18. if (converter.getPDUType(packet) == alert)and
19. (converter.getPDUField(packet,alert_description) == close){
20. converter.DropPacket(packet);
21. return; /* End of attack */
22.}}}}
Figure 6. Generic attack script implementation.
Finally the generic attack script is implemented according to the template in
Figure 5 and Figure 4’s ECA rules. The generic attack script implements
mainAttack operation of Attacker interface as shown in Figure 6. This script can be
reused for testing other similar implementations, what hardly occurs with traditional
security testing approaches.
3.1. Attack scripts transformation
The generic attack script’s operations are transformed into the specific language
of the testing component, prior to execution, using a converter. The converter is
modelled based on the adapter design pattern (Gamma et al., 1995).
Figure 7 illustrates the class diagram containing the converter. The
Attack_Script()class implements Attacker interface and desire to use
Testing_Tool() class operations. The Converter() class – that represents the
converter – implements the operations of Attacker and Victim interfaces which are
used by the generic attack script Attack_Script()class as shown in Figure 6. So
operations of Converter()class call and translate the operations of
Testing_Tool()class – that uses specific tool language – to be understood and used
by Attack_Script() class. Then Attack_Script() class can call operations of
Converter() class that call Testing_Tool() class operations, which return the
desired tool language instructions. This capacity to port a generic attack script to
different testing tools is not found in traditional security testing approaches.
10. 10 SEC-SY 2010
package Data[ Conversor ]
Attack Victim Attacker
+mainAttack() +getProperties() : Protocol_properties +InterceptPacket() : Packet
Converter
The class operations
Attack_Script +tool : Testing_Tool are not exhibited.
+converter : Converter +getProperties() : Protocol_properties
+InterceptPacket() : Packet
+mainAttack()
The other operations
of Attacker interface
Testing_tool are not exhibited.
...
converter.InterceptPacket(); +InterceptPacket() : Packet
...
...
tool.InterceptPacket();
The other operations ...
of Testing_Tool class
are not exhibited.
Figure 7. Class diagram for attacking components.
Operation Instructions
converter.getProperties These values are obtained from system’s
specification
converter.InterceptPacket(interface) This operation is executed by the tool
SET 0x9 R0 #TCP field offset
READB R0 R1
converter.getProtocolType(packet)
SUB R1 R6
== TCP JMPZ R6 IS_TCP
JMP ERROR_OK
SET 0x14 R0 #port field offset
READS R0 R1
converter.getSourcePort(packet)
SUB R1 R7
== Webserver_port JMPZ R7 TO_BROWSER
JMP ERROR_OK
SET 0x1C R0 #PDU field offset
READB R0 R1
SET 0x0F R0 #PDU byte mask
converter.getPDUType(packet)
== application_data
AND R0 R1
SUB R8 R1
JMPZ R1 PDU_AD
JMP ERROR_OK
READS R9 R1
converter.getPDUField(packet, SUB R5 R1
record_sequence) == lastRecord JMPZ R1 DO_TRUNC
JMP ERROR_OK
DRP
converter.DropPacket(packet) JMP INIT
11. Attack scripts generation for security validation 11
Table 2. Mapping from operations to tool’s instructions.
We use the Firmament testing tool (Drebes et al., 2005) to exemplify this step.
The Table 2 shows the indirect mapping from operations of Attack_Script()class
to Firmament’s language instructions. Using this mapping for the converter and
mainAttack operation’s logic in Figure 6 we can easily obtain the final executable
attack script.
4. Conclusions and Future Work
In this paper we proposed an original approach to generate executable attack
scripts for security testing in an efficient way. Attacks scenarios are generated from
a threat model. The threat model is build from real vulnerabilities and known attacks
that are taken from global vulnerabilities databases. The approach shows how to
select attack scenarios that are feasible for a testing tool.
One of the main contributions of this work is the notation based on UML to
represent attack scenarios and generate platform independent attack scripts. The
approach also describes a converter to transform generic scripts to executable
scripts, making it possible to port the script to an ample gamma of testing tools.
One possible future work is to use an existing attack language to represent the
attack scenarios in order to enhance the approach flexibility and portability. We can
use other vulnerabilities attributes from the databases for the attack modelling to
improve the scenarios searching and sorting. It is also necessary to create a
systematized method to generate unknown attacks from reported attacks so that new
vulnerabilities can be uncovered during the testing.
5. References
A. Morais, E. Martins, A. Cavalli, W. Jimenez, "Security Protocol Testing Using Attack
Trees," cse, vol. 2, pp.690-697, 2009 International Conference on Computational Science
and Engineering, Vancouver, 2009
A.P.Moore, R.J.Ellison, R.C.Linger. Attack Modelling for Information Security and
Survivability. Technical Note CMU/SEI-2001-TN-001. March 2001.
D. Aitel, “The Advantages of Block-Based Protocol Analysis for Security Testing”,
Immunity Inc., February 2002. Obtained in May/2009 at: http://www.immunitysec.com/
downloads/advantages_of_block_based_analysis.html.
E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable
Object-Oriented Software. Addison Wesley, 1995.
F. Bachmann et al. Volume II:. Technical Concepts of Component-Based Software
Engineering - 2nd Edition. Obtained in Abr/2010 at: www.sei.cmu.edu/reports/00tr008.pdf.
12. 12 SEC-SY 2010
Herbert H. Thompson, James A. Whittaker, Florence E. Mottay, “Software security
vulnerability testing in hostile environments”, ACM Symposium on Applied Computing (SAC)
2002: 260-264. Madrid, Spain.
James W. Gray III, John McLean, “Using temporal logic to specify and verify
cryptographic protocols”, Proc. of 8th. IEEE Computer Security Foundations Workshop
(CSFW '95), March 13-15, 1995, Kenmare, County Kerry, Ireland, pp 108-117.
J.M. Orset, B. Alcalde and A. Cavalli, “A formal approach for detecting attacks in ad hoc
networks”, International Journal of Network Security, 2(2): 141-149, 2007.
G. Lowe, “Towards a Completeness Result for Model Checking of Security Protocols”,
Proceedings of the 11th Computer Security Foundations Workshop (PCSFW), IEEE
Computer Society Press, 1998.
Hussein, M., Zulkernine, M., “UMLintr: a UML profile for specifying intrusions”. In
Proceedings of the IEEE International Conference and Workshop on the Engineering of
Computer-Based Systems, Tucson, AZ, USA, pp. 279–288 (2006).
K. S. Edge, R. A. Raines, R. O. Baldwin, M. A. Grimaila, and R. Bennington, “The Use
of Attack and Protection Trees to Analyze Security for an Online Banking System”, the
Hawaii International Conference on System Sciences-HICSS-40, Kauai, Hawaii, January
2007, 8 pages (CD)
NIST National Vulnerability Database, 2010, statistics 2004-2010, http://nvd.nist.gov/.
N. Paton, O. Díaz, M.H. Williams, J. Campin, A. Dinn e A. Jaime. “Dimensions of Active
Behaviour”. In N. Paton et M. Williams, editor, Proceedings of 1st Int. Workshop on Rules in
Database Systems (RIDS’93), Edinburgh - Scotland, September 1993. Springer Verlag.
P.C.H.Wanner, R.F.Weber. “Fault Injection Tool for Network Security Evaluation”.
LNCS Volume 2847/2003, Dependable Computing, Pp 127-136, Sept/2003.
PROTOS - Security Testing of Protocol Implementations, obtained in May/2009 at: http://
www.ee.oulu.fi/research/ouspg/protos/.
R.J. Drebes, G. Jacques-Silva, J. F. da Trindade, T. S. Weber, “A Kernel-based
Communication Fault Injector for Dependability Testing of Distributed Systems”. Parallel
and Distributed Systems: Testing and Debugging (PADTAD-3), 2005, Haifa, Israel.
