Journal of Machine Intelligence and Data Science (JMIDS)

1. Introduction

According to an IoT tech news source, "Sales of IoT cellular devices will approach 350 million per year by 2025" [1]. This shows that the upcoming expectations of the IoT devices aim at convenience for people to use. However, there is a known fact in the world of Cyber Science that “Security and Convenience are related in indirect proportionality”. More convenience, less security. By taking advantage of this fact, we came up with a covert channel to abuse the functionalities of an IoT device by using MODBUS protocol since IoT is built using protocols that help communicate within centralized networks. A covert channel is a form of a communication medium that is kept hidden so that messages could be sent and received in secrecy. In order to do so, the original functionalities of an API are programmed in a way to send and receive messages thereby abusing it. For instance, if a person commands Amazon Echo to switch on a light bulb, it must complete only that particular functionality. However, this paper talks about how messages can be sent and received along with switching ON and OFF a light bulb in an IoT device.

Nowadays, IoT devices are operated over a wireless internet connection (WiFi) and these connections are established using a wireless protocol. For example, MQ Telemetry Transport (MQTT) helps in transmitting packets between IoT devices via remote locations [3]. Instead of MQTT, for our research we have used the MODBUS protocol to communicate with the IoT device. The purpose of using MODBUS protocol in an IoT device is that it is not easy to understand and even harder to implement. Supervisory Control and Data acquisition (SCADA) systems have adopted this protocol because of its easy operability but not yet implemented in IoT systems. Hence, such MODBUS requests could escape through packet analyzers in current times.

MODBUS has two types of communications which are query/response and broadcast [4]. The covert channel in this paper uses the first approach. In the query/response, the communication is between the Master (user client) and the Slave (server-IoT device). The Master initiates the communication by requesting for the current status of the light bulbs (read commands) and the Slave replies back with the status. The Master could also request to change the current status of the light bulbs from On to OFF or vice-versa (write commands) and the Slave follows the functionality and switches OFF or ON a light bulb accordingly. Another example would be that the user wants to turn the heater up; he would use the device application to initiate the request to the centralized modem which is (Master) to pass the request packets to the IoT heater (Slave). The full establishment will be via MODBUS functions.

2. Related Work

The Internet of Things (IoT) was aimed to improve society's life in a comfortable way. For instance, “turn the heater OFF “via Alexa is applied through human’s voices. Which makes life easier instead of physical movement. IoT devices authenticate each other via a round network. It started from the user's voice then centralized the area “router” and finally the meant device to apply. Wi-Fi is one of the popular protocols that is used in this authentication. In the past, Radio Frequency Identifier (RFID) was the protocol to let things “devices” authenticate each other via tracking the device’s tag [8]. When there is more than one device in an area, it comes under a mesh network [9].

