Implementation of a Wormhole Attack on Wireless Sensor Networks with XBee S2C Devices

Abstract

One of the most dangerous threats to Wireless Sensor Networks (WSN) are wormhole attacks due to their capacity to manipulate routing and application data in real time and cause important damages to the integrity, availability, and confidentiality of network data. In this work, an empirical method to launch such attack (which is successful) on IEEE 802.15.4/Zigbee devices with source routing enabled is adopted to find signatures for detecting wormhole attacks in real environments. It uses the KillerBee framework with algorithms for packet manipulation through a malicious node to capture and inject malicious packets in victim nodes. Besides, a reverse variant of wormhole attack is presented and executed. To evidence the realization of this threat by the attacking software, the experimental framework includes XBee S2C nodes. The results include recommendations, detection signatures and future work to face wormhole attacks involving source routing protocols like DSR.

1 Introduction

A The Internet of Things (IoT) is a growing technology trend towards connecting all kinds of electronic devices to the Internet. The purpose of IoT devices is to interact and share information to ease end users’ life. Thanks to it, by 2020 nearly 37 billion devices are going to be connected to the cyberspace [1]. Nevertheless, IoT is a new challenge in the information security field because a wide range of devices with different security features can be integrated, leading to a wider security gap. Furthermore, the implementation of security measures such as strong cipher protocols on devices with reduced processing power and memory, like environmental sensors, is a difficult task [2]. One of the most important IoT technologies are Wireless Sensors Networks (WSN), which can be deployed in many places (e.g. homes, buildings, cities, factories and hospitals) to monitor environmental variables: temperature, humidity, movement, lighting, and also to improve processes in the industrial field [3].

On the other hand, a considerable number of vulnerabilities and security threats related to WSNs has been presented in various research studies [4,5,6] that introduce potential damages to the integrity, availability, and confidentiality of the information in a WSN. Some of these threats are related to the network layer in the protocols stack. They include attacks selective forwarding, sinkholes, and wormholes, and are intended to induce an unwanted behavior in specific elements of WSNs through malicious nodes and traffic manipulation. These attacks are successful because they give an attacker the ability to intercept and modify data in real time, execute denials of service and selective forwarding attacks, store packets, inject false information into legitimate nodes and disrupt routing processes [7]. The risks of wormhole attacks represent new security gaps that must be addressed and reduced to protect end users’ data and privacy.

1.1 Background

Wormhole attacks exploit the mechanisms to discover routes of on-demand routing protocols. The most remarkable cases are Ad-Hoc On-Demand Distance Vector (AODV) and Dynamic Source Routing (DSR) protocols, which use route request (RREQ) and route replay (RREP) packets as a way to discover routes by nodes in a WSN [8]. A RREQ packet is a broadcast message sent by a source node (“S”) to request a route to a destination node (“D”), while an RREP is a unicast message sent by the destination node in response to an RREQ. Besides, when the RREP that contains the route to reach “D” arrives at “S”, the source node stores the route collected by the RREP in the route cache and then sends the application data to “D” through that route. Accordingly, the main goal of wormhole attacks is to build a tunnel between two remote nodes through a third node (“M”) placed within transmission range of “S” and “D”. This occurs when “S” needs to send application data to “D” and broadcasts an RREQ message to discover a route to “D”. “M” (which is listening to network traffic) forwards the message directly to “D” because the RREQ sent by “M” reaches “D” before the original RREQ through the direct link. “M” can listen to RREP from “D” first and then forward it to “S” with better metrics (zero hops), thus creating a false direct link between “S” and “D” through “M” in the process (Fig. 1).

Fig. 1.

Wormhole attack with malicious node

At this point, the attacker can control the data that flows through the malicious tunnel and launch other attacks. Finally, if victim nodes are too far from each other, the attacker can use two malicious nodes sharing a link to build the wormhole tunnel [9].

1.2 Related Work

