IoTSec:The Denial of Service Attack from IoT devices

= The Denial of Service Attack from IoT devices=

Recent IoT­based botnet attacks on Dyn in the USA (mid Oct 2016) and Liberia (4 Nov 2016) were originated by estimated 100.000 infected Internet of Things (IoT) devices. These devices were e.g. surveillance (CCTV) cameras, video-recorders, and set­top boxes. The question addressed in this blog is which consequences we can draw from these attacks, and what we can do against them.

The changing world through IoT
Devices have started to make our life easier and more comfortable. In order to check the weather, we can look at out app or request the data from an outdoor thermometer. Our TV recorder can be controlled from remote places, and we can even remotely open the door of our garage or our house. Needless to say, the surveillance camera provides us with pictures and videos of what is going on today.

However, the networked home has also opened for security threats. Jonathan Margulies has performed a case study addressing security issues using the door opener as an example. Other security experts have pointed out the challenge of open IP addresses for e.g. home automation and surveillance, as they might become entry doors for attacks. The recent (Oct/Nov 2016) attacks from IoT devices on both the DNS provider Dyn in the USA, and the attack on the Internet in Libera happened from IoT devices, which were not properly secured. In most of the cases, users have just installed e.g. a surveillance camera, without changing the username/password, or by using extremely easy passwords like “1111” or “1234”.

How IoT devices attacked the Internet
Having installed a device with an open IP address, which in addition announces itself to the Internet, gives everyone an entry point to see the outcome of the device. This might indeed be useful, as open WebCams provide the view of the landscape in some remote areas. For us in Norway, it’s always nice to check the snow conditions close to our hut.

However, having access to the address of the device will often allow access to the device itself. As an example, a Web cam might have the address http://MyWebCam.no. Knowing the camera model, one might find out that the administration of the camera is performed through http://MyWebCam.no/admin. And through the administration page we can try to login using standard usernames and passwords, e.g. admin, admin or root, root. The problem is not new, Tom Connor mentioned in an article in 2011 how Google can be used to find a list of open Web cams using specific search words .

Thus, creating a tool which scans for open devices, and tries to login to these devices is easy to create. The attackers on Dyn and Liberia used the Mirai toolkit. The toolkit : Having installed the service on some 100.000 machines, the attacker can then ask all machines to “request” a specific service, e.g. the Web page of the New York Times.
 * searches for devises with open IP addresses,
 * identifies the device type, e.g. CCTV camera,
 * tries the standard username and password for the device, e.g. admin, 1111 and some variants, and
 * installs a service which can be remotely controlled, e.g. a request to a specific web page.

The attack on Dyn was so successful, as it hit the heart of translating from a web address like www.google.com to an IP address, e.g. 216.58.196.100. Companies like PayPal, Amazon and other IP-specialist companies. Loshin reports that the attack had a data-rate of up to 1.2 Tbps, which is 1200 Gbps, and that the servers could not handle that attack, hence denial of service (DOS) attack. In comparison 4G LTE networks offer top speeds in the range of 20-50 Mbps. The attack on Liberia was seen as a test to take down a country.

Given the power of the attack, and the possibility that the attack will be targeted towards critical state infrastructures such as hospitals, police headquarters, or governmental servers, shows the criticality of the attack.

= Lessons learned from the IoT attack=

The straight forward solution is that we need better installation routines and controls of IoT devices, especially when including devices to our home Wifi network and make them become available over the Internet. Thus, we suggest novel mechanisms to include IoT devices in a secure way into the network.

Margulies points out that 2-factor authentication, policy-based access controls and a more granular alert system might be needed to have appropriate security. Regarding the access control to the home door, he provided examples for the useful policies, addressing:
 * allowing multiple user accounts to control the door, but only one to administer it;
 * allowing administration from specific devices only;
 * restricting certain accounts (such as caregiver or contractor) to operating the door only during business hours; and
 * creating time-limited guest accounts.

We can’t stop DoS attacks, but we might be able to make them more difficult. Hamann and Kohlenberg point out three factors, which are extended here:
 * IoT device must have better security mechanism, even if they are just cheap consumer articles. In IoTSec.no we talk about measurable security and suggest security classes, which would allow customers to buy class A devices.
 * A better collaboration between Nations to block IP addresses from infected IoT devices, and mechanisms to filter attacks coming in from those IP addresses.
 * An international agreement against CyberCrime.

One might extend the list with tools allowing for checking IoT devices for vulnerability, e.g. a Mirai-type of tool listing all vulnerable devices and informs the owners to apply better security.

Our conclusion from IoTSec.no is that information about these attacks should be made available, leading to better awareness and better security devices.

=References=