The SCADA system plays important roles for processing controls that have network interfaces. The methodology of that system is based on a monitor (PC), programmable logic controller (PLC) or distributed control systems (DCS) and sensors [10]. In the past, IEC 870 Telecontrol equipment was the protocol that linked that methodology together. Since the SCADA system was based on an open systems interconnection model (OSI), this protocol was suitable for the authentication. By 1990, there was another innovative protocol Distributed Network Protocol Version 3.0, (DNP3) [10]. It helped to let master stations, remote telemetry units (RTUs) and other intelligent electronic devices (IEDs communicate with each other [10]. Compared to IEC 60870-5, this protocol obtained wide attention because of equipment manufacturers adoption [10]. Both protocols provide reliable communication of data and control which SCADA relies on [10].

Modbus TCP/IP Protocol is better suited than MODBUS RTU for IoT devices to manage request messages and transmit data in a wireless environment. It is also equipped to handle multiple masters (clients) and slaves (servers) with minimally complex tasks in the same environment requiring maximal complexity. However before it could become a standard medium for IoT protocols, this protocol needs several changes. A lack of adequate computing power to manage a hash-based algorithm to extract anonymity and integrity from its requests was the explanation for missing an authentication mechanism on the slave side.

A resource [7] explains that due to the lack of this authentication mechanism in MODBUS, it is prone to several attacks such as impersonation, IP spoofing, DDoS and many more. Its vulnerabilities cause a threat to the CIA, has inaccurate TCP session handling and complex data handling structure.

3. Introduction to MODBUS protocol

The MODBUS packet is encapsulated inside a TCP/IP frame which consists of the IP address of the slave (the IoT device) and its standard MODBUS port number 502 with which a TCP connection is established. MODBUS protocol uses a connection-oriented communication which consists of the two most important functional parameters: the executable function number and the register data, in order to execute instructions

The most prominently used functions for communication are read coils (0x01), Write Single Coil (0x05) and Write Multiple Coils (0x0F)[4].

Based on these function numbers, an IoT device performs the operations. These functions are given (address, count) values whenever a function is required to be performed. The address parameter contains the number addressed to a specific light bulb that one wants to access. This parameter ranges from 0 to 9, since we have used 10 light bulbs for this research paper. The address value can be increased from more than 9 if more devices are added to the circuit. The count parameter only uses 2 values - 0 for OFF and 1 for ON.

For example:

pi.read_coils(1,1).bits: This command reads the value of the bulb number 2 to see if it is switched ON.

pi.write_coil(2,1): This command will switch ON the light bulb number 3.

Our covert channel has been developed to only and only use the "read'' function for our commands list. The reason being that "read" functions are not visible to other users and are very rarely monitored. Another reason to use the “read” function for this covert channel is that it allows one to set the "count" value for more than 1. The slave uses this functionality to send out garbage values back to the master but the slave is still entitled to perform its functions. On the other hand, the "write" function does not accept any value beside "0" or "1". For any other value it sends out an error message; hence, to separate the legitimate overt channel from the covert channel, our working model depends on using "read" functions only.

3.1 Working Model

The covert channel is built using 2 Masters and 1 Slave. To simplify, there will be 2 clients (covert sender and covert receiver) and one server (IoT device). For the IoT device, this working model uses Raspberry Pi 3 (RPi3). Before running the RPi3, connect to the circuit according to Figure 5. The IoT application that processes incoming instructions from the master to the slave will be installed into the RPi3. This covert channel uses Python’s “pymodbus” module to create the covert channel[6].

Under normal circumstances, if Master 1 wishes to communicate with its Slave, it will generate a MODBUS packet containing the requested function and (address, count) value and send it as a query to the RPi3. Using the above example: pi.read_coils (1,1).bits, the function number will be 0x01, the (address, count) value is (1,1). Once the query is received by the Slave, it will start peeling off the packet, layer-by-layer, to finally reach the MODBUS TCP/IP packet. It checks for all the fields in the MODBUS packet and fulfils the query request with an appropriate response sent back to Master 1. Figure 6 shows the process clearly.

4. Our Covert Channel

Based on the above working model, we made a few changes in the working code that programmed the Slave's functionalities.

• Step 1: Enter the covert message: For this research paper, only block letters, 0-9 digits, space and period "." were fed into the system. The number of possible characters increases as the number of devices connected to the Slave increases.
• Step 2: Every character is mapped to a read function. This read function is fed with garbage (address, count) values. A combination of these values is the actual message here. The reason the "read" function was chosen is that RPi3 responded to garbage read requests but not garbage "write" requests. Hence, the entire mapping of characters is based on garbage "read" requests only.
• Step 3: A legitimate MODBUS TCP/IP packet with the embedded read function is sent to Slave the IP address of Master 1. After looking at the packet captures in Wireshark, they only seem to be legitimate read requests initiated from Master 1. Hence, nothing suspicious is noticeable.
• Step 4: After the MODBUS packet reaches the Slave, it analyses the packet structure and data. The Slave specifically computes the value of (address, count). Since the count is neither 0 nor 1, it sends back rubbish values to Master 1. Meanwhile, according to the modified code, the Slave strips off the values of (address, count) and sends those as a string to the IP address of Master 2 as shown in Figure 5.
• Step 5: Master 2 is already running the listener for the values sent by the Slave. The values reach Master 2 and are further computed. A similar version of the mapping is programmed at Master 2 which maps the received string into a character. And thus, the covert message is received.

4.1 Elements Of A Covert Channel

• Medium: the "read" function acts as a medium to generate the covert message.
• Modulation: the (address, count) values act as modulated values which represents each character
• Encoding: at the receiver's side, the covert message is encoded (mapped) into a series of "read" functions with the modulated values whereas on the receiver's side, the modulated values are encoded back into the corresponding characters.

5. Implementation

• Master 1: When the program is run, it asks for a covert message. The covert message is fed in by the covert sender as shown in figure 8.

Once the message is entered, Master 1 uses an interval of time to map the characters to read commands until the entire message is sent.

• Slave: At the server side, the Slave receives the read requests and generates packets accordingly. It also strips out the (address, count) value and sends it to Master 2. The image shows that a "read" function is requested having the function code 0x01. The (address, count) are stripped and shown separately and then concatenated into a string. When the message is complete, the connection is closed.
• Master 2: The Master 2 side that is currently in listener mode accepts the strings being sent from the slave and maps them back into characters and prints the output of every character as shown in figure 10.

5.1 Why This Covert Channel?

This covert channel was successfully built by exploiting several MODBUS vulnerabilities.

• Lack of authentication: It is very easy to operate the MODBUS protocol, if one knows the IP address and the port number of the slave on which the MODBUS protocol runs. As a result, any user can use the MODBUS protocol to send commands to the slave without any type of authentication. Due to this reason, the protocol itself becomes promiscuous to threats like impersonation.
• Improper error handling: The MODBUS protocol does not make proper provisions to send error messages to the master that sent incorrect requests to the slave. Even though the slave sends back an error message, it can be easily modified to send it to another master in the form of a message. If MODBUS had proper error handling methods, it should be able to verify the master before taking error handling actions.
• Allows invalid “count” values: The MODBUS protocol is designed to allow either “0” or “1” in its “count” field to locate the status of the device. However, the protocol also accepted values greater than 1 specifically for the “read” function. The protocol sends back garbage replies to invalid “count” values but not the exception messages. Using this vulnerability, the covert message could be created at the master’s end.

Analysis

6.1 Packets Per Second

• The above message consisted of 21 characters. In order to send and receive 21 characters, it took a total of 6-7 seconds. As shown in figure 11, the numbers of packets sent per second were 3-5 packets.
• The above image shows the number of packets transmitted (TX) and received (RX). However, the maximum packets sent vary from 2 to 9 and the number of received packets varies from 12 to 64. Since every request requires a TCP 3 way handshake to be established, the number of transmitted and received packets increases.

6.2 Bandwidth

Even with such a noisy channel/interface, the bandwidth required is very low. The analysis shows that a maximum of 3 kb/s of bandwidth are used to send the packets. It can be seen in figure 12.

6.3 Detectability

The "read" requests are flooded into the network during character mapping; hence network packet analyzers like Wireshark are unable to capture all the read requests. Every MODBUS packet that is captured is very similar to the legitimate "read" request packet. Hence, it is difficult to decipher between legitimate and garbage "read" requests. However, if one analyzes the packets received by the Slave from the Slave side, one can easily differentiate garbage read requests from the legitimate ones since the "count" value in (address, count) would be more than 1. However, in order to analyze the packets, the packet analyzer must be physically connected to the Slave which is never the usual case.

Under normal circumstances, there are no packet captures physically connected to the Slave side. As a result, it is estimated that this covert channel escapes detectability by over 90% of the time.

6.4 Robustness

This covert channel uses the "read" functions to circulate covert data among the masters and slaves. Since, from the analysis, it was seen that that slave provides a higher priority for the "read" functions over other functions, the robustness level is maintained from medium to high. Even after the detection of the covert channel, it is not likely to remove the malware infested configurations from the IoT device. Along the similar lines, the network packet analyzers process the read requests from the covert channel as legitimate requests, hence network filters also make little to no restrictions for the "read" requests.

6.5 Prevention

The only way to prevent this covert channel is to buy a new device. Once the malware is installed into the slave, only through factory reset configurations the slave can be brought back to its original functionalities. Since its detectability rate is less than 10%, it is very much likely to be ignored and hence prevention is averted.

7. Limitations

• The only characters used for this system model to generate a covert message are block letters from A to Z, digits from 0 to 9, space and period ".". For more characters and special symbols, more light bulbs must be added. Hence, more devices are connected to the IoT device; better crafted covert messages will be generated.
• In any situation, if a legitimate user accidentally uses the count value as more than 1, it will get back rubbish values as its answer; however the covert message might be altered. This can be called a plausible human error which cannot be escaped at any point. In such cases, covert receivers might have to ask the sender to send the message again.
• The MODBUS protocol used in this research is the TCP/IP frame which does not include a CRC (message error check functionality) unlike the MODBUS RTU model. Hence, there are no functions to check if the received covert message is correct.

8. Conclusion and Future Scope

MODBUS's mission is to establish a communication between devices working in the same network to secretly send information from one user to another. For our covert channel, we established communication between devices by abusing the basic "read" functionality of the system model. The reason this covert channel was implementable is because the functionality did not include any restrictions on the use of values outside their operating domain. The IoT device was not designed on how to respond to garbage requests. There are several IoT devices that are manufactured with such loopholes for the sole purpose of making them light on computing. Since IoT devices are not equipped with high computing capabilities, their programming is predominantly focused on "what to do'' when a correct command is entered, rather including operations on a side note about "what to do'' when garbage requests are received.

Since this covert channel was built on 10 LED bulbs on a breadboard which were being operated using Raspberry Pi 3, they are also implementable in worldly acceptable IoT devices such as a thermostat, IoT Christmas lights or even Amazon Echo. Once their functioning APIs are gained, their functionalities can be changed and inserted back into the devices very easily. This idea could also be extended to using the MODBUS RTU model for its functioning instead of the MODBUS TCP/IP model since RTU includes a CRC check in its packet. This would give more robustness to the covert message. One may also use different function numbers such as 0x02, 0x03, 0x04, 0x06, 0x07 and 0x08 other than the ones used in this research paper.

Creating a covert channel using the MODBUS protocol gives endless possibilities of escaping detection for a huge amount of time. From our analysis, we can state that MODBUS protocol shows a promising path towards covert communication.

Acknowledgement

We would like to thank our guide Prof. Daryl Johnson for teaching us about Covert Channels and helping us in our articulating idea for a covert channel and providing us with the required hardware and Raspberry Pi3 to build our covert channel. We would also like to thank our Dean and Department Head for their financial support behind our conference publication.

References