In [10], wormhole attack detection is based on hop count and delay changes between source and destination nodes. If there is a wormhole tunnel between given source and destination nodes, the delay increases due to the longest path created by the wormhole tunnel, while hop count decreases for the same reason. In that sense, the detection scheme compares delay and hop count at a given moment with previous values to detect the attack. [11] proposes to apply modifications to the DSR routing protocol to automatically calculate a Round Trip Time (RTT) delay value between source and destination nodes at a given moment. Thus, initial RTT values are stored and compared with subsequent values of the same kind. If RTT changes, a wormhole attack is detected. Additionally, the network nodes are set in a promiscuous mode to monitor neighboring nodes. [12] introduces a modified version of the AODV routing protocol to calculate the transmission force from source nodes. The method aims to detect wormhole attacks with high transmission power by establishing a transmission power threshold for network nodes. If a node exceeds such threshold, it could be a compromised node and a wormhole attack is detected. In another modification of the AODV protocol [13], network nodes introduce the hash of the hop addresses and hop count into the RREQ packet while it follows a path from source to destination. When the RREQ packet reaches the destination node, the expected hash of RREP is calculated and compared with the received hash. If the hashes do not match, the packet is discarded assuming a wormhole attack in progress. In [10], to detect a wormhole attack, source nodes of RREQ calculate the delay between a sent RREQ and every received RREP to establish an average RTT value for all received routes. If the RTT of one or more routes is less than the average RTT, a wormhole attack is detected, malicious routes discarded, and the detection is replied to neighboring nodes to delete the malicious routes from their routing table. In [13], every node calculates changes in the number of neighboring nodes by counting neighbors at different times.

As a result, a wormhole attack is detected if a predefined threshold of the number of neighboring nodes is exceeded by one or more nodes. Besides, [14] presents a wormhole detection algorithm with node connectivity and statistical calculation. Such method defines two terms, node connectivity and network connectivity, to determine the probability of a wormhole attack in progress in the network. The probability of said attack depends on the network’s density, which is based on the number of nodes and connections between nodes.

The research studies above conducted tests in simulation environments to measure the impact of wormhole attacks and the effectiveness of different detection/prevention algorithms in WSNs. Nevertheless, they are based on simulations of routing protocol attacks and are difficult to implement in real environments because of the lack of devices with the features required by the proposed methods. Due to existing and potential cybersecurity threats to WSNs, intrusion detection systems need to be developed for real sensor nodes. At last, since most WSN security research studies are based on simulation results, future characterization of WSN threats should focus on real devices to build actual security solutions and prevent security disasters in WSN technologies.

To expose the flexibility of a wormhole attack and its impact on real cybersecurity environments, this paper proposes an algorithm to execute classic and “reverse” wormhole attacks on XBee S2C devices with source routing enabled. The main goal is to modify the route record field in routing packet headers to manipulate the routing cache in victim nodes. The algorithm is implemented in Python language using the KillerBee framework and an RZUSBSTICK dongle with preinstalled KillerBee firmware. The results include recommendations to prevent wormhole attacks, attack patterns and fingerprints to develop an Intrusion Detection System (IDS) for WSNs as future work.

2 Proposed Wormhole Attack Algorithm

The route record field in source routing packets [15, 16] contains the whole route from source to destination when the routing packet reaches the source of data transmission. This feature allows the intermediary hops between source and destination nodes to introduce their network address into the routing packets (RREP) while the packet follows the path from destination to source. A route is thus created and can be used by source nodes to send data packets to the corresponding destination of the source route, as shown in Fig. 2. When the route record field is void in received RREP packets, it means that both nodes source and destination are neighboring nodes.

Fig. 2.

Route record parameter process

In a classic wormhole attack, the main goal is to create a false neighborhood between two remote nodes through a third malicious node causing the route record field of RREP packets sent through the malicious links to be unmodifiable by intermediary nodes; as a result, they arrive at the destination with zero hops. This approach encompasses capturing packets, modifying the route record in RREP packets and injecting them into the source node to override its routing table with zero hop routes, which eventually builds a false neighborhood between source and destination nodes, as shown in Fig. 3. Consequently, the route record parameter needs to be modified because RREP packets could come from an intermediary node.

Fig. 3.

False route record injection

