Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint

11/7/2016
10:30 AM
Paul Madsen
Paul Madsen
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Changing IoT Passwords Won't Stop Attacks. Here's What Will.

The solution will take an industry-wide effort, it won't happen overnight, and the problem is not the users' fault!

The distributed denial-of-service attack on domain name service provider Dyn that downed Twitter, Spotify, Reddit, and other big websites in October shows that hackers can easily turn millions of connected Internet of Things (IoT) devices into cyber weapons. So far, experts have been advising people to change the default passwords when they install webcams, home routers, and other devices. Putting the onus on users to fix this isn’t fair; the device manufacturers bear significant responsibility.

The solution is to ensure security throughout the IoT environment — from the manufacturer, through the supply chain, into the home setup process, and on through the connection and integration a device has with other devices and apps such as Wi-Fi routers and cloud services. The initial process by which a device is brought into the home, how it's added to the home network, how it's configured, and how security credentials are established will determine the security and privacy of that device over its life cycle. The current reality is that these processes don't implement many security best practices or standards. The industry should take this opportunity to determine a set of best practices and security technologies for this key piece of device life cycle. This will take an industry effort, not just a public service announcement to consumers. And it won’t happen overnight.

Tokens, not Passwords
Changing the password for the interface by which a new device is administered is but one piece of what should happen when a new device is added to the home. The new device needs to be set up with the necessary credentials for accessing relevant networks and applications. How these credentials are issued will have a significant impact on whether or not those devices can operate in a secure and privacy-respecting manner once they start work.

New appliances must be able to connect to the Internet to be "smart," and this is usually done via a Wi-Fi network. Currently, the Wi-Fi password is pushed to the device and stored. That makes it difficult to give different devices customized network access rights, such as only connecting during specific hours. One possible alternative to pushing Wi-Fi credentials to the devices would be to provision a security token to the device that would be used on subsequent authentication to the Wi-Fi router. Applying the OAuth model, the open standard for the authorization method used on websites, to Wi-Fi authentication could present some security advantages, such as when a homeowner wanted to grant access permissions to temporary houseguests.

The devices also need to connect to related cloud apps that let them push data to servers in the cloud. This poses the same authentication problem that the Wi-Fi network does. The device identity needs to be tied to the user for authentication purposes, requiring another set of credentials. For example, the Nest thermostat has to talk to Google APIs in order to report temperatures so the Nest app can learn the heating patterns in the home. The API has to know that Nest is in a specific home and needs to be given a set of credentials specific to the user.

Currently, to authenticate to their cloud APIs, many devices ask the user to provide the password for the affiliated cloud service or app, but this is less than ideal because it increases the places where the password is stored (and so can be compromised). With the OAuth token model, people wouldn't be required to hand out their passwords for one account to be connected to a device. The device doesn’t see the password but uses a token credential to authenticate each time. A user presents the Nest password only to the Nest website, not to the devices that want to push data to the Nest APIs.

Baby Steps
The DDoS attack used older devices — mostly lacking the latest security measures that newer devices have, showing there's been some progress at least. Over the past few years, the industry has made inroads in mitigating the most severe risks associated with using passwords as the sole authentication mechanism. OAuth, OpenID Connect, and Fast IDentity Online (FIDO) are all standards that either supplement or eliminate the need for password-based authentication. We as an industry must do the same for the IoT. Industry groups have already started standardizing the protocols for device-to-device communication, but the proposed mechanisms for authentication and authorization are arguably insufficient. Unlike computers that communicate over HTTP, these connected devices may use protocols more appropriate to their limitations, so industry needs to define how to apply the OAuth model to these other protocols.

This is a critical time for the industry to address this problem or face more and bigger attacks than we’ve seen. Today, it’s hackers turning parts of the Internet dark for a few hours. Tomorrow, it could be attacks on the electrical grid and other critical infrastructure. Attackers are quick to take advantage of the market for new smart devices and homes. The industry needs to be as quick to ensure the ecosystem is secure. 

Related Content:

 

Paul Madsen is a senior technical architect within the Office of the CTO at Ping Identity. Madsen has participated in various design, chairing, editing and education roles for a number of identity standards, including OASIS SAML, the Simple Cloud Identity Management (SCIM), ... View Full Bio
 

Recommended Reading:

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
News
FluBot Malware's Rapid Spread May Soon Hit US Phones
Kelly Sheridan, Staff Editor, Dark Reading,  4/28/2021
Slideshows
7 Modern-Day Cybersecurity Realities
Steve Zurier, Contributing Writer,  4/30/2021
Commentary
How to Secure Employees' Home Wi-Fi Networks
Bert Kashyap, CEO and Co-Founder at SecureW2,  4/28/2021
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
How Enterprises are Developing Secure Applications
How Enterprises are Developing Secure Applications
Recent breaches of third-party apps are driving many organizations to think harder about the security of their off-the-shelf software as they continue to move left in secure software development practices.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2021-31793
PUBLISHED: 2021-05-06
An issue exists on NightOwl WDB-20-V2 WDB-20-V2_20190314 devices that allows an unauthenticated user to gain access to snapshots and video streams from the doorbell. The binary app offers a web server on port 80 that allows an unauthenticated user to take a snapshot from the doorbell camera via the ...
CVE-2021-31916
PUBLISHED: 2021-05-06
An out-of-bounds (OOB) memory write flaw was found in list_devices in drivers/md/dm-ioctl.c in the Multi-device driver module in the Linux kernel before 5.12. A bound check failure allows an attacker with special user (CAP_SYS_ADMIN) privilege to gain access to out-of-bounds memory leading to a syst...
CVE-2021-31918
PUBLISHED: 2021-05-06
A flaw was found in tripleo-ansible version as shipped in Red Hat Openstack 16.1. The Ansible log file is readable to all users during stack update and creation. The highest threat from this vulnerability is to data confidentiality.
CVE-2019-25043
PUBLISHED: 2021-05-06
ModSecurity 3.x before 3.0.4 mishandles key-value pair parsing, as demonstrated by a "string index out of range" error and worker-process crash for a "Cookie: =abc" header.
CVE-2020-18889
PUBLISHED: 2021-05-06
Cross Site Request Forgery (CSRF) vulnerability in puppyCMS v5.1 that can change the admin's password via /admin/settings.php.