Abstract
Internet of Things networks represent an emerging phenomenon bringing connectivity to common sensors. Due to the limited capabilities and to the sensitive nature of the devices, security assumes a crucial and primary role. In this paper, we report an innovative and extremely dangerous threat targeting IoT networks. The attack is based on Remote AT Commands exploitation, providing a malicious user with the possibility of reconfiguring or disconnecting IoT sensors from the network. We present the proposed attack and evaluate its efficiency by executing tests on a real IoT network. Results demonstrate how the threat can be successfully executed and how it is able to focus on the targeted nodes, without affecting other nodes of the network.
1. Introduction
The Internet is today adopted for a wide range of different purposes and by several kinds of entities, ranging from banking and stock market sectors adoption to personal use for social networking and web surfing. The Internet is indeed populated by billions of devices of different nature. In the last years, we have seen the appearance of several categories of always connected devices: smartphones, tablets, smartwatches, and healthcare devices are today only a few kinds of components of the global network. We are today experiencing a new emerging trend related to the evolution of common “analog” sensors, making them connect to each other, creating a “parallel” network based on machine-to-machine communications.
In this context, the term Internet of Things (IoT) represents a general concept relative to the ability of common sensors to collect data from the real world and hence share the retrieved information across a network, by communicating with other connected devices. IoT networks are today deployed for different purposes. The most known and adopted ones are the home automation/domotics and the industrial (Industry 4.0) contexts: while in a domotic context IoT networks are used to provide connectivity to common and security devices (light bulbs, internal cameras, fire sensors, etc.), in an Industry 4.0 scenario, IoT is used to monitor, control, inform, and automate production processes. In order to communicate on the network, IoT devices support different communication protocols, such as Industrial Ethernet [1], Wi-Fi [2], ZigBee [3], and Z-Wave [4].
Our research, presented in this paper, investigates security aspects of IoT networks. We focus on ZigBee, a communication protocol ensuring low power consumption and characterized by low data transmission rates. During our study, we found important security issues related to a ZigBee based system and, potentially, to other IoT protocols. We identified the possibility of sending Remote AT Commands, where AT means “attention,” to a connected sensor, in order to reconfigure the device, for instance, by making it join a different malicious network and hence forward captured data to the enemy. We evaluate the possibility of perpetrating a successful attack by setting up a network laboratory composed of XBee devices (XBee is one of the most adopted ZigBee radio modules in the Do-It-Yourself (DIY) scenario [5]). We describe the exposure to Remote AT Commands threats by focusing on evaluating efficiency and performance characteristics of this innovative attack.
The focus of our work is on the proposal of an innovative cyberattack. This may result in an unconventional and not needed activity. Nevertheless, especially in the research field, it is well known that offence research is as needed as defense research, in order to properly master a field and better prepare to counter cyber-criminal activities [6, 7].
The remaining of the paper focuses on the presentation of the innovative discovered threat and it is structured as follows. Section 2 reports the structure of the ZigBee protocol. Section 3 reports related work on the topic, while Section 4 reports our contribution on Remote AT Command exploitation. Then, Section 5 exposes the adopted testbed and obtained results by executing the attack on a controlled environment. Finally, Section 7 concludes the paper and reports possible extensions of the work.
2. The ZigBee Protocol
ZigBee is a wireless standard introduced by the ZigBee Alliance in 2004. It is based on the IEEE 802.15.4 standard, used in the Wireless Personal Area Networks (WPAN) context [8]. ZigBee is designed for embedded systems, often characterized by extremely low power consumption and low-rate transfers requirements [9]. The protocol is indeed able to minimize battery replacement frequency (up to years) and to provide a communication rate up to kbps, for a coverage radius up to meters. Figure 1 depicts the ZigBee stack protocol.
The physical layer of the IEEE 802.15.4 standard manages modulation and demodulation operations. Particularly, ZigBee supports three different frequencies:(i) GHz with support to different channels, providing a maximum communication rate of kbps (used worldwide)(ii)MHz with support to channel and a maximum data rate of kbps (used in Europe)(iii)MHz with support to channels and kbps of communication rate (used in US)
Since they work on the same frequency, in case of 2.4 GHz adoption, there may be interferences with existent Wi-Fi networks [10].
The MAC layer, also implemented in IEEE 802.15.4, takes care of ensuring a reliable and secure communication, by implementing a Carrier Sense Multiple Access with Collision Avoidance (CSMA/CA) to control access to the physical level [11].
The network layer of the ZigBee protocol implements instead network topologies, new devices management, and security handling. Particularly, ZigBee supports three different network topologies:(i)A star topology, where each node communicates with a central node(ii)A tree topology, where central nodes of different networks are connected with a bus network(iii)A mesh topology, where all the nodes are connected to each other
Mesh networks are the most interesting ones: in this case, ZigBee implements ad hoc routing algorithms to automatically rearrange communications if a node of the network is disconnected [12].
The Application Framework layer represents the user interface and it is composed of three main components:(i)Application Support Sublayer (APS), providing an interface between network and application layers; moreover, it controls and manages data sent and received by other protocol layers to ensure proper packet transmission and encryption(ii)ZigBee Device Objects (ZDO), an application object responsible for the initialization procedures of the APS and the ZigBee network layer to perform discovery of services and new nodes in the network(iii)Application Framework (AF), an execution environment for “application objects,” each ones identified by an endpoint address from 1 to 254 (0 is reserved for ZigBee Device Object (ZDO), 255 for broadcast messages): application objects are usually implemented by different manufacturers. In order to enhance products interoperability, the ZigBee Alliance has published different application profiles. The most common ones are home automation, smart energy, light link, and green power [8]
2.1. ZigBee Node Types
ZigBee supports different kind of devices with different functionalities:(i)ZigBee end-device (ZED): it represents the sensor, usually in sleep mode most of the time and periodically waking up in order to communicate with the other nodes of the network.(ii)ZigBee router (ZR): it is an optional node used to route packets on the network.(iii)ZigBee coordinator (ZC): it is a ZigBee router with gateway functions used to manage the network.
While on the same network it is common to have several different ZED nodes and different routers, a single coordinator is found.
2.2. ZigBee Security
As many other wireless networks, like Wi-Fi [13] or ad hoc wireless sensor network [14, 15], security assumes a crucial role in the ZigBee protocol. The encryption algorithm used in ZigBee is Advanced Encryption Standard (AES) with a -bit key. Such algorithm, considered extremely secure and reliable, guarantees confidentiality and authenticity on wireless communications [16].
ZigBee provides two different security profiles [17]: Standard Security, the basic security profile, rarely adopted because of its exposure to attacks, and High Security, mostly used since it guarantees greater security during communications. Particularly, while considering the standard security profile, the network key is shared in clear text (unencrypted), it is encrypted with the link key in case of high security profile adoption. The link key is one of the security keys adopted by ZigBee:(i)Master key is usually hardcoded on the device or shared out-of-band. It is needed in order to retrieve the other keys but it is never directly sent on the network.(ii)Network key is a key shared by all the devices connected to the same network. It is generated by the Trust Center and it can be sent on the network as plain text or in encrypted form, depending on the adopted security profile.(iii)Link key is a key generated using the master key and adopted for communications between two different devices on the same network.
In a ZigBee network, if communication is unencrypted, an attacker may access all information of the network and may even sniff/capture exchanged packets. Otherwise, if communication is encrypted, a malicious user may only perform attacks that do not require access to the network, such as denial of service or jamming, since it is very difficult to retrieve the ZigBee adopted network key and hence decrypt exchanged packets.
3. Related Work
Because of the wide adoption of the ZigBee protocol, one of the most important concerns is related to ZigBee based networks protection. Many security experts have studied the protocol and identified several threats able to target such systems. In this context, an important contribution is provided by Wright, the creator of Killerbee, a framework including a set of tools able to exploit the ZigBee protocol analyzing network traffic and processing the recovered packets [18]. Although such software is extremely dangerous, its specific hardware requirements (such as Atmel AVR USB Stick or TelosB mote models) limit the execution of properly equipped attackers. Thanks to Killerbee, it is possible to execute several attacks against a ZigBee network: for instance, it is possible to retrieve the network key when sent as clear text. Such retrieval requires the attacker to be located in proximity of the network nodes, in order to sniff the key exchange. Killerbee also includes other threats such as replay [19] or manipulation/injection [20].
Other attacks focus on denial of service (DoS) activities, executed in order to disconnect a node from the network. DoS attacks are popular on the Internet [7] and they are extending to last generation fields such as mobile [21], SDN [22], and IoT [23]. Considering such kind of threats perpetrated against a ZigBee system, several attacks target battery powered sensors in order to reduce the lifetime of the device. In this context, the ZigBee end-device sabotage attack [24] is executed by keeping sensors active when a broadcast message is sent every time the device wakes up from the sleep status. In this way, a sensor under attack is forced to reply the malicious user, hence delaying the next sleep and discharging the batteries quickly. A similar threat, the ghost attack proposed by Shila, reduces the lifetime of the targeted device by sending several crafted bogus messages to the victim [25]. Vidgren et al. demonstrate instead how it is possible to discharge the batteries of a sensor if the attacker knows the adopted sensor polling rate [26]. Pacheco et al. investigate instead DDoS attacks feasibility against IoT environments [27]. Another DoS attack proposed by Vidgren et al. exploits the ZigBee frame counter. Such counter is commonly used by different network protocols to prevent threats such as replay attacks. Concerning ZigBee frame counter exploitation, a malicious user could send a parameter containing the maximum allowed frame counter value (sized bytes), hence forcing the victim to set the counter to the received value. If Message Integrity Check [28] is not implemented by the victim, each packet received after the malicious one will be discarded by the victim since it will present a lower frame counter [26].
Another attack, known as same-nonce attack [29], can be carried out only if the Trust Center, a device providing reliability during the key exchange stage, provides the same-nonce encrypt with the same network key for two consecutive times. In a ZigBee network, coordinators have role of Trust Center. In this scenario, an attacker may retrieve part of the plain text simply calculating the XOR between the two sniffed packets. Although this situation rarely happens, it is possible to force this behavior by causing a power failure, for example, by discharging batteries of a Trust Center. In this case, Trust Center resets the nonce to its default value and it is possible to send a packet with the same nonce [26].
Considering other threats, ZigBee networks are also vulnerable to attacks known as Sinkhole and Wormhole, proposed by Karnain and Zakaria [30]. During a Sinkhole attack, a malicious node attracts the network packets with the aim of creating confusion in the routing phase. Instead, during a Wormhole attack, the malicious user receives packets at one point in the network and then replays these packets in other areas to interfere with all network functionality. Also, while Krivtsova et al. propose the broadcast storm attack clogging the network by sending numerous broadcast packets [31], Yang et al. introduced two attacks against ZigBee, known as Absolute Slot Number (ASN) and time synchronization tree attack. Considering that the time is split into different slots/ASNs of fixed length, during an ASN attack, since current ASN value is sent during communication, the legitimate nodes may get an incorrect ASN value from the attacker that sends on the network a broadcast message with a wrong ASN value. In this way, a node would not be able to communicate on the network since the wrong ASN packet would lead to a communication interruption. In time synchronization tree attack, the malicious user may send bogus DAG Information Objects (DIO) packets [32] to the neighbors with the aim of desynchronizing their connections with the network [32]. A Sybil attack, proposed by Lee et al., is launched by an attacker that acquires multiple identities on the network. The aim of this attack is to convince the other devices that the malicious node is a legitimate node. In this way, a malicious node may, for example, access all services of the network or identify itself as a ZigBee router [33]. Another type of attack is performed if the enemy can physically access a ZigBee device. Indeed, the malicious user may perform a firmware dump in order to extrapolate the network key stored/hardcoded in the device [34].
Other attacks focus instead on specific version of ZigBee. In this context, a particular version of the ZigBee protocol, called ZigBee Light Link, used, for instance, by Philips Hue bulbs [35], has been exploited different times. Indeed, Gent found that the adopted ZigBee network key can be retrieved if an attacker can sniff the reinitialization process accomplished by the bulbs after a reset and if he knows the ZigBee Light Link master key [36]. Another attack on ZigBee Light Link is proposed by Ronen et al., creating a worm that automatically infects adjacent bulbs, building a custom infected firmware, and being deployed as a fake OTA update [37].
Many works focus instead on ZigBee protection. For instance, a solution to detect the Sybil attack is proposed by Marian and Mircea, presenting an interesting protection system using RSSI derived metrics to detect a Sybil attack by computing the location of a node and then classifying it as malicious or not [38]. Al Baalbaki et al. introduced instead an Anomaly Behavior Analysis System (ABAS) for the ZigBee protocol based on network traffic analysis. After detection is triggered, ABAS can classify the attack as known or unknown using information like packets origin or destination [39]. Another protection algorithm proposed by Jokar and Leung and known as HANIDPS implements machine learning based intrusion detection and prevention system. HANIDPS analyzes the network traffic and compares it with a normal in order to detect a running threat [40]. A similar approach may analyze energy consumption [41] to identify running attacks. Cui et al. proposed instead a fuzzing method based on finite state machines. A fuzzy test is implemented by injecting different testing cases into the system in order to detect vulnerabilities [42]. A defense against impulsive noise is proposed by Jia and Meng, implementing a system using a noise filtering processing activity in two steps: while during the first step an estimate of the noise is computed, in the second one, a noise cancellation is accomplished, in order to state if the estimate is suspect or not [43].
During our research work, we have studied security aspects of ZigBee based IoT networks by initially studying the protocol, thus analyzing the major threats affecting it, hence studying possible protection systems and approaches. During our study, we have discovered the proposed threat and, to the best of our knowledge, we noticed that a vulnerability analysis focused on AT Command exploitation is still missing. Nevertheless, this vulnerability should be considered extremely innovative and particularly dangerous, since it allows malicious users to retrieve/forward sensitive information or manipulate nodes functionality. Our work focuses on the proposal of the innovative Remote AT Command attack, explained in the next section, by illustrating the proposed threat and evaluating its efficiency.
4. Remote Control Exploitability
In order to properly investigate ZigBee security, we have studied the protocol and analyzed communication flows, considering the different types of packets supported by ZigBee. While, at first, we focused on packets containing data sent from the coordinator to the end-device, later, we have also analyzed other packets exchanged in the network. In this context, we found that, at the MAC layer, it is possible to send Remote AT Commands. By working at such lower layer, received packets are not processed at the application layer; hence, it may not be possible to access the packet content to avoid interpretation, except from the device manufacturer.
During our research work, we identified a particular vulnerability affecting AT Commands capabilities implemented in IoT sensor networks. Our work focuses on the exploitation of such weakness. AT Commands are specific packets, historically adopted by old generation modems to interface with the device, today used by radio modules such as XBee [44], ESP8266 (more information is available at http://esatjournals.net/ijret/2017v06/i01/IJRET20170601027.pdf), or ETRX3 [45] to configure parameters like connection type, network identifier, device name on the network, or destination address for a communication. AT Commands are today supported by many devices of different nature, providing different functionalities and hence commands. For instance, modules that provide connectivity support AT Command packets for network parameters configuration, while other modules may use these packets to alter light intensity of light bulbs.
For our research, as previously mentioned, we focused on XBee modules. Such modules, widely adopted around the world, especially in DIY contexts, implement two different AT Command packets, related to request and response operations, respectively. Concerning XBee modules, these packets can be sent remotely: we talk in this case of Remote AT Commands. Such packets belong to the (IEEE 802.15.4) MAC layer and they are interpreted by the (XBee) module automatically. Therefore, by being such interpretation demanded to the device firmware, and being such firmware provided by the manufacturer, Digi International, it is not possible to avoid implicit Remote AT Commands interpretation. In order to execute the proposed attack, the AT Command functionality of XBee has to be exploited. XBee supports several AT Command packets (more information is available at https://www.sparkfun.com/datasheets/Wireless/Zigbee/XBee-Datasheet.pdf). Particularly, for our aim, we have used ATID commands to target sensors (in general, other commands/approaches may be used for different purposes: e.g., to make the sensor join a different network, to forward (sensitive) data to a different malicious receiver, and to disable data encryption). ATID is used by XBee modules to set the network identifier. During the proposed Remote AT Command attack, the malicious user sends an ATID packet with a bogus identifier in order to make it join a different (inexistent, in our case) network.
In order to maliciously exploit Remote AT Command, it is assumed that the attacker is connected to the network of the target. In this case, the enemy may, for instance, disconnect an end-device from the ZigBee network and make it join a different (malicious) network and hence forward potentially sensitive data to third malicious parties. Given the nature of IoT end-devices, often associated with a critical data and operations, it may be obvious how a Remote AT Command attack represents a serious threat for the entire infrastructure.
5. Testbed
In this section, we report information about the tests we have conducted in order to validate the success and the efficiency of a Remote AT Command attack. In order to accomplish the tests, we have built a ZigBee test network, depicted in Figure 2.
The network is composed of a single ZigBee coordinator, two end-devices representing common sensors on the network, and a malicious user/node connected to the ZigBee network. As can be deduced from the figure, the attacker sends Remote AT Command packets only to one sensor and not to each device on the network. This implementation allows us to monitor the effects of the attack on the two sensors, hence evaluating the possibility of carrying out a successful attack without affecting targeted nodes. Indeed, we expect that, during a Remote AT Command attack, only the targeted sensor is affected by the threat, while other nodes keep working correctly (unless their behavior depends on the targeted sensor).
Considering the described scenario, we will now detail at first adopted hardware, hence reporting information about testbed configuration, finally exposing the obtained results.
5.1. Testbed Configuration
Different devices have been used to create ZigBee network to implement AT Command attack. For our aim, network components are composed as reported in the following:(i)Coordinator, composed of a Raspberry Pi 3 equipped with an XBee USB Board and an XBee Series 2(ii)Targeted sensor, composed of an Arduino UNO R3, equipped with an XBee Shield and an XBee Series 2(iii)Not targeted sensor, composed of an Arduino UNO R3, equipped with an XBee Shield and an XBee Series 2(iv)Attacker, composed of a Raspberry Pi 3 equipped with an XBee USB Board and an XBee Series 2
As the reader may notice, end-devices/sensors share the same hardware. Hence, our evaluation allows us to identify the efficiency of the attack on the targeted node, and simultaneously the possibility of avoiding side effects on other nodes (this is not possible, e.g., for jamming attacks).
Moreover, since XBee series 2 modules have low computational capacity, we adopted Arduino microcontrollers to generate and elaborate information, hence using XBee modules only for network communications. In order to guarantee the sleep status of end-devices, a PIN Hibernation has been implemented [46] by connecting the th PIN of the XBee Shield to an Arduino digital PIN. In order to implement PIN Hibernation, value, a PIN used to send and receive serial data, has been disabled (through XCTU XBee programming software). In order to test this vulnerability, the innovative attack is implemented and tested with this configuration: the attack was performed on only one sensor because by monitoring the network traffic is possible to verify the efficiency of this threat.
5.2. Network Nodes Implementation
Every 35 seconds, sensors are programmed to send a packet to the coordinator. Each packet contains a random generated number. After the message has been sent, the sensor device enters in sleep mode in order to reduce power consumption. Since the content of the message is not meaningful to us, the “random number” solution allows us to generate data to be transmitted on the network without requiring environmental sensors.
Figures 3 and 4 monitor the network traffic of the various XBee modules. Although we stated that a single packet is sent every 35 seconds, sending is relative to application layer packets, while the capture is relative to the entire ZigBee network stack. Although such capture includes additional (lower layers) packets (including, for instance, wake-up commands containing network node information and synchronization packets), it is representative of the network behavior of the sensor (e.g., we can see that, after the attack, no packets are sent by the victim node), while a capture focused on application layer packets/messages would produce single peaks missing useful information.
(a) Traffic generated by targeted sensor
(b) Traffic generated by not targeted sensor
Data is received by the coordinator and shown to the user through an HTML based graphical interface, also reporting if sensors are correctly communicating with the coordinator. This environment is representative of a wide range of network types. For instance, sensors installed on a specific area/farm/company could be monitored through a similar approach, or industry machines and fire prevention systems may be part of a network system similar to the proposed one.
6. Results
Network traffic was analyzed from an external ZigBee device capturing data on the same channel used by the targeted network. From sniffed traffic, we are able to extrapolate communication flows of single hosts of the network.
Figures 3(a) and 3(b) report the network traffic flow of both targeted and not targeted sensors during a running attack. Traffic was monitored for seconds and it is split into two phases: during the first seconds, the attacker acts in a “passive” way, by scanning the ZigBee spectrum in order to identify the devices connected to the network and define the target. Instead, on the second “active” phase, the attacker sends Remote AT Command packets to the targeted sensor in order to perform the attack. Particularly, for our aim, the passive behavior is not intended as a “listen only” behavior. Instead, during this phase, the attacker does not send any malicious packet on the network. Therefore, we expect that detecting a malicious behavior during the passive phase is particularly difficult.
Figure 3(a) reports the traffic flow of the targeted sensor. By analyzing the graph, it is possible to notice that while the sensor is correctly working during the passive phase, a few seconds after the attack is (actively) performed, the device is disconnected from the network and its communication with the coordinator is interrupted. Therefore, the attack is successful on the targeted sensor.
Instead, Figure 3(b) reports the status of the nontargeted sensor during the attack. Particularly, it is possible to notice that the connection is maintained alive for the entire considered period. Indeed, since this sensor is not directly targeted by the attacker, Remote AT Commands are not received/interpreted; hence, the network parameters of the sensor are not altered by the attacker and communication capability of the sensor is maintained and not even disturbed. This represents an important characteristic of the proposed threat, since it is able to only affect the targeted device, by making the attack not directly visible to the other sensors/devices. Such stealth behavior makes the attack more difficult to detect. Moreover, considering that device communication interruption may be related to external factors (e.g., battery drain, wireless noise, and malfunctioning device), the proposed attack should be considered a serious threat.
Figure 4 shows instead the captured attack traffic during the considered period.
By analyzing the passive phase of the attack, as previously mentioned, the enemy performs a scan of the network in order to identify each device connected to the network and choose the targeted device. Instead in the active attack phase, Remote AT Command packets are sent to the targeted sensor with the aim of disconnecting it from the network (by reconfiguring it). If we analyze the attack traffic flow, it is very difficult to distinguish a passive (hence, potentially legitimate) behavior from an active (malicious) one. Hence, detection of a running threat may require packet inspection or data flows interpretation (not easy to accomplish in case of encrypted traffic).
Although our testbed focuses on two network sensors/devices, the proposed Remote AT Commands attack is particularly scalable, due to the (minimum) requirements for the attacker (a single packet is sent to the victim to reconfigure it). Particularly, the time required to send such packet is minimal, so in case of multiple targeted sensors, the attack success is guaranteed. Of course, in case of extremely large amounts of targeted sensors, the effectiveness of the attack depends on the scan time: the attack is successful if the minimum “sleep time” of each sensor is larger than the average time required to target all the sensors.
7. Conclusion and Future Work
The proposed paper is focused on Internet of Things (IoT) environments security, by analyzing the possibility of carrying out a successful attack against a targeted node/sensor/device. During our work, we found a novel vulnerability affecting IoT devices: by exploiting a particular type of packet, Remote AT Command, it is possible to remotely reconfigure/program network nodes as the attacker wishes, hence compromising data communication security of the network.
By focusing on the ZigBee (wireless) protocol, we have described and implemented the proposed attack with the aim of interrupting the communication capabilities of a targeted device of the network. For our tests, we targeted XBee modules [44], able to communicate through the ZigBee protocol. Results show that the attack is successful and it is able to target a single node without affecting the other nodes of the network. Moreover, since the number of packets sent by the attacker is minimum, it is not easy to detect a running attack, without doing deep packet inspection. The attack is therefore particularly dangerous, since it may compromise the security of an IoT network with minimum effort for the attacker. By comparing the effects of the proposed attack to other network based threats, they can be assimilated to denial of service, man-in-the-middle (traffic sniffing), or traffic redirection activities, in function of the strategy adopted by the attacker.
Future work on the topic may concern additional tests of the attack in large scale networks composed of different nodes, in order to identify the limits of the threat, in function of the sleeping/polling times adopted by the nodes. Considering instead the design of defense systems, additional extensions of the work may be directed to the implementation of efficient protection techniques able to defend an IoT system from a Remote AT Command attack. Since detection of a running threat may not be immediate, in order to protect a remote device from a Remote AT Command attack, it may be preferred to directly work on the (potentially vulnerable) nodes. In this context, three different approaches can be adopted, working at different levels:(i)Firmware level: creation of a modified version of the firmware, implementing Remote AT Commands filtering or allowing AT Commands elaboration at the application layer(ii)Device configuration level: providing to the user the ability to configure a device with disabled support to Remote AT Commands(iii)External level: demanding protection capabilities to an external application program.
Each approach provides an efficient solution to protect the device. Nevertheless, some approaches may not be adopted (e.g., device configuration, if not available). Suggested implementations provide a possible protection for this innovative threat.
The first proposed solution (firmware level protection) requires a device firmware upgrade to allow total AT Command packet management, such as the ability to process only packets received by the coordinator or secure devices. Such solution would provide the user with the possibility of configuring the device in order to avoid implicit Remote AT Commands interpretation.
Since modifying a firmware may not be easy, and the source code must be open source, it is suggested to have simpler but equally effective solutions. The second solution (device configuration level protection) implements the ability to disable Remote AT Command support of the module, by implementing a specific setting able to disable automatic Remote AT Command interpretation (e.g., packets discard). In this way, the proposed threat would be ineffective.
The last proposed solution (external level protection) is the most interesting; the main purpose is to implement protection logics on the Arduino device by implementing a function at application layer. The aim of the function is to verify if the XBee module may be communicating on the network. In this case, just before the sensor is ready to communicate on the network, an internal check is accomplished.
Although the mentioned approaches may protect IoT modules and network sensors from this innovative attack, by ensuring data transmission security, their design implementation and evaluation are on the scope of further work on the topic.
Conflicts of Interest
The authors declare that there are no conflicts of interest regarding the publication of this paper.
Acknowledgments
This work has been supported by the following research projects: (i) My Health-My Data (MHMD) project has received funding from the European Union’s Horizon 2020 Research and Innovation Programme under Grant agreement no. 732907; (ii) Advanced Networked Agents for Security and Trust Assessment in CPS/IoT Architectures (ANASTACIA) project has received funding from the European Union’s Horizon 2020 Research and Innovation Programme under Grant agreement no. 731558.