Netw Sci (2011) 1: 0–00 DOI 10.1007/s13119-012-0012-0 RESEARCH ARTICLE
Generating attack scenarios for the system security validation Anderson Morais1, Iksoon Hwang2, Ana Cavalli1 (), Eliane Martins3 1. Software-Networks Department, Télécom SudParis, 9 rue Charles Fourier 91000 Evry, France 2. Software R&D Center, Samsung Electronics, 129 Samsung-ro, Yeongtong-gu, Suwon-si, Gyeonggi-do, 443-742, Republic of Korea 3. Institute of Computing, University of Campinas, Av. Albert Einstein 1251 13083-852 Campinas-SP, Brazil
Received: 9 June 2012/Revised: 9 October 2012/Accepted: 23 November 2012 © Tsinghua University Press and Springer-Verlag Berlin Heidelberg 2012
Abstract Next Generation Network (NGN) is a completely new architectural concept for providing end-users with voice, video, and all sorts of data services. However, secure communication is a key and challenging requirement for NGN service providers. In this paper, we propose an innovative attack script generation and injection approach to evaluate the security of the communication system and consequently detect its security flaws. We apply attack modeling technique to describe the system vulnerabilities and generate system context attack scenarios. The attack scenarios are then refined to executable attack scripts which are executed by communication testing tools in charge of emulating the system attacks. The approach is applied to Wireless Application Protocol (WAP), which is a customized protocol used in resource constrained mobile devices. We performed experiments using specific attacks of the mobile protocol such as Denial of Service (DoS) and Message Truncation attacks. The experiments results demonstrate the effectiveness of the attack injection approach in the role of detecting security vulnerabilities in the communication system. Keywords security evaluation, attack scripts, security testing, attack injection
1
Introduction
The evolution from traditional telecommunication networks towards Next Generation Networks (NGNs) is enabling service providers to deploy a wide range of data services, all on the same underlying IP network. However, this emerging network architecture also exposes end-users and the entire network to a wide range of security treats. In this way, new security strategies for NGNs are demanded for protecting customers’ sensitive information against malicious users and attackers. For that purpose, security validation and verification techniques have excelled among traditional security solutions to strengthen the network defense mechanisms against external treats and insider attacks. The system security can be defined in terms of the attackvulnerability-intrusion model [1]. Attack is a malicious interaction fault aimed to intentionally violate one or more security properties of the system such as integrity and confidentiality. Attackers exploit the system vulnerabilities E-mail:
[email protected]
to accomplish their goals. Vulnerability is a fault introduced during the system development phases, e.g., requirements, analysis, design, and configuration, which could be exploited to create intrusions. An intrusion is an external malicious fault resulting from an attack that succeeded in exploiting a vulnerability. An intrusion can lead the system to erroneous states. If errors are not identified and isolated, security failures may occur, then violating one or more security properties of the system. Vulnerability removal is thus a very important task since it reduces the risk of successful attacks by reducing the number of vulnerabilities. Different Verification and Validation (V&V) techniques can be used for that purpose during the system development, such as static verification techniques which includes formal proofs and model checking, or dynamic verification techniques that includes testing. The identified flaws may then be removed by fixing the software errors. In this work, we focus on dynamic verification, in particular security testing, where the system code is exercised
2
by providing real inputs while its security mechanisms are evaluated. Wireless service providers are still offering low-cost WAPenable mobile devices since low-tier handsets are commonly used in developing countries. According to a recent report from Juniper Research [3], low-cost handset shipments will number more than 700 million in 2014, up by 31% as compared with 2008, as more consumers in emerging markets go wireless. In addition, spin-off technologies such as Multimedia Messaging Service (MMS), that is a combination of WAP and SMS, have further driven the WAP usage. As a result, WAP technology is actively present in low-tier mobile devices. In this paper, we present an attack script generation approach for validating security aspects of the system. The approach is applied to WAP protocol, more specifically to Wireless Transport Layer Security (WTLS) protocol [4] that is part of WAP stack. The protocol vulnerabilities are detected in the presence of attacks that are emulated by executing tailored attack scripts. Attack scenarios are automatically generated from the threat model, which describes real vulnerabilities of the protocol. Then, the attack scenarios are refined to attack scripts by applying sophisticated software engineering techniques such as attack pattern [5], eventcondition-action (ECA) rule [6], keyword vocabulary [2], and UML elements. Experiments were performed using real attacks such as Message Truncation and Denial of Service (DoS) attacks. The experimental results revealed security vulnerabilities in the WAP/WTLS protocol. In previous work [7], we have introduced our approach showing a general point of view for the attackers and the attack scenario description. In work [8], we detailed the refinement step of attack scenarios, which outputs generic attack scripts. Also, we presented the converter that maps the operations of the generic attack script to the testing tool’s instructions in order to produce the final executable attack script. The main contributions of this paper are (i) to provide a complete approach for generating generic attack scripts from attack models; (ii) to apply software engineering elements to convert attack scenarios to executable attack scripts for communication testing tools; (iii) to inject complex attacks from threat models. The remainder of the paper is structured as follows. Section 2 introduces the attack script generation approach. Section 3 presents experimental results. Section 4 describes the related work. Section 5 concludes the paper.
Morais et al. / Networking Science
Figure 1 presents the proposed approach that is composed of six steps. The steps are described in the remainder of this section.
Fig. 1 Approach for generating attack scripts
2.1 Identify the threats Attack information can be obtained from different sources, such as the Internet, books, and papers. In this step, we have to identify the attacks and vulnerabilities of the target system which are modeled in Step 3 “attack modeling” of Section 2.3. This information is mainly available in vulnerabilities databases, for instance, NIST National Vulnerability Database (NVD) and Open Source Vulnerability Database (OSVDB), which provide general information of vulnerabilities, such as release date, attack description, and vulnerability metrics which include complexity, exploitability, and violated security properties. In this work, we make use of the Attack Description (AD) and Violated Security Properties (VSP) information. Therefore, we have to perform the following steps. 1) Collect different attacks against the target system from vulnerability databases as many as possible. 2) Categorize the attacks taking into account the VSP: integrity, confidentiality, and availability. 3) Identify the attacker goals that will be used as input to model the attacks in Step 3. Firstly, we collect information of WTLS protocol vulnerabilities and attacks from the following sources: Saarinen’s work [14], SSL technical analysis [15], and WTLS Denial of Service (DoS) attacks work [16]. Next, we take the AD and the respective VSP. This information identifies the goals of the attacker. Then the attacks are categorized according to the VSP.
2 The attack script generation approach 2.2 Define the attacker capabilities In this section, we demonstrate how to generate attacks scripts from the attack description in order to evaluate the system security and find potential security vulnerabilities.
In this step, we define the Attacker Capabilities (AC), which are the abilities the attacker owns to execute the attacks. In
3
Morais et al. / Networking Science / Vol. 1, No. 1
that way, we can make sure the attack scenarios selected at Step 4 “generate the attack scenarios” can be properly carried out by the attacker. The AC are based on Dolev-Yao intruder model [17] since we use a communication system to evaluate our approach. In this model, the attacker has complete control over the communication network. The adversary can intercept, corrupt, drop, and delay messages, and send messages to any participant in the network, i.e., impersonate a given user. In addition, the attacker is aware of the status of all participants in the network. He knows what message a participant expects to receive and what message each participant sends after receiving a given message. The AC are implemented by a fault injector and a packet injector, which are able to execute the actions of the intruder model. We opted for Firmament tool [18] as fault injector since it was used in our previous work [19] for robustness testing. Firmament is capable of performing the following attacker actions: intercept, corrupt, drop, delay, and duplicate messages, as well as store/restore system information and set/get system variables. We chose the packet injector Network Traffic Generator [23] to perform the action of impersonation. The AC can be updated or redefined by the user in accordance with the testing tools selected to emulate the attacks. If the AC is modified, the keyword vocabulary defined at Step 5 “refine the attack scenarios” must also be updated accordingly. 2.3 Attack modeling Threat modeling allows systematically describing and classifying security issues and threats that affect the system by applying a methodical and structured approach [20]. Threat models range from attack tree models to more formal models like Petri net-based methods. Methods based on UML notations [21] such as use-cases, classes, and state-machines have been adopted over the last years. We apply the attack tree model as explained in work [8]. The attacker goals, which define the attacks requirements to build the attack tree model, are retrieved from the AD. We employ the same approach as Schneier [20] to perform the security analysis using the attack tree model. In attack trees, the root node represents the accomplishment of the final goal of the attacker. Each child node represents sub-goals that have to be achieved so that the parent goal succeeds as well. Parent nodes can be connected to their children in an OR or AND relationship. In an OR relationship, if any of the sub-goals are accomplished, then the parent node succeeds, which represents an ORdecomposition of the node. In an AND relationship, all of the sub-goals must be accomplished so that the parent node
succeeds, then corresponding to an AND-decomposition of the node. Then, the attack tree basically consists of a combination of AND- and OR-decompositions of the nodes, i.e., conditional decompositions of nodes. The leaf nodes, the nodes that do not have any children, represent the actions taken by the attacker. Attack trees allow selecting attack scenarios, which are generated by applying a depth-first search in the attack tree. Only leaf nodes are kept in the attack scenario since they represent the attacker actions. It is also possible to assign attributes to the nodes like the cost of an attack action, which can be used as a criterion for selection of attack scenarios. We use the vulnerabilities information collected in Step 1, i.e., AD and VSP, along with the AC parameters defined at Step 2 in Section 2.2 to build the attack tree for the WTLS protocol. As there are no specific guidelines on how to design generic attack trees, we propose the following top-bottom procedure to construct it. 1) The root node represents the generic final goal of attacking the target implementation “Attack WTLS”, thus it is an OR node and obligatorily an OR-decomposition. 2) The second level represents the VSP that the attacker attempts to violate: integrity, privacy, authentication, or availability, which constitute AND- and OR-decompositions. 3) The third level represents the WTLS security mechanisms exploited by the attacker or attack steps, which are extracted from the AD, and also constitute AND- and OR-decompositions. 4) Subsequent levels represent the attack steps to accomplish the sub-goals of level three, which are also extracted from the AD. The WTLS attack tree graphical representation is built using SecureITree tool [22], as shown in Fig. 2. The leaf nodes have the two associated attributes: AC and TA, which help establishing the Selection Criterion Sc: Sc ( AC P I ) (TA P I )
(1)
where AC is defined at Step 2, and the Test Architecture TA represents the elements to perform the tests, for example, the operating system and the testing tools. These attributes assume Boolean values: Possible P=1 or Impossible I=0. For instance, if Sc ( AC P ) (TA I ), it indicates that the attacker is capable of executing the attack scenario but the actual TA does not support the attack scenario. 2.4 Generate the attack scenarios In this step, the attack scenarios are generated from the attack tree model. An Sc must be defined in order to find the appropriated attack scenarios to be refined. We defined the Sc that designates which attributes values should be checked
4
Morais et al. / Networking Science
Fig.2 The WTLS attack tree model
for when going through the WTLS attack tree. The Sc is “to cover all attack scenarios that satisfy the AC and can be emulated by actual TA”: Sc ( AC P ) (TA P )
(2)
The attack scenarios that conform to this Sc are {1.1.2, 1.2.1, 1.3.2.1, 1.3.2.2, 1.3.2.3, 1.4.2.1, 1.4.2.2, 1.5.1, 1.5.2}. This step is completely automated since the tool that supports the construction of the attack tree model can also generates the attack scenarios based on the Sc. The obtained attack scenarios could also be used to create an attack library, which is useful to test similar systems. Alternatively, we could use preconditions and postconditions attack parameters, which are described in Section 2.5, for the leaf nodes, i.e., the attacker actions, as Sc for generating specific attack scenarios from the attack tree. However, preconditions and postconditions attributes should be previously added to the nodes of the tree. 2.5 Refine the attack scenarios The generated attack scenarios are expressed in textual language. In this step, a set of refinements are performed to produce a description suitable to be processed by the testing tool. The first sub-step of the refinement step is to describe the attack scenario applying attack pattern technique [5]. Attack pattern is a generic representation of a deliberate,
malicious attack which often occurs in particular contexts. It should be noted that the attack scenarios are, in fact, nodes of the tree, i.e., the leaves of the attack tree, as presented in Fig. 2. In this context, we apply the attack pattern elements: goal, preconditions, and steps to refine each attack scenario into three steps. We do not consider the postconditions part of attack pattern during the process of attack scenario refinement since we do not take into account actions or countermeasures for mitigating the attack impact when generating the final attack script. (1) “The overall goal of the attack”, that is the attack scenario itself generated from the attack tree model. (2) “A list of preconditions so that the attack happens”, that are the system events to activate the attack, e.g., a message that is sent from the server to the client. They are extracted from the AD. (3) “The steps to carry out the attack”, that are tasks the attacker must accomplish to succeed with the attack, which are represented as an AND-decomposition of the leaf node. They are also extracted from the AD. The WTLS protocol is based upon TLS protocol and it uses similar semantics as TLS but adapted for resource constrained mobile devices for providing security functionalities in transactions between the client and the server. In that way, we make use of attack scenario “SSLv.3/TLSv.1 truncation attack”, which is also applicable to WTLS, to demonstrate this refinement step. This attack is executed when closing
5
Morais et al. / Networking Science / Vol. 1, No. 1
an SSL/TLS connection between the client and the server. The AD is “the attacker drops the last application data Record (a PDU) and the Alert Message Record close_notify transmitted from the server to the client when closing the TCP connection, then making it appear that the whole message sent to client is shorter”. Figure 3 shows the attack pattern representation for this attack scenario. For the second sub-step of the refinement, we make use of the event-condition-action (ECA) rule, that was initially proposed to represent active databases [6]. The ECA rule is used to represent the attack pattern elements of Fig. 3 into a sequence of steps that must be carried out by the tool. 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 semantic is the following: “IF the event occurs AND the condition is verified, THEN the action is executed”. The event part stands for external events in the system context, such as the reception or transmission of messages, and it determines when the rule is triggered. The event part corresponds to the second attack pattern element “(2) preconditions”. The condition part checks if any system data, for example, a message field or state variable, contain particular values, and then fires the rule. The condition part corresponds to the third attack pattern element “(3) steps” in case it contains an ‘if ’, as presented in Fig. 3. The action part describes the actions that are performed by the attacker against the system in case the rule was fired. The action part also corresponds to the third attack pattern element “(3) steps” but only if it contains an attacker action, for example, ‘drop’ action. We use a keyword vocabulary to describe the ECA rule. This method is applied for keyword-driven testing or table-driven testing [2], where keywords are selected by an experienced tester according to the software domain under testing during the software planning phase. Then, tests are developed as data tables that contain the keyword vocabulary, which is independent of the testing tool used to execute the tests. Such data table records contain the keywords that describe the actions the tester should perform. In Fig. 4, the data table contains the keywords that describe the parts
ECA rule event
Keywords {send(A,B,m,,,,,) rcv(B,A,m,,,,,)}
condition {m.PDU_type,m.,var,protocol.} action
{intercept(m),corrupt(m.),drop(m), duplicate(m),delay(m),impersonate(m)}
Legend send() rcv()
send a message receive a message
source port destination port
A,B
sender, receiver
m.PDU_type
PDU type
m
message
m.
message field
transport protocol var
state variable
source IP destination IP
protocol properties
protocol.
Fig. 4 Keyword data table for the ECA rule
of ECA rule. The software domain taken into account is a communication system, where participants exchange messages. The keywords for action part are based on the AC defined at Step 2 in Section 2.2, and they mean the actions the attacker can perform on the communication network. In case the AC is modified at Step 2, the keywords must also be updated. The attack pattern elements of truncation attack in Fig. 3 are then converted to the ECA rule as seen in Fig. 5. The element “(2) preconditions” is mapped to event part. The elements “(3) steps” {1,2,4,5} are mapped to the condition part since they contain an ‘if ’. And the elements “(3) steps” {3, 6} are mapped to action part since drop is a keyword of action defined in the data table of Fig. 4. We can group syntactically the elements “(3) steps” {1,2} and the elements “(3) steps” {4,5} using an operator AND. In that way, two separate ECA rules are created but sharing the same event part. The event-condition-action parts of these two rules are then specified employing the keywords of the table in Fig. 4 as demonstrated in Fig. 5. Rule 1:
(2) preconditions: PDU sent from the server to the client
ON event: send(A,B,m,,,, \ ,) IF condition: (1. m.PDU_type == protocol. \ ) AND \ (2. m.==LAST) DO action: 3. drop(m)
(3) steps:
Rule 2:
AND 1. if the Record is application data
ON event: send(A,B,m,,,, \ ,) IF condition: (4. m.PDU_type == protocol. \ ) AND \ (5. m. == \ protocol.) DO action: 6. drop(m)
(1) goal: “SSLv.3/TLSv.1 truncation attack”
2. if the Record is the last one 3. drop the last Record 4. if the Record is Alert Message 5. if the Alert Message Record is close_notify 6. drop the Record close_notify
Fig. 3 Attack pattern elements for the attack scenario
Fig. 5 ECA rule representation for the attack pattern
6
Morais et al. / Networking Science
The third sub-step of the refinement is to identify UML elements to implement the ECA rule and the respective keywords in order to generate the generic attack script. The UMLintr (UML for intrusion specifications) approach [21] uses stereotypes and tagged values to specialize various UML diagrams such as use cases, classes, and state diagrams for the context of intrusion scenarios. In our approach, we propose the use of UML interface components [24] to facilitate the reusability and flexibility of the generic attack script. We define three UML interfaces: Attacker, Attack, and Victim, which represent three components that provide services through their operations. The Attacker UML interface represents the AC and provides operations for the ECA rule and its corresponding keywords. The Victim UML interface stands for the target system along with its properties extracted from the system specification. The Attack interface stands for the generated attack scenario and it will coordinate the attack steps utilizing the operations of Attacker and Victim interfaces. Table 1 presents the UML interfaces and their respective operations. We can notice Attacker and Victim UML interfaces’ operations are directly mapped to the ECA rule’s parts and the related keywords, where. • Attacker’s operations such as getProtocolType, getSourceIP, and getDestinationIP are mapped to the event part for messages analysis. • Attacker’s operations getPDUType and getPDUField are mapped to the condition part for message data extraction. The extracted data is compared with the target system’s properties, which are retrieved by Victim’s operation getProperties that is also mapped to condition part. • Attacker’s operations such as InterceptPacket, DropPacket, and DelayPacket are mapped to the action part for executing the attacker actions.
The final sub-step of the refinement is to implement the generic attack script. 1) Firstly, we implement mainAttack operation of Attack UML interface. 2) Then, we use getProperties operation of Victim UML interface to extract the target system’s properties, which are the constants of the attack script. 3) Finally, we implement the generic attack script taking into consideration the Attacker’s operations of Table 1 in conformance with the keywords of ECA rule parts in Fig. 5, and adopting the syntax: ON event IF condition DO action. Figure 6 shows the generic attack script implementation, where the Attack_Script class implements Attacker UML interface. This attack script uses a general format that is independent of the testing tool employed, so facilitating its maintainability. Moreover, this attack script can be reused to test other similar implementations, which is not common practice in traditional security testing. 1. class Attack_Script implements Attack { 2. mainAttack() { 3. Protocol_Type TCP; Port server_port; 4. PDU_Type application_data; PDU_Type alert; 5. PDU_Field record_sequence; 6. PDU_Field alert_description; 7. PDU_Field lastRecord = LAST; 8. PDU_Field close = close_notify; 9. Boolean truncate; Packet packet; 10. Converter converter; 11. UDP,server_port,application_data,alert, \ 12.
record_sequence,alert_description = \
13.
converter.getProperties(TLS);
14. while(packet==converter.InterceptPacket()){
Table 1 Interfaces and operations mapped to the ECA rule
15. if(converter.getProtocolType(packet)==TCP) AND \
Interface
16. (converter.getSourcePort(packet)==server_port){
Part
event
Attacker
condition
Keywords
Interface operation
send(…),rcv(…)
getProtocolType()
send(…),rcv(…)
getSourceIP()
send(…),rcv(…)
getDestinationIP()
send(…),rcv(…)
getSourcePort()
send(…),rcv(…)
getDestinationPort
m.PDU_type
getPDUType()
m.
getPDUField()
17. /* Rule_1:condition and action operations*/ 18. if(converter.getPDUType(packet)== \ 19.
application_data)AND \
20. (converter.getPDUField(packet,record_sequence)\ 21.
==lastRecord){
22.
converter.DropPacket(packet);}
23. /* Rule_2:condition and action operations*/
action
intercept(m)
InterceptPacket()
drop(m)
DropPacket()
delay(m)
DelayPacket()
duplicate(m)
DuplicatePacket()
impersonate(m)
SendPacket()
corrupt(m.field)
CorruptPDUField()
Victim
condition protocol.
getProperties()
Attack
—
mainAttack()
24. if(converter.getPDUType(packet)==alert) AND \ 25.
converter.getPDUField(packet, \
26.
alert_description) == close){
27.
converter.DropPacket(packet);
28.
return;} /* End of the attack */
29. }}}}
Fig. 6 Generic attack script implementation
7
Morais et al. / Networking Science / Vol. 1, No. 1
2.6 Transform the attack scripts
Table 2 Mapping from operations to Firmament instructions Operation
In this step, the generic attack script is transformed into the specific language of the testing tool, prior to execution, by a converter. The converter is modeled based on adapter design pattern [25]. The adapter pattern translates one interface into a compatible interface for a class. An adapter allows classes to work together that normally could not do because of incompatible interfaces by providing its interface to the clients while using the original interface. Figure 7 illustrates the class diagram containing the converter. In the diagram, Attack_Script class implements Attacker interface and seeks to indirectly use the operations of Testing_Tool class. The Converter class, which stands for the converter, implements the operations of Attacker and Victim interfaces, which can be directly used by Attack_Script class, as shown in Fig. 6. Hence, the operations of Converter class call and translate the operations of Testing_Tool class, which uses specific language of the tool, so that they can be understood and used by the Attack_Script class. In that way, the Attack_Script class may call the operations of Converter class, which in turn calls the operations of Testing_Tool class that returns the expected instructions provided by the testing tool language. We use Firmament tool to exemplify this step. Table 2 shows the indirect mapping of the Attack_Script class operations to Firmament’s instructions. We can obtain the executable attack script by implementing this mapping into the converter and following the steps of mainAttack operation described in Fig. 6. The obtained executable attack script has a minimum faultload, i.e., the number of actions executed by Firmament, to carry out the attack. In point of fact, the executable attack script just uses drop instruction: ‘DRP’. On the contrary, syntax testing based approaches has to generate a large faultload to detect vulnerabilities. In case of changing the testing tool, this is the only step that needs to be executed again.
Fig. 7 Class diagram for the attack script transformation
converter.getProperties()
Instruction These values are obtained from system’s specification
converter.InterceptPacket() This operation is executed by the tool SET 0x9 R0 #Read TCP field in pkt READB R0 R1 converter.getProtocolType SUB R1 R6 (packet) == TCP JMPZ R6 IS_TCP #If pkt=TCP continue JMP ERROR_OK
converter.getSourcePort (packet)==Webserver_port
SET 0x14 R0 #Read port field in pkt READS R0 R1 SUB R1 R7 pkt mfro JMPZ R7 _BROWSER#If TO server JMP ERROR_OK
converter.getPDUType (packet)==aplication_data
SET 0x1C R0 #Read PDU field in pkt READB R0 R1 SET 0x0F R0 #Check PDU mask AND R0 R1 SUB R8 R1 JMPZ R1 PDU_AD #Ifata PDU=ap_d continue JMP ERROR_OK
READS R9 R1 #Read Record Sequence converter.getPDUField SUB R5 R1 (packet,record_sequence)== JMPZ R1 DO_TRUNC #If PDU=last lastRecord continue JMP ERROR_OK DRP # Drop packet converter.DropPacket(packet) JMP INIT
3 Evaluation and results We selected attack scenarios 1.5.1 “DoS attack for CPU exhaustion” and 1.1.2 “Message Truncation attack” from WTLS attack tree model to be refined and transformed in executable attack scripts in order to demonstrate the approach efficiency for detecting vulnerabilities. The same Test Architecture described in work [7] is used to execute the experiments, which consists of a main machine with CPU Intel Core2Duo 2.40 GHz and 2.0 GB of RAM running Windows XP OS. As WAP client, we make use of Nokia Mobile Browser (NMB) simulator v.4.0.And for the WAP gateway, that is the target system, we use Columbitech WAP Connector v.1.3. The attacker is implemented by Firmament injector, which emulates the attack scenario 1.1.2, and by Network Traffic Generator v.1.3.0 for emulating the attack scenario 1.5.1.
8
The computational resources consumed by the testing tools in the main machine are minimal and do not affect the experiment execution, such as the exchange of messages between the WAP gateway and the WAP client. 3.1 The denial of service attack The “WTLS DoS attack” aims to exhaust the WAP gateway’s CPU resource. It occurs when the attacker, acting as a legitimate client, abandons abnormally the handshake phase after sending a Client Hello message with a forged IP address to the WAP gateway. Then, the WAP gateway processes the Client Hello message and replies with the messages Server Hello, Server Key Exchange, and Server Hello Done. If the attacker succeeds to send an enormous number of hostile Client Hello messages, the gateway CPU will be completely consumed while trying to process all of these fake messages then failing to provide services for legitimate clients. We defined 4 test cases to execute the attack injections against the WAP gateway. The duration of each test case execution is 3600 seconds, which gives a total experiment duration of 240 minutes. We implemented the DoS Attack_Script instance according to the attack scenario 1.5.1. The instance injects 36000000 fake Client Hello messages during 3600 seconds, i.e., 1 message/10 ms. During
Fig. 8 CPU usage of WAP gateway during attack execution
Morais et al. / Networking Science
the experiments, we monitor the CPU usage for the WAP gateway as illustrated in Fig. 8. For test case 1, we used one instance of the Attack_Script with the parameters: (i) repeat_count = 360000 packets; (ii) time_interval = 10 ms; (iii) source_address = 10.1.1.3; and (iv) destination_address = 10.1.1.4. During the execution of the script, the average WAP gateway’s CPU usage AWG is low, i.e., around 10%, and the maximum WAP gateway’s CPU usage is MWG=15%, as shown in Fig. 9 and Fig. 8(a). The average total CPU usage A T is 11%. Therefore, the attack failed for this test case. Although we increase the time_interval to its maximum level of 1 ms, i.e., a package is injected at every 1 ms, AWG does not increase. Since the instance of the Attack_Script used in test case 1 was not sufficient to exhaust the CPU resource, then for test case 2 we decided to create ‘variations’ of the Attack_Script. Each variation modifies the parameter source_address=10.1.1.X, where X is the number of variations, i.e., the number of the different forged IP addresses used in the experiment. Then, we simultaneously executed 12 variations of Attack_Script during the attack injection. For this test case, AWG significantly increased from 10% to 35%, and CPU usage reached a peak of MWG=47%, as shown in Fig. 9. The WAP gateway CPU usage remains constant during the test case execution, as shown in Fig. 8(b),
9
Morais et al. / Networking Science / Vol. 1, No. 1
Fig. 9 Summary of the DoS attack results
and AT=44%. However, the DoS attack also failed for this test case. According to WTLS specification, the WAP gateway has a protection mechanism to prevent DoS attacks, where it ignores Client Hello requests if they are received very often from the same IP address. Therefore, it is very likely that for test cases 1 and 2 the WAP gateway treats the fake Client Hello message requests until a certain limit is reached, then subsequently discarding all the fake requests. In test case 3, we used 24 variations of the Attack_Script to attempt bypassing the WAP gateway protection mechanism. As explained earlier, each variation contains a different forged IP address. Then, AWG increased from 35% to 78% compared to test case 2, and CPU usage reached a peak MWG=84%, as seen in Fig. 9. For this test case, the CPU resource was completely exhausted, i.e., AT=99%, since AWG=78% and the average network service’s CPU usage ANS was 21%, then consuming 99% of CPU. The DoS attack succeeded for this test case and the WAP gateway protection mechanism failed. In test case 4, we used 36 variations of the Attack_Script. For this test case, we can note AWG=65% and CPU usage reachesa peak of MWG=77%, as presented in Fig. 9 and Fig. 8(d). Thus, the CPU resource was also totally consumed, i.e., AT=99%, since AWG=65% and ANS=34%. The DoS attack also succeeded for this test case and the WAP gateway protection mechanism equally failed. During the injection of attacks, we tried to access WAP pages in the WAP browser, such as wap.yahoo.com, in order to verify the WAP gateway service availability. For test cases 1 and 2, the WAP gateway replied to all the requests from the browser, therefore security property of availability is not violated. Nevertheless, for test cases 3 and 4, the WAP gateway did not reply the requests from the browser since its CPU was completely exhausted. After a timeout of 65 seconds, the WAP gateway displays the error message:
“Unable to establish secured connection”. Therefore, a security failure is detected and the security property of availability is violated since the requested service is denied to legitimate users. The Attack_Script variations used for test cases 2, 3, and 4 are, in reality, mutations of the original Attack_Script instance executed in test case 1. These variations can be interpreted as a new type of WTLS DoS attack since they use different forged IP addresses rather than only using one fake IP address as described in the original attack scenario of 1.5.1. This new type of DoS attack is a Distributed Denial of Service (DDoS) attack, where several compromised systems flood the bandwidth and computational resources of the target system for denying service for legitimate users. 3.2 The message truncation attack The “WTLS Message Truncation attack” is based on the “SSLv.3/TLSv.1 truncation attack” explained in Section 2.5. However, for this attack only the last application data Record is dropped during the data transfer session because WAP uses UDP protocol as transport service as opposed to TLS protocol that uses TCP protocol. Thus, the security layer of WAP does not transmit the closure Alert Message Record close_notify to signalize a connection closure. We selected four WAP sites, for instance, wap.yahoo.com, for the experiments, and we consider four navigation levels for each WAP site. The first navigation level corresponds to the initial WAP page, the second level corresponds to a random link accessed through the initial page, and so on. We create a separate test case for each WAP site navigation level, then resulting in 16 test cases. We inject the Message Truncation attack for every test case, i.e., when the respective WAP page is loaded in the browse. We performed 90 attack injections for each test case, then 360 attack injections per WAP site, and a total of 1440 attack injections. The duration of each attack injection is about 75 seconds, which gives a total experiment duration of 30 hours. The attack scenario 1.1.2 aims violating integrity security property. Consequently, a security failure occurs when any information is missed or altered for the user context, i.e., a page is not exhibited as expected in the browse interface. The observed results are classified as Successful Attack SA or Failed Attack FA, as follows: (1) SAT: data truncation on the top of the page, i.e., the browser misses to load any content on top area of the page; (2) SAB: data truncation on the bottom of the page, i.e., the browser misses to load some content on bottom area of the page; (3) SAO: other data truncation on the page, i.e., the browser misses to load page any content in other region of the page; and (4) FA: no data truncation, i.e., no change is observed on the page
10
displayed by the browser. The experiment results are summarized in Fig. 10. We can note that the percentages of SAT, SAB, and SAO results differ from each other for all the WAP sites, even though the sum of the SA results, i.e., SAT+B+O, have similar values for the WAP sites. This behavior is observed because one navigation level of a given WAP site has major SA results compared to the others navigation levels of this WAP site. For instance, WAP site 1’s navigation levels 1 and 2 have significant SAT results (45.6%), and the navigation levels 3 and 4 have significant SAB results (46.7%), which result in more expressive SAT and SAB results for WAP site 1. We can also note the percentage of one SA result alone, e.g., SAT, varies among the WAP sites, as shown in Fig. 10, because of the same reason. We observe that WAP site 3 has the highest percentage of FA results among the WAP sites, as shown in Fig. 10. This is because the test cases of WAP site 3 employed as input WAP pages loaded with more embedded content compared to the other WAP sites test cases, which required more data packets to be transmitted between the WAP gateway and the browser. Then, the communication network interface was obliged to adjust the total number of data packets to be transmitted, so causing traffic fluctuations. Therefore, the last data packet of the message could not be detected by the attack script, and the last application data Record was not dropped, then leading to FA result. That means that in real life, the attacker would need to execute for this particular type of WAP page a high number of attack instances in order to succeed with the Message Truncation attack. In Fig. 10, we can see SAT+B+O result for “All WAP sites” (87.4%) is much higher than FA result (13.3%), which means most of injected attacks resulted in security failure, i.e., the security property integrity is violated. That demonstrates
Fig. 10 Summary of the Message Truncation attack results
Morais et al. / Networking Science
the good precision of the approach in exploiting security flaws. The approach efficiency is calculated as follows. total of SAT+B+O /total of injections=87.36% This value is superior to Fuzz and syntax testing based approaches, where a large proportion of attack injections, i.e., at least 30% of the injection experiments, has no visible effect on the target system [26]. Therefore, they are irrelevant for the testing campaign and not detectsecurity vulnerabilities on target system. The different types of SA results obtained show how the same Message Truncation attack can cause distinct types of failures on the target application. Actually, these diversified SA results depend on the content of the last packet that is dropped during the WAP session because the application layer of WAP treats the received data in different ways for displaying the WAP page. An SA result means that a security failure occurred, i.e., the WTLS did not detect the message truncation. During the attack injection, the browser keeps waiting for the last packet (PDU) for approximately 65 seconds. After that period, the browser displays the error message: “Operation aborted by server”, and it displays the WAP page partially loaded with the truncated content instead of aborting the WAP page exhibition, then characterizing a typical application failure. 4 Related work and comparison Several works have applied security testing and fault injection methods to evaluate the system security. Thompson et al. [9] tested the software security in a hostile environment. Faults are injected during runtime by monitoring and modifying system calls made by the application to the operating system. In that sense, they emulate the behavior of a hostile environment. However, they do not mention how to associate the malicious behavior with more realistic attacks. Wanner and Weber [10] designed and developed a communication fault injector to test network security systems. The fault injector provides security functionalities to the user, for instance, DNS-spoofing and Tcpkill, in order to simulate attacks against applications using TCP/IP protocol. However, in this work, the threat scenarios are injected without applying a systematic methodology for performing security testing and the feasibility of the approach is not demonstrated. Neves et al. [11] proposed an attack injection tool for vulnerability detection, where the protocol messages are modified by using syntax testing in combination with value testing in order to violate the integrity of the protocol behavior. Then, the tool connects to the target application
11
Morais et al. / Networking Science / Vol. 1, No. 1
and injects such corrupted packets. The approach is applied to IMAP protocol, in which a large number of attacks are injected against several IMAP server applications containing flaws. The method efficiency is measured as E=#detected_ flaws/#injections. Then, we calculated the approach efficiency using the data provided by the authors and obtained E=1.02%, which is a very low value compared to the efficiency of our approach, that was 87.36% for the truncation attack. In the work [12], Kaksonen et al. presented an approach for security assessment of applications based on fault injection. The test cases are generated by mutating the message syntax, message content, and message exchanges, i.e., the syntax specification of the protocol. The approach is likewise applied to WAP protocol, more specifically to Wireless Session Protocol (WSP) of WAP suite. Then, the entire test suite is executed against different WAP gateway applications. The approach efficiency is defined as E=#failed_tests/#test_cases. Thus, we obtained E=59.94%, which is superior to that one of Neves et al’s approach [11], but it is inferior to the efficiency estimated for our attack generation and injection method. Hsu et al. [27] proposed a model based approach to detect security flaws in protocol implementations. The approach makes use of the protocol behavior model together with Fuzz testing [13] for generating the system inputs, which are executed by a fuzzing test tool. The approach is applied to Microsoft MSN instant messaging (MSNIM) protocol, and the experimental results show it finds a significant number of crash instances as a result of the fuzzed input messages provided to the MSNIM applications. However, we cannot verify the approach efficiency since the authors do not present the total number of messages altered, i.e., the number of incorrect inputs provided to the target protocol, compared to the number of vulnerabilities discovered, i.e., the number of crashes for the application instances. Most of the actual security testing approaches produce attacks either by applying Fuzz testing, where random inputs are provided to the interfaces of the system and protocol messages, or by using syntax testing, where the inputs of the application are corrupted with known malicious attack patterns, for example, long strings and invalid characters. With the use of such approaches, the system security vulnerabilities are exploited in a limited manner since there is no direct correlation between the number of inputs provided, i.e., number of test cases, and the number of vulnerabilities found for the target system, then making it difficult to reproduce the exact results obtained from the tests by employing these security testing techniques. Moreover, the majority of security validation methods do
not mention how to model the attacks, i.e., the test cases, which are executed in the course of the experiment. Therefore, they do not allow the attack scenarios to be reused for analogous applications or ported to compatible testing tools/attack injectors. In addition, an extensive number of testing experiments is needed to detect a few vulnerabilities, which has naturally a negative impact on the efficiency of the approach. 5 Conclusions We have proposed an original attack scenario generation and injection approach to efficiently perform security evaluation. Attack scenarios are derived from the attack tree model that is composed of real vulnerabilities and attacks from the target system. These attack scenarios are refined to executable attack scripts for communication fault injectors. We show the approach viability by applying it to the WAP/WTLS protocol. We performed various experiments by injecting Message Truncation and DoS attacks against the target protocol. The experiments results prove the good precision and efficiency of the proposed approach in uncovering security vulnerabilities. In a future work, we envisage to implement attack generation methods for creating variants of the attack scripts and attack scenarios in order to evaluate the effectiveness of the system defense and analyze the intrusion detection capabilities of the target system. References [1] D. Powell, A. Adelsbach, C. Cachin, S. Creese, M. Dacier, Y. Deswarte, T. McCutcheon, N. Neves, B. Pfitzmann, B. Randell, R. Stroud, P. Verissimo, and M. Waidner, “MAFTIA (Maliciousand Accidental-Fault Tolerance for Internet Applications),” in Proc. Int. Conf. Dependable Systems and Networks (DSN), Göteborg, Sweden, 2001, pp. D32-D35. [2] C. Nagle. (2001). Keyword Driven Automation Framework Model [Online]. Available: http://safsdev.sourceforge.net/ FRAMESDataDrivenTestAutomationFrameworks.htm. [3] Juniper Research. (2011, Jan. 27). Low Cost Handsets & Entry Level Smartphones [Online]. Available: http://juniperresearch.com/ reports/low_cost_handsets_&_entry_level_smartphones. [4] Wap Forum. (2001, Apr. 06). Wireless Transport Layer Security Specification Version 06-Apr-2001 [Online]. Available: http://www.wapforum.org/what/technical.htm.. [5] A.P. Moore, R. J. Ellison, and R.C. Linger, “Attack modeling for information security and survivability,” Technical Note CMU/SEI-2001-TN-001, Mar. 2001. [6] N. W. Paton, O. Díaz, M. H. Williams, J. Campin, A. Dinn, and A. Jaime, “Dimensions of active behaviourn,” in Proc. 1st Int. Workshop Rules in Database Systems, Edinburgh, Scotland, 1993, pp. 40 57.
12 [7] A. Morais, E. Martins, and A. Cavalli, “Security Protocol Testing Using Attack Trees,” in Proc. Int. Conf. Computational Science and Engineering, Vancouver, Canada, 2009, pp. 690 697. [8] A. Morais, E. Martins, and A. Cavalli, “A model-based attack injection approach for security validation,” in Proc. 4th Int. Conf. Security of Information and Networks, Sydney, Australia, 2011, pp. 103 110. [9] H. H. Thompson, J. A. Whittaker, and F. E. Mottay, “Software security vulnerability testing in hostile environments,” in Proc. ACM Symp. Applied Computing (SAC), Madrid, Spain, 2002, pp. 260 264. [10] P. C. H. Wanner and R. F. Weber, “Fault injection tool for network security evaluation,” in Dependable Computing: LNCS vol. 2847, R. de Lemos, T. S. Weber, and J. B. Camargo, Jr, Eds. Berlin: Springer, 2003, pp. 127 136. [11] N. Neves, J. Antunes, M. Correia, P. Veríssimo, and R. Neves, “Using attack injection to discover new vulnerabilities,” in Proc. Int. Conf. Dependable Systems and Networks (DSN), Philadelphia, USA, 2006, pp 457 466. [12] R. Kaksonen, M. Laakso, and A.Takanen, “System security assessment through specification mutations and fault injection,” in Proc. IFIP TC6/TC11 Int. Conf. Communications and Multimedia Security Issues of the New Century, Darmstadt, Germany, 2001, p. 27. [13] B. Miller. (1990). Fuzz Testing of Application Reliability [Online]. Available: http://pages.cs.wisc.edu/~bart/fuzz/. [14 ] M.-J. O. Saarinen, “Attacks against the WAP WTLS protocol,” in Proc. IFIP TC6/TC11 Joint Working Conf. Secure Information Networks: Communications and Multimedia Security, 1999, pp. 209 215. [15] D. Wagner and B. Schneier, “Analysis of the SSL 3.0 protocol,” in Proc. 2nd USENIX WorkshopElectronic Commerce, Berkeley, USA, 1996, pp. 29 40. [16] R. Zhang and K. Chen, “Improvements on the WTLS protocol to avoid denial of service attacks,” Computers & Security, vol. 24, no. 1, pp. 76 82, Feb. 2005.
Morais et al. / Networking Science [17] D. Dolev and A. Yao, “On the security of public-key protocols,” IEEE Trans. Inf. Theory, vol. 29, no. 2, pp. 198 208, Mar. 1983. [18] R. J. Drebes, G. Jacques-Silva, J. F. da Trindade, and T. S. Weber, “A kernel-based communication fault injector for dependability testing of distributed systems,” in Proc. of Parallel and Distributed Systems: Testing and Debugging (PADTAD-3), Haifa, Israel, 2005, pp. 177 190. [19] A. Cavalli, E. Martins, and A. Morais, “Use of invariant properties to evaluate the results of fault-injection-based robustness testing of protocol implementations,” in Proc. 4th Workshop Advances in Model Based Testing (AMOST'08), Lillehammer, Norway, 2008, pp. 21 30. [20] B. Schneier, “Attack trees: Modeling security threats,” Dr. Dobb’s Journal, vol. 24, no. 12, pp.21 29, Dec. 1999. [21] M. Hussein and M. Zulkernine, “UMLintr: A UML profile for specifying intrusions,” in Proc. 13th Annu. IEEE Int. Symp. and Workshop Engineering of Computer Based Systems, Postdam, Germany, 2006, pp. 279 288. [22] Amenaza Technologies Limited. (2006, Aug. 16). Secur/Tree Tutorial [Online]. Available: http://www.amenaza.com/downloads/ docs/Tutorial.pdf. [23] R. Sandilands. (2009). Network Traffic Generator [online]. Available: http://sourceforge.net/projects/traffic/. [24] F. Bachmann, L. Bass, C. Buhman, S. Comella-Dorda, F. Long, J. E. Robert, R. C. Seacord, and K. C. Wallnau, “Volume II:. Technical concepts of component-based software engineering,” Technical Report CMU/SEI-2000-TR-008, 2nd ed. May 2000. [25] E. Gamma, R. Helm, R. Johnson, and J. Vlissides, Design Patterns: Elements of Reusable Object-Oriented Software. Reading, USA: Addison-Wesley, 1995. [26] LAAS-CNRS. (2006). Deliverable D12 Resilience-Building Technologies: State of Knowledge. Available: http://www.resistnoe.org/outcomes/outcomes.html. [27] Y. Hsu, G. Shu, and D. Lee, “A model-based approach to security flaw detection ofnetwork protocol implementations,” in Proc. 16th IEEE Int. Conf. Network Protocols (ICNP), 2008, pp. 114 123.
