AntibIoTic: Protecting IoT Devices Against DDoS Attacks

The 2016 is remembered as the year that showed to the world how dangerous Distributed Denial of Service attacks can be. Gauge of the disruptiveness of DDoS attacks is the number of bots involved: the bigger the botnet, the more powerful the attack. This character, along with the increasing availability of connected and insecure IoT devices, makes DDoS and IoT the perfect pair for the malware industry. In this paper we present the main idea behind AntibIoTic, a palliative solution to prevent DDoS attacks perpetrated through IoT devices. 1 The AntibIoTic Against DDoS Attacks Today, it’s a matter of fact that IoT devices are extremely poorly secured and many different IoT malwares are exploiting this insecurity trend to spread globally in the IoT world and build large-scale botnets later used for extremely powerful cyber-attacks [1,2], especially Distributed Denial of Service (DDoS) [3]. Therefore, the main problem that has to be solved is the low security level of the IoT cosmos, and that is where AntibIoTic comes in. What drove us in the design of AntibIoTic is the belief that the intrinsic weakness of IoT devices might be seen as the solution of the problem instead of as the problem itself. In fact, the idea is to use the vulnerability of IoT units as a means to grant their security: like an antibiotic that enters in the bloodstream and travels through human body killing bacteria without damaging human cells, AntibIoTic is a worm that infects vulnerable devices and creates a white botnet of safe systems, removing them from the clutches of other potential dangerous malwares. Basically, it exploits the most efficient spreading capabilities of existing IoT malwares (such as Mirai) in order to compete with them in exploiting and infecting weak IoT hosts but, once control is gained, instead of taking advantage of them, it performs several operations aimed to notify the owner about the security threats of his device and potentially acting on his behalf to fix them. In our plans, AntibIoTic will raise the IoT environment to a safer level, making the life way harsher for DDoS capable IoT malwares that should eventually slowly disappear. Moreover, the whole solution has been designed including some functionalities aimed at creating a bridge between security experts, devices manufacturers and users, in order to increase the awareness about the IoT security ar X iv :1 70 8. 05 05 0v 1 [ cs .C R ] 2 8 Ju n 20 17 problem and potentially pushing all of them to do their duties for a more secure global Internet. Similar approaches have been occasionally tried so far [4,5,6] but, to the best of our knowledge, they have mostly been rudimentary and not documented pieces of code referable to crackers (or, as wrongly but commonly named, hackers) that want to solve the IoT security problem by taking the law into their own hands, thus poorness or even lack of preventive design and documentation are the common traits. Nevertheless, these attempts are the proof that the proposed solution is feasible and parts of their source code have been published under OpenGL license [7], which makes them reusable for the implementation of AntibIoTic. The paper continues presenting a high level overview of the AntibIoTic functionalities and infrastructure, respectively in Sections 2-3. Then, a comparison with existing similar approaches is given in Section 4, and legal and ethical implications are discussed in Section 5. 2 AntibIoTic Functionalities Looking from an high level perspective, the AntibIoTic functionalities include, but are not limited to: – Publish useful data and statistics Thanks to the infrastructure behind the AntibIoTic worm, IoT security best practises and botnet statistics computed from the data collected by the worm, can be published online and made available to anyone interested (not only experts); – Expose interactive interfaces Interactive interfaces with different privileges are also publicly exposed in order to let anyone join and improve the AntibIoTic solution; – Sanitize infected devices Once the control of a weak device is gained, the AntibIoTic worm cleans it up from other possibly running malicious malwares and secure its perimeter avoiding further intrusions; – Notify device owners After making sure the device has been sanitized, the AntibIoTic worm tries to notify the device owner pointing out the device vulnerabilities. The notification aim is to make the owner aware of the security threats of his device and give him some advices to solve them; – Secure vulnerable devices Once notified the device owner, if the security threats haven’t been fixed yet, the AntibIoTic worm starts to apply all the possible security best practises aimed to secure the device. For instance, it may change the admin credentials and update the firmware; – Resistance to reboot AntibIoTic incorporates a basic mechanism that let it keep track of all spotted vulnerable devices and, if a target device reboot occurs, it is able to reinfect them as soon as they are up and running. Moreover, in order to avoid the worm to be wiped off from device memory by a simple reboot, the AntibIoTic worm may also use an advanced mechanism to persistently settle into the target system by modifying its startup settings. Fig. 1. Device owner secures its device after receiving the AntibIoTic notification Please consider that the functionalities presented above are only an high level summary of the AntibIoTic set of functions, aimed to give the reader a first conception of the solution. A more clear explanation of the AntibIoTic modus operandi is given in Section 3. 2.1 Real World Scenarios Given the basic idea behind AntibIoTic, in this subsection we will get through some different working scenarios that the AntibIoTic worm could face during its propagation and in which a subset of the aforementioned functionalities are used. Each scenario will be presented using an high level graphical workflow and a brief textual explanation. Scenario 1 Awareness notification The first scenario is the one shown in Figure 1. It is the ideal situation in which as soon as the device owner sees the AntibIoTic notification, he performs some of the suggested operations in order to secure the device. Fig. 2. Credentials change after persistent installation First of all, AntibIoTic scans the Internet looking for IoT weak devices. As soon as a vulnerable device is found, it is infected and sanitized in order to secure its perimeter and ensure that no other malwares are in execution on the same device. Subsequently, the awareness notification is sent to the owner pointing out the security threats of the device and some possible countermeasures to solve them. Then, the scrupulous device owner looks at the notification and secures its device following the guidelines given by AntibIoTic. At this point, the IoT device is not vulnerable anymore thus the AntibIoTic intent has been reached and it can terminate its execution freeing the device. More elaborate (and, probably, real) cases, in which the owner doesn’t perform any action to increase the security level of its device, are presented in the following scenarios. Scenario 2 Credentials change on a rebooted device The second scenario is depicted in Figure 2. In this case, the device owner is impassive to the AntibIoTic notification and a device reboot occurs while AntibIoTic is performing its security tasks. However, thanks to the persistent installation and the credentials change functionalities, AntibIoTic is able to secure the device as well. As seen in the first scenario, at first AntibIoTic looks for a vulnerable device, infects and sanitizes it, and notifies its owner. Nevertheless, in this case, the device owner either ignore or doesn’t see the AntibIoTic notification, thus he performs no actions. Whereby, AntibIoTic starts to secure the device by checking if it’s possible to settle down on the hosting device in order to resist to potential Fig. 3. Firmware update after reinfection reboots. In this scenario, we are hypothesizing that the persistent installation is possible hence the AntibIoTic worm persistently settles down on the vulnerable device. Now, let’s suppose a device reboot occurs. However, since AntibIoTic has been persistently installed on the device, after the reboot it starts again and quietly picks its tasks up where it left off. It checks if a credentials change is possible. In this scenario, we are supposing that it is allowed, thus the AntibIoTic worm changes the admin credentials. Now, thanks to the security actions performed, the target device is not vulnerable anymore, hence the AntibIoTic worm terminates its execution and frees the device. Scenario 3 Firmware update of a reinfected device The third scenario is shown in Figure 3. It is a harsh environment for AntibIoTic, since persistent installation and credentials change are not possible and a device reboot occurs while it is performing its duties. Nevertheless, thanks to its reboot-resistant design, it is able to reinfect the device and secure it through a firmware update. The first part of the workflow moves along same lines as the aforementioned scenarios: AntibIoTic finds a vulnerable device, infects and sanitizes it, notifies the owner. Also in this case the owner doesn’t perform any action, so the AntibIoTic worm checks if the persistent installation is possible. In this case, we are hypothesizing that it is not allowed and that a device reboot occurs before AntibIoTic can perform any other operation. So, the hosting device is rebooted and our worm is wiped off from its memory. Nevertheless, the AntibIoTic infrastructure detects the reboot and monitors the target device to reveal whenever it is up and running again. As soon as again available, the vulnerable device is reinfected and resanitized by the AntibIoTic worm. Now, it continues to perform its actions checking if credentials change is possible. We are supposing that it is not, so AntibIoTic looks if a firmware update is feasible. Let’s suppose that it is and our worm downloads and installs an up-to-date firmware on the hosting device. Now, the target device is safe and the AntibIoTic worm can stop its execution freeing the device. 3 Overview of AntibIoTic Infrastructure The overall architecture of AntibIoTic (Figure 4) is mostly arisen from the Mirai infrastructure. This choice has been driven by the strong evidence of robustness and efficiency that Mirai gave to the world the last year as well as by the ascertainment that, despite its efficiency, the Mirai architecture is relatively simple and most of the source code needed for its implementation is already available online [8], which makes it easily reusable. Fig. 4. AntibIoTic infrastructure At a macroscopic level, the AntibIoTic infrastructure is made of several components and actors interacting with each other. 3.1 Command-and-Control (CNC) Server It is the central component of the infrastructure. It is in charge of performing several tasks interacting with other actors and components. It is composed of different modules: – Web Server It is the module that exposes the botnet human interface with human actors. It shows some useful data and live statistics and supports the interaction with two type of actors, each allowed to perform different operations: user, admin; – Reporter It is the module in charge of receiving and processing vulnerability results and relevant notifications sent by AntibIoTic Bots; – Spotter It is the module that handles the keep-alive messages continuously sent from AntibIoTic Bot Sentinel modules, ensuring a working connectivity with each infected devices. If for some reason (e.g., device reboot) the communication between the Spotter and the device is lost, the former immediately notifies the Loader to periodically try to gain the control of the insecure device again; – Loader It is the module that uses the received vulnerability results to remotely infect and gain control of insecure devices. It is also in charge of loading up-to-date modules on and sending commands to AntibIoTic Bots; – Data Manager It is the module which exposes the API to access all data saved on the Storage. Each module of the CNC Server interacts with Data Manager to perform any operation to local data. All data and files relevant for the whole infrastructure are saved in the Storage. It is accessible by all the modules of the CNC Server through the Data Manager.