This paper is included in the Proceedings of the 26th usenix security Symposium August 16–18, 2017 • Vancouver, bc, Canada

Automatic updates

Automatic updates — already

canonical in the desktop and mobile operating system

space — provide developers a timely mechanism to patch

bugs and vulnerabilities without burdening consumers

with maintenance tasks or requiring a recall. Automatic

updates require a modular software architecture by de-

sign to securely overwrite core modules with rollback

capabilities in the event of a failure. They also require

cryptographic primitives for resource-constrained devices

and building PKI infrastructure to support trusted updates.

Apart from these challenges, patching also requires the

IoT community to actively police itself for vulnerabilities,

a potentially burdensome responsibility given the sheer

diversity of devices. Bug bounties can help in this respect:

roughly 25% of all vulnerabilities patched by Chrome

and Firefox came from bug bounties in 2015 [28], while

Netgear launched a bug bounty for its router software in

January, 2017 [75]. In the event of a zero-day exploit that

disables automatic updates, IoT developers must provide

a secure fallback mechanism that likely requires physical

access and consumer intervention.

The Deutsche Telekom infection and subsequent fix

provide an excellent case study of this point. DT’s routers

had a vulnerability that enabled the botnet to spread via its

update mechanism, which provides a reminder that basic

security hardening should be the first priority. However,

since DT did have an automatic update mechanism, it was

also able to patch devices rather swiftly, requiring mini-

mal user intervention. Implementing automatic updates

on IoT devices is not impossible, but does take care to do

correctly.

Notifications

Notifications via out-of-band channels

serve as a fallback mechanism to bring devices back into

security compliance or to clear infections. Recent ex-

amples include alerting device administrators via CERT

bulletins, emailing the abuse contact in WHOIS records,

and in-browser warnings to site owners that a page is

compromised [24, 56, 57]. Notifications in the IoT space

are complicated to say the least. IoT devices lack both a

public indication of ownership and an established com-

munication channel to reach consumers. Were consumers

reachable, there must also be a clear and simple update

path to address the problem. As a minimum alternative,

IoT devices could be required to register an email address

with the manufacturer or with a unified, interoperable

monitoring platform that can alert consumers of serious

issues. This is a space where IoT requires non-technical

intervention. The usability challenge of acting on notifi-

cations remains an open research problem.

Facilitating device identification

Even when device

models or firmware versions are known to be vulnerable,

detecting such devices on the network can be extremely

difficult. This made our investigation more challenging,

but it also makes it hard for network operators to detect

vulnerabilities in their or their customers’ devices. To

mitigate this, IoT manufacturers could adopt a uniform

way of identifying model and firmware version to the

network — say, encoding them in a portion of the device’s

MAC address. Disclosing this information at layer 2

would make it visible to local network operators (or to

the user’s home router), which could someday take auto-

mated steps to disable remote access to known-vulnerable

hardware until it is updated. Achieving this in a uniform

way across the industry would likely require the adoption

of standards.

Defragmentation

Fragmentation poses a security (and

interoperability) risk to maintaining and managing IoT de-

vices. We observed numerous implementations of Telnet,

FTP, and HTTP stacks during scanning. The IoT commu-

nity has responded to this challenge by adopting a handful

of operating systems, examples of which include Android

Thing, RIOT OS, Tock, and Windows for IoT [30]. This

push towards defragmentation would abstract away the

security nuances required of our prescriptive solutions.

End-of-life

Even with security best practices in mind,

end-of-life can leave hundreds of thousands of in-use IoT

devices without support. Lack of long-term support will

yield a two class system of protected and unprotected

devices similar to the current state of Windows XP ma-

chines [63]. Over time, the risk that these devices pose to

the Internet commons will only grow unless taken offline.

8

Related Work

Since as early as 2005, the security community has

been working to understand, mitigate, and disrupt bot-

nets [17]. For example, Zand et al. proposed a detection

method based on identifying command and control sig-

natures [97], and Gu et al. focused on analyzing network

traffic to aid in detection and mitigation [32, 33]. Unfortu-

nately, mitigation remains a difficult problem as botnets

often evolve to avoid disruption [6].

This work follows in a long line studies that have ana-

lyzed the structure, behavior, and evolution of the botnet

ecosystem [12,37,76,84,85,91,96]. Bailey et al. note that

each technique used in understanding botnets has a unique

set of trade offs, and only by combining perspectives can

we fully analyze the entire picture [11]. This observation

and the seminal work of Rajab et al., implicating botnet

activity in 27% of all network telescope traffic, inspire

our approach [2].

Botnets have historically been used to launch DDoS

attacks, and there exists a parallel set of studies focusing

on characterizing and defending against these attacks [66,

67], as well as estimating their effect [69]. In response to

the recent growth of amplification attacks, there have been

USENIX Association

26th USENIX Security Symposium    1107

---