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
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
New Free Tool Scans for Chrome Extension Safety
Dark Reading Staff 2/21/2019
Making the Case for a Cybersecurity Moon Shot
Adam Shostack, Consultant, Entrepreneur, Technologist, Game Designer,  2/19/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Emerging Cyber Threats to Watch for in 2019
Online attackers are constantly developing new, innovative ways to break into the enterprise. This Dark Reading Tech Digest gives an in-depth look at five emerging attack trends and exploits your security team should look out for, along with helpful recommendations on how you can prevent your organization from falling victim.
Flash Poll
How Enterprises Are Attacking the Cybersecurity Problem
How Enterprises Are Attacking the Cybersecurity Problem
Data breach fears and the need to comply with regulations such as GDPR are two major drivers increased spending on security products and technologies. But other factors are contributing to the trend as well. Find out more about how enterprises are attacking the cybersecurity problem by reading our report today.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-6485
PUBLISHED: 2019-02-22
Citrix NetScaler Gateway 12.1 before build 50.31, 12.0 before build 60.9, 11.1 before build 60.14, 11.0 before build 72.17, and 10.5 before build 69.5 and Application Delivery Controller (ADC) 12.1 before build 50.31, 12.0 before build 60.9, 11.1 before build 60.14, 11.0 before build 72.17, and 10.5...
CVE-2019-9020
PUBLISHED: 2019-02-22
An issue was discovered in PHP before 5.6.40, 7.x before 7.1.26, 7.2.x before 7.2.14, and 7.3.x before 7.3.1. Invalid input to the function xmlrpc_decode() can lead to an invalid memory access (heap out of bounds read or read after free). This is related to xml_elem_parse_buf in ext/xmlrpc/libxmlrpc...
CVE-2019-9021
PUBLISHED: 2019-02-22
An issue was discovered in PHP before 5.6.40, 7.x before 7.1.26, 7.2.x before 7.2.14, and 7.3.x before 7.3.1. A heap-based buffer over-read in PHAR reading functions in the PHAR extension may allow an attacker to read allocated or unallocated memory past the actual data when trying to parse the file...
CVE-2019-9022
PUBLISHED: 2019-02-22
An issue was discovered in PHP 7.x before 7.1.26, 7.2.x before 7.2.14, and 7.3.x before 7.3.2. dns_get_record misparses a DNS response, which can allow a hostile DNS server to cause PHP to misuse memcpy, leading to read operations going past the buffer allocated for DNS data. This affects php_parser...
CVE-2019-9023
PUBLISHED: 2019-02-22
An issue was discovered in PHP before 5.6.40, 7.x before 7.1.26, 7.2.x before 7.2.14, and 7.3.x before 7.3.1. A number of heap-based buffer over-read instances are present in mbstring regular expression functions when supplied with invalid multibyte data. These occur in ext/mbstring/oniguruma/regcom...