Endpoint

12/12/2016
12:12 PM
Mark Baugher
Mark Baugher
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
100%
0%

Whats Naughty & Nice About The Internet Of Things

It's easy to catalogue the worst IoT security hazards. But that's not the whole story.

The press rightly publicizes the worst IoT security hazards, and there’s a hefty catalogue of what’s wrong. The most recent entry on the naughty list is the “IoT-powered DDoS” traffic-flooding attack, where hackers exploit well-known passwords to control insecure connected devices like cameras and use them en masse to disrupt Internet service. Easily exploitable connected devices pollute the public Internet. The situation begs comparison to Ohio’s much-abused Cuyahoga River, which grew so concentrated with industrial sludge that it actually caught fire at least 13 times over the course of a century.

As was the case with the river, the ultimate solution to public Internet pollution problems may be regulation of access to this public resource, but self-correction on the part of industry and the populace also matters. Reputable companies only stay reputable if their products reliably serve their rightful owners. At minimum, reputable suppliers ship non-polluting IoT products — and feature state-of-the-art security, even if the state-of-the-art is not yet all that it needs to be.

What's Wrong with IoT Security: Insecure Onboarding
Shipping a product with a well-known password is not state-of-the-art security. But it’s part of a more general problem that has long plagued IoT: The earliest IoT specifications set contradictory security goals in an attempt to make things easy and spur adoption. One standards group wanted security to be “transparent during setup” and the “best security possible.” Experience has shown that security can be either transparent or the best, but it’s rarely both. To serve transparency, suppliers have used common pre-shared keying material, dispersed keys over networks in plaintext, or shipped with well-known passwords. All are risky practices that are vulnerable to common attacks such as jamming and malware scripts.

In general, some person or provider must take ownership of an Internet-connected device before it commences operation, and too many do a poor job of locking down this initial step. The problem stems from the desire for simple, universal “plug and play” products. Even today, plenty of home routers operate and move packets as soon as you turn them on, even if their well-known passwords remain unchanged. Such a device may work properly for months or years, but is easily accessible to malware from day one. Few consumer routers or IoT devices offer secure plug-and-play — not yet, anyway.

Secure plug-and-play requires a vendor to “pre-provision” a device; for example, provide a factory-provisioned secret, public key, and signed digital certificate stored in a designated cloud account awaiting automatic enrollment. The cloud service automatically and securely associates the device with the user account when the device is plugged in. The service also puts the device under individual user control if done properly. Obviously, the user/owner of the device must trust the cloud provider explicitly for the model to work — and this is a major drawback for some.

The Middle Way: Security Ceremonies
A responsible alternative is to require a security ceremony, so that the user takes ownership and securely associates a device with a local network or cloud account. Typing in a PIN when installing a network camera, router, or other device is a common ceremony, and one of the best. You could argue that forcing the user to do anything (even entering a short number) is not “plug and play” in the literal sense. But provisioning network devices is necessary to prevent pollution: If a provider cannot provision ownership for the user, then the user must assert ownership of the device. This was true before the 2005 specification on UPnP Device Security and it is true today.

Since the root of all evil in IoT security begins with first use of an insecure device, vendors must be somehow compelled to follow best practices in the secure setup of a new device, such as with public-key cryptography, user-supplied input such as a PIN, or other means. Who or how to determine these practices and compel vendors to follow them is not considered here. But we do see the industry defining best practices in the security of both public and proprietary IoT systems such as Z-Wave, ZigBee, HomeKit, and Thread.

What's Improving: Secure Onboarding
Public-key cryptography is being introduced for better IoT security, though not in order to integrate (often low-powered) IoT devices into a public-key infrastructure (like Web clients or servers). Instead, the goal is to securely setup an IoT device prior to operation, which is variously called “onboarding” or “commissioning.” The use of elliptic-curve cryptography (ECC) by Z-Wave, ZigBee, HomeKit, Thread, and other solid IoT standards, solves today’s problem of securely taking ownership of a device like a camera or light bulb before it is activated and before it can be accessed by attackers via the network.

To wit, one of the newer IoT security systems is Z-Wave’s Security 2 (S2), which is in beta. Two of the people who hacked the Z-Wave system, Behrang Fouladi and Sahand Ghanoun, were subsequently recruited to the S2 design team.

