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
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
5 Security Technologies to Watch in 2017
Emerging tools and services promise to make a difference this year. Are they on your company's list?
Flash Poll
New Best Practices for Secure App Development
New Best Practices for Secure App Development
The transition from DevOps to SecDevOps is combining with the move toward cloud computing to create new challenges - and new opportunities - for the information security team. Download this report, to learn about the new best practices for secure application development.
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-7445
Published: 2015-10-15
The Direct Rendering Manager (DRM) subsystem in the Linux kernel through 4.x mishandles requests for Graphics Execution Manager (GEM) objects, which allows context-dependent attackers to cause a denial of service (memory consumption) via an application that processes graphics data, as demonstrated b...

CVE-2015-4948
Published: 2015-10-15
netstat in IBM AIX 5.3, 6.1, and 7.1 and VIOS 2.2.x, when a fibre channel adapter is used, allows local users to gain privileges via unspecified vectors.

CVE-2015-5660
Published: 2015-10-15
Cross-site request forgery (CSRF) vulnerability in eXtplorer before 2.1.8 allows remote attackers to hijack the authentication of arbitrary users for requests that execute PHP code.

CVE-2015-6003
Published: 2015-10-15
Directory traversal vulnerability in QNAP QTS before 4.1.4 build 0910 and 4.2.x before 4.2.0 RC2 build 0910, when AFP is enabled, allows remote attackers to read or write to arbitrary files by leveraging access to an OS X (1) user or (2) guest account.

CVE-2015-6333
Published: 2015-10-15
Cisco Application Policy Infrastructure Controller (APIC) 1.1j allows local users to gain privileges via vectors involving addition of an SSH key, aka Bug ID CSCuw46076.

Dark Reading Radio
Archived Dark Reading Radio
In past years, security researchers have discovered ways to hack cars, medical devices, automated teller machines, and many other targets. Dark Reading Executive Editor Kelly Jackson Higgins hosts researcher Samy Kamkar and Levi Gundert, vice president of threat intelligence at Recorded Future, to discuss some of 2016's most unusual and creative hacks by white hats, and what these new vulnerabilities might mean for the coming year.