Attacks/Breaches
10/13/2016
10:30 AM
Daniel Riedel
Daniel Riedel
Commentary
Connect Directly
Twitter
LinkedIn
Google+
RSS
E-Mail vvv
100%
0%

IoT Default Passwords: Just Don't Do It

The rise of the Internet of Things makes the use of default passwords especially perilous. There are better options.

Earlier this month, an underground forum released the code for the Mirai malware, which lets attackers hijack the thousands (and counting) of Internet of Things devices that are used to carry out distributed denial-of-service attacks.

Panic ensued.

Of course it did. This hack means that everyone can now view the code that allowed someone using the name Anna-senpai to harness 380,000 bots via weak telnet connections. Let's ignore for now that in 2016 there is absolutely no reason to have telnet on any IoT device.

That aside, much of the subsequent hand-wringing over default password damage control missed the one glaring thing that manufacturers, startups, and providers can do to prevent this sort of devastating vulnerability: Don't use default usernames and passwords in the first place.

The most common reasons for using default usernames and passwords boil down into a few key arguments (when you leave out "we've always done it this way," which I won't even dignify with a response because I know if you're reading this, that's not an argument you care about).

Users should reset the username and password when they get a device. Philosophically, they should. In reality, do they? No, they don't. This is putting your device security into the hands of human nature, which runs directly counter to high security by always looking for the path of least resistance.

It costs more. Let's be real: It probably will cost more up front. But the more important question is whether that investment is worth preventing a likely future debilitating attack on your network, your company, your customers, and your brand. Cyberattackers are becoming more sophisticated by the second, and as the Dark Reading audience knows, we've passed the time for "if" and moved into "when" as it relates to being attacked. It's a common argument for any cybersecurity investment, but it bears repeating because so many organizations will want their team to stick with the username/password formula.

It takes more time. Again, that's true. But the good news is that the technology exists today to make default passwords on IoT devices obsolete. It's not even a herculean undertaking; your engineers could implement the fixes below in a matter of weeks:

  • Fix 1: Tie device security to a globally unique identifier, or key that would be a different code for each device ensuring that someone can’t guess the password for the device. This isn't ideal, but it's miles better than the admin/password approach.
  • Fix 2: Generate a one-time password that a user is forced to reset as part of setting up a device. If there is a reliance on the user anyway to reset a password, at least make it mandatory.
  • Fix 3: Create a shared certificate that is used with the device that needs to pair with the IoT device in question, perhaps using the "trust on first use" principle (which locks the device to the network or application upon first use) or Apple/Android's authentication platform. Similar approaches could be devised through OAuth, public key infrastructure, or other key exchanges, which give the ability to create a handshake upon installing the device.
  • Fix 4 (and the best, in my opinion): We build an industry standard for IoT authentication that is tested by the best minds in the world in infrastructure, security, and manufacturing. As IEEE points out, several of its standards address security elements that are applicable to IoT devices. These include IEEE P1363, a standard for public key cryptography; IEEE P1619, which addresses encryption of data on fixed and removable storage devices; IEEE P2600, a standard that addresses the security of printers, copiers, and similar devices; and IEEE 802.1AE and IEEE 802.1X, which address Media Access Control Security (MACsec).

Linksys has at least made headway with its WPA2 passwords being unique on each device. So the market is learning, but not fast enough.

The bottom line is that IoT isn't going anywhere. We'll soon live in a world with billions of devices that will do everything from watch your cat to measure your REM sleep. With a little effort, your organization can be at the forefront of protecting these devices, all while breaking the seemingly endless cycle of username and password vulnerability.

Related Content:

Daniel Riedel is the CEO of New Context, a systems architecture firm founded to optimize, secure, and scale enterprises. New Context provides systems automation, cloud orchestration, and data assurance through software solutions and consulting. Daniel has experience in ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Janice, I think I've got a message from the code father!
Current Issue
Security Operations and IT Operations: Finding the Path to Collaboration
A wide gulf has emerged between SOC and NOC teams that's keeping both of them from assuring the confidentiality, integrity, and availability of IT systems. Here's how experts think it should be bridged.
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-2017-0290
Published: 2017-05-09
NScript in mpengine in Microsoft Malware Protection Engine with Engine Version before 1.1.13704.0, as used in Windows Defender and other products, allows remote attackers to execute arbitrary code or cause a denial of service (type confusion and application crash) via crafted JavaScript code within ...

CVE-2016-10369
Published: 2017-05-08
unixsocket.c in lxterminal through 0.3.0 insecurely uses /tmp for a socket file, allowing a local user to cause a denial of service (preventing terminal launch), or possibly have other impact (bypassing terminal access control).

CVE-2016-8202
Published: 2017-05-08
A privilege escalation vulnerability in Brocade Fibre Channel SAN products running Brocade Fabric OS (FOS) releases earlier than v7.4.1d and v8.0.1b could allow an authenticated attacker to elevate the privileges of user accounts accessing the system via command line interface. With affected version...

CVE-2016-8209
Published: 2017-05-08
Improper checks for unusual or exceptional conditions in Brocade NetIron 05.8.00 and later releases up to and including 06.1.00, when the Management Module is continuously scanned on port 22, may allow attackers to cause a denial of service (crash and reload) of the management module.

CVE-2017-0890
Published: 2017-05-08
Nextcloud Server before 11.0.3 is vulnerable to an inadequate escaping leading to a XSS vulnerability in the search module. To be exploitable a user has to write or paste malicious content into the search dialogue.

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.