S2 improves secure onboarding of new Z-Wave devices by requiring the installer to input a code from the newly introduced device to the Z-Wave gateway. That code is actually part of the public key of the Z-Wave device. Thus, if the gateway vendor decides to cut corners and skip the user input step, the S2 devices won’t work together. The user must supply part of the public key. Without that input, the key is unusable and the device can’t be commissioned into service.

The introduction of public-key cryptography is one small improvement to IoT security, but an important one. Public standards bodies, software developers, and IoT vendors have an important role to play in promoting best practices, which may greatly reduce the power of IoT botnets and ease our pollution problems.

Related Content:

 

 

Mark Baugher is the principal security engineer at Greenwave Systems, a leading international IoT software provider and services integrator partnering with Verizon, NXP, IBM, E.On, and others. Mark is a highly regarded IoT security engineer having created and patented ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
richa_gangwani
50%
50%
richa_gangwani,
User Rank: Apprentice
12/20/2016 | 2:05:35 AM
Good one
Good one! Thank you for sharing such an informative content.

It's my pleasure to inform you about BetaPage (https://betapage.co/) it is a startup directory where you can discover, hunt and upvote on various innovative startups as per your choice.
rayray2016
50%
50%
rayray2016,
User Rank: Apprentice
12/13/2016 | 1:01:23 PM
The 3 Week Diet Reviewsx
I have subscribed to the newsletter. thanks
rayray2016
50%
50%
rayray2016,
User Rank: Apprentice
12/13/2016 | 12:59:46 PM
The 3 Week Diet Reviewsx
I have subscribed to the newsletter. thanks
rayray2016
50%
50%
rayray2016,
User Rank: Apprentice
12/13/2016 | 12:53:56 PM
Re: Twenty Motion
I think thats a classy way to do it
Mark.Baugher
50%
50%
Mark.Baugher,
User Rank: Author
12/13/2016 | 8:54:42 AM
Re: Standards and passwords
The http://www.csoonline.com/article/3148695/security/netgear-working-to-fix-flaw-that-left-thousands-of-devices-open-to-attack.html hack is an example from a company that has long had automated firmware update and one of the better onboarding/commissioning process for the line of home routers I tested in the past.
kbannan100
50%
50%
kbannan100,
User Rank: Apprentice
12/12/2016 | 8:26:37 PM
Standards and passwords
We are at a time that reminds me of when people first realized that printers were a huge target -- and a security risk. While they still are, vendors and users alike are doing things that make them less of a target over the long run. Things like constantly updating firmware, building in self-healing and self-monitoring protection and turning off things like FTP are big leaps ahead for everyone involved. 

--Karen Bannan for IDG and HP
12 Free, Ready-to-Use Security Tools
Steve Zurier, Freelance Writer,  10/12/2018
Most IT Security Pros Want to Change Jobs
Dark Reading Staff 10/12/2018
6 Security Trends for 2018/2019
Curtis Franklin Jr., Senior Editor at Dark Reading,  10/15/2018
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Flash Poll
The Risk Management Struggle
The Risk Management Struggle
The majority of organizations are struggling to implement a risk-based approach to security even though risk reduction has become the primary metric for measuring the effectiveness of enterprise security strategies. Read the report and get more details today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2018-10839
PUBLISHED: 2018-10-16
Qemu emulator <= 3.0.0 built with the NE2000 NIC emulation support is vulnerable to an integer overflow, which could lead to buffer overflow issue. It could occur when receiving packets over the network. A user inside guest could use this flaw to crash the Qemu process resulting in DoS.
CVE-2018-13399
PUBLISHED: 2018-10-16
The Microsoft Windows Installer for Atlassian Fisheye and Crucible before version 4.6.1 allows local attackers to escalate privileges because of weak permissions on the installation directory.
CVE-2018-18381
PUBLISHED: 2018-10-16
Z-BlogPHP 1.5.2.1935 (Zero) has a stored XSS Vulnerability in zb_system/function/c_system_admin.php via the Content-Type header during the uploading of image attachments.
CVE-2018-18382
PUBLISHED: 2018-10-16
Advanced HRM 1.6 allows Remote Code Execution via PHP code in a .php file to the user/update-user-avatar URI, which can be accessed through an "Update Profile" "Change Picture" (aka user/edit-profile) action.
CVE-2018-18374
PUBLISHED: 2018-10-16
XSS exists in the MetInfo 6.1.2 admin/index.php page via the anyid parameter.