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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 9/25/2020
Hacking Yourself: Marie Moe and Pacemaker Security
Gary McGraw Ph.D., Co-founder Berryville Institute of Machine Learning,  9/21/2020
Startup Aims to Map and Track All the IT and Security Things
Kelly Jackson Higgins, Executive Editor at Dark Reading,  9/22/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Special Report: Computing's New Normal
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
How IT Security Organizations are Attacking the Cybersecurity Problem
How IT Security Organizations are Attacking the Cybersecurity Problem
The COVID-19 pandemic turned the world -- and enterprise computing -- on end. Here's a look at how cybersecurity teams are retrenching their defense strategies, rebuilding their teams, and selecting new technologies to stop the oncoming rise of online attacks.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15208
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, when determining the common dimension size of two tensors, TFLite uses a `DCHECK` which is no-op outside of debug compilation modes. Since the function always returns the dimension of the first tensor, malicious attackers can ...
CVE-2020-15209
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, a crafted TFLite model can force a node to have as input a tensor backed by a `nullptr` buffer. This can be achieved by changing a buffer index in the flatbuffer serialization to convert a read-only tensor to a read-write one....
CVE-2020-15210
PUBLISHED: 2020-09-25
In tensorflow-lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, if a TFLite saved model uses the same tensor as both input and output of an operator, then, depending on the operator, we can observe a segmentation fault or just memory corruption. We have patched the issue in d58c96946b and ...
CVE-2020-15211
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 1.15.4, 2.0.3, 2.1.2, 2.2.1 and 2.3.1, saved models in the flatbuffer format use a double indexing scheme: a model has a set of subgraphs, each subgraph has a set of operators and each operator has a set of input/output tensors. The flatbuffer format uses indices f...
CVE-2020-15212
PUBLISHED: 2020-09-25
In TensorFlow Lite before versions 2.2.1 and 2.3.1, models using segment sum can trigger writes outside of bounds of heap allocated buffers by inserting negative elements in the segment ids tensor. Users having access to `segment_ids_data` can alter `output_index` and then write to outside of `outpu...