A wormhole attack begins with an attacker introducing a malicious node into a WSN to gather critical information about network attributes related to node types, network ID, frequency and operational channel. During this step, the target nodes are selected. Subsequently, the malicious node starts a packet capture process to find routing packets involving target nodes (interesting traffic). Once the interesting traffic is captured, the malicious node sets the hop count and relay list to zero in the route record header of the routing packets. Besides, source and destination MAC addresses are changed to match the network addressing of victim nodes since packets from an intermediary node can be captured. Finally, the malicious node forwards the modified routing packet to the destination node, overriding its routing table with the false route and creating a false neighborhood between target nodes in the process. The next step is to continue capturing packets to find application data to be modified and injected into destination nodes. When malicious nodes are not able to capture interesting traffic, the packets are stored and the capture process is restarted. Figure 4 shows the workflow of the proposed algorithm.

Fig. 4.

Proposed wormhole attack algorithm.

In addition, two conditions must be satisfied to carry out a successful wormhole attack: (1) Source and destination addresses must match between layer 2 (802.15.4) and layer 3 (Zigbee); otherwise, the destination node of the RREP discards the packet. (2) The packet sequence number has to be different from the original routing packet; otherwise, the modified packet is discarded [13]. The proposed attack works by overriding the destination node of the RREP’s routing cache by injecting a modified version of the original routing packet, which prevents ZigBee devices from using the original route.

2.1 Attacking Software Design

The proposed algorithm was used to develop an attacking software for real devices as a tool to probe security levels in wireless sensor networks since most research studies describe wormhole attacks by means of simulation environments. On the other hand, the purpose of the attacking software is to expose attributes of ZigBee devices and wormhole attacks that could be used to effectively detect the latter. This section presents a short description of every phase of the attack.

2.2 Software Requirements

Scapy and KillerBee frameworks are required to dissect, capture and store packets, and also to inject malicious traffic into victim nodes. These features are combined in a Python script to execute the wormhole attack and build the malicious tunnel.

• (1) Malicious node introduction: During this phase, an attacker sends “beacon-frame”¹ requests channel by channel to discover routing and coordinator nodes in the network, as well as device addressing and network ID using the zbstumbler command of the KillerBee framework.

• (2) Attacking software design: The attacking software presents the following attributes and functions.

Packet Capture and Network Learning:

It occurs when the attacker has selected victim nodes in the network. Then, using relevant networking data like PANID, frequency channel, and node addressing, it captures the packets transmitted over the air through a malicious node. The following pseudocode algorithm describes the packet capture phase.

The attack begins by using the sniffer object of the KillerBee framework to capture packets with ZigBee source routing header. Once a source routing packet has been captured, the next step determines if the packet belongs to a target device. If not, the while loop continues until KillerBee’s sniffer captures a source routing packet that involves victim nodes.

Interesting Traffic:

A packet is interesting traffic when it is originated or sent from/to an attacker-defined victim device. In that sense, the attacker must dissect the captured packet, extract the addressing data and compare it with victim nodes’ addressing. As shown in Algorithm 1, the compare function compares addresses. Since the KillerBee sniffer generates an object from the captured packet, packet dissection becomes a simple task. It consists of retrieving the addressing data from the packet object attributes (Algorithm 2).

The previous algorithm determines if a captured packet involves victim nodes’ addressing in a data transaction. Once the addressing data is compared, the result can be true if both destination and source addresses of the captured packet and victim nodes are the same. It can also be false if one or more addressing data are not equal. In that case, the packet capture algorithm is executed again.

Routing Packet Modification:

After finding an RREP packet with the right addressing, the attacking software changes some attributes of the routing information in the captured packet to build the malicious tunnel. It specifically modifies route record information related to hop count, relay list, and sequence number. Algorithm 3 executes the routing packet modification.

Packet modification begins by rewriting the sequence_number of the captured packet with a random number between 1 and 255 to prevent the destination node form discarding the modified packet sent by the malicious node. At that point, the wormhole attack can present two scenarios: (1) victim nodes are further apart than one hop of distance, or (2) the victim nodes are neighbors.

