Fast & Furious IoT Botnets: Regifting Exploits
Internet of Things (IoT) botnet authors are adapting to a shift in more secure IoT devices, which has diverted attacker’s focus to exploiting vulnerabilities in IoT devices, either to supplement brute-forcing factory default passwords or completely supplant it. As IoT device security is still in its infancy, it’s not uncommon to find basic vulnerabilities like command injection. In November 2018, our honeypot observed several older IoT vulnerabilities being used as a means to deliver malware. Our data indicates it takes less than one day before a new IoT device is hit with exploitation attempts against known vulnerabilities, and less then 5 minutes before we see brute force login attempts using default IoT credentials (Dipping Into The Honeypot.)
NOTE: Customers using NETSCOUT APS/AED products receive early warnings about DDoS attack targeting seen in our honeypots through the ATLAS Intelligence Feed (AIF) service.
- IoT botnet authors are increasingly adding exploitation of IoT related vulnerabilities to their arsenal in addition to the usual brute-forcing routing. In some cases attackers will complement the brute-forcing with attempts to exploit known vulnerabilities.
- IoT related vulnerabilities are valid attack vectors for longer periods of time due to the difficulties and slow cadence of patching IoT devices.
- Our data collection revealed it takes less than five minutes from when IoT device comes online to when the first brute-forcing attempts begin. Within twenty-four hours, those same devices begin receiving exploitation attempts against known vulnerabilities.
The use of IoT based vulnerabilities has helped botnet authors increase the number of devices within their botnets with little effort. A great example of this are the numerous Mirai variants which included IoT specific vulnerabilities. Based on data from our honeypot, we can see a quick turnaround time from when a vulnerability is made public to when botnet authors integrate them into their botnet.
We see a mixture of new and older IoT related vulnerabilities against out honeypots in a constant stream. There are two main reasons why we still see older IoT vulnerability exploitation attempts. First, IoT devices can sit on a shelf for weeks on end before being purchased. If a security update is released for the device, it won’t be applied to these devices until the software is updated. Thus, leaving the device vulnerable out of the box. Due to this, when an IoT device is plugged in, it can be exploited quickly. Our honeypot data shows it only takes a few minutes after the device is connected to the Internet before someone is scanning it and attempting brute-force logins. The second reason is the agonizingly slow rate at which IoT devices receive patches. These devices are thought of as “set and forget” type of devices. When’s the last time you updated your IP camera or cable modem?
Looking at data from our honeypots during the month of November, we saw a plethora of activity related to a Hadoop YARN exploit described in “Mirai: Not Just For IoT Anymore”.
Within the onslaught of Hadoop YARN requests, we observed a mix of older IoT related vulnerabilities. These vulnerabilities included CVE-2014-8361, CVE-2015-2051, CVE-2017-17215 and CVE-2018-10561. Figure 1 shows the number of unique sources which attempted to exploit these vulnerabilities against our honeypots during the month of November.
Figure 1: Older IoT Vulnerabilities attempts for November 2018
Let’s take a deeper dive into two of these vulnerabilities, CVE-2014-8361 and CVE-2017-17215. The example in Figure 2 shows the use of CVE-2014-8361 to deliver a MIPS variant of Mirai. As we see in the highlighted payload below, the vulnerability uses “wget” to download a copy of the bot and execute it on a vulnerable device. CVE-2014-8361 was publicly disclosed in April of 2015 and has been used in several high profile IoT botnets such as Satori and JenX.
Figure 2: Example of CVE-2014-8361
Figure 3 is an example of CVE-2017-17215, which was used to deliver yet another variant of Mirai. In similar fashion, we see the abuse of “wget” to download the bot and execute it on the vulnerable device.
CVE-2017-17215 was also leveraged in several high profile IoT botnets. This vulnerability was disclosed in December 2017 with a proof of concept published on exploit-db on December 25, 2017.
Figure 3: Example of CVE-2017-17215
As the rate of patching IoT devices is done at a glacial pace, these older vulnerabilities are still leveraged by IoT botnets due to their level of success. The continued use of these tried and true vulnerabilities highlights “what is old is new” when it comes to IoT botnets.
IoT devices sooner or later get patched, but not at the same rate nor priority which we see with operating systems. This makes the longevity and usefulness of IoT based vulnerabilities much longer and very attractive to botnet authors. This trend can be seen within our honeypot data.
Due to the sheer number of IoT devices connected to the internet, finding vulnerable devices is easy and quick. Add to the mix the large delta of when a vulnerable device is “turned on” and when updates for security vulnerabilities are applied, and attackers can quickly amass large botnets. In most cases these botnets are immediately conscripted into a DDoS army. It doesn’t take a significant amount of effort to create a large IoT botnet and create havoc, as we saw with the DDoS attacks conducted by Mirai in 2016.
As we end 2018 and roll in to 2019, we’ll continue to see an uptick in the use of IoT based vulnerabilities. The ease of updating botnet source code like Mirai to take advantage of these vulnerabilities plays a significant role. The ability to create larger botnets with minimal time and resources translates into why we are seeing a trend in the amount of IoT botnets.