The first case describes a classic wormhole attack, and the modifications of hop_count and relay_list are made to “eliminate” the distance between victim nodes. Such changes also make nodes “think” they are neighbors because of the wormhole tunnel. Because victim nodes are distant from each other, layer 2 addressing must be altered to match layer 3 addressing. The second scenario is a “reverse” wormhole attack, where victim nodes are neighbors and a malicious node tries to add distance in-between. In such case, packet modifications are performed by increasing the hop_count number and adding intermediary nodes to the relay_list.

Routing Packet Forwarding:

After the routing packet has been modified, the next step is to send it to its real destination with the send method of the KillerBee framework. Additionally, a new packet capture process is conducted to search for application data. The latter is used to make further modifications that may cause an unwanted behavior in the application of the WSN. Algorithm 4 shows the packet injection process.

Packet injection causes two possible effects in victim nodes because, once the modified packet is processed by the destination node, it depends on the malicious node whether to forward the next application packets or not. If they are not forwarded, the attack may cause a denial-of-service (DoS) state.

Data Packets Modification and Forwarding:

As shown in Algorithm 4, this wormhole attack tries to modify application as well as routing data. In this case, the destination node of the application data would receive the attacker’s data. The main differences with a replication attack is that the proposed wormhole prevents the direct communication between involved victim nodes and it works over real-time traffic.

At last, the entire process is repeated indefinitely, injecting false routes with every modified data packet sent to the destination node to maintain the wormhole tunnel until the script is stopped or moved to another network point.

3 Implementation and Results

In this section, the implementation of the proposed worm- hole attack on a testing network takes place without encryption protocols applied in the packets to measure its impact on unsecured devices.

3.1 Network Requirements and Characteristics

Table 1 lists legitimate features of nodes and the parameters used to build the prototype network. The malicious node specifications are shown in Table 2. Atmel RZUSBSTICK with KillerBee firmware is used in conjunction with Raspberry Pi 3 to capture packets and inject modified data and routing packets into victim nodes.

Table 1. Legitimate node features.

Table 2. Malicious node features.

In order to execute the reverse and classic wormhole attacks, two testing networks were built with a coordinator node and two router nodes. Figure 5 presents a reverse wormhole scenario with router nodes sharing a direct link, which is common between neighboring nodes. On the other hand, Fig. 6 shows router nodes without a direct link and the coordinator node as an intermediary node (adding one hop of distance between router nodes) to test a classic wormhole attack.

Fig. 5.

Prototype network for reverse wormhole attack

Fig. 6.

Prototype network for classic wormhole attack.

In a reverse wormhole attack, victim nodes are identified by network addresses 0x72DD (source of route record) and 0x88F8 (source of application data). In a classic wormhole attack, the source node has the network address 0xE99C, while the destination node has 0xF14B. At last, the coordinator node has the default address 0x0000 in both cases.

3.2 Wormhole Attack Execution

• (1) Reverse wormhole attack: The main goal is to add distance between victim nodes by modifying the hop count and relay list in the routing packet, thus avoiding using the direct link shared by nodes 0x72DD and 0x88F8. The following command line output shows the execution of the wormhole attack script.

  

The attack starts by capturing packets until a source routing packet involving victim nodes is found. Then, the routing packet is injected a hop count equal to 1 and an intermediary node (0xABCD) into its relay list parameter. Finally, when the script captures an application packet, the application data is replaced with the sentence “reverse wormhole”. Figure 7 shows the original application frame sent by node 0x88F8. In this case, the original application packet has the word “TEST”. When the packet arrives at the destination node, an update of the source route is sent to 0x88F8 from 0x72DD, as shown in Fig. 8.

Fig. 7.

Original application packet payload.

Fig. 8.

Original source routing packet for neighboring nodes.

Figure 9 shows the malicious route injected into 0x88F8 when the reverse wormhole attack captures the first source routing packet.

Fig. 9.

Modified source routing packet.

Figures 8 and 9 show the difference between both routes. The first one contains the attributes of the original route with 0 relays as “Number of addresses”. The second one contains the false intermediary nodes with a relay that has the address 0xABCD. Due to this, the malicious node is the only one that can listen to the next application packets sent by 0x88F8, which are changed by the attacker’s malicious data (Fig. 10).

Fig. 10.

Malicious data received at destination node.

• (2) Classic wormhole attack: Similar to a reverse wormhole attack, this variant captures routing packets to create the malicious tunnel and application packets to inject malicious data. Figure 11 shows the legitimate and malicious routing packet received at the source node. The first route record indicator entry belongs to the original source of RREP and the second entry is the RREP modified by the malicious node to override the routing table of a victim node.

  Fig. 11.

  

  Received routing packets.

Once again, a source route is updated when the source node attempts to send the word “TEST” and the packet is captured and modified by the wormhole attack. Figures 12 and 13 present the changes in the route received by the source node.

Fig. 12.

Original source route fields.

Fig. 13.

False source route fields.

An evident change can be observed in the field Number of addresses (hop count) of the source routes: the value goes from 1 hop in the first packet to 0 hops in the second. After false route injection, the source node attempts to send the word “TEST” and the task of the wormhole attack script is to replace these data with the word “WORMHOLE”. Figure 14 shows the malicious data packet received by the destination node, and Fig. 15 shows the content of the packet.

Fig. 14.

Modified application data received at destination node.

Fig. 15.

Application data content after attack.

3.3 Signatures for Wormhole Attack Detection

• (1) Routing packet duplication: In ZigBee devices, source routes can be requested by sending the Network Discovery (ND) command or updated when destination nodes receive a packet. In that sense, a wormhole attack must inject false routes for every modified packet that is sent, thus forcing the sensors/devices to receive two source routing packets per data packet transmitted to destination nodes. The abrupt changes in route record fields of the routing packets and the increase in transmitted routing packets could be used to detect the presence of an attacker in the network.

• (2) Multiple “beacon-frame” requests without a joined de- vice: The first step to attack WSNs is launching a discovering process to identify possible targets in the network. In 802.15.4/Zigbee networks, “beacon-frame” requests are responded by router and coordinator nodes to have new nodes join the network. However, after malicious nodes send a “beacon-frame” request, no new devices join the network. To monitor this behavior, pairing beacon request frames with newly joined devices in the WSN would help to detect active scans before the wormhole attack occurs.

• (3) Neighborhood table and link status packets: ZigBee devices regularly send link status packets to maintain a first hop neighborhood table. Due to the fact that remote nodes cannot share link status packets, wormholes are detected by examining previous link status messages of nodes in a routing packet with route record of zero hops. If previous link status messages are not found, a wormhole threat is detected. On the other hand, a reverse wormhole is detected by checking routing packets with route records containing more than one hop. If the nodes involved in the transmitted packet have shared link status messages before, a reverse wormhole is detected. This approach could be used with neighborhood tables instead of link status messages.

3.4 Recommendations

Due to the harmful behavior of a wormhole attack, the cryptographical features of the ZigBee specification should avoid modifying data and routing packets during wireless transmission. Besides, encryption keys must be regularly changed to prevent brute force attacks and reduce the functionality of possible key extraction from a stolen node. Additionally, a better randomization method for the sequence number in every packet must be implemented by the ZigBee specification to make predicting this number difficult and prevent packet injection attacks, which causes packets with a wrong sequence number to be the discarded by legitimate nodes.

4 Conclusions and Future Work

This implementation of a wormhole attack in real devices was successful in using the algorithm proposed to manipulate packets with the KillerBee framework and Scapy decoders. Besides, a new variant of the wormhole attack was introduced and tested to show the flexibility and risk of malicious nodes in a network. Such variant takes advantage of the vulnerability of ZigBee devices for wormhole attacks and packet injection. On the other hand, the lack of effective security measures for WSNs must be explored from an empirical point of view to close the security gap of IoT with the available technology. This would also enable end users to implement security tools for real devices. As future work, an Intrusion Detection System (IDS) for wormhole attacks is going to be designed and implemented using signatures and patterns presented in this paper as result of the wormhole attack execution on real devices. Additionally, other experimental attacks, such as sinkhole and Sybil, will be explored to improve